Was sollte ein IT-Spezialist im Jahr 2020 vermeiden?

Habr ist voller Prognosen und Tipps dazu, was im nächsten Jahr zu tun ist – welche Sprachen zu lernen, in welche Bereiche man investieren sollte, wie man mit seiner Gesundheit umgehen kann. Das klingt inspirierend! Doch jede Medaille hat zwei Seiten, und wir stolpern nicht nur über Neues, sondern hauptsächlich über das, was wir jeden Tag tun. „Warum hat mich denn niemand gewarnt!“, rufen wir oft verärgert, wenn wir uns selbst ansprechen. Wir ziehen den Fokus auf uns – daher haben wir eine Liste zusammengestellt, was man im Jahr 2020 (oder vielleicht immer) NICHT tun sollte. 

Und die Schwerkraft hat man nicht gefragt.

Wir würden sehr gerne die Anti-Empfehlungen der Reihe nach auflisten, von den wichtigsten bis zu den weniger bedeutenden. Doch sie sind so verbreitet, gleichwertig und fast jedem bekannt, dass wir sie durcheinander schreiben werden. Also, überprüfen wir die Liste?

Man sollte nicht in die IT-Branche gehen, wenn alles gut läuft.

Verlassen Sie sich nicht darauf, eine neue Technologie zu lernen, um den Beruf zu wechseln oder von vorne zu beginnen. Unsere Zeit bietet die Möglichkeit, sich weiterzubilden, den Job zu wechseln oder sogar das Berufsfeld zu ändern – und das bis zur Rente. Es ist eine spannende und verführerische Option. Aber wenn Sie über 28-30 Jahre alt sind, sollten Sie nicht alles aufgeben, nur um in die IT einzusteigen oder in einen neuen Technologiestack zu wechseln (zum Beispiel von der Entwicklung hochbelasteter Systeme in Java zu neuronalen Netzwerken in Python). Der Grund ist einfach: Es wird nicht leicht sein. Erstens besteht eine hohe Konkurrenz von Spezialisten, die seit Beginn ihrer Karriere in diesem Technologiestack arbeiten. Zweitens müssen Sie wieder als Junior mit einem niedrigen Gehalt anfangen. Drittens wird es moralisch herausfordernd sein, sich als unterster Mitarbeiter in der Hierarchie wiederzufinden. Daher, wenn Sie in eine andere Richtung gehen möchten, versuchen Sie, dies entweder im Rahmen Ihrer aktuellen Arbeit und Aufgaben zu tun, oder entwickeln Sie neue Kenntnisse als Hobby, arbeiten Sie an einem Nebenprojekt, um bei einem neuen Job nicht mehr als Junior einzusteigen. 

Den Technologie-Stack zu wechseln – verschwendete Zeit.

Wechseln Sie nicht ständig zwischen Technologiestacks für Ihre Entwicklung. Wenn Sie ein Projekt in einer Sprache schreiben und ein bestimmtes Framework sowie Bibliotheken verwenden, sollten Sie nicht alles über den Haufen werfen und auf Dart umsteigen, nur weil es Ihnen interessant erscheint. Gewöhnen Sie sich an, eine fundierte Begründung für den Technologiewechsel zu finden — das sollte nicht nur auf der Ebene von "Ich will nicht" basieren, sondern auch finanziell und ingenieurtechnisch sinnvoll sein. 

Es ist nicht nötig, stur zu bleiben und in Ihrer Meinung zu verharren.

An einer einzigen Sprache oder Technologie festzuhalten und sich nicht mit Neuem auseinanderzusetzen, ist genauso extrem wie bei jeder neuen Technologie den Stack zu ändern. Lernen Sie unbedingt neue Bibliotheken und Frameworks kennen; seien Sie nicht stur in der Überzeugung, dass alles, was gedacht wurde, bereits vor Ihnen existierte und ausschließlich von Ihnen perfektioniert wurde. Praktisch für jede Sprache erscheinen ständig Updates, die Ihr Projekt erheblich verbessern können. Faulenzen Sie nicht, wenn es um die Dynamik Ihres Stacks geht, und wenn Sie etwas Cooles und Nützliches finden, bringen Sie es mutig in Ihr Projekt!

Der eigene Verstand ist gut, immer gut.

Denken Sie selbst und nicht wie andere. Die eigenen Ideen sind immer besser. Leider gibt es Entwickler, die darauf warten, dass ihnen eine Aufgabe zugeteilt wird, und die nicht versuchen, etwas Eigenes in ein Projekt einzubringen, eine neue Funktion zu entwickeln, diese zu testen und sie in die Produktion zu bringen. Warum sich anstrengen, wenn es einen Teamleiter oder Unternehmensleiter gibt, der alles für einen entscheidet? Wenn Sie sich hier wiedererkennen, haben wir schlechte Nachrichten: Eine passive Haltung wird Ihnen weder in der Karriere noch in Ihrer Entwicklung helfen. Sie haben die Chance, sich als Software-Ingenieur und nicht als reiner Programmierer in einem echten Projekt auszuprobieren und herauszufinden, wohin Sie sich entwickeln sollten und was Ihnen fehlt. Stattdessen ziehen Sie es vor, Ihre Zeit mit anderen Dingen zu verbringen und „nur das Nötigste“ zu erledigen. Solche Menschen haben es in der modernen IT immer schwerer, also befreien Sie sich aus dem Anästhesiezustand. 

Benutzer sind furchterregende Menschen

Überschätzen Sie die Nutzer Ihrer Software nicht: Wenn Sie nicht für Programmierer schreiben, müssen Sie damit rechnen, dass Ihr Programm auf unverständnisvolle Reaktionen stößt. In den ersten Tagen oder Wochen wird der Nutzer Ihre Software hassen, weil "die alte nicht so dumm war". Um dies zu vermeiden, erstellen Sie eine anspruchsvolle Dokumentation und Schulungsmaterialien. Bei der Installation oder dem Kauf sollten Sie nachdrücklich darauf hinweisen, dass die Handbücher vor Beginn der Arbeit mit dem Programm gelesen werden sollten, nicht erst nach dem Absturz der Datenbank, dem Verlust des Passworts und dem Verlust der Selbstkontrolle.

Man sollte die Nutzer nicht unterschätzen: Sie sind schlauer, intelligenter und neugieriger, als man denkt. Wenn Sie glauben, dass der Fehler mit dem Variablenformat und die Ausnahme beim 138. Drücken der Enter-Taste mit einem Intervall von einer Sekunde nicht auftauchen werden, liegen Sie falsch – sie werden auftauchen und die Funktionalität Ihrer Anwendung auf die seltsamste Weise beeinflussen. Es gilt die Regel des Amateurs: Er macht die besten Tests. Aber die Nutzer mögen es aus irgendwie nicht, Bugs in der Produktion zu finden – keine IT-Solidarität. Kurz gesagt, je mehr Vertrauen Sie in Ihre Software haben, desto besser. Schließlich ist es besser, die Veröffentlichung einiger Funktionen zu verzögern, als sie in eine funktionierende Anwendung einzufügen und sie plötzlich unausgereift zu machen.

Genug gegoogelt!

Hören Sie auf, sich nur auf Google zu verlassen. Das ist nicht einmal eine Diskussion wert – im Bereich der Entwicklung können Sie durch direkte Anfragen an Suchmaschinen eine Menge finden. Je tiefer Sie in Ihrer Informationssuche graben, desto mehr „Nebeninformationen“ erhalten Sie und desto mehr erfahren Sie, da Sie Neues entdecken, das nicht direkt mit Ihrer Anfrage zu tun hat, aber in der Zukunft von Nutzen sein könnte. Nutzen Sie umfassende Materialien, Bücher, Artikel usw. Programmiersprachen und Bibliotheken haben Spezifikationen, Communities, Anleitungen, und so erhalten Sie den zuverlässigsten Weg, Ihre Programmierfähigkeiten zu entwickeln – indem Sie einfach die Dokumentation lesen, anstatt nach lokalen Lösungen und Codefragmenten zu suchen. Vielleicht wird Ihre Lösung effizienter, schneller und besser sein? 

Vertrauen ist gut, Kontrolle ist besser

Verwenden Sie keine Bibliotheken und Frameworks von Drittanbietern, ohne den Code zu überprüfen und ihn an Ihre Bedürfnisse anzupassen. Sie haben keinen Grund, diesem Code-Autor, den Sie nicht kennen, bedingungslos zu vertrauen. Ja, absichtlich schädliche Elemente im Code von Dritten sind nicht so häufig, und es ist nicht nötig, paranoid zu sein. Dennoch kann das blinde Kopieren von fertigen Softwareteilen in Ihr Projekt zu unvorhersehbaren Folgen führen. Daher sollten Sie den Code unbedingt lesen und analysieren, bevor Sie ihn verwenden, und Tests nach der Implementierung durchführen. 

Machen Sie Backups!

Hören Sie auf, keine Backups zu machen oder sie auf denselben externen Servern zu speichern, auf denen Ihr Projekt gehostet wird. Denken Sie, das ist ein absurd und unnötiger Ratschlag? Doch mehr als 700 Teilnehmer des Telegram-Chats, die in eine unangenehme Situation mit der Stilllegung eines bekannten Rechenzentrums geraten sind, denken anders — es gab alles Mögliche: von kleinen Projekten bis hin zu großen Websites von Regierungsbehörden und Unternehmensdatenbanken für 1C und Abrechnung. Ein erheblicher Teil — ohne Backups oder mit Backups auf denselben Servern. Verteilen Sie also die Risiken und speichern Sie ein Backup mindestens auf Ihrem Haupt-Hosting, auf einem zuverlässigen VDS und auf Ihrem lokalen Server. Am Ende wird es viel günstiger sein. 

Hören Sie auf, Ihr Projekt zu gefährden.

Führen Sie in Ihrem Arbeitsprojekt nicht aus, was Sie möchten, sondern das, was Ihre Kunden benötigen. Ja, es ist unglaublich spannend, ein eigenes neuronales Netzwerk zu erstellen, es zu trainieren und in Ihre Software zu integrieren, aber wenn Ihre Kunden ein einfaches Kontaktmanagementsystem benötigen, wäre das ein teurer Luxus. Schauen Sie sich an, wie das Projekt funktioniert, lesen Sie die Dokumentation, die Bewertungen und Anfragen von Kunden und setzen Sie das um, was dem Projekt geschäftlichen Mehrwert verleiht. Wenn Sie etwas Wissenschaftliches oder besonders Komplexes erschaffen möchten, starten Sie mit Ihrem eigenen Projekt.

Nicht der Code, sondern ein Nervenbündel

Schreiben Sie keinen unleserlichen und undokumentierten Code. Wir kennen dieses Phänomen: Ein Entwickler schreibt Code, wie es ihm gefällt, und verkompliziert ihn absichtlich ein wenig, damit niemand aus dem Team seinen Gedankengang nachvollziehen kann — eine Art präventive Rache, bevor etwas schiefgeht. Doch damit setzen Sie nicht nur das Unternehmen (das Ihnen für Ihre Arbeit zahlt) aufs Spiel, sondern auch sich selbst: Es ist durchaus möglich, dass Sie selbst nicht mehr wissen, was Sie mit dieser unbeabsichtigten Obfuskation ausdrücken wollten. Das Gleiche gilt für unzureichend dokumentierten Code: Wenn Sie sich auf Ihre Namensgebung von Variablen und Funktionen und Ihr gutes Gedächtnis verlassen, könnten Sie in ein paar Jahren nicht mehr wissen, warum Sie diese Schleife, Methode, dieses Muster usw. gewählt haben. Eine Dokumentation des Codes und seine gute Struktur sind ein wertvoller Service für Kollegen, Arbeitgeber und vor allem für sich selbst. 

Halten Sie es einfach, Dumme

Komplizieren Sie nicht den Code, Lösungen und Projekte. Es ist nicht nötig, komplexe Strukturen zu schaffen und bedeutungslose Entitäten zu erzeugen. Je komplizierter Ihr Code ist, desto mehr wird er zu Ihrer Fessel — es wird extrem schwierig sein, ihn zu warten und weiterzuentwickeln. Natürlich passt das berühmte Prinzip KISS („Keep it simple, stupid“) nicht immer, aber es hat seinen Grund: Einfachheit und Eleganz des Codes sind der Schlüssel zu erfolgreichem Einsatz und Wiederverwendbarkeit.

Schützen Sie sich

Ignorieren Sie die Sicherheit nicht — im Jahr 2020 ist das buchstäblich ein Verbrechen. Selbst wenn Ihr Unternehmen, Ihre Entwicklung und Sie für Angreifer uninteressant sind, können Sie von Problemen betroffen sein, die mit der Kompromittierung eines Netzwerks, eines Hosting-Anbieters, einem Angriff auf ein Rechenzentrum, dem Diebstahl von E-Mail-Passwörtern und unsicherem Verhalten von Mitarbeitern zusammenhängen, die Daten aus dem Unternehmen stehlen, Kunden abwerben oder den Quellcode des gesamten Projekts entführen können. Wenn es in Ihrem Ermessen liegt und in Ihren Verantwortungsbereich fällt, versuchen Sie, die Projekte, an denen Sie arbeiten, zu schützen. Und halten Sie sich selbst an die Informationssicherheit, das hat noch niemandem geschadet. 

Spucken Sie nicht in den Brunnen

Gehen Sie nicht Ihrem Arbeitgeber auf die Nerven. Heutzutage haben die Kommunikationsmittel ein Niveau erreicht, bei dem beispielsweise alle HR-Mitarbeiter der Stadt untereinander bekannt sind und Informationen in Chats und geschlossenen Gruppen austauschen können (wie bei der Jobsuche, so wie man auch schreiben kann: „Wassili Ivanow, Systemarchitekt, hat beim Verlassen alle Konten gelöscht, Backups überschrieben und das Netzwerk abgeschaltet, die Wiederherstellung dauerte 3 Tage. Stellen Sie ihn nicht ein.“). Ihr Verhalten wird somit ausschließlich gegen Sie arbeiten – und manchmal hilft nicht einmal ein Umzug in eine andere Stadt oder Hauptstadt. Selbst wenn Sie mit einem Groll gehen, gibt es keine bessere Rache, als ein wertvoller und großartiger Mitarbeiter des Konkurrenten zu werden 🙂 Und das Beste ist, dass Sie dabei vollkommen straffrei bleiben.

Das sollte man auch nicht tun. Aber wie die Erfahrung zeigt, hören wir nicht auf,

Im Allgemeinen, Freunde, lest die Ratschläge, aber handelt so, wie es euch am besten erscheint - denn echte Entdeckungen geschehen, wenn wir an bereits bekannten Wahrheiten zweifeln. Wir wünschen euch ein frohes neues Jahr, möge eure Projekte erfolgreich sein, eure Karriere interessant, eure Kollegen und Vorgesetzten angemessen, und das Leben insgesamt gelingt. Auf das neue Jahr und auf neuen Code! 

Mit Liebe,
das Team von RegionSoft Developer Studio

Im neuen Jahr werden wir weiterhin für Sie arbeiten und unser leistungsstarkes Desktop-CRM-System weiterentwickeln RegionSoft CRM sowie einen einfachen und benutzerfreundlichen Helpdesk und Ticketsystem ZEDLine Support.

Quelle: habr.com