Wie viel Vielseitigkeit als Entwickler ist zuviel?

[Assarbad]

Da ich ich erst kürzlich hier in der Delphipraxis schon einmal das Vorurteil zu hören bekam, zu viel Vielseitigkeit sei problematisch - zumindest habe ich die Aussagen jeweils so interpretiert - und heute nochmal, wollte ich doch einmal fragen, wie die anderen Forenten hier insgesamt zu dem Thema stehen, siehe Titel.

Um eines vorwegzuschicken: Jeder nach seiner Façon!

Es geht hier also nicht darum ein allumfassendes und auf alle Entwickler anwendbares Dogma zu finden, jedoch empfand ich Aussagen als ... nunja, pointiert.

Zitat 1:

Zitat von Bernhard Geyer:

Als "Zwitter" der x Tools nutzt wird es natürlich schwieriger zu verargumentieren.
Wäre evtl. beser mal einige der "Nebenschauplätze" zu beenden und z.B. alles in eine IDE zu entwickeln die man "sonst auch" nutzt.

Zitat 2:

Zitat von Sherlock:

Außerdem soll es doch ein Qualitätsmerkmal eines guten Entwicklers sein, auf 100 Hochzeiten zu tanzen...sagt man mir immer wieder, dann nicke ich weise und mach weiter nur meine zwei bis drei Hochzeiten auf Delphi/Win und Python/Linux.

In meiner Replik auf Bernhard habe ich schon einige Punkte aus meiner Sicht thematisiert. Eine weitere Replik seinerseits gab es nicht und das Thema ist ohnehin geschlossen worden.

Mein Standpunkt ist: Jede neu erlernte (Programmier-)Sprache, eröffnet dir einen neuen Blick auf die (Software-)Welt.

Und in der Tat kann das Reinschnuppern in Erlang, Io, Lisp, Ruby, Rust o.ä. einen gewissen Lerneffekt für die bereits "gemeisterten" Programmiersprachen bedeuten. Ich empfehle wärmstens die beiden Bücher von Bruce A. Tate (Seven Languages in Seven Weeks, Seven More Languages in Seven Weeks).

Man sollte aber wissen wie viel genug ist - zumindest zur gleichen Zeit. Ich habe bspw. schon mit vielen "weiteren" Programmiersprachen geliebäugelt, aber erst bei Rust steige ich jetzt gerade wieder voll ein. Meines Erachtens nach reicht es eine Sprache - so wie Tate es mit den Büchern versucht - erst einmal soweit zu lernen, daß man deren Vorzüge und Nachteile kennt. Kurzum: daß man deren idealen Einsatzzweck einschätzen kann und "weiß was es 'da draußen' so gibt". Wenn ich dann irgendwann vor einem Problem stehe und weiß, daß es da diese oder jene Sprache (oder Werkzeug) gibt, dann bin ich halt in der Lage nicht jedes Problem als sprichwörtlichen Nagel zu behandeln. Meine Kenntnisse vertiefen kann ich dann noch immer.

Außerdem rosten (Programmier-)Sprachkenntnisse, wie auch bei natürlichen Sprachen, ein. Bspw. hatte ich einst mit MIPS, PPC und SPARC-Assembler zu tun, müßte mich da aber erst wieder mit vertraut machen. Bei Delphi, Perl oder PHP ist es ganz ähnlich und VBA werde ich mal lieber aus dem Lebenslauf streichen (schon weil ich keinen Bock drauf hab ).

Und dann sind da ja noch weitere Dimensionen (bei C#, Java oder Python ist das recht kraß) wie die Standardbibliotheken oder auch Bibliotheken und Frameworks allgemein. Und nur weil du total der Checker mit STL-Containern oder IOStreams bist, magst du von Programmierung rund um SUS/POSIX nicht viel Ahnung haben. Und dennoch kannst du C++ "gemeistert" haben (soweit das eben geht). Des weiteren kommen noch Betriebssysteme, Bare Metal usw. hinzu ...

Und ja, es gibt sicher einige Leute, die sich schon als Berater zum Thema SQL verdingen wenn sie eine Suchmaschine bedienen können (man sieht's ja häufig an der Tiefe der Fragen). Ein Kumpel und ehemaliger Kollege hat das mal sehr schön auf den Punkt gebracht. Er fragte mich wie gut ich SQL "könne". Habe ihm dann halt erzählt was ich bei MySQL (bzw. MariaDB) und SQLite3 schon gemacht habe, daß ich aber nun wirklich keine tiefergehenden Kenntnisse (stored procedures, Optimierung) habe. Darauf meinte er: "Da hast du wahrscheinlich mehr Ahnung als so mancher Berater (consultant)".

Klar, vielleicht sind einige der Probleme über die ich in meiner Karriere gestolpert bin auch eher esoterischer Natur. Aber was nützt mir halt die geile IDE auf meinem lokalen Rechner, wenn der Kunde mir nur per "Bildschirm teilen" Zugriff auf ein Terminal mit einer SSH-Verbindung zum Endgerät (Server, Kühlschrank, Meßsonde ...) gibt und ich dort allenfalls vi und gdb vorfinde? Da sitzt man dann in der Telko vor der lokal installierten IDE ... und dann? Oder ich debugge auf dem System eines Kunden und habe - aus einleuchtenden Gründen - keine Debugsymbole. Oder oder oder ...

Und bei der Windows-Treiberentwicklung war man jahrelang damit konfrontiert daß es keine Integration in Visual Studio gab, wenn man die von Microsoft "vorgeschriebenen" Werkzeuge verwendete (DDK/WDK). Daraus entstand ja mein DDKWizard und Projekte von anderen wie VisualDDK. Apropos Treiber: da verbietet sich Delphi schon aus mehreren Gründen als Implementierungssprache (und ja, die entsprechenden Prototypen sind mir bekannt).

Die Vielseitigkeit habe ich ja über Jahre aufgebaut und nicht alles gleichzeitig gemacht. Dennoch habe ich das Gefühl von diesen Erfahrungen zu zehren und kann eingeschlafenes Wissen schnell reaktivieren, wenn es benötigt wird (erst unlängst mit Delphithemen geschehen).

Wie viel Vielseitigkeit ist also zuviel? Was meint ihr?

[Rollo62]

Ich bleibe gerne in bekannten Gefilden, und freue mich wenn andere Sprachen z.B. wie C aussehen.
Zuviel Neue Syntax finde ich erstmal verwirrend, es sei denn man hat ein Projekt damit, und man muss.

Dabei geht es ja nicht um die 40 neuen Keywörter, sondern eher um neue Konzepte wie Funktionale Programmierung.

Ich finde sowieso das den Sprachen zuviel Gewicht gegeben wird, mir geht es mehr um Libraries und Frameworks.
Wie gebe ich ein Audio-File aus, die Sprache ist doch da nur noch marginal wichtig.

Es gibt natürlich die Entwickler welche das letzte aus einer Sprache rauskitzeln müssen,
und deswegen an theoretische, performante, speicher- threading- stack- und andere Limits stossen können.
Das verstehe ich natürlich, und bin froh das meine Projekte in der Regel mehr Anwendungsorientiert sind.

[philipp.hofmann]

Es bedeutet natürlich Aufwand, aber um 2-3 Hochzeiten kommt man teilweise nicht umhin. Manchmal nimmt man dies aber auch gar nicht so wahr. Es gibt für jedes Problem geeignete und ungeeignete Lösungsansätze (egal, ob Sprache, Betriebssystem, Datenbanken, ...). Aber sehr oft ist der Lösungsansatz ja auch kundengetrieben, weil bestimmte Dinge schon da sind.

Wenn der Kunde eine Oracle-Datenbank hat und dort Daten durch die Gegend geschoben müssen (auch über Servergrenzen hin weg), dann mache ich dies nach Möglichkeit per SQL-Stored-Procedure und Triggern. Dies ist an Performance nicht zu schlagen und bietet mittlerweile auch relativ viele Möglichkeiten der Codierung. Ansonsten kann ich aber genauso gut Delphi(=Pascal [um hier genau zu bleiben])/Java und im Bedarfsfall auch C/C++-Code implementieren.

Die Grundstrukturen guter Entwicklung bleiben ja glücklicherweise gleich und ich nutze eher weniger Frameworks/Libraries. Bedeutet zwar teilweise Mehraufwand bei der initialen Entwicklung, aber wenn ich mir anschaue, welche Projekte schon an Hibernate-Problemen gescheitert sind, dann gibt mir dies bisher recht. Ich habe schon mehrfach mit Frameworks überlastete Projekte komplett neu implementiert und sehe dort meist sehr deutliche Performance-Verbesserung (teilweise bis Faktor 4, also 4 mal so schnell), deutlich geringere Hauptspeicherbelastung und eine deutlich besser Nachvollziehbarkeit und der Entwicklungsaufwand ist am Ende des Tages auch kleiner. Wenn ich dann Frage, warum man das Framework A oder B den genutzt hat, heißt es meist, dass dies Vorgabe war ohne das es einen technischen Sinn macht. Und da ich wenig Frameworks und Libraries nutze, komme ich auch schneller in eine neue Programmiersprache.

Aber um es zu unterstreichen (und nicht missverstanden zu werden), in einem anderen Kontext kann dann Framework A Sinn machen, weil der Aufwand sonst zu groß wird. Nur muss man es dann wirklich im Griff haben und auch trotzdem noch in der Lage zu sein, zu verstehen, was die Software wann und warum tut. Wenn man dies nicht mehr versteht, sollte man das Vorgehen überdenken, den wehe es kommt ein Fehler.

[Assarbad]

Zitat von philipp.hofmann:

Aber sehr oft ist der Lösungsansatz ja auch kundengetrieben

... oder vorgesetztengetrieben, hab ich da so gedacht

Zitat von philipp.hofmann:

Wenn der Kunde eine Oracle-Datenbank hat und dort Daten durch die Gegend geschoben müssen (auch über Servergrenzen hin weg), dann mache ich dies nach Möglichkeit per SQL-Stored-Procedure und Triggern. Dies ist an Performance nicht zu schlagen und bietet mittlerweile auch relativ viele Möglichkeiten der Codierung.

Jupp, wohl wahr. Was man in SQL ausdrücken kann, sollte man nicht in anderen Sprachen ausdrücken. Auch schon mehrfach anders erlebt.

Zitat von philipp.hofmann:

Aber um es zu unterstreichen (und nicht missverstanden zu werden), in einem anderen Kontext kann dann Framework A Sinn machen, weil der Aufwand sonst zu groß wird. Nur muss man es dann wirklich im Griff haben und auch trotzdem noch in der Lage zu sein, zu verstehen, was die Software wann und warum tut. Wenn man dies nicht mehr versteht, sollte man das Vorgehen überdenken, den wehe es kommt ein Fehler.

Ich denke das kann man generell so sagen, oder? Mir wird ja auch immer bange wenn Kollegen nicht wissen wie etwas hinter den Kulissen läuft, aber gleichzeitig basierend auf Annahmen (oder anders ausgedrückt: Unwissen) Entscheidungen treffen oder gutheißen. Diese Vorgehensweise gibt es natürlich in Schattierungen. Aber ein Fall wo ich das regelmäßig erlebe ist das Linken auf Linux. Da wird auf Uraltsystemen gebaut, nur weil man nicht versteht wie's funktioniert und man so ja Aufwärtskompatibilität bekommt. Daß damit auch veraltete Compiler und Bibliotheken in Stein gemeißelt werden, wird dabei gern ignoriert.

Zitat von Rollo62:

Dabei geht es ja nicht um die 40 neuen Keywörter, sondern eher um neue Konzepte wie Funktionale Programmierung.

Genau. Das meinte ich bei so Beispielen wie Lisp. Diese Konzepte aus "Fremdsprachen" sind es ja - aus meiner Sicht - die den Horizont erweitern.

Zitat von Rollo62:

Es gibt natürlich die Entwickler welche das letzte aus einer Sprache rauskitzeln müssen,
und deswegen an theoretische, performante, speicher- threading- stack- und andere Limits stossen können.

Naja, meistens habe ich es erlebt, daß basierend auf Annahmen über das Laufzeitverhalten Entscheidungen getroffen wurden wie "das implementieren wir direkt in Assembler", obwohl niemand nachgemessen hat. Und Compiler sind inzwischen extrem gut im Optimieren. Solche Anwendungsfälle gibt es und im Embedded-Bereich will man natürlich alles rauskitzeln, aber zuvor messen sollte man schon. Ansonsten optimiert man an der falschen Stelle. Daher würde ich der Behauptung, daß an einer gewissen Stelle Optimierungsbedarf besteht, immer mit Skepsis begegnen.

[Rollo62]

Zitat von Assarbad:

[

Zitat von Rollo62:

Dabei geht es ja nicht um die 40 neuen Keywörter, sondern eher um neue Konzepte wie Funktionale Programmierung.

Genau. Das meinte ich bei so Beispielen wie Lisp. Diese Konzepte aus "Fremdsprachen" sind es ja - aus meiner Sicht - die den Horizont erweitern.

Ja gerne, aber das nützt mir wenig wenn ich das in der Hauptsprache dann nicht nutzen kann.
Z.B. in Delphi gibt es noch nicht mal ein vernünftiges MVVM Konzept, funktionale Programmierung wird schwierig, DI-Container geht so einigermaßen, SmartPointer/Nullables soll kommen, Inline-Vars sind gerade mal da, ....

Würde ich wegen der fehlenden Konzepte sofort die Sprache wechseln ?
- Nein, nicht wenn ich 20 Jahre Erfahrung mit einem System habe.
- Bin ich frisch von der Uni, dann kann ich erstmal Alles (den letzten heissen Sch...) ausprobieren

[Sherlock]

Die Syntax einer Sprache ist schnell gelernt. Relevant sind aber die die verfügbaren Bibliotheken und Frameworks. Da geht sehr schnell sehr viel auseinander, gerade in dem von Dir von mir zitierten Fall Windows/Delphi und Python/Linux. Das ist nicht wirklich miteinander vereinbar, und ich ertappte mich gerade im ersten Jahr des Python Lernens und Anwendens immer wieder dabei in Delphi Dinge tun zu wollen, die zwar in Python gehen, aber nicht in Delphi - allein schon deswegen, daß Python im Grundsatz eine interpretierte Scriptsprache ist und nicht kompiliert werden muß, was manche lustige Sachen ermöglicht, die mir als Delphientwickler aber die Haare zu Berge stehen lassen, oder zum Ausruf verleiten "das habe ich schon immer gebraucht!" Beispiele hier. Das Debakel mit dem Python 2 zu 3 Sprung hat bei mir nicht gerade für Liebe gesorgt, einige der von mir benötigten Libs (allen voran matplotlib) taten sich sehr schwer auf 3 zu migrieren.

Klar kann ich auch Fortran77, Basic und verlerne gerade massiv CoffeeScript und Assembler aber wozu soll ich mir das alles merken, wenn ich mit meinen beiden aktiv genutzten Sprachen glücklich werden kann? Denn wie gesagt, mit der Sprache alleine ist es nicht getan. Bei Java kommt man ohne J2EE, JDK oder sonstigen Framworks/Toolkits auch nicht sonderlich weit. Wozu den Balast mit tragen, wenn ich ihn nicht brauche. Sollte ich den Arbeitgeber wechseln, lerne ich eben das was dort gefordert ist. Aber eben erst dann, ich gebe mir nicht freiwillig eine babylonische Sprachverwirrung. Diese scheint im übrigen, jetzt da ich darüber nachdenke, dazu zu führen, daß manche Entwickler aus ihrem Wirrwarr nicht herausfinden und darum das eine oder andere "unverzichtbare" Sprachfeature in Delphi fordern, damit sie nix mehr durcheinanderbringen. Letzteres ist eine absolut haltlose Spaßbehauptung.

Sherlock

[Rollo62]

So sehe ich das auch, Frameworks der Plattformen müssen sinnvoll abstrahiert werden.
Das ist meistens das Hauptproblem.
Schaut mal nach RemObjects, da sind vier (oder schon mehr) Sprachen unter einem Projekt nutzbar.
Das ist cool

Übrigens hat das "Mehrsprachen"-Konzept auch den Charme das man mehr gute Entwickler findet,
wenn jeder in seiner Lieblingssprache am Projekt mitarbeiten kann.

Zitat:

Aber eben erst dann, ich gebe mir nicht freiwillig eine babylonische Sprachverwirrung.

Da gebe ich auch zu Bedenken das es oft "Nullwissen" ist, das morgen schon obsolet ist.
(Basic, COM, COM+, VB, Excel-VBA, Access, FoxPro, Objective-C, ...)
Man lernt um zu Vergessen

[Sherlock]

IIRC kann man auch in VisualStudio ein .net Projekt quer durch VB, C#, J# und F# mischen. Macht das alles in Codereviews und ähnlichen übergeordneten Prozessen aber auch nicht wirklich einfacher.

Sherlock

[Assarbad]

Zitat von Rollo62:

Ja gerne, aber das nützt mir wenig wenn ich das in der Hauptsprache dann nicht nutzen kann.

Das halte ich für kurzsichtig. Gibt es in Python Zeiger? Nö. Ist es relevant für einen Entwickler - allgemein, nicht nur Python - das Konzept Zeiger zu verstehen? (Aus meiner Sicht: ) Absolut!

Zitat von Rollo62:

Würde ich wegen der fehlenden Konzepte sofort die Sprache wechseln ?
- Nein, nicht wenn ich 20 Jahre Erfahrung mit einem System habe.
- Bin ich frisch von der Uni, dann kann ich erstmal Alles (den letzten heissen Sch...) ausprobieren

Das war doch auch nicht die Prämisse, oder? Quasi der neuesten durch's Dorf getriebenen Sau hinterherlaufen.

Zitat von Sherlock:

Die Syntax einer Sprache ist schnell gelernt. Relevant sind aber die die verfügbaren Bibliotheken und Frameworks. Da geht sehr schnell sehr viel auseinander, gerade in dem von Dir von mir zitierten Fall Windows/Delphi und Python/Linux.

Bei Lua finde ich bspw. die Bibliotheken nicht so maßgeblich wie bei C# oder Java (oder eben Python). Und die VCL ist für Delphi ja auch in gewisser Weise konstituierend.

Zitat von Sherlock:

Das ist nicht wirklich miteinander vereinbar, und ich ertappte mich gerade im ersten Jahr des Python Lernens und Anwendens immer wieder dabei in Delphi Dinge tun zu wollen, die zwar in Python gehen, aber nicht in Delphi - allein schon deswegen, daß Python im Grundsatz eine interpretierte Scriptsprache ist und nicht kompiliert werden muß, was manche lustige Sachen ermöglicht, die mir als Delphientwickler aber die Haare zu Berge stehen lassen, oder zum Ausruf verleiten "das habe ich schon immer gebraucht!" Beispiele hier.

Diese Verwechslungen sind mir bei natürlichen Sprachen schon passiert, aber bisher noch nicht bei Programmiersprachen. Danke für den Link. 5 und 10 kannte ich noch nicht. Wobei ich bei 10 wohl ein set() erstellt mit List Comprehension genommen hätte.

Zitat von Sherlock:

Das Debakel mit dem Python 2 zu 3 Sprung hat bei mir nicht gerade für Liebe gesorgt, einige der von mir benötigten Libs (allen voran matplotlib) taten sich sehr schwer auf 3 zu migrieren.

Ging mir anfangs auch so. Aber wenn man sich anschaut wie lang eigentlich die Übergangsfrist war, ist das schon üppig.

Zitat von Sherlock:

Klar kann ich auch Fortran77, Basic und verlerne gerade massiv CoffeeScript und Assembler aber wozu soll ich mir das alles merken, wenn ich mit meinen beiden aktiv genutzten Sprachen glücklich werden kann?

Verlernst du es, oder "schläft" dieses Wissen vielleicht nur? Sowohl bei Programmiersprachen als auch bei natürlichen Sprachen bin ich recht flott immer wieder drin, sobald ich mich dem - auch nach längeren Pausen - aussetze.

Zitat von Sherlock:

Denn wie gesagt, mit der Sprache alleine ist es nicht getan. Bei Java kommt man ohne J2EE, JDK oder sonstigen Framworks/Toolkits auch nicht sonderlich weit.

Genau, erwähnte ich ja. Bei C# ist das ja auch so und auch in Python nutzt man ganz schnell Funktionen der Standardbibliothek.

Zitat von Sherlock:

Sollte ich den Arbeitgeber wechseln, lerne ich eben das was dort gefordert ist. Aber eben erst dann, ich gebe mir nicht freiwillig eine babylonische Sprachverwirrung.

Also wenn ich dich richtig verstehe sparst du Energie (und Hirn-Speicher), weil du für dich keinen Nutzen siehst, richtig?

Zitat von Sherlock:

Diese scheint im übrigen, jetzt da ich darüber nachdenke, dazu zu führen, daß manche Entwickler aus ihrem Wirrwarr nicht herausfinden und darum das eine oder andere "unverzichtbare" Sprachfeature in Delphi fordern, damit sie nix mehr durcheinanderbringen. Letzteres ist eine absolut haltlose Spaßbehauptung.

Kannst du mal ein Beispiel für ein solches gefordertes Feature geben?

Zitat von Rollo62:

(Basic, COM, COM+, VB, Excel-VBA, Access, FoxPro, Objective-C, ...)
Man lernt um zu Vergessen

Also erstens nutze ich COM nach wie vor und die Kenntnis der Interna hat mir schon mehrfach den A.... gerettet und zweitens nehme ich meist mehr aus einer Sprache mit als rein die Syntax. Diverse Konzepte aus COM helfen eben auch beim API-Design oder begegnen einem in ähnlicher Form in anderen Umgebungen. Aber gut, vielleicht bin ich ja wirklich einfach nur "anders". Ich kann mich zum Beispiel durchaus noch an VBA-Code erinnern den ich 2002 geschrieben hab, obwohl ich den lieber vergessen würde.

Zitat von Sherlock:

IIRC kann man auch in VisualStudio ein .net Projekt quer durch VB, C#, J# und F# mischen. Macht das alles in Codereviews und ähnlichen übergeordneten Prozessen aber auch nicht wirklich einfacher.

Aber allein die Abstraktion führt zu eigenen Erkenntnissen, finde ich. Beispiel. Wenn du C-Code hast der auf Windows, Linux, AIX, FreeBSD, Solaris usw. laufen soll: nimmst du dann WCHAR (WideChar) oder definierst du nen eigenen Typ? Wie abstrahierst du das Ermitteln von Verzeichniseinträgen über die Betriebssysteme hinweg? Wie definierst du "Pfadnamen" wenn auf Windows UTF-16 gemeint ist und auf den anderen allenfalls UTF-8? Ich habe bspw. schon mehrfach Code von anderen Entwicklern übernommen, die sich nen Ast abgebrochen haben um die Unterschiede zwischen den Betriebssystemen zu betonen. Der Code ist durchsetzt mit #ifdef und alles andere als wartungsfreundlich.

[TiGü]

Mir fehlt in der bisherigen Diskussion die Betrachtungsweise für das jeweilige Fachgebiet, für das die Software geschrieben ist.
Oftmals muss man als Softwareentwickler ganz tief verstehen, wofür ein "Produkt" gut ist, was und wie es etwas tut und wie man es erweitern kann.

Klar, wenn man seit 20 Jahren - womöglich bei der gleichen Firma - nur z.B. Buchhaltungssoftware schreibt (ohne das jetzt abwerten zu wollen), dann hat man irgendwann alles gesehen und gelernt und hat dann ggf. Zeit und Lust sich in seiner Freizeit mit interessanten Konzepten von Interpreter-Sprachen zu beschäftigen.

Aber bspw. war ich in den letzten 10 Jahren in vier komplett verschiedenen Branchen unterwegs.
Neben den reinen Wissen, welches für die Softwareentwicklung notwendig ist (Grundlagen und Spezialisierungen in so Themen wie Programmiersprache(n), Entwicklungsumgebungen, Frameworks, Betriebsysteme, Netzwerke, Hardware, usw.), musste ich mir immer - zum großen Teil selbst - den fachlichen Kontext drauf schaffen.
Das zieht viel Zeit und Energie. Daneben gibt es ja noch ein Privatleben und Familie.

Versteht mich nicht falsch. Ich versuche eine Vielzahl von Blogs, Artikeln und Büchern zumindest zu überfliegen, schaue mir GitHub-Repositories an, weil man von fremden Quelltexten viel lernt (gerne auch C- und C++-Projekte wie ReactOS oder Wine) und versuche in Delphi auf den neusten Stand zu sein.
Aber um mich jetzt noch mit exotischen Sprachen und Frameworks intensiv zu beschäftigen, die ich auf Arbeit auf absehbarer Zeit nicht brauchen werde, dafür fehlt mir oft die Muße.

Zum Abschluss noch ein polemisches Zitat, was ich allgemein unterstütze, aber damit nicht Foristen hier meine:

Zitat von Felix von Leitner:

Es ist besser, in einer Sprache richtig gut als in 20 Sprachen Anfänger zu sein.
Denkt da ruhig mal aus Sicht eines HR-Menschen drüber nach. Stellt euch vor, ihr seit der Headhunter, und ihr wäret mit einem Lebenslauf konfrontiert, bei dem jemand ein paar Applets (das klingt schon von alleine mittelmäßig und irgendwie abwertend) in Java gemacht hat, der gerade Windows Forms in Visual C# zusammenklicken lernt, der ein paar dynamische Webseiten mit PHP gemacht hat.

Für was für einen Job soll so jemand denn bitte qualifiziert sein?

Zum c't Lesen?

Anspruchsvolle Jobs kann man so jemandem doch gar nicht geben!
Wer sich nur oberflächlich mit Sachen beschäftigt, der wird auch nur oberflächliche Jobs bekommen. Was für eine grauenvolle Vorstellung…

Insofern: setzt euch hin, sucht euch etwas aus, das ihr am besten noch nicht kennt, und arbeitet euch richtig tief ein.
Nehmt euch dafür ein paar Monate. Hört erst auf, wenn ihr das Gefühl habt, selbst der Erfinder der Sache könnte euch nichts wirklich überraschendes mehr dazu erzählen.
Solche Leute braucht das Land, nicht noch mehr Visual Basic Pfuscher.

https://blog.fefe.de/?ts=bda79e3f