deesaster.org

Die Jungs (und natürlich auch das eine Mädel) von Extra Credits haben zwei sehr gut Webepisoden zum Thema „Wie wird man Software-Entwickler“ veröffentlicht:

• Episode 1
• Episode 2

Da ich den Inhalt wichtig finde und voll unterschreiben kann (auch wenn ich kein Spiele-Entwickler bin), hier eine kurze Zusammenfassung der wichtigsten Punkte („SW“ ist die Abkürzung für „Software“):

Episode 1:

• SW-Entwickler sitzen normalerweise nicht in dunklen Kämmerchen ohne Tageslicht und hacken die ganze Zeit auf der Tastatur herum
• SW-Entwicklung beschäftigt sich hauptsächlich mit Problemlösungen (Problemfindung, Problemanalyse und Erstellen der Lösung)
• als (neuer) SW-Entwickler bekommt man Probleme gestellt, die noch niemand zuvor (in der Firma) gelöst hat (ansonsten bräuchte man denjenigen nicht)
• SW-Entwickler benötigen gutes analytisches und abstraktes Denken (gute Fachgebiete hierfür sind Mathematik und andere Logikthemen)
• weniger wichtig ist das Auswändiglernen von Daten und Fakten
• sehr gute SW-Entwickler lösen Probleme schnell und elegant
• Kenne Deine Werkzeuge! (Das gilt wahrscheinlich für alle Berufe.)
• kontinuiierliche Weiterbildung (und praktische Anwendung) ist überlebenswichtig
• viele SW-Entwickler erweitern auch freiwillig privat ihr Wissen (Analyse von Fremdcode, Teilnahme in Open-Source-Projekten)
• Erfahrungen anderer SW-Entwicklern ist wichtig

Episode 2:

• Kommunikation ist extrem wichtig
• die meisten SW-Entwickler arbeiten in Teams und nicht alleine für sich
• fehlende oder falsche Kommunikation führt zu Missverständnissen, Verzögerungen, Fehlern und ggf. zum Scheitern eines Projekts
• ein offenes Ohr für Kritik ist wichtig; man ist nicht immer auf dem richtigen Weg
• eine gute Aufwandsabschätzung ist wichtig für Termineinhaltung (hier sollte man aus früheren Fehlabschätzungen lernen)
• als SW-Entwickler hackt man nicht nur Code, man sollte auch verstehen, was der Kunde eigentlich erreichen will; eine Lösung muss nicht immer perfekt sein
• Low-Level-Sprachen (C/Assembler) sind oft hilfreich, um die internen Abläufe zu verstehen
• ebenso sollte man (zumindest grob) verstehen, wie die Hardware funktioniert, auf der man arbeitet