Erwartungen im Abschluss im Vergleich zu Realität [geschlossen

softwareengineering.stackexchange https://softwareengineering.stackexchange.com/questions/12589

Frage

Bei der Wahl, was wir studieren wollen und mit unserer Karriere und unserem Leben tun, haben wir alle einige Erwartungen daran, wie es sein wird. Jetzt, wo ich seit fast einem Jahrzehnt in der Branche bin, habe ich ein wenig darüber nachgedacht, was ich dachte (damals, als ich Informatik studierte), würde das Arbeitsleben sein und wie es sich tatsächlich herausstellt sein.

Meine zwei größten Schocks (oder sollte ich sagen, gebrochene Erwartungen) sind bei weitem die bloße Menge an Wartungsarbeiten, die an der Software beteiligt sind, und der allgemeine Mangel an Professionalität:

  1. Wartung: Bei der UNI wurde uns alle gesagt, dass die Mehrheit der Software -Arbeiten die Wartung bestehender Systeme ist. Ich wusste also, dass ich dies im Zusammenhang mit dem Zusammenfassung erwarte. Aber ich habe mir nie genau vorgestellt, wie überwältigend das sein würde. Vielleicht ist es etwas, über das ich mental verglasiert habe, und hoffte, ich würde viel mehr von Grund auf neue neue Sachen aufbauen. Aber es ist wirklich der Fall, dass die meisten Jobs überwiegend Wartung, Fehlerreparatur und Unterstützung sind.

  2. Mangel an Professionalität: Bei Uni hatte ich immer den Eindruck, dass kommerzielle Softwarearbeiten sehr prozessorientiert und streng konstruiert sind. Ich hatte Bilder von ISO -Prozessen, Unmengen der technischen Dokumentation, jede Funktion und jeden Fehler, der streng dokumentiert war, und eine allgemein professionelle Umgebung. Es war ein großer Schock zu erkennen, dass die meisten Softwareunternehmen für ein Team von Studenten, die an einem großen semesterlangen Projekt arbeiten, nicht anders arbeiten. Und ich habe sowohl im kleinen agilen Hack -Shop als auch im mittelgroßen Unternehmensunternehmen gearbeitet. Ich würde zwar nicht sagen, dass es immer "unprofessionell" war, aber es fühlt sich definitiv so an, als wäre die Softwareindustrie (insgesamt) weit entfernt von der starken technischen Disziplin, die ich erwartet hatte.

Hat noch jemand ähnliche Erfahrungen damit gemacht? Wie unterscheiden sich Ihre Erwartungen, wie unser Beruf aussehen würde, von der Realität?

War es hilfreich?

Lösung

Ich fühle dich Mann. Ich habe gerade vor etwas mehr als einem Jahr abgeschlossen und habe das erste Stellenangebot aufgenommen, das mir in den Weg kam und den größten Schock meines Lebens bekam.

Dinge, die ich nicht erwartet hatte:

Schulstress und Arbeitsstress sind nicht gleich- Der Stress, an einem Schulprojekt mit Freunden zu arbeiten oder alleine zu arbeiten, auch wenn diese drohende Abschlussfrist oder eine spezielle Projektverteidigung nicht mit dem Stress scheinbar unvernünftiger Arbeitsfristen, Kommunikationsprobleme (ein wenig Büropolitik) und Crunch verglichen werden mal.

Mangel an Best Practices- Wie Ihre Erfahrung in der Professionalität. Bevor ich meinen ersten Job annahm und während meiner Trainingszeit überprüfte und über Best Practices sowohl in der Programmierung als auch in der Software -Engineering überprüft und gelesen wurde. Diese werden nicht so gut verfolgt, wie sie für unpraktische und, um faire, praktische Gründe zu sein sollten. Und manchmal zählt Ihr Wissen nur 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, um mich durchzubringen, war ich, gelinde gesagt, schockiert, als ich beim ersten Stück Code, den ich pflegen sollte, verblüfft anstarrte. Viele der Fähigkeiten, die ich jetzt verwende, wurden am Arbeitsplatz oder während meines Jobs erlernt, dass ich mich immer wieder frage, ob ich es ohne Hochschulabschluss hätte machen können. XD

Die Bedeutung der Kommunikation- Ich habe mir klar gemacht, wofür all diese Englischunterricht waren. Vor der realen Welt konnte ich die Relevanz nicht sehen, drei bis vier verschiedene Englischunterrichts im College zu haben, wenn sie seit unserer Zeit in der ersten Klasse unterrichtet wurden. Sie verwenden Ihren Job nicht, wenn Sie mit einem Computer sprechen können, aber nicht mit Menschen sprechen können.

Andere Tipps

Der größte Teil der Arbeit, die Sie tun, ist nicht bahnbrechend

Als ich bei Uni an KI-Routinen arbeitete, um Fußball-Roboter zu kontrollieren, baute ich Compiler und hackte Kernel des Betriebssystems.

Aber in der realen Welt 99%* der Softwareentwicklung ist eigentlich ziemlich langweilig. Ich habe immer Architekten oder Bauherren bewundert, die, als ich gefragt wurde: "Was machst du beruflich?" kann auf ein Gebäude oder was auch immer hinweisen und sagen: "Ich habe es getan das". Aber die meisten Softwareentwickler können das nicht tun. Auf die Frage" Was machen Sie beruflich? " Verarbeitete SMS -Nachrichten für Radiosender und dergleichen ... Ich könnte sagen: "Sie wissen, wenn Sie in einen Radiosender schreiben, um für ein Lied zu stimmen. Nun, ich habe die Software geschrieben, die diese Stimmen und Dinge verarbeitet. So cool wie in der Lage zu sein, auf ein Gebäude zu verweisen und zu sagen: "Ich habe das gebaut."

Natürlich da sind Leute, die sagen können "Ich habe an Windows gearbeitet" oder was auch immer, aber ich bin sicher, sie sagen niemandem, dass ich aus Angst vor der nächsten Frage meinen Drucker nicht zum Laufen bringen kann, können Sie das beheben mich?"


* und 62% aller Statistiken sind vor Ort zusammengesetzt

Wenn Sie sich heute über die Objektiv der Geschichte des Ingenieurwesens auf Software befassen, ist es sicherlich technisch technisch - aber es ist die Art von Ingenieurwesen, die Menschen ohne das Konzept des Bogens getan haben. Die meisten Software sind heutzutage einer ägyptischen Pyramide mit Millionen von Ziegeln, die übereinander gestapelt sind, ohne strukturelle Integrität, sondern nur mit brutaler Kraft und Tausenden von Sklaven. -Alan Kay, 2004

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

Ich bin kein Industrie -Tierarzt; Ganz im Gegenteil, ich bin ein Absolvent in letzter Zeit, aber von einer Top -CS -Schule in den USA, aber mein instinktives Gefühl ist, dass die Art und Weise, wie wir Software bauen, falsch ist. Anstatt die Pause -Taste zu treffen und die Grundlagen des Programms zu überprüfen, haben wir gerade mit datierten Modellen aus den 50er Jahren nach vorne geeilt. Wenn wir so weitermachen, werden wir nie vorbeikommen, wo wir uns befinden. Menschen können die Komplexität der Dinge, die die Größe der MS Windows -Codebasis haben, einfach nicht verwalten. 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 Software -Läden Software zu machen scheinen, indem sie sie ohne ein tiefes Verständnis der grundlegenden Prinzipien zusammenhacken.

Ich habe keinen Abschluss gemacht, aber ich habe ein bisschen in Bibliotheken und Labors an Hochschul- und Universitätslabors abgeholt.

  • Großes Eisen - Die Technologien, die sie unterrichteten, waren hauptsächlich Mainframes und Minicomputer. Der Dekan eines Colleges sagte mir, ich würde keinen Job bekommen, weil ich nicht einmal wusste, was eine Masterfile war. Ich hatte nicht die Absicht, an Mainframes zu arbeiten, da ich mir keine leisten konnte, aber ich würde nicht so dumm sein, dass ich nicht leicht vorbereitet bin. Vaxen war cool und ich freute mich darauf, in meiner Kabine für den Code für meinen eigenen Mikrovax bezahlt zu werden. Was für eine Schande dieser Markt völlig implodiert. (Wie sich herausstellte, hatte ich zwei Positionen mit Mainframes… als Auftragnehmer für IBM.)

  • Softwareentwicklung - Auf den Fersen von strukturierten Programmier-, SASD- und anderen Entwurfsmethoden haben Sie vielleicht gedacht, wir würden echte Ingenieure sein. Ich tat. Aber die Lehrer gaben nur sehr wenig Anleitung zu den Designtechniken, die ich in der Bibliothek gelesen habe. Die Schüler mussten für sich selbst sorgen, und Micros machte es zu einfach, in Code zu drücken, bis sie eine Antwort erhalten, mit der sie zufrieden waren. Ich wusste nicht, wie viel schlimmer es auf dem Arbeitsmarkt war. Irgendwie musste ich ziemlich viel neuen Code machen, also war es nicht so langweilig. Aber ich habe auch viel übernommen und sie waren schon schlimm genug, es war wie ein neues Projekt, weil ich viel Code reparieren musste. Es war eine Kombination aus Erforschung bestehender Funktionen und Erstellen neuer Code (sein Ersatz); Schreiben von Tools zur Vereinfachung des Prozesses und der Einführung eines besseren Projektmanagements.

  • High-Tech-Karriere - Es ist eine Sache, wenn die Schulen alte Gebäude und Ausrüstung haben (die Punschkartenausrüstung wurde im Semester ersetzt, bevor ich 1984 begann… Bei der Support-Linie werden Sie feststellen, dass Ihre Stellenbeschreibung wahrscheinlich nicht das Kochen von Popcorn mit einem 5-Megawatt-Laser beinhaltet.

  • Entwicklung ist hauptsächlich Teamwork. Das bedeutet, dass Kommunikation (gesprochen und gelesen), das Code anderer zu lesen und frühere Module (sowohl im Haus als auch in der Außenverkehrszahl) zu lesen, fast jeden Tag zu sehen ist. In meinem College musste ich zumindest in sehr wenigen Gelegenheiten mit mehr Menschen codieren, also dachte ich, dass der Hauptteil der Arbeit darin bestand, allein in der Wildnis zu codieren. Es ist nicht.
  • Nichtentwicklern zu erklären ist schwer, Dinge zu erklären, ist schwer (Auch für den ersten Punkt abgedeckt) und ist in Ihrer Verantwortung, Ihre Punkte (nicht von den anderen 99% der Welt) zu machen.
  • Der gute Test ist der Test, der fehlschlägt. (zumindest zum 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 zeitaufwändiger) Teil Ihres Jobs.
  • Es gibt keine silbernen Kugeln. Jede Technologie hat ihre Vor- und Nachteile.
  • Das College lehrt Sie nicht hochmoderne Technologien. Aber auch 90% der Arbeiten verwenden ziemlich alte Technologien. Was übrigens manchmal benötigt wird.
  • Nichttechnische Menschen treffen Entscheidungen über technische Lösungen, hauptsächlich aus esoterischen Gründen wie Wartung, Partnerschaft, Verfügbarkeit des Arbeitnehmers ...
  • Du fing gerade erst an, jung Padawan.

Ich habe seitdem begonnen, über die Tatsache zu erkennen, dass die Codierung eine Arbeit ist, die Sie in Verbindung mit mehr Menschen machen, insbesondere jetzt, wo Open-Source stärker ist. Aber als ich am College (späte neunziger Jahre) war, war ich davon überzeugt, dass ich Dinge von Grund auf neu machen und nie in den Code eines anderen untersucht oder mit anderen koordinieren musste ...

Rückblickend für mich ist einer der besten Teile Lernen und andere unterrichten.

  • Computerprogrammierung ist nicht physisch und nicht intuitiv.
    • Wenn ein Hausbauer seine Arbeit beendet, kann er/er herumlaufen und sofort sehen/fühlen, wenn etwas falsch ist. Ein Computerprogrammierfehler kann nicht auf die gleiche Weise entdeckt werden und kann monatelang oder sogar Jahrzehnte im System lauern.
    • Während ein Programmierer durch Code -Überprüfung einen Quellcode aussieht/spürt, wird nicht garantiert, dass jeder im Code enthaltene Fehler entdeckt wird. Ein Computer könnte jedoch jedes Mal den Fehler reproduzieren, indem das Programm mit bestimmten Eingaben ausgeführt wird. Das menschliche Verständnis eines Stücks Quellcode ist daher immer ein unvollkommenes Modell, dass es sich um die Anweisungen für einen Computer handelt.
  • Es ist sehr einfach, ein Programm zu codieren, das die häufigsten Fälle abwickelt, aber die Kantenfälle vollständig behandelt.
    • In anderen Disziplinen ist es relativ einfach, eine Abhilfemaßnahme nach dem Fakten anzuwenden. Möglicherweise gibt es sogar ein Wissenskörper, das speziell den Abhilfemaßnahmen gewidmet ist. Es gibt keine so etwas in der Softwareentwicklung.
    • Glücklicherweise hilft die testgetriebene Entwicklung bei der Kodifizierung der Kantenfälle, die der Code verarbeiten soll.
    • Hinzugefügt Auf der anderen Seite scheinen bestimmte Methoden zur Softwareentwicklung darauf hinzudeuten, dass wir den Geschäftswert (schnellerer Zeitpunkt usw.) extrahieren können, indem wir uns bewusst dafür entscheiden, keine Randfälle zu bearbeiten und diese Entscheidungen den Kunden zu vermitteln.
  • Kunden finden Unternehmenswerte in einer Software, die nur die häufigsten Fälle behandelt. Daher sind Softwareanbieter nicht allzu besorgt über die Behandlung der seltenen Fälle.
    • Kunden lernen einfach, die groben Kanten zu vermeiden.

Hinzugefügt

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

Hinzugefügt

Meine zwei Cent: Gewöhnen Sie sich einfach daran.

Bilder von ISO -Prozessen, Unmengen der technischen Dokumentation, jeder Funktion und jeder Fehler, die streng dokumentiert sind, und eine allgemein professionelle Umgebung beschreibt meine Firma ziemlich gut. Wir machen jedoch kritische Infrastruktur -Software-/Hardwareprodukte. Nun, der Druck ist also der Druck an Für Qualität (wir sind zum Beispiel ISO 9001 zertifiziert).

Ich dachte nach dem Abschluss, dass die verantwortlichen Menschen gute Arbeit aus schlechter Arbeit erkennen könnten. Nachdem Sie die millionste Kopie von "wirklich großartiger Code unserem Top -Codierer zusammengestellt" erhalten hatten und sie so aussehen lassen:

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 vor sich geht. "Großartig" bedeutet Wartungsalptraum, "gut" bedeutet Crash in einer sanften Brise, und "schreckliches Chaos" bedeutet entweder diese oder eine gut strukturierte Code -Basis, deren Ingenieure sich offensichtlich geweigert haben, obszöne Fristen einzuhalten, um ihre geistige Gesundheit zu behalten.

Ich habe gehört, dass alle Software -Engineering nach der ersten Codezeile die Wartung sind. Und das scheint sicher zu meiner Erfahrung zu passen. Der einzige Code, den ich geschrieben habe, der nicht die meisten Kosten für die Wartung hatte, war Code, der so erfolglos war, dass er nie oder nur kurz verwendet wurde.

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

Das, was ich jedoch zu schätzen gelernt habe, ist, dass die Herausforderung nicht immer den perfekten Algorithmus oder die sauberste Lösung für das Problem findet. Aber oft handeln Sie alle möglichen Einschränkungen (Ressourcen, Kenntnisse, Geld, Zeit, Fähigkeiten, Risiken, bereits bestehende Benutzerschulungen usw. usw.), um die höchste Rendite für die verfügbare Investition zu erzielen. Dies baut ein System auf, das am besten für all diese Faktoren und nicht nur für technische Einflüsse geeignet ist.

Viele Software schafft es einfach nicht so weit, dass sie genug verwendet/gekauft wird. Wenn man es schafft, bleibt es in der Wartung tendiert und ist nur miteinander "durcheinander".

Die Erwartungen der Benutzer steigen jeden Tag für Funktionen, in vielen Bereichen sind sie jedoch in den Bereichen Engineering niedriger. Nehmen wir an, die Banken -Transaktionssoftware ist ebenso solide und professionell konstruiert wie ein modernes Auto. Das Umgang mit dem Volumen ist ein modernes Wunder, aber was ist die Zuverlässigkeit jeder Transaktion? Nicht so viel. Ihr Beitrag über den ersten Mist Ihres Welpen auf dem Teppich wurde fallen gelassen, na und. Es ist eher wie die kleinen Plastiktüten im Lebensmittelgeschäft. Sie machen Milliarden von ihnen, sie reißen und zerreißen und werden weggeworfen. Die meisten Menschen kümmern sich nicht genug darum, eine bessere Tasche zu fordern.

Ich denke, qualitativ hochwertige Software wird schließlich gemacht. Einige davon trifft früher auf den Markt als die meisten Kamer -Produkte. Wer darf ein Auto in Beta fahren?

Lizenziert unter: CC-BY-SA mit Zuschreibung
scroll top