10 Punkte, die ich gerne früher als Software Entwickler gewusst hätte

4-minute read

10 Punkte, die ich gerne früher als Software Entwickler gewusst hätte Link to heading

  • möchte gerne mein Wissen weitergeben
  • habe während der Corona Zeit viel darüber nachgedacht, was man als ITler heutzutage wissen sollte

  • “You have to maintain your work life balance.”: In der IT ist dein wichtigstes Instrument dein Verstand. Daher ist es wichtig, dass du dir regelmäßig Ausgleich schenkst. In der IT werden wir in den nächsten Jahren immer wieder so viele unterschiedliche neue Konzepte, Frameworks und Programmiersprachen kennenlernen. Deswegen ist es notwendig, dass wir täglich mit Spaß zur Arbeit gehen (Außnahmen bestätigen die Regel).

  • “You should search a mentor.”: Sucht Euch einen Mentor (bspw. Kollegen oder Vorgesetzten), von dem Ihr Euch Dinge abschauen könnt. Denkt immer daran, dass man von jeder Person etwas lernen kann. Schaut Euch bspw. an, wie die Person sich in Kundengesprächen verhält, in Stresssituationen reagiert, an Problemstellungen rangeht oder ihren Arbeitsalltag koordniert.

  • “You are a business to code translator.”: Lernt die Anforderungen des Kunden zu verstehen. Wofür benötigt der Kunde die Funktionalität? Gibt es bspw. die Möglichkeit den Prozess zu optimieren, bevor dieser in eine Software gegossen wird? Versucht mit dem Kunden regelmäßig ein Big Picture zu definieren. Dies hilft dabei sich auf das Wesentliche zu konzentrieren und eine gemeinsame Sprache zu entwickeln.

  • “Try to develop yourself continuously.”: Kontinuierliche Weiterbildung, meinte Erfahrung ist, dass es am besten damit klappt, wenn Ihr euch feste Termine blockt, wo Ihr Euch Themen anschauen könnt. Mir hat es sehr geholfen, dass ich mir täglich Morgens ca. 1 Stunde blocke, wo ich mir neue Themen anschauen kann. Weiterbildung gehört nicht komplett in die Freizeit, sollte aber auch aus meiner Sicht nicht komplett in der Arbeitszeit betrieben werden. Ein Buch oder einen interessanten Vortrag kann man auch mal am Wochenende sich anschauen.

  • “You should learn reading code.”: Als Junior-Entwickler wird man ganz schnell lernen, dass eines der wichtigsten Themen ist, den Code von anderen zu lesen und verstehen. Für Probleme findet Ihr Lösungen bei Stackoverflow & Co. Versucht diese Lösungen zu verstehen und für eure Use-Cases zu adaptieren.

  • “Practice, Practice, Practice!”: Versucht so viel Erfahrung wie möglich zu sammeln. Mein Lessons learned dabei, versucht dies nicht nur über die Projekte auf der Arbeit zu erreichen, sondern überlegt Euch Projekte für Eure Freizeit. Dann könnt Ihr selber entscheiden wie viel ihr macht und die Themen verfolgen, die euch wirklich Spaß machen.

  • “Quality Assurance”: Versucht in Euren Projekten von Anfang an Wert darauf zu legen, Delivery Pipelines einzuführen. Dadurch bekommt Ihr von Anfang Feedback über die Qualität Eurer Anwendung. Ich würde Euch immer dazu raten, diese Pipelines aufzubauen bevor ihr die erste Zeile Quellcode im Projekt schreibt. Ggf. habt ihr in eurer Firma schon Templates, wie Ihr solche Pipelines aufbaut, dann geht dies in der Regel relativ zügig und müsst die bestehenden Konfigurationen nur adaptieren.

  • “Keep it simple and stupid”: Die Komplexität von IT-Projekten steigt gefühlt täglich, es werden immer mehr Tools und Anforderungen eingeführt, externe Cloud Services angebunden usw. Das Ganze ist auch gut so, weil dadurch eine immer bessere Funktionalität für die Endkunden geboten werden kann. Aber man sollte sich immer die Frage stellen, ob die Komplexität gerechtfertigt ist. Und lieber erst andere Dienste einbinden, wenn selber nicht weiterkommt. Gerade als Junior Entwickler wird man häufig in bestehende Projekte geworfen und muss sich in diese einarbeiten. Wenn man das 1-2 gemacht hat, in Projekten wo schlecht dokumentiert wurde, zu viele Entwickler sich verwirklicht haben, dann wird man hoffentlich schnell lernen, dass man dies anderen nicht hinterlassen möchte.

  • “Dependency hell”: Bevor immer mehr externe Frameworks und Libraries eingesetzt werden, sollte man versuchen zu verstehen, was der Sinn und Zweck hinter diesen ist und ob der Overhead gerechtfertig ist. Manchmal braucht man nur eine einzelne Funktion einer Library, da sollte man sich lieber überlegen, ob diese nicht selber implementiert, bevor man das komplette Modul einbindet. Im Nachhinein wird es deinen Kollegen oft schwer fallen zu bewerten, ob die Dependency noch benötigt wird oder nicht.

  • “You build it, you run it”: Frühzeitig überlegen, wie man die Anwendungen im späteren Verlauf eines Projektes betreiben kann. Frühzeitig Kollegen befragen, die Erfahrung in diesem Bereich haben. Gute Punkte findet man hier bei dem 12 Faktor App Pattern.