Sieben Jahre als Entwickler gearbeitet: Welche Lektionen habe ich gelernt?

Die Zeit vergeht wie im Fluge, oder?

Meine Karriere begann 2012 mit dem ersten Praktikum in C ++. Ehrlich gesagt hatte ich keine Ahnung, was ich tat (tatsächlich hat sich nichts geändert). Ich habe jedoch einige Lektionen gelernt.

Haftungsausschluss: Diese Nachricht enthält keinen Code.

Frage: Was ist die wichtigste Programmiersprache?


Das ist Englisch. Oder Spanisch, Chinesisch, Polnisch. Jeder, mit dem Sie mit Kollegen kommunizieren.

Mit Menschen zu sprechen ist viel wichtiger als mit Autos zu sprechen.


Programmieren ist ein Mannschaftssport. Es gibt selten ein brillantes Produkt, das von einer Person von Grund auf neu erstellt wurde ( CodeSandbox ist ein gutes Beispiel, obwohl Ives kürzlich einige Mitarbeiter eingestellt hat), aber in den meisten Fällen wird ein Team benötigt.

Kommunikationsfähigkeiten können ein Projekt retten oder begraben. Keine Sorge, das Problem liegt nicht nur bei Ihnen, auch die NASA leidet darunter .

Professionelle und kommunikative Fähigkeiten können für den Projekterfolg wichtiger sein als rein technische. Wen kümmert es, dass Sie die fünf besten Datenbankexperten der Welt eingestellt haben, wenn sie sich weigern, miteinander zu sprechen, und Sie am Ende fünf verschiedene Instanzen von MySQL, Aurora und MongoDB haben.

Sie müssen genau verstehen, was Sie entwickeln und warum


Die meisten Menschen werden glücklicher, wenn sie ein Ziel haben. Dies gilt auch für die Arbeit.

Ihr Ziel als Entwickler ist es nicht, JIRA in JavaScript, Trello in C # usw. zu übersetzen. Ihr Ziel ist es, Probleme zu lösen .

Wenn Sie ein tiefes Verständnis für das System haben, das Sie erstellen / warten, können Sie Entscheidungen außerhalb der reinen Technologie treffen. Fragen stellen: Ist diese Funktion überhaupt notwendig? Welches Problem löst es? Können wir dieses Problem anders lösen? Wir wollen dieses Problem überhaupt lösen?

Ein solches Denken wird manchmal als Geschäftskontext bezeichnet. Wenn Sie jedoch Ihre Arbeit gut machen möchten, müssen Sie den Kontext nicht nur verstehen, sondern auch gestalten und beeinflussen können. Um ein Produkt zu beeinflussen, ist es nicht erforderlich, eine Führungsposition in einer Organisation einzunehmen. Zumindest ist dies für das Verständnis des Produkts nicht erforderlich.

Wenn eine Codeüberprüfung stressig ist, ist sie schrecklich, schrecklich falsch organisiert.


Oh Gott. Codeüberprüfung.

Wir denken wirklich nicht darüber nach, aber die Veröffentlichung des Werks mit seiner Studie durch mehrere andere Personen ist etwas Einzigartiges in unserem Beruf. Kein Wunder, dass dies Stress verursacht.

Ich persönlich habe Leute gesehen, die eine Codeüberprüfung speziell zu einer Zeit gesendet haben, als X nicht im Büro war oder Y auf Geschäftsreise war. X ist ein brillanter Programmierer, aber es ist schwierig, seine Codeüberprüfung aufrechtzuerhalten. Hunderte von wählerischen Kommentaren im Rahmen der Junior-Pool-Anfrage beweisen keineswegs Ihre Überlegenheit als Entwickler. Dies beweist nur Ihre schlechte Natur.

OK, aber was soll ich tun, wenn diese Funktion vollständig unterbrochen ist?

Steh auf. Kontaktieren Sie diese Person, sprechen Sie persönlich . Sprechen Sie mit ihm und finden Sie heraus, warum er den Code auf diese Weise implementiert hat.

Die meisten Leute wollen keinen schlechten Code schreiben. Und wenn doch, haben sie es wahrscheinlich mit Einschränkungen zu tun, die Sie nicht kennen. Sie können (noch) nicht sehr gut programmieren, und hier können Sie sich als Mentor beweisen.

Etwas muss schief gehen, mach dich bereit


Laut Wikipedia:

Murphys Gesetz ist ein Sprichwort oder Epigramm, das normalerweise lautet: "Alles, was schief gehen kann, wird schief gehen."

Dies ist eines der Dinge, die zu wahr sind. Nehmen Sie beim Entwerfen eines Systems immer einen Fehler an.

Wenn Sie ein Anmeldeformular erstellen, gehen Sie davon aus, dass der Text des gesamten Buches kopiert und in das Kennwortfeld eingefügt wird.

Wenn Sie ein WYSIWYG-Fenster erstellen, nehmen wir an, dass jemand versucht, es zu beschädigen, und dies wahrscheinlich tun kann.

Wenn Sie eine Datenbank haben, wird diese irgendwann getrennt. Wenn Sie das Wiederherstellen einer Datenbank aus einer Sicherung nicht getestet haben, handelt es sich nicht um eine Sicherung.

Wenn Sie eine Demonstration vor Publikum vorbereiten, stellen Sie sicher, dass die Demo online, offline, verkehrt herum und unter Wasser funktioniert.

Haben Sie keine Angst zu sagen "Ich weiß nicht"


Das angenehmste Privileg des Titels "Senior" auf dem Abzeichen ist schließlich die Möglichkeit zu antworten:

Ich weiß nicht, ich habe es nie versucht. Ich werde schauen und dich zurückrufen.

Als Junior hatte ich schreckliche Angst: Plötzlich würde jemand vermuten, dass ich ein Betrüger bin. Nach ein paar Jahren als Entwickler - wenn ich etwas nicht gesehen habe, ist es vielleicht immer noch nicht aufgetaucht. Oder es ist gerade eine andere coole Technologie aufgetaucht, die erforscht werden muss. Lebenslanges Lernen ist kein Schlagwort, es ist eine Realität in der IT.

Oder ich bin nur ein unglaublicher Betrüger, der es geschafft hat, alle zu täuschen, dass ich meinen Job wirklich machen kann. Du weißt es nie.

In der Öffentlichkeit lernen


Sobald Sie von "Ich weiß nicht" zu "Nun, das war interessant" wechseln, teilen Sie es mit jemandem. Schreiben Sie einen Blog, nehmen Sie ein Video auf, sprechen Sie bei einer Veranstaltung zum Wissensaustausch oder ... erzählen Sie es einfach jemandem. Wenn Sie denken, dass für jeden etwas offensichtlich ist, ist dies nicht der Fall. Selbst die besten Profis können von Anfängern etwas lernen und umgekehrt.

Der Unterricht ist ein unglaublich effektiver Weg, um sicherzustellen, dass Sie das betreffende Thema wirklich verstehen.

Wie jemand verdammt schlau sagte:

Wenn einer unterrichtet, lernen zwei.

Welche Lektionen haben Sie als Entwickler gelernt?

Source: https://habr.com/ru/post/de451884/


All Articles