Wie würden Sie erklären, dass Software-Engineering spezialisierter ist als andere Engineering-Bereiche? [geschlossen]


9

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?


7
Wenn Sie abstimmen wollen, können Sie sich zumindest dazu äußern, warum? Zumal Ihre Eingabe dazu beitragen könnte, die Frage neu zu formulieren / zu fokussieren.
Spencer Kormos

11
Erstens ist dies eine Beschimpfung und keine Frage, und zweitens ist es eine fehlerhafte Annahme, dass dies abgelehnt und geschlossen werden muss.

6
@JarrodRoberson Hier gibt es eine berechtigte Frage, denke ich. Es wird nach einer guten Erklärung gefragt, die nach einer Erklärung fragt, warum manche das Software-Engineering als mehr oder weniger spezialisiert betrachten als andere Engineering-Bereiche.
maple_shaft

7
@SpencerK Ihre Frage lautet "Ein zufälliger Typ hat eine schlechte Analogie gemacht, wie antworte ich", und nun, das ist nicht wirklich eine Frage. Fragen Sie einfach nach soliden Beweisen und / oder Referenzen, die seine Position stützen. Sie sind nicht derjenige, der sich hier beweisen muss.
Yannis

5
-1 weil ich mit Ihrer Prämisse nicht einverstanden bin. Software Engineering ist nicht spezialisierter als andere technische Bereiche. Sie können sowohl hochspezialisiert als auch verallgemeinert sein. Ein guter elektromechanischer Ingenieur ist möglicherweise kein guter biomedizinischer Ingenieur. Andererseits könnte ein guter Elektriker sowohl an Häusern als auch an Autos arbeiten.
zzzzBov

Antworten:


23

aber in gewisser Weise trivialisiert es auch den Beruf, wie in "Codemonkey, go sling code".

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.


8
Ich möchte auch betonen, wie wichtig es ist, Konzepte und Prinzipien gegenüber Sprachen und Werkzeugen zu verstehen.
Oded

+1 Eine meiner Lieblingsbeschwerden sind die Leute, die sagen "Ich bin ein C # -Entwickler ...". Und dann trink einfach die Kool-Hilfe und akzeptiere alles von MS als Evangelium. 10 Jahre Programmieren Ich habe über 11 Programmiersprachen gelernt und jede hat meine Programmierung in den anderen Sprachen massiv verbessert. Lernen Sie Software-Engineering! Keine Plattformen, die in 2 Jahren verschwunden sein werden.
Timothy Baldridge

+1 für Ford Engineer Referenz. Ich habe noch nie so über Software Engineers vs Programmers nachgedacht.
Dalin Seivewright

Ein Programmierer ist eine Teilmenge eines Ingenieurs, nicht umgekehrt.
Spencer Rathbun

11

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.


"Ein guter Softwareentwickler befasst sich mit allgemeinen Prinzipien des Designs und der Softwareproduktion." Die Herstellung eingebetteter Steuerungssysteme und Webanwendungen sind fast genau gleich , oder?
Marcin

@Marcin: Einige der Prinzipien sind ja. Der Punkt, den ich gemacht habe, ist, dass (zum Beispiel) das Entwerfen eines eingebetteten Systems in C oder Assembler die gleichen Prinzipien verwendet, obwohl die Werkzeuge unterschiedlich sind.
JeremyP

Diese Tools sind nicht so unterschiedlich und adressieren sehr ähnliche Problembereiche. Aus diesem Grund ist dies nicht hilfreich.
Marcin

1
@Marcin: Sie haben offensichtlich entweder nicht in Assembler oder nicht in C programmiert. Ich versichere Ihnen, dass C trotz des verbreiteten Mythos kein Assembler ist und die Programmierung in diesen Tools so unterschiedlich ist wie (sagen wir) die Programmierung in C und Ruby.
JeremyP

1
@Marcin, klar, und Bowling ist nur eine Frage des Umschlags aller Stifte. Ein Kinderspiel wirklich. Während Webprogrammierung und eingebettete Programmierung einige allgemeine Prinzipien und Best Practices teilen können, sind die Einschränkungen, die die Implementierung dieser Praktiken regeln, das, was die tägliche Arbeit wirklich regelt. Während Sie können schließlich in der Lage sein , einen Web - Programmierer wie und Embedded - Ingenieur und vice versa umschulen, sind sie nicht fungibel.
Charles E. Grant

5

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.


5

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.


Die zugrunde liegenden Prinzipien können sehr unterschiedlich sein.
Marcin

1
@Marcin Nein, das tun sie nicht. Die Informatik ändert sich nicht, wenn sich die Technologien ändern. Die Mathematik ändert sich nicht. Statistiken ändern sich nicht. Anforderungsanalyse, Systemdesign, Konfigurationsmanagementpraktiken, Verifizierungs- und Validierungsstrategien, Qualitätsprinzipien ...
Thomas Owens

Tatsächlich ändern sich "Anforderungsanalyse, Systemdesign, Konfigurationsmanagementpraktiken, Verifizierungs- und Validierungsstrategien, Qualitätsprinzipien" zwischen den Problembereichen. Wenn Sie das nicht erkennen, werden Sie wahrscheinlich einen sehr, sehr schlechten Job in einer Domäne machen, die Sie nicht kennen, weil Sie zu arrogant sind, um zu erkennen, was Sie nicht wissen. Auch die anwendbare Mathematik ändert sich ziemlich stark, aber ich wette, Sie stellen sich vor, Sie wissen auch alles über Mathematik.
Marcin

@Marcin Ich habe in allen Bereichen gearbeitet, von eingebetteten Systemen bis hin zu Webanwendungen. Sie ändern sich nicht so sehr. Die Eigenschaften einer guten Anforderung ändern sich nicht je nach Domain. Die zum Entwerfen eines Systems verwendeten Tools ändern sich nicht. Wie Sie qualitativ hochwertige Systeme messen und erreichen, ändert sich nicht.
Thomas Owens

1
Ja, Sie haben Recht, jedes Softwareprojekt auf der Welt ist das gleiche und Sie haben herausgefunden, wie Sie jedes einzelne Projekt verwalten können. Sie sollten wahrscheinlich ein Buch schreiben, in dem die One True Way zum Schreiben und Verwalten der gesamten Software erläutert wird.
Marcin

4

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.

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.


1
Die Softwarekonstruktion auf derselben Ebene ist unabhängig vom Softwareprodukt gleich. Wir nennen sie nur Methoden anstelle von Fließbändern , aber sie sind konzeptionell dasselbe.

1
@JarrodRoberson Nein. Montagelinien sind nicht einheitlich und Methoden sind nicht allgemein anwendbar.
Marcin

2
Ich stimme Marcin zu, Sie müssen Kenntnisse über ein Produkt haben, um eine Montagelinie für das Produkt zusammenstellen zu können. Sie müssen in der Lage sein, die zu verwendenden Werkzeuge genau auszuwählen, um das richtige Endergebnis zu erzielen. In der Software wäre eine Methodik ein bestimmtes Werkzeug oder eine bestimmte Aufgabe. Wenn Ihre einzige Aufgabe darin besteht, eine bestimmte Aufgabe zu erledigen, benötigen Sie möglicherweise keine Kenntnisse über das Ganze. Aber dann sind Sie ein Bediener und kein Ingenieur. Wenn Sie die richtigen Methoden auswählen, um das Fließband zu bilden, sind Sie wie andere Ingenieure ein Ingenieur. Es ist nicht spezialisierter oder anders.
RJay75

2

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.


1

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.


Ich denke, das ist eine Selbstverständlichkeit, aber es geht wirklich um den ROI. Ich würde keinen Ingenieur mit primärer Java-Erfahrung einstellen, wenn ich in 6 Monaten ein C ++ - Projekt herausbringen möchte. Wenn Sie ein Swing-Projekt haben, das in 6 Monaten veröffentlicht werden muss, kann sich ein primärer serverseitiger Techniker dennoch qualifizieren.
Spencer Kormos

@SpencerK absolut einverstanden. Es hängt davon ab, wie schnell Sie Ihren ROI benötigen. Wenn Sie länger warten müssen, sollte der bessere Softwareentwickler "gewinnen".
Ozz

Auch hartes Minus, wenn du es warst!
Ozz

1
Nein, nicht ich. Ich stimme nicht ohne Kommentar ab, warum. Ich habe bessere Manieren als das!
Spencer Kormos

1

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.


2
"Ja wirklich?" Ich nehme an, Sie würden erwarten, dass ein Sicherheitsingenieur in 6 Monaten bereit ist, Spiele zu programmieren und von einem erfahrenen Spezialisten nicht zu unterscheiden ist.
Marcin

Ich stimme Marcin zu, es ist nicht nur die Kenntnis einer Programmiersprache oder Plattform. Ich habe in zwei verschiedenen Bereichen gearbeitet und jeweils ein paar Jahre in jedem von ihnen verbracht: Es dauert eine Weile, bis Sie vertraut genug sind, um in einem Bereich wirklich professionell und produktiv zu sein. Ein erfahrener Software-Spezialist zu sein, beschleunigt natürlich die Dinge, aber ich würde eher mit 2, 3 Jahren als mit 6 Monaten rechnen.
Giorgio

1

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.


1

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:

  • Körperform- und Farbtheorie: Skulpturen, Comics und Gemälde
  • Textkommunikation: Romane und Comics

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

  • Algorithmen: Betriebssysteme / integrierte Systeme, Spiele und andere Orte, die Sie häufig für Geschwindigkeit oder Speicher optimieren müssen. Selten eine große Sache in der Webentwicklung
  • Design: Überall in der Webentwicklung, aber in integrierten Systemen ohne Benutzeroberfläche nicht sehr wichtig.
  • Client / Server-Software: Die Mentalität "Vertraue dem Client nicht", die in einigen Domänen nicht unbedingt vorhanden ist (Einzelspieler-Spiele und andere eigenständige Desktop-Software, die ich zugeben muss, ist heutzutage seltener).

Ich habe immer argumentiert, dass Programmierung und Software-Design ebenso eine Kunst sind wie Wissenschaft oder Technik. Ich denke, dies ist ein weiteres Beispiel dafür, wie ähnlich sie sind.
Izkata

Oh, und bevor mich jemand dafür beißt, spreche ich mit "Algorithmen" über die hochrangigen CS-y. Fibonacci-Haufen und Timsort sind zwei, die mir in den Sinn kommen. (Ich arbeite fast nie auf dieser Ebene der algorithmischen Komplexität, daher weiß ich überhaupt wenig über dieses Thema)
Izkata

0

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.


2
Dies ist eine schlechte Analogie, sie sprechen von Ingenieuren, nicht von Bauarbeitern, obwohl sie die Metaphern in der Frage mischen. Zu diesem Zweck wird von allen Bauingenieuren, die Straßen bauen, erwartet, dass sie jede Art von Straße bauen können! So wie jeder Muldenkipperfahrer, der den Asphalt zur Baustelle transportiert, in der Lage sein sollte, jede Art von Muldenkipper zu fahren.

1
@JarrodRoberson Ich stimme zu, dass es eine schlechte Analogie ist, aber ich bin nicht sicher, ob Ihre Behauptung als Bauingenieur besser ist. Sicher, jeder Bauingenieur sollte in der Lage sein, die Pläne für jede Straße zu lesen. Aber wenn Sie eine Landebahn oder eine Eisstraße bauen, möchten Sie jemanden einstellen, der jahrelang Autobahnen gebaut hat, oder möchten Sie jemanden, der spezielle Erfahrungen mit Landebahnen oder Eisstraßen hat?
Caleb

0

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.

Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.