9 harte Lektionen, die ich in 18 Jahren Entwicklung gelernt habe

Ich begann mit 14 Jahren im Zimmer meiner Eltern zu programmieren. Ich erinnere mich, dass ich alles gelesen habe, was ich mit meiner langsamen Internetverbindung in die Hände bekommen konnte. Dann, als ich 20 war, unterschrieb ich meinen ersten Vertrag, wurde Webentwickler und lernte PHP und JavaScript. Ich habe 18 Jahre gebraucht, um zu erkennen, dass Codierung nur ein Teil des Berufs ist. Beachten Sie, dass ich immer noch gerne codiere. Ich glaube nicht, dass ich jemals aufhören werde zu programmieren, auch wenn es nur mein Hobby ist, aber es gibt viel mehr als nur Code. Deshalb möchte ich meine Erfahrungen teilen. Ich denke, manchmal lernen Entwickler diese Lektionen zu spät.








1. Lass das Ego an der Tür



Entwickler haben Egos aufgebläht. Es ist eine Tatsache. Aber warum? Ich würde sagen, dass jeder, der seinen Beruf ernst nimmt, sich selbst als eine Art Kunst betrachtet. Ja, wir singen nicht vor Millionen und zeichnen nicht "Mona Lisa", aber manchmal schreiben wir Code, der komplexe Probleme so effizient und elegant löst, dass wir nicht anders können, als stolz auf unsere Arbeit zu sein. Ich denke, dass der Entwickler aufgrund seiner Herangehensweise an Probleme ein Mann der Kunst ist, genauso wie ein Mathematiker. Als solches neigen wir dazu, um den Code herumzukriechen, genau wie eine Mutter um ihren Nachwuchs herum. Wir schreiben es, lieben es und hassen es, wenn Leute darüber streiten, wie falsch der Code ist oder nicht.



Andererseits hat es noch niemandem geholfen. Wir lieben unseren Job, aber wir müssen verstehen, dass wir Probleme lösen. Wenn Sie unsere Ideen und Lösungen mit anderen Menschen diskutieren, kann sich eine bessere Alternative ergeben. Da ist nichts falsch. Tatsächlich führt die Zusammenarbeit tendenziell zu besseren Lösungen. Ich habe alle Arten von Ego beobachtet, aber ich habe nie eine Situation gesehen, in der das Ego für einen Entwickler funktionieren würde.

Welchen Rat kann ich geben? Lassen Sie Ihr Ego von dem Moment an, an dem Sie als Entwickler arbeiten, an der Tür. Schlucken Sie es und hören Sie zu, was andere über Ihre Arbeit zu sagen haben. Akzeptieren Sie, dass die besten Ideen möglicherweise nicht in Ihrem Kopf sind und dass sie Ihre Professionalität verbessern können. Sie profitieren nur vom Anhören des Feedbacks.



2. Sprachen sind ein Werkzeug. Kennst du nur den Hammer? Dann sind alle Probleme wie Nägel



Nennen Sie sich nicht länger Java-Entwickler oder JavaScript-Entwickler. Ja, es gibt Sprachen, die Sie aufgrund ihrer Syntax oder Funktionen mögen. Das ist völlig normal. Sie gewinnen jedoch, wenn Sie einige Zeit damit verbringen, etwas anderes zu studieren. Das Erlernen neuer Sprachen, insbesondere wenn sie einem anderen als dem üblichen Paradigma folgen, kann dazu beitragen, Ihren Geist für verschiedene Lösungsansätze zu öffnen.



Ich weiß nicht einmal, wie wichtig dies ist: Das Erlernen und Anwenden neuer Sprachen kommt Ihren Fähigkeiten zugute. Ich habe vor einigen Jahren das Buch Sieben Sprachen in sieben Wochen gelesen und es hat mir viele Möglichkeiten eröffnet, nur weil es Wege aufgezeigt hat, Probleme zu lösen, die in anderen Sprachen verfügbar sind.



Wir sind Entwickler. Wir wissen, wie man Probleme mit Code löst. Beschränke dich nicht. Schauen Sie über die Grenzen hinaus, denken Sie über den Tellerrand hinaus, lernen Sie andere Optionen, Sprachen und Möglichkeiten zur Lösung von Problemen. Auch wenn Sie es nicht lange tun, kehren Sie mit frischen Ideen und umfassenderem Denken zu Ihrem vertrauten Werkzeug zurück.



3. Es geht nicht darum, Algorithmen auswendig zu lernen, sondern sie zu finden



Einige Neulinge denken, dass sie die Algorithmen auswendig müssen, und fühlen sich daher schlecht, sobald sie feststellen, dass sie vergessen haben, wie man eine for-Schleife schreibt. Das ist nicht nur normal. Ich würde sagen, dass es sogar nützlich ist. Wir müssen uns einfach zu viel erinnern. Das ist aber auch unnötig. Wir müssen die Tatsache akzeptieren, dass das Internet nur ein weiteres Werkzeug ist, das als unsere IDE benötigt wird, um Antworten zu finden.



Das machen wir alle. Und wenn Sie sich dadurch schlecht fühlen, verschwenden Sie keine Zeit mit diesem Gefühl. Suchen Sie einfach bei Google nach der Antwort und verstehen Sie Ihr Problem. Denk darüber nach. Jede Sprache hat ähnliche, aber leicht unterschiedliche Möglichkeiten, das Observer-Muster zu implementieren. Was ist nützlicher? Verstehen, wofür ein Muster gut ist und welche Probleme es löst, oder sich daran erinnern, wie es in jeder Sprache implementiert werden kann, mit der Sie arbeiten?



Wenn Sie wissen, dass das Muster Ihr Problem lösen wird, haben Sie es bereits gelöst. Alles andere ist nur eine Suche nach dem besten Weg, es bei Google zu implementieren. Diese Suche nimmt Ihnen, Ihrer Arbeit oder Ihrer Erfahrung keinen Respekt. Gleiches gilt für jede andere Suche. Konzentrieren Sie sich auf das, was wichtig ist, lösen Sie das Problem und lassen Sie Google Ihr Gedächtnis erweitern. Deshalb existiert es.



4.



Oder besser gesagt, Sie müssen für Ihre gesamte Karriere studieren. Die Entscheidung, ob Sie die neuesten Entwicklungen in der Branche verfolgen, liegt bei Ihnen. Aber es ist am besten, dies zu tun, wenn Sie übereinstimmen möchten.



Sprachen und Technologien entwickeln sich weiter, und das ist völlig normal. Natürlich ändern sich einige Ökosysteme schneller als andere, und es mag wie eine titanische Aufgabe erscheinen, mit ihnen Schritt zu halten. Konzentrieren Sie sich jedoch auf die wichtigen Dinge. Denken Sie daran, dass Sie nur Menschen sind und nicht alles wissen können. Wenn Sie also eines lernen müssen, empfehle ich Ihnen, das Lernen zu lernen.



Ich weiß, das klingt vielleicht albern, aber vielleicht hat der Entwickler diese Fähigkeit Nummer eins. Wir müssen lernen, schnell neue Fähigkeiten zu erlernen. Andernfalls besteht die Gefahr, dass Sie das "veraltete" Etikett erhalten.



Hier kommen einige der anderen Lektionen in diesem Artikel ins Spiel. Variabilität, Veränderung, neue Herausforderungen, mangelndes Ego - all dies wird Ihnen helfen, Ihr Spektrum an Fähigkeiten zu erlernen und zu erweitern. Je mehr Sie es üben, desto besser. Schließlich werden Sie feststellen, dass alle Sprachen ähnlich sind. Sie werden beginnen, ihre gemeinsamen Wurzeln zu erkennen und mit jedem von ihnen arbeiten zu können. Alles was Sie tun müssen, ist ein paar wichtige Dinge zu lesen. Während Ihrer Karriere werden Sie studieren:



  • Neue Sprachen.
  • Neue (und alte) Programmierparadigmen.
  • Neue Arbeitsansätze.
  • Neue Wege zur Lösung von Problemen.
  • Neue Möglichkeiten zur Interaktion mit Teamkollegen.
  • Neue Ansätze zum Überprüfen und Testen Ihres Codes.


Wenn Sie nicht bereit sind, ein ewiger Schüler zu sein, überlegen Sie, ob eine solche Karriere für Sie ist. Beachten Sie, dass ich nicht "Sofort gehen" gesagt habe, sondern überlegt habe, ob Sie bereit sind, Ihren Geist für kontinuierliches Lernen zu öffnen.



5. Funktioniert besser als ideal



Als Manager habe ich das zu oft gehört. Als Entwickler sind wir jedoch der Meinung, dass der Code vor der Veröffentlichung perfekt sein sollte. Und das ist nicht nur falsch, sondern möglicherweise ein Problem. Eine frühzeitige Optimierung ist ein Problem, da Sie am Ende viel Zeit und Mühe mit Dingen verbringen, die möglicherweise nicht optimiert werden müssen. In einigen Situationen treffen Sie bei dieser Optimierung Annahmen, die die Funktionalität beeinträchtigen.



Konzentrieren Sie sich also auf die zu erledigende Arbeit und das Problem, das Sie lösen möchten. Nachdem Sie das Problem gelöst haben, testen Sie es, wiederholen Sie die Ergebnisse und sehen Sie, was Ihr Team über Ihre Lösung denkt, auch wenn Sie bereits Möglichkeiten zur Verbesserung sehen. Wenn Sie noch zwei Tage damit verbringen, den Code perfekt zu machen, er aber möglicherweise gerade in Produktion geht, sollte er wahrscheinlich gerade in Produktion sein.



Am Ende lösen Sie das Problem. Je schneller Sie das Problem lösen, desto besser für Ihre Benutzer.



6. Lassen Sie den Code funktionieren und optimieren Sie ihn



Fallen Sie nach einigen der vorherigen Punkte nicht in das frühe Optimierungs-Schwarze Loch. Selbst wenn Sie glauben, dass Sie den Code schnell erhalten, werden Sie feststellen, dass der Zeitdilatationseffekt real ist, sobald er veröffentlicht ist (falls dies jemals der Fall sein sollte).



Ihre erste Priorität als Softwareentwickler, der eine neue Funktion schreibt oder einen Fehler behebt, besteht darin, sie funktionsfähig zu machen, unabhängig davon, wie hässlich der Code aussieht oder wie ineffizient die Lösung ist. Wenn der Code funktioniert, haben Sie gerade bewiesen, dass es möglich ist, Code zu schreiben. Dies ist die halbe Miete.



Der zweite Schritt ist die Optimierung. Dieser Schritt ist optional. Details, die manche Leute gerne vergessen. Die Zeit, die Ihnen zur Optimierung Ihres Codes zur Verfügung steht, hängt von vielen Variablen ab, die Sie manchmal nicht steuern. Konzentrieren Sie sich also darauf, den Code zum Laufen zu bringen, und finden Sie heraus, ob Sie tatsächlich Zeit haben, ihn zu optimieren.



Frühzeitiges Optimieren bedeutet, dass Sie Ihren Code beim Schreiben optimieren. Dies ist eine gefährliche Vorgehensweise, da wir bei der Optimierung Annahmen über Laufzeit, Datenanforderungen, Speicheranforderungen und andere Faktoren treffen, die wir noch nicht in Aktion gesehen haben. Eine solche Annahme kann falsch sein, und schließlich werden Sie Fehler in Ihre Logik einführen.



Denken Sie an den TDD-Workflow:



  1. Schreiben Sie einen Test, um alles zu verstehen, was für Ihre Funktion getan werden muss (der Test schlägt fehl).

  2. Schreiben Sie Ihren Code so, dass der Test erfolgreich ist.

  3. Sorgen Sie sich jetzt um die Optimierung Ihres Codes.



Der zweite Schritt ist erforderlich. Zuerst müssen Sie sich um den Test kümmern, was bedeutet, dass die Funktion funktioniert. Dem Test ist es egal, dass Sie drei verschachtelte if-Anweisungen in Ihren Algorithmen verwenden. Dies wird möglicherweise in der Phase der Codeüberprüfung wichtig.



7. Die letzten 10% des Projekts dauern 90% der Zeit



Dies ist besonders wichtig, wenn Sie alleine arbeiten, aber Teams leiden auch darunter, dass dieses kleine mathematische Detail nicht richtig ist. Jeder, der ein Projekt abgeschlossen hat, wird dasselbe sagen (und ehrlich gesagt ist dies nicht nur in unserer Branche der Fall). Zuerst stürzen Sie sich durch viele Details, um später darüber nachzudenken.



Und das ist völlig normal. Wir konzentrieren uns hauptsächlich auf große Funktionen und lassen kleine Details oder sogar bekannte Fehler bis zum Ende zurück. Trotzdem müssen Sie sie bekämpfen - und hier erscheinen weitere 90%. Sie müssen testen, den Code korrigieren, erneut testen, den Benutzern den Umgang mit der Lösung beibringen, die endgültige Version der Lösung einreichen und so weiter. Natürlich hängt alles vom Kontext ab, wer Ihr Kunde ist und von vielen anderen Faktoren, aber es gibt immer etwas. Denken Sie also daran, wenn Sie denken, dass Sie mit dem Code fast fertig sind, haben Sie wahrscheinlich etwas vergessen.



8. Wenn Sie in einem Team sind, brauchen Sie Abstraktion.



Beim Codieren geht es um das Verhalten von Abstraktionen. Indem wir die allgemeine Logik abstrahieren, können wir sie an anderen Stellen wiederverwenden, aber am Anfang vergessen wir die Bedeutung von Abstraktionen. Hier ist meine persönliche Regel: Wenn der Code an zwei Stellen wiederholt wird, wird er an eine Funktion (Methode, Modul) gesendet. Du hast die Idee. Wenn zwei Wiederholungen für Ihre Augen wie eine kleine Zahl aussehen, denken Sie daran, dass es in Zukunft möglicherweise andere Stellen gibt, an denen Sie den gerade abstrahierten Code anwenden können. Wenn Sie den Code sofort abstrahieren, haben Sie sofort Zugriff darauf.



Abstraktion ist Skalierung. Ein Stück abstrahierter Logik kann mit minimalem Aufwand viele Male verwendet werden, während Kopieren und Einfügen (obwohl dies einfach ist) - je mehr Sie es verwenden, desto mehr Aufwand ist erforderlich. Überlegen Sie, was passiert, wenn Sie aufgrund eines Fehlers eine Logik ändern müssen, die fünfmal wiederholt wird. Um einen Fehler zu beheben, ändern Sie buchstäblich fünf Mal denselben Teil des Codes.



Die gleiche Logik gilt für alltägliche Aufgaben. Wenn Sie etwas mehr als einmal tun, kann es wahrscheinlich irgendwie automatisiert werden. Dies ist der Schlüssel zur Effizienz. Betrachten Sie also die Wiederholung nicht nur in Ihrem Code, sondern auch in Ihren Aktionen. Wenn Sie eine Aufgabe automatisieren, die 10 Minuten pro Tag dauert, sparen Sie 5 Stunden pro Monat.



9. Nebenprojekte sind optional, können aber helfen



Einige sagen, wenn Sie ein erfolgreicher Entwickler sein wollen, brauchen Sie Nebenprojekte. Ich glaube nicht, dass das stimmt. Ich persönlich kenne viele großartige Entwickler, die nur Code bei der Arbeit schreiben, "von 9 bis 17". Um ehrlich zu sein, bewundere ich sie. Sie beherrschen ihr Handwerk und genießen in ihrer Freizeit das Leben, wenn sie etwas anderes tun. Daran ist absolut nichts auszusetzen. Manchmal benötigen Sie jedoch zusätzliche Übung. Manchmal haben Sie das Gefühl, hinter Ihren Kollegen zurückzubleiben. hier und helfen Nebenprojekte.



Ich spreche nicht von einer Revolution in der Branche - der Entwicklung eines Frameworks mit Millionen von Benutzern. Schreiben Sie es, wenn Sie möchten, aber ich spreche davon, die Projekte anderer zu kopieren, um daraus zu lernen. Ich spreche auch davon, zu Projekten anderer Leute beizutragen, Fehler zu beheben und Funktionen hinzuzufügen.



Sie können Nebenprojekte schreiben, um andere Aspekte der Entwicklung kennenzulernen, die Sie normalerweise nicht berühren würden. Wenn Sie 8 Stunden am Tag Komponententests schreiben, denken Sie möglicherweise darüber nach, etwas von Grund auf neu zu schreiben oder Funktionen zu entwickeln. Wenn Sie es satt haben, alleine zu arbeiten, tragen Sie zu einem bestehenden Projekt anderer Menschen bei und erfahren Sie, was es bedeutet, Ihre Arbeit mit anderen zu koordinieren. Sie können ein Nebenprojekt schreiben, um Ihr Können zu verbessern, indem Sie Schwachstellen beheben. Aber andererseits haben Sie nicht das Gefühl, dass Sie mit einer grünen Github-Aktivitätsleiste daran arbeiten müssen, um als ernsthafter Entwickler zu gelten. Das ist einfach albern.



Fazit



Hier sind meine 9 harten Lektionen als Entwickler in den letzten 18 Jahren. Hoffentlich habe ich durch das Teilen meiner Erfahrungen etwas Licht in Ihre zukünftige oder aktuelle Karriere gebracht. Haben Sie noch etwas gelernt, das Sie gerne teilen möchten? Ich würde gerne in den Kommentaren von Ihnen hören, ich würde gerne etwas von Ihnen lernen.



Bild






Andere Berufe und Kurse


















All Articles