Graduiertenerwartungen versus Realität [abgeschlossen]

50

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?

Bobby Tische
quelle
4
Dies ist eine sehr interessante Frage, da ein Student fast die Universität verlassen hat! Ich kann es kaum erwarten, ein paar Antworten zu sehen
Mike42
8
Was Sie jetzt sehen, ist die Realität. Andere lustige Fakten, die ebenfalls zur Realität gehören, sind: Milliarden von Menschen ohne Nahrung, Analphabeten, unter ständiger Bedrohung durch Kriegsführung, dem bevorstehenden Zusammenbruch des Finanzmarktes usw. Mit anderen Worten, das College ist ein wunderbares Feld für Realitätsverzerrungen, und die Menschen können es Lerne viel über Lehrbücher im Schutz dieses Gebietes.
rwong
Sie sollten erwarten, was Sie wollen. Wenn sich herausstellt, dass etwas weniger ist, als Sie erwartet haben, akzeptieren Sie das nicht als Realität. Seien Sie Vorreiter und setzen Sie Ihre Erwartungen in die Realität um!
Atomix
1
Ich liebe es zu programmieren. Ich hasse die Realität, wie Software in der "realen" Welt entwickelt wird. Was Sie beschreiben, ist eine ziemlich genaue Darstellung der Situation in der Softwareindustrie.
Captain Sensible
Als Fresh Jr.Software Engineer erlebe ich das auch. Ich dachte, das ist nur in meinem Land. Jetzt bekomme ich die ungeschriebene Funktion der Softwareentwicklung.
Parmanand

Antworten:

27

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.

Jonn
quelle
5
+1 Die Bedeutung der Kommunikation. Was # 2 betrifft, so mangelt es nicht an Best Practices. es sind (i) zu viele Best Practices und (ii) das vorherrschende mangelnde Interesse daran, irgendwelche zu befolgen.
rwong
1
+1 für die Spitze des Eisbergs! So viele Absolventen denken, sie wissen alles, jetzt habe ich das Gefühl, ich weiß weniger als je zuvor!
billy.bob
+1 Einige gute Punkte hier. Oft liegt der Grund für das Fehlen von Best Practices / Systemen / Verfahren in den Anschaffungskosten (dh es sind Investitionen erforderlich, um sie zu kaufen) - aber der Preis dafür, dass sie nicht zur Verfügung stehen, ist eine erhöhte Wartung oder, schlimmer noch, ein Produktfehler durch außer Kontrolle geratene Fehlerlisten oder Anforderungen nicht erfüllen .. welche gute Kommunikation helfen könnte zu vermeiden :-)
JBRWilkinson
2
Ich mag diese Antwort. Das ist ein guter. Und ich frage mich: Warum gibt es keine Art "Praktikum", das alle Ärzte absolvieren müssen? Eine langwierige berufliche Übergangszone, in die man involviert sein kann, ohne jedoch den kritischen Pfad eines Projekts zu stören. Einige große Unternehmen haben das vielleicht, aber es ist einfach kein universeller Standard in diesem Beruf. Doch die Arbeit, die viele Programmierer / SW-Entwickler / SW-Ingenieure leisten, ist für Organisationen aller Art genauso gefährlich und kritisch wie die Arbeit, die Ärzte für Einzelpersonen leisten.
DarenW
1
Wenn möglich, gebe ich zusätzlich +1 für die Spitze des Eisberges!
DarenW
18

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

Dean Harding
quelle
1
Dies ist wahr, aber nicht bahnbrechend bedeutet nicht, dass es nicht entscheidend oder wichtig ist. Es gibt viele Anwendungen, die nicht bahnbrechend sind und die ohne Support und Fehlerbehebungen abstürzen könnten, sagen unsere Wirtschaft (auf der extremen Seite ...) ... und es wird immer Innovationen geben, die von Zeit zu Zeit vom Projekt abhängen ...
Aggietech
3
Viele von uns gehen jeden Tag neue Wege. Es ist vielleicht kein Heilmittel gegen Krebs, aber wir feiern die kleinen Erfolge mit High-Fives, einer Runde Kuchen / Muffins / Donuts usw., um den Moment zu markieren. Viele Jobs, nicht nur die Programmierung, haben keine Ausgabe, die Sie Ihren Freunden / Familie zeigen können, aber das ist eine Frage des Rahmens: Sie könnten sagen "Ich konfiguriere Netzwerk-Switches, DNS-Server und Firewalls", oder Sie könnten dies umformulieren als "Sie kennen das Internet - Facebook, YouTube, Twitter und all das? Nun, ich helfe dabei, dass es funktioniert".
JBRWilkinson
1
@ JBRWilkinson: +1. Der beste Fall von "Umrahmung", den ich hatte, war bei einem früheren Job, bei dem ich an der NurseCall-Beeper-Software für Krankenhäuser arbeitete. Man könnte etwas Allgemeines dazu sagen, wie "Ich habe Programme geschrieben, die Piepser ausführen". OTOH, Sie können auch sagen "Ich habe Software geschrieben, die Krankenhäusern geholfen hat, besser zu laufen, und ich habe wahrscheinlich Leben gerettet !!". Hatte bis jetzt nicht daran gedacht ... aber statistisch ist es wahrscheinlich wahr. Ich fühle mich jetzt viel besser in diesem Job. Das heißt, diese Software ist dank meiner Bemühungen früher in Produktion gegangen usw. Könnte wirklich Leben gerettet haben. :)
Bobby Tables
1
@Guzica: Dass Sie täglich zur Rettung von Menschenleben beitragen können, ist wahrscheinlich die beste Arbeitszufriedenheit, die man haben kann - gut gemacht!
JBRWilkinson
1
Haha, ausgezeichnete Antwort und +1 für Humor!
Captain Sensible
17

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.

Maharishi
quelle
Als relativ neuer grad, ich habe den Eindruck , dass die Art und Weise , dass eine Menge von Orten zu tun Software ist falsch, aber dass mein aktueller Ort der Beschäftigung ist ... nicht perfekt, aber sie versuchen, und es funktioniert besser viel aus . Sicherlich scheint es eine ganze Reihe von Orten zu geben, die einen schrecklichen "Brute Force" -Ansatz verfolgen ... aber wenn Sie sich an einem dieser Orte befinden, sollten Sie nach einem anderen Ort suchen.
1
Softwareentwicklung als Ganzes ist ein nicht revolutionärer, sondern ein evolutionärer Prozess. Natürlich könnte man theoretisch eine Pyramidenstruktur aus Kohlenstoffnanoröhren bauen, die stärker, haltbarer und leichter ist als die ägyptischen Pyramiden. Aber es ist weder praktisch noch machbar, dies zu tun. Wenn der Ort, an dem Sie arbeiten, wirklich schlecht ist, suchen Sie einen neuen Job. Lassen Sie sich ansonsten nicht zu sehr von Perfektion einfangen, da echte Programmieraufträge mit echten Einschränkungen verbunden sind (z. B. Zeit / Finanzierung). Denken Sie daran, dass "Theorie und Praxis identisch sind. In der Praxis ist dies nicht der Fall."
Evan Plaice
>>> Wir brauchen einen neuen Weg. Ich weiß nicht was das ist. - Auch sonst niemand, so geht es weiter!
Gary Willoughby
5

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.

Huperniketes
quelle
5
  • 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 .

Khelben
quelle
"Das College bringt Ihnen nicht die neuesten Technologien bei.": Ja und nein. In einigen Bereichen ist die Wissenschaft der Branche 20 bis 30 Jahre voraus, und davon kann man im College etwas lernen.
Giorgio
3
  • 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.

rwong
quelle
8
Hausbau im Vergleich zur Behebung von Fehlern, hmm? "Hey, ich habe gerade meinen Türknauf in die falsche Richtung gedreht und das Haus ist gerade verschwunden!"
xor_eq
3

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).

Paul Nathan
quelle
1
@Guzica: Eines der Unternehmen, für das ich gearbeitet habe, war ziemlich ingenieurorientiert. Nicht ISO9001-zertifiziert, aber recht formell nach strengen internen Prozessen. Die anderen waren, wie gesagt, nicht organisierter als eine Gruppe von CS-Studenten, die zusammen ein Abschlussprojekt durchführen.
Bobby Tables
2

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.

Wheaties
quelle
1

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.

flamingpenguin
quelle
Sehr gute Punkte. Zwei der mittleren und großen Unternehmen, in denen ich gearbeitet habe, haben einen starken Kontrast zwischen diesen beiden Fällen gezeigt. Der eine war stark ingenieurorientiert, und der andere arbeitet eher wie eine Gruppe von CompSci-Studententeams, die separate Projekte für das letzte Jahr in ihren eigenen Bläschen durchführen - und diese dann irgendwie später integrieren müssen. (Hinweis: Das Management unterstützt diese "Blasen" - der eigentliche Name - und denkt, dass es für Teams effizienter ist, getrennt zu arbeiten, als sich um die Integration während der Entwicklung zu kümmern. Ich mache keine Witze.)
Bobby Tables
1

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?

JeffO
quelle