Ich arbeite mit jemandem zusammen, der darauf besteht, dass jeder gute Softwareentwickler sich in jeder Softwaretechnologie entwickeln kann, und Erfahrung in einer bestimmten Technologie spielt für die Erstellung guter Software keine Rolle. Seine Analogie war, dass Sie keine Kenntnisse über das zu bauende Produkt haben müssen, um zu wissen, wie man eine Montagelinie baut, die dieses Produkt herstellt.
In gewisser Weise ist es ein Kompliment, mit einem Auge gesehen zu werden, dass "wenn du gut bist, bist du in allem gut", aber in gewisser Weise trivialisiert es auch den Beruf, wie in "Codemonkey, go sling code". Ohne Erfahrung mit bestimmten Software-Frameworks können Sie schnell in Schwierigkeiten geraten, und das ist wichtig.
Ich habe versucht, das zu erklären, aber er hat es nicht gekauft. Irgendwelche unterschiedlichen Ansichten oder Gedanken dazu, um zu erklären, dass meine Erfahrung in einer Sache nicht auf alle Dinge übertragen werden kann?
quelle
Antworten:
Ich würde das Gegenteil argumentieren. Ein guter Softwareentwickler hätte die Fähigkeit, qualitativ hochwertige Software unabhängig von der Technologie zu konzipieren, zu entwerfen und zu entwerfen. Das entgegengesetzte Ende dieses Spektrums ist die .NET oder Java oder PHP nur „codemonkey“ , das gut ist in Richtung gegeben wird oder Spezifikationen und unter Verwendung des Werkzeugs um die Software zu implementieren.
Ein Softwareentwickler muss nicht alle Werkzeuge beherrschen, sollte aber ein ziemlich gutes Verständnis dafür haben, was die meisten von ihnen sind, was sie auf den Tisch bringen und was für das jeweilige Projekt wahrscheinlich am besten geeignet ist . Ich würde erwarten, dass ein Code-Affe nur ein Meister seines proklamierten Fachwissens in einem bestimmten Werkzeug ist.
Ich würde keinem Ford-Ingenieur vertrauen, der nicht weiß, wie er die Arbeit des Mechanikers erledigen soll.
Dennoch ist Software-Engineering eines dieser Bereiche, in denen in vielen Fällen erwartet wird, dass wir gleichzeitig Ingenieur, Bauherr und Mechaniker sind.
quelle
Ich stimme in gewissem Maße der Person zu, mit der Sie arbeiten. Ein guter Softwareentwickler befasst sich mit allgemeinen Prinzipien des Designs und der Softwareproduktion. Die tatsächlichen Sprachen und Frameworks sind Details.
Das soll nicht die Leichtigkeit trivialisieren, mit der Sie neue Sprachen und Frameworks erlernen können. Mit ihnen ist immer eine Lernkurve verbunden, aber der Punkt ist, dass es sich um eine Kurve handelt, nicht um eine vertikale Wand für einen guten Softwareentwickler.
Ein guter Softwareentwickler verfügt über eine breite Erfahrung in einer Reihe verschiedener Tools und Technologien. Wenn nicht, wie kann er dann das beste Werkzeug für den Job auswählen? Um das alte Klischee auszurotten, sieht für einen Mann, der weiß, wie man einen Hammer benutzt, jedes Problem wie ein Nagel aus. Selbst wenn Sie kein Experte mit einem Schraubenzieher sind, lohnt es sich, ein vorübergehendes Verständnis dafür zu haben, damit Sie eine Schraube nicht nur als einen lustig aussehenden Nagel erkennen können.
quelle
TLDR-Version: Andere Ingenieurdisziplinen benötigen Kenntnisse über die von ihnen verwendeten Materialien (z. B. müssen Architekten wissen, wie viel Last die Materialien tragen können, die sie in ihrem Entwurf verwenden ). Die Sprachen und Frameworks, die wir für das Software-Engineering verwenden, haben bestimmte Grenzen, und wir müssen mit ihnen vertraut sein, um sie effektiv zu entwerfen und zu entwickeln.
Was wir tun, besteht aus zwei unterschiedlichen Phasen. Das erste ist Konzeption. Dies ist ein Systemdesign auf hoher und niedriger Ebene (z. B. unter Verwendung von UML). High-Level-Designs können theoretisch implementierungsunabhängig sein (obwohl manchmal ein High-Level-Design Besonderheiten wie Datenbankplattform, Standard-Middleware usw. berücksichtigen muss). Low-Level-Designs sind etwas kniffliger. Sie können die Besonderheiten der Geschäftslogik entwerfen, ohne die Infrastrukturdetails in diese einzutragen. Auch diese können theoretisch plattformunabhängig sein.
Die zweite Phase ist die eigentliche Programmierung. Während einige die Programmierung als Konstruktion betrachten, argumentieren andere (einschließlich mir), dass das Codieren immer noch eine Designdisziplin ist (in PPP bezieht sich Bob Martin auf einen Artikel, in dem der Autor ein sehr gutes Argument für diesen Effekt vorbringt, mit dem ich es nicht habe Ich jetzt, aber ich werde diese Antwort mit einem Link zu diesem Artikel aktualisieren. Die eigentliche Konstruktion erfolgt, wenn Sie auf Kompilieren klicken, und ist praktisch kostenlos.
So wie ein Architekt Dinge wie die Zug- und Druckfestigkeit der von ihm verwendeten Baumaterialien berücksichtigen muss, muss auch ein Softwareentwickler die Fähigkeiten der Plattform kennen, gegen die er entwickelt, wenn er Code schreibt. Ich würde argumentieren, dass ein Low-Level-Systemdesign nicht sehr effektiv ist, wenn es nicht auch die Plattformauswahl berücksichtigt.
quelle
Als jemand, der ein Software Engineering-Studium abgeschlossen hat, kann ich sagen, dass Ihr Mitarbeiter teilweise richtig ist. Ein guter Softwareentwickler konzentriert sich auf die Anwendung von Mathematik, Statistik, Informatik und Domänenerfahrung, um ein System aufzubauen. Die Methoden, die ein Softwareentwickler verwendet, sind in der Regel technologie- und sprachunabhängig - die Tools sind weniger wichtig als die zugrunde liegenden Prinzipien.
Die Analogie Ihres Kollegen ist jedoch fehlerhaft. Das Verständnis der Domänenprobleme ist für jede technische Disziplin von wesentlicher Bedeutung. Wenn Sie das Problem, das Sie zu lösen versuchen, und die Menschen, die Sie zu befriedigen versuchen, nicht vollständig verstehen, wird es unendlich schwieriger, die bestmögliche Lösung für ihre Probleme zu finden.
Letztendlich geht es beim Software-Engineering (und jeder technischen Disziplin) darum, eine Reihe von Konzepten anzuwenden, um ein Problem zu lösen. Wenn Sie häufig dieselben Tools verwenden, werden Sie mit diesen Tools besser vertraut. Es wird für Sie einfacher sein, Probleme zu identifizieren, die diese Tools lösen können, die Risiken oder Fallstricke bei der Verwendung dieser Tools und dann diese Tools zu verwenden, um eine Lösung zu erstellen.
quelle
Dies ist mit ziemlicher Sicherheit falsch. Spezialisierte Produktionsingenieure müssen viel über die von ihnen betreuten Produkte wissen.
Eine bessere Analogie besteht auf jeden Fall bei Absolventen von Maschinenbaukursen: Obwohl jeder (sowohl in Mech als auch in Software) mit den gleichen Fähigkeiten anfängt, bleibt niemand "ein Maschinenbauingenieur", sondern spezialisiert sich auf die Arten von Dinge, die sie bauen. Ebenso hat die Softwareentwicklung sehr unterschiedliche Unterfelder.
Um zur Fließbandanalogie zurückzukehren, ist jedes Fließband für jedes Produkt unterschiedlich, und unterschiedliche Arten der Softwareentwicklung erfordern unterschiedliche Methoden. Sie würden Ihre Sicherheitssoftware nicht so erstellen, wie Sie ein Spiel erstellen.
quelle
Es gibt eine Lernkurve, die mit verschiedenen Spezialisierungen verbunden ist. Ich spreche über Unterschiede zwischen Embedded- / Echtzeitprogrammierung, Web-App-Programmierung, System- / Betriebssystemprogrammierung, Thick-Client-Programmierung, mobiler Entwicklung usw.
Jemand, der Experte für eine Art von Programmierung ist, kann aufgrund unterschiedlicher Anforderungen möglicherweise nicht sofort in eine andere wechseln. Sicher, ein Softwareentwickler hat die Grundlagen dazu, aber es braucht Zeit, um sich auf etwas zu spezialisieren.
quelle
Ich stimme der Prämisse zu, die Ihr Kollege vorschlägt, obwohl ich eine Einschränkung hinzufügen würde.
Ein guter Softwareentwickler kann in jeder Technologie gute Software erstellen ... nachdem er ein wenig in der neuen Technologie gelernt hat.
Es mag einige Macken geben, die zunächst nicht offensichtlich sind, aber ein guter Softwareentwickler wird sie bald lernen.
Ich denke, was er wirklich meint, ist, dass nur weil ein Entwickler über 2 Jahre solide C # -Erfahrung verfügt, dies nicht bedeutet, dass ein besserer Softwareentwickler mit Java-Hintergrund, der noch nie zuvor C # gemacht hat, nicht mitkommen, C # lernen und schnell werde ein besserer C # -Entwickler als der erste.
Mit anderen Worten, Sie sollten den Java-Typ nicht unbedingt für einen Job rabattieren, NUR weil er in C # "die Zeit erledigt" hat.
quelle
Ein typisches Beispiel: Das Software-Framework, von dem Sie glauben, dass es so wichtig ist, über spezielle Erfahrungen zu verfügen, gab es vor 10 Jahren noch nicht oder es hat sich in diesem Fall erheblich verändert. Die Natur unseres Berufs macht es unmöglich, sich auf die gesamte Karriere zu spezialisieren. Abhängig von Ihren jeweiligen Fähigkeiten bietet Ihnen Ihre Spezialisierung einen Vorteil zwischen 1 und 6 Monaten gegenüber jemandem, der Ihr spezielles Framework noch nie verwendet hat. Danach sind Sie auf Augenhöhe.
quelle
Ich arbeite für eine Hubschrauberfirma und die Luftfahrtingenieure hier sind auf die Flugzeugtypen spezialisiert, mit denen sie arbeiten können. Sie müssen "typgeprüft" sein. Technisch konnten sie an allem arbeiten, von einem Robinson R22 bis zu einem Jumbo Jet, aber nicht ohne das Konvertierungstraining.
Ich denke, dies ist dem Software-Engineering ziemlich ähnlich, außer dass das "Conversion-Training" für Software-Ingenieure informeller ist.
quelle
Würden Sie ihm im Gespräch mit einem Maler sagen, dass er keine Probleme mit der Bildhauerei haben würde?
Das Erlernen einer neuen Sprache oder von Besonderheiten in einem neuen Bereich ähnelt einem Künstler, der sich hauptsächlich mit Bleistift und Tinte befasst und das Malen lernt (oder umgekehrt). Dies ist, worüber die meisten anderen Antworten sprechen, wie Ihr Freund teilweise richtig ist - viele der gleichen Konzepte gelten.
Aber einem Maler beizubringen, wie man ein 3D-Objekt modelliert oder einen Roman schreibt (beide Formen des künstlerischen Ausdrucks), ist ein ganz anderes Tier. Das ist der Standpunkt, von dem Sie kommen.
Webbasierte Software erfordert ein völlig anderes Denken als Desktop-Software. Beide sind völlig unterschiedlich, wenn sie auf Spiele oder eine Arbeitsumgebung angewendet werden. Ich vermute, dass die Arbeit an einem Betriebssystem oder integrierten Systemen auch ein anderes Denken erfordert (aber ich habe keine Erfahrung damit). Und ich habe keinen Zweifel, dass es andere Bereiche gibt, die ebenfalls eine andere Denkweise erfordern.
Zusammenfassung und Beispiele:
"Kunst" umfasst Skulpturen, Romane, Comics und Gemälde. Fähigkeitsüberschneidungen umfassen:
... Und so weiter. Aber wie oben erwähnt, ist es unwahrscheinlich, dass ein Comiczeichner bei seinem ersten Roman gut abschneidet. Sie müssen anders denken.
Ebenso gibt es Überschneidungen in verschiedenen Bereichen der Programmierung / Softwareentwicklung, aber die meisten von ihnen sind zu unterschiedlich, um einfach hineinspringen zu können. Zum Beispiel:
quelle
Können alle Straßenbauarbeiter alle Geräte und Maschinen auf der Baustelle verwenden? Die Antwort ist nein. Es gibt Maschinen, die sie kennen und mit denen sie wahrscheinlich vertraut sind. Das Gleiche sollte für Softwareentwickler gelten. Es gibt x Sprachen und Frameworks, die Sie kennen, weil Sie jeden Tag mit ihnen arbeiten. Es sollte jedoch nicht erwartet werden, dass Sie die genauen Abläufe anderer ohne Schulung kennen. Es ist, als würde man den Presslufthammerarbeiter nehmen und ihm die Aufgabe übertragen, den Betonmischer anzutreiben.
Programmiersprachen und Frameworks sind nur Werkzeuge in einem Werkzeuggürtel für Softwareentwickler. Es gibt einige Tools, die Sie aufgrund Ihrer Erfahrung besser kennen als andere. Das beste Werkzeug ist letztendlich das Verständnis der Kernkonzepte und -prinzipien des Rechnens. Bei der Auswahl von Sprachen und Frameworks wird lediglich ausgewählt, welcher Schraubendreher für welche Schraube verwendet werden soll.
quelle
So etwas passiert oft dort, wo ich arbeite.
Ich vergleiche gerne mit dem Beruf des Onkels meiner Frau - einem Automechaniker.
Er ist auf Mercedes spezialisiert , er kann sein Wissen auf andere Automarken anwenden, und er tut es - einige davon eher selten, aber das bedeutet nicht, dass er Marke X sofort reparieren kann, weil Sie sagen, dass es ein Geräusch macht.
Ich programmiere in einigen Sprachen, aber das bedeutet nicht, dass ich weiß, warum Safari auf Ihrem MacBook die Seiten jedes Mal neu lädt, wenn Sie die Registerkarte wechseln (der heutige seltsame Aufruf). Ich werde versuchen herauszufinden, warum, aber ich werde es nicht genau wissen, weil das Computerfeld RIESIG ist .
In beiden Fällen könnten wir nach einiger Zeit in unseren jeweiligen Bereichen wahrscheinlich die Antwort herausfinden, aber nicht in den zehn Sekunden, die die Leute denken, weil "aber Sie arbeiten mit Autos" oder "aber Sie arbeiten mit Computern".
Sagen die Leute solche Dinge zu ihrem lokalen Arzt (wie "Ich habe Kopfschmerzen, welche Krankheit habe ich?") - ich wette, sie tun es, weil die meisten Leute wirklich nicht verstehen, dass es in einem Beruf mehr gibt als ihre unmittelbaren Erwartungen des besagten Berufes.
quelle