Graduiertenerwartungen versus Realität [abgeschlossen]

Bei der Auswahl, was wir studieren und was wir mit unserer Karriere und unserem Leben anfangen wollen, haben wir alle einige Erwartungen, wie es sein wird. Jetzt, da ich fast ein Jahrzehnt in der Branche bin, habe ich ein wenig darüber nachgedacht, wie das Programmieren im Berufsleben aussehen würde (damals als ich Informatik studierte) und wie es sich tatsächlich entwickelt Sein.

Meine zwei größten Schocks (oder sollte ich sagen, gebrochene Erwartungen) sind die enorme Menge an Wartungsarbeiten, die mit Software verbunden sind, und der allgemeine Mangel an Professionalität:

1. Wartung : Bei uni wurde uns allen gesagt, dass der Großteil der Software-Arbeit in der Wartung bestehender Systeme besteht. Also wusste ich, dass ich dies abstrakt erwarten musste. Aber ich hätte nie gedacht, wie überwältigend das werden würde. Vielleicht ist es etwas, über das ich mich im Geiste hinweggesetzt habe, und ich hoffte, ich würde noch viel mehr cooles neues Zeug von Grund auf neu aufbauen. Aber es ist wirklich so, dass die meisten Jobs überwiegend auf Wartung, Fehlerbehebung und Support ausgerichtet sind.

2. Mangelnde Professionalität : Bei uni hatte ich immer den Eindruck, dass kommerzielle Software sehr prozessorientiert und stringent konstruiert ist. Ich hatte Bilder von ISO-Prozessen, unzählige technische Dokumentationen, alle Funktionen und Fehler wurden streng dokumentiert und ein allgemein professionelles Umfeld. Es war ein großer Schock zu bemerken, dass die meisten Softwareunternehmen nicht anders arbeiten als ein Studententeam, das an einem großen semesterlangen Projekt arbeitet. Und ich habe sowohl im kleinen agilen Hack-Shop als auch im mittelständischen Unternehmen gearbeitet. Ich würde zwar nicht sagen, dass es immer geradezu "unprofessionell" war, aber es fühlt sich definitiv so an, als ob die Softwareindustrie (im Großen und Ganzen) weit von der starken technischen Disziplin entfernt ist, die ich erwartet hatte.

Hat jemand ähnliche Erfahrungen gemacht? Wie haben sich Ihre Erwartungen an unseren Beruf von der Realität unterschieden?

Ich fühle dich, Mann. Tatsächlich habe ich vor etwas mehr als einem Jahr meinen Abschluss gemacht und bin auf das erste Stellenangebot gesprungen, das mir in den Sinn kam, und habe den größten Schock meines Lebens bekommen.

Dinge, die ich nicht erwartet hatte:

Schulstress und Arbeitsstress sind nicht dasselbe - Der Stress, mit Freunden an einem Schulprojekt zu arbeiten oder allein zu arbeiten, selbst mit dem sich abzeichnenden Termin für Abschlussarbeiten oder der besonderen Projektverteidigung, ist nicht mit dem Stress von scheinbar unvernünftigen Arbeitszeiten und Kommunikationsproblemen zu vergleichen , (ein bisschen Büropolitik) und Krisenzeiten.

Mangel an Best Practices - Genau wie Ihre Erfahrung in Bezug auf Professionalität. Bevor ich meinen ersten Job antrat und während meiner Ausbildungszeit, habe ich mich beeilt, Best Practices sowohl in der Programmierung als auch in der Softwareentwicklung durchzulesen. Diese werden aus unpraktischen und, um fair zu sein, praktischen Gründen nicht so gut befolgt wie sie sollten. Und manchmal zählt Ihr Wissen sehr wenig gegen andere, die nur Angst vor dem Unbekannten haben und diese Praktiken mit Verachtung behandeln.

Was sie in der Schule unterrichteten, war nur die Spitze des Eisbergs - Als ich dachte, dass das, was ich selbst lernte und aus dem Unterricht stammte, ausreichte, war ich gelinde gesagt schockiert, als ich verblüfft auf das erste Stück Code starrte, das ich war soll pflegen. Viele der Fähigkeiten, die ich jetzt benutze, wurden im Job oder während meines Jobs erlernt, und ich frage mich immer wieder, ob ich es überhaupt ohne College-Abschluss hätte schaffen können. XD

Die Bedeutung der Kommunikation - ließ mich erkennen, wofür all diese Englischkurse gedacht waren. Vor der realen Welt konnte ich nicht erkennen, wie wichtig es ist, drei bis vier verschiedene Englischklassen am College zu haben, wenn es unterrichtet wird, seit wir in der ersten Klasse waren. Sie können nicht mit Ihrem Job arbeiten, wenn Sie mit einem Computer sprechen können, aber nicht mit Menschen.

Die meiste Arbeit, die Sie machen, ist nicht wegweisend

Als ich an der Uni war, arbeitete ich an KI-Routinen zur Steuerung von Fußballspielrobotern, baute Compiler und hackte Betriebssystemkerne.

In der Praxis sind 99% ^* der Softwareentwicklung jedoch ziemlich langweilig. Ich habe immer Architekten oder Bauherren bewundert, die auf die Frage "Was machen Sie beruflich?" kann auf ein Gebäude oder was auch immer zeigen und sagen "Ich habe das getan ". Aber die meisten Softwareentwickler können das nicht. Auf die Frage "Was machen Sie beruflich?" Das Nächste, was ich jemals erreichen konnte, war, als ich für eine Firma arbeitete, die Software entwickelte, die SMS-Nachrichten für Radiosender und dergleichen verarbeitete ein Radiosender, um für einen Song zu stimmen. Nun, ich habe die Software geschrieben, die diese Stimmen und so weiter verarbeitet. " Immer noch nicht annähernd so cool, wie auf ein Gebäude zeigen zu können und zu sagen: "Das habe ich gebaut."

Natürlich gibt es Leute, die sagen können "Ich habe unter Windows gearbeitet" oder was auch immer, aber ich bin sicher, dass sie niemandem sagen, dass aus Angst vor der nächsten Frage "Ich kann meinen Drucker nicht zum Laufen bringen", kannst du das für mich reparieren? "

^* und 62% aller Statistiken werden vor Ort erstellt

Wenn Sie sich heute Software aus der Perspektive der Ingenieurgeschichte ansehen, dann ist es sicherlich eine Art Ingenieurwesen - aber es ist die Art Ingenieurwesen, die Menschen ohne das Konzept des Bogens taten. Die meiste Software ähnelt heutzutage einer ägyptischen Pyramide, in der Millionen von Bausteinen übereinander gestapelt sind, ohne strukturelle Integrität, sondern nur durch rohe Gewalt und Tausende von Sklaven. -Alan Kay, 2004

Das vollständige Interview finden Sie unter http://queue.acm.org/detail.cfm?id=1039523

Ich bin kein Industrie-Tierarzt. Ganz im Gegenteil, ich habe gerade meinen Abschluss gemacht, aber eine der besten CS-Schulen in den USA. Aber ich habe das instinktive Gefühl, dass die Art und Weise, wie wir Software entwickeln, falsch ist. Anstatt die Pausentaste zu drücken und die Grundlagen unserer Programmierung zu überdenken, haben wir uns auf die Suche nach veralteten Modellen aus den 50er und 60er Jahren gemacht und immer wieder etwas Zucker hinzugefügt. Wenn wir so weitermachen, kommen wir nie dort vorbei, wo wir uns gerade befinden. Menschen können die Komplexität von Dingen, die die Größe der MS Windows-Codebasis haben, einfach nicht bewältigen. Wir brauchen einen neuen Weg. Ich weiß nicht was das ist.

Ich denke, dies ist der Grund für das Gefühl, dass große und kleine Softwarehäuser scheinbar Software herstellen, indem sie sie ohne tiefes Verständnis grundlegender Prinzipien zusammen hacken.

Ich habe keinen Abschluss bekommen, aber ich habe ein bisschen in Universitätsbibliotheken und Labors gelernt.

• Big Iron - Die Technologien, die sie lehrten, waren in erster Linie Großrechner und Minicomputer. Der Dekan eines Colleges sagte mir, dass ich keinen Job bekommen würde, weil ich nicht einmal wusste, was ein Masterfile ist. Ich hatte nicht die Absicht, an Großrechnern zu arbeiten, da ich mir keinen leisten konnte, aber ich würde nicht so dumm sein, nicht leicht vorbereitet zu sein. VAXen waren cool und ich freute mich darauf, dafür bezahlt zu werden, auf meinem eigenen Micro VAX in meiner Kabine zu codieren. Was für eine Schande, dass der Markt völlig implodierte. (Es stellte sich heraus, dass ich zwei Positionen bei Mainframes hatte… als Auftragnehmer für IBM.)

• Software-Engineering - Nach Strukturierter Programmierung, SASD und anderen Entwurfsmethoden haben Sie vielleicht gedacht, wir wären echte Ingenieure. Ich tat. Aber die Lehrer gaben sehr wenig Anleitung zu den Designtechniken, die ich in der Bibliothek las. Die Schüler waren auf sich allein gestellt, und Mikros machten es zu einfach, den Code so lange einzugeben, bis sie eine Antwort erhielten, mit der sie zufrieden waren. Ich wusste nicht, wie viel schlimmer es auf dem Arbeitsmarkt war. Irgendwie musste ich einiges an neuem Code schreiben, also war es nicht so langweilig. Aber ich habe auch viel übernommen und sie waren schlimm genug, es war wie ein neues Projekt, weil ich viel Code reparieren musste. Es war eine Kombination aus der Erforschung vorhandener Funktionen und der Erstellung von neuem Code (dessen Ersatz). Schreibwerkzeuge zur Vereinfachung des Prozesses und Einführung eines besseren Projektmanagements.

• Hightech-Karriere - Es ist eine Sache, wenn Schulen alte Gebäude und Geräte haben (die Lochkartengeräte wurden in dem Semester ersetzt, bevor ich anfing ... 1984), aber wenn Sie in einem schlecht beleuchteten Lager oder für einen Chef arbeiten, der auflegt Bei Kunden, die sich an den Kundendienst wenden, merkt man, dass das Kochen von Popcorn mit einem 5-Megawatt-Laser in der Regel keine Rolle spielt.

• Entwicklung ist hauptsächlich Teamarbeit. Dies bedeutet, dass die Kommunikation (gesprochen und gelesen), das Lesen des Codes anderer und die Wiederverwendung früherer Module (sowohl intern als auch extern) etwas sind, mit dem man sich fast täglich auseinandersetzen muss. Zumindest in meinem College musste ich in sehr wenigen Fällen mit mehr Leuten programmieren, daher dachte ich, dass der Hauptteil der Arbeit darin bestand, allein in der Wildnis zu programmieren. Es ist nicht.
• Nicht-Entwicklern Dinge zu erklären ist schwierig (auch für den ersten Punkt) und liegt in Ihrer Verantwortung, Ihre Punkte zu machen (nicht von den anderen 99% der Welt).
• Der gute Test ist der Test, der fehlschlägt. (Zumindest beim ersten Mal) Und natürlich gibt es keinen fehlerfreien Code. Sie sind kein schlechter Programmierer, wenn Sie Fehler haben. Fehler sind nur ein (sehr wichtiger und zeitraubender) Teil Ihres Jobs.
• Es gibt keine silbernen Kugeln. Jede Technologie hat ihre Vor- und Nachteile.
• Das College bringt Ihnen nicht die neuesten Technologien bei. Aber auch 90% der Arbeiten verwenden ziemlich alte Technologien. Was übrigens manchmal nötig ist.
• Nichttechniker treffen Entscheidungen über technische Lösungen , hauptsächlich aus esoterischen Gründen wie Wartung, Partnerschaft, Verfügbarkeit der Mitarbeiter ...
• Du fängst gerade erst an , junger Padawan .

Seitdem ist mir klar geworden, dass das Codieren eine Arbeit ist, die Sie gemeinsam mit mehr Menschen ausführen, insbesondere jetzt, wo Open Source eine größere Rolle spielt. Aber als ich am College war (Ende der Neunziger), war ich überzeugt, dass ich Dinge von Grund auf neu machen und niemals in den Code eines anderen schauen oder mich mit anderen abstimmen musste ...

Wenn ich zurückblicke, ist es für mich das Beste, andere zu lernen und zu lehren .

• Computerprogrammierung ist nicht physisch und nicht intuitiv.
  • Wenn ein Hausbauer seine Arbeit beendet hat, kann er herumlaufen und sofort sehen / fühlen, ob etwas nicht stimmt. Ein Computerprogrammierungsfehler kann nicht auf die gleiche Weise entdeckt werden und kann monatelang oder sogar jahrzehntelang im System lauern.
  • Während ein Programmierer durch Codeüberprüfung einen Teil des Quellcodes sehen / fühlen mag, ist nicht garantiert, dass er jeden im Code enthaltenen Fehler entdeckt. Ein Computer könnte den Fehler jedoch jedes Mal exakt reproduzieren, indem er das Programm mit einer bestimmten Eingabe ausführt. Das menschliche Verständnis eines Teils des Quellcodes ist daher immer ein unvollständiges Modell dafür, dass es sich im Wesentlichen um die Anweisungen für einen Computer handelt.
• Es ist sehr einfach, ein Programm zu programmieren, das die häufigsten Fälle behandelt, die Randfälle jedoch nicht vollständig verarbeitet.
  • In anderen Disziplinen ist es relativ einfach, eine Abhilfemaßnahme nachträglich anzuwenden. Es kann sogar einen Wissensbestand geben, der speziell für Abhilfemaßnahmen vorgesehen ist. In der Softwareentwicklung gibt es so etwas nicht.
  • Glücklicherweise hilft die testgetriebene Entwicklung dabei, die Randfälle zu kodifizieren, die der Code behandeln soll.
  • Hinzugefügt Auf der anderen Seite scheinen bestimmte Software - Entwicklungsmethoden vorschlagen , dass wir Geschäftswert (schneller auf dem Markt, etc.) extrahieren können , indem bewusst die Wahl nicht an Griffkanten Fälle und diese Entscheidungen zu den Kunden zu kommunizieren.
• Kunden können Geschäftswerte in einer Software finden, die nur die häufigsten Fälle abwickelt. Daher sind Softwareanbieter nicht allzu besorgt, wenn es darum geht, die seltenen Fälle abzuwickeln.
  • Kunden lernen einfach, die rauen Kanten zu vermeiden.

Hinzugefügt

• Die Eleganz des Quellcodes wird nicht gewürdigt.
  • Kunden sehen die Eleganz des Quellcodes nicht. Sie sehen nur die Eleganz der Benutzeroberfläche und Interaktionen.
  • Programmierer hingegen schätzen die Eleganz der Benutzeroberfläche in der Regel nicht und bleiben in der Regel nicht lange genug in einem Projekt, um ein elegantes Softwaredesign zu schätzen.
  • Da weder Kunden noch Programmierer die Eleganz des Quellcodes schätzen, wird er auch von Unternehmen nicht geschätzt.

Hinzugefügt

Meine zwei Cent: gewöhne dich einfach daran.

Bilder von ISO-Prozessen, unzählige technische Dokumentationen, jede Funktion und jeder Fehler werden streng dokumentiert, und ein allgemein professionelles Umfeld beschreibt mein Unternehmen ziemlich gut. Wir tun kritische Infrastruktur - Software / Hardware - Produkte jedoch so, na ja, der Druck auf für Qualität (wir sind nach ISO 9001 zertifiziert, zum Beispiel).

Ich dachte nach meinem Abschluss, dass die Verantwortlichen gute Arbeit von schlechter Arbeit unterscheiden könnten. Nachdem wir die millionste Kopie von "wirklich großartigem Code, den unser Top-Codierer zusammengestellt hat" erhalten haben, sah es so aus:

def lf(p, q, r):
    x = 4
    xx = 4.5
    t = {1:p, 2:p+2, 3:p*4} #I think there's a bug in here but I don't know
    .
    .
    .

Ich habe es fast aufgegeben zu verstehen, was zwischen den Ohren des spitzen Chefs vorgeht. "Großartig" bedeutet Wartungsalptraum, "gut" bedeutet Abstürze in einer sanften Brise, und "schreckliches Durcheinander" bedeutet entweder das oder eine gut strukturierte Codebasis, deren Ingenieure sich offenkundig geweigert haben, obszöne Fristen einzuhalten, nur um ihren Verstand zu wahren.

Ich habe gehört, es argumentiert, dass alle Software-Engineering nach der ersten Codezeile Wartung ist. Und das scheint sicherlich meiner Erfahrung zu entsprechen. Der einzige Code, den ich geschrieben habe, der nicht die meisten Wartungskosten verursacht hat, war Code, der so erfolglos war, dass er nie oder nur kurz verwendet wurde.

Ich denke, Sie können disziplinierte Ingenieurteams finden, die starke Prozesse entwickeln und befolgen, die zur Veröffentlichung von robustem Code führen, in den das Team ein hohes Maß an Vertrauen haben kann (obwohl ich dies nicht mit großen Mengen an Dokumentation konvolutieren würde). Ich glaube, dass ich im Moment in einem solchen Team arbeite. Obwohl ich sicherlich die andere Art der Entwicklung erlebt habe.

Was ich jedoch zu schätzen gelernt habe, ist, dass die Herausforderung nicht immer darin besteht, den perfekten Algorithmus oder die sauberste Lösung für das Problem zu finden. Oft werden jedoch alle möglichen Einschränkungen (Ressourcen, Wissen, Geld, Zeit, Fähigkeiten, Risiken, Schulungen für bereits vorhandene Benutzer usw.) gegeneinander abgewogen, um die höchste Rendite für die verfügbaren Investitionen zu erzielen. Das ist der Aufbau eines Systems, das all diesen Faktoren und nicht nur den technischen Einflüssen am besten entspricht.

Eine Menge Software schafft es einfach nicht bis zu dem Punkt, an dem sie gebraucht / gekauft wird. Wenn man es schafft, neigt es dazu, herumzuhängen und ist nur bei der Wartung "durcheinander".

Die Benutzererwartungen an Features steigen täglich, in vielen Bereichen sind sie jedoch in technischen Bereichen geringer. Nehmen wir an, die Software für Banktransaktionen ist so solide und professionell wie ein modernes Automobil. Die Handhabung des Volumens ist ein modernes Wunder, aber wie steht es um die Zuverlässigkeit jeder Transaktion? Nicht so viel. Dein Beitrag über den ersten Mist deines Welpen auf dem Teppich wurde fallen gelassen, na und. Es ist eher wie mit den kleinen Plastiktüten im Supermarkt. Sie machen Milliarden von ihnen, sie zerreißen und werden weggeworfen. Die meisten Leute interessieren sich nicht genug, um eine bessere Tasche zu fordern.

Ich denke, dass irgendwann Qualitätssoftware hergestellt wird. Ein Teil davon kommt früher auf den Markt als die meisten kommerziellen Produkte. Wer darf in der Beta ein Auto fahren?