Im Allgemeinen bedeutet "Junior" weniger Erfahrung. Dies hängt nicht eng mit einer bestimmten Fähigkeit zusammen. Wie Phyrfox es ausdrückte, führt

jahrelange Erfahrung nicht zu einer Qualität des Codes, sondern wirkt sich normalerweise auf andere Nicht-Code-Fähigkeiten aus, wie z. B. Teamwork, Arbeiten unter Druck und genaue Geschäftsanforderungen usw.

Zum Beispiel, abhängig vom jeweiligen Job ...

• Lesen des Codes anderer Personen
• Erlernen des Produktdesigns - Manchmal, wenn keine Dokumentation vorhanden ist, sind die Dokumente falsch und / oder die Experten haben das Unternehmen verlassen.
• Wie Patricia Shanahan in den Kommentaren erwähnt, konzentrieren sie sich auf die Dinge, die Sie wirklich lernen müssen, um mit dem Produkt produktiv zu sein Codebasis, anstatt zu versuchen, alles zu lernen, was unpraktisch ist.
• Debuggen des Codes anderer Leute
• Brechen eines Produkts auf eine kritische und schwer vorhersehbare Weise
• Arbeiten Sie mit der Qualitätssicherung zusammen, um Ihren Code
• nach den Unternehmensrichtlinien im Allgemeinen oder nach den Richtlinien dieses Unternehmens, insbesondere
• nach einem Softwareentwicklungslebenszyklus
• nach som Das Design eines anderen
• macht einem Team klar, wie man etwas richtig umsetzt
• und macht es auf die Weise des anderen, wenn sein Ansatz gewinnt
• Interaktion mit Kunden
• Interaktion mit dem Kundensupport
• Akzeptieren von Entscheidungen, die aufgrund von Faktoren, die Sie einfach nicht verstehen, keinen Sinn ergeben
• Erkennen, wann etwas wirklich ist schädlich, untersuchen, um zu verstehen, warum die Entscheidung getroffen wurde, und einen effizienteren und kostengünstigeren Weg finden, um dies zu tun (oder die Entscheidung zu realisieren, ist richtig)
• in einem Team mit unterschiedlichen Fähigkeiten arbeiten
• Mentoring anderer
• , die im jeweiligen Problembereich der Anwendung arbeiten
• Arbeiten in einem Produkt, das so groß ist wie das, an dem Sie arbeiten würden. Wie HLGEM in den Kommentaren hervorhebt, sind professionelle Bewerbungen riesig - viel, viel größer als das, woran Sie in der Schule arbeiten. Sie sind in der Regel Zehntausende von Zeilen in mittelgroßen Projekten und können in größeren Projekten Millionen von Zeilen sein.
• kommunizieren effektiv mit nicht-technologischen Leuten
• , die in einem Goldfischglas / einer Fischkabine arbeiten / office
• Teamdynamik verstehen
• Unternehmenspolitik verstehen und steuern
• die Unternehmensziele verstehen und wie sich Ihr Job auf diese Ziele auswirkt

Es gibt noch viel mehr. Sie haben vielleicht erstaunliche Programmierkenntnisse, aber sind all diese Fähigkeiten wirklich so gut geübt?

Die anderen Antworten sind richtig, aber Sie haben speziell nach dem Code gefragt.

Es scheint, als würde ich alle 5-10 Jahre jeden Aspekt des Codierens vollständig verstehen und dennoch eine weitere Revolution finden. Jeder kann jedes Problem mit Code lösen, wenn er motiviert genug ist - ich habe gesehen, dass Nicht-Programmierer erstaunliche Lösungen entwickelt haben.

An diesem Punkt glaube ich, dass der Hauptunterschied darin besteht, wie viel einer solchen Codebasis zuvor hinzugefügt werden kann es schlägt fehl und muss neu geschrieben werden, und wie viel Zeit / Mühe / Geld müssen Sie für die Wartung aufwenden.

Wenn Sie in der Kompetenz steigen, sinken diese Kosten erheblich. Es ist schwierig, zuerst darauf hinzuweisen. Stellen Sie sich den Unterschied zwischen jemandem vor, der Basketball spielt und jeden auf seinem Block schlagen kann, und einem Profi-Basketballspieler - auch wenn sie so aussehen, als würden sie alles auf die gleiche Weise tun, werden Sie den Nachbarn nicht in der Nähe des Profis finden.

Es braucht mehr als nur Zeit, es braucht Erfahrung, Monate damit zu verbringen, wirklich dumme Fehler zu finden, Jahre damit, Ihren eigenen Code zu überarbeiten, um ihn zu verbessern, Konzepte zu kennen, denen Sie möglicherweise jahrelang nicht begegnen, sowie das Wissen darüber WISSEN Sie, dass ein neues Muster, von dem Sie gerade erfahren haben, nicht das gesamte System überflutet.

Möglicherweise müssen Sie eine Million kleiner Dinge wissen. Vielleicht einige Beispiele, die sich nur auf das Codieren beziehen:

• Dunkle Muster / Werkzeuge, die zu bestimmten Szenarien passen, wie eine Statustabelle oder ein Quad-Baum für 2 Beispiele (von Tausenden) - und genau die Probleme Vereinfacht durch ihre Verwendung
• Die Funktionsweise verknüpfter Listen, Arrays und Hashes zum Verständnis der Auswirkungen auf die Leistung.
• Identifizieren von Redundanzen in Code, die möglicherweise überhaupt nicht ähnlich aussehen.

Spezifische Beispiele sind schwer zu nennen, es gibt verschiedene Stile und Meinungen. Hauptsächlich halte ich einen guten Programmierer für jemanden, der versteht, dass er programmiert, dass die nächste Person liest, die Maschine nicht zum Laufen bringt und entsprechend codiert.

Nur die Fähigkeit, Code zu schreiben, macht Sie nicht zu einem professionellen Programmierer. Es bedeutet lediglich, dass Sie Code schreiben können. Das Schreiben kleiner Programme für sich selbst oder als Teil Ihrer Kursarbeit ist keine professionelle Arbeit. Per Definition wird ein Fachmann für seine Arbeit bezahlt. Es ist ihr Beruf. Es hat nichts mit dem Unterschied im Code zu tun, sondern mit der immateriellen Erfahrung, die sich aus der Arbeit für ein Unternehmen in einem professionellen Umfeld ergibt.

Wie arbeiten Sie unter Druck oder unter Fristen? Wie arbeiten Sie mit anderen Menschen zusammen, nicht nur mit Kollegen und Vorgesetzten, sondern auch mit Endbenutzern und Kunden? Wie gehen Sie mit der Arbeit an Projekten mit massiven Codebasen um? Dies sind Dinge, nach denen ein potenzieller Arbeitgeber suchen wird, wenn er Ihr Erfahrungsniveau beurteilt, nicht nur, wie gut Sie programmieren können.

Bildung kann Ihnen einige der Werkzeuge geben, um ein professioneller Programmierer zu werden, aber es ist keineswegs ein Ersatz für die Arbeit in einem Unternehmen. Es ist nichts Falsches daran, ein Junior-Entwickler für Einsteiger zu sein - wir mussten alle irgendwann dort anfangen. Aber verwechseln Sie Bildung nicht mit Erfahrung.

Ich kann nicht mit Ihrem Punkt 1 sprechen (der unter programmers.SE möglicherweise themenbezogener ist). Aber ich werde gerne auf Punkt 2 eingehen.

Ja, neben der Codierung gibt es viele Dinge, die einen Junior von einem Senior-Entwickler unterscheiden. Nur ein paar Beispiele aus meinem Kopf:

• Ein Großteil der Zeit eines Entwicklers wird nicht für das Hacken aufgewendet. Sie überprüfen Anforderungsdokumente (oder erstellen sogar Ihre eigenen), schreiben Story- und andere Dokumente, entwerfen (und codieren) Tests und so weiter. Aktivitäten wie diese können 90% Ihrer Zeit in Anspruch nehmen, verglichen mit 10% bei der eigentlichen Codierung. Möglicherweise haben Sie dies an der Universität gelernt oder nicht, aber wenn Sie dies getan haben, erwähnen Sie es in Ihrer Frage nicht.

• Es sei denn, Sie arbeiten in einem sehr kleinen Unternehmen, a Entwickler werden wahrscheinlich in einem Team arbeiten, das ein kleines Scrum-Team oder Teil eines großen Teams sein kann, das über mehrere Kontinente verteilt ist. In einer solchen Umgebung müssen Sie Prozesse (verteilte Entwicklung, Code-Repositorys usw.) verstehen, und müssen Sie die Menschen verstehen und in der Lage sein, mit ihnen zu arbeiten. Dies ist normalerweise etwas, was Sie an der Universität nicht lernen. Das tägliche Programmieren von Paaren mit jemand anderem (weil auf diese Weise Wissen verbreitet wird) ist etwas anderes als ein Projekt mit denselben ein oder zwei Mitschülern.

• Sogar Der Hacking-Teil unterscheidet sich zwischen der Universität und dem Arbeitsplatz. Zum Beispiel werden Sie irgendwann in Ihrer Karriere gebeten, einen Fehler zu beheben, den jemand anderes im unkommentierten fünf Jahre alten Spaghetti-Code eingeführt hat. Ich gehe davon aus, dass Sie so etwas an der Universität nicht gesehen haben, wo Sie wahrscheinlich keinen alten Code pflegen müssen, der von anderen Leuten erstellt wurde. Ältere Entwickler wurden bereits damit konfrontiert und haben sich damit befasst.

Während andere Antworten Listen mit Fähigkeiten zu geben scheinen, die als "erfahrener" angesehen werden müssen, denke ich, dass der Unterschied viel einfacher ist.

Alles läuft darauf hinaus, wie viel Kontrolle und Richtung Sie benötigen und wie sich diese skaliert.

Ich werde ein Unterprodukt verwenden, um zu verhindern, dass dies softwarespezifisch ist, aber ich stelle mir ein Unterprodukt als Modul vor.

Neue Absolventen erfordern in der Regel viel Kontrolle /Richtung. Sie müssen die Details genau lernen, wie die Dinge in diesem Unternehmen gemacht werden. Ihnen wird in der Regel genau gesagt, was sie tun müssen. Sie arbeiten in der Regel an genau definierten Teilen eines Unterprodukts.

Etwas erfahrenere Personen, die noch jünger sind, erhalten möglicherweise ganze Unterprodukte, die genau definiert sind und unter Anleitung einer älteren Person ausgeführt werden.

Wenn Sie etwas älter werden, haben Sie die Verantwortung, die genauen Details eines Unterprodukts zu definieren, wie sie von mehr älteren Personen mit minimalen Details definiert wurden.

Senior und Sie Lassen Sie sich Personen zuweisen, die Ihnen bei Ihren größeren Unterprodukten helfen.

Wenn Sie älter sind, beginnen Sie, alle verschiedenen Unterprodukte anhand einer bereits definierten Spezifikation zu identifizieren.

Senior und Sie helfen dabei, diese Spezifikation aus vage definierten Kundenbedürfnissen zu erstellen.

Senior und Sie suchen aktiv nach Kundenbedürfnissen, die Geld in das Unternehmen bringen. Mit anderen Worten, Sie definieren Ihre Arbeitsaufgaben.

Im Allgemeinen läuft es auf die Erwartung hinaus, dass je älter Sie aufsteigen, desto weniger Anleitung Sie benötigen, desto größere Produkte können Sie erfolgreich abschließen und mehr Leute, die Sie leiten.

Sie mögen also ein großartiger "was auch immer Ihre Spezialität sein" sein, aber Sie werden immer noch eine große Lernkurve haben, wie man Dinge auf "Unternehmensart" macht. Also viel Versehen. Sie müssen sich auch beweisen, bevor Sie einer genauen Prüfung unterzogen werden. Also viel Versehen. Sie werden lernen, dass Techniken und Praktiken, die sich hervorragend für kleinere Projekte eignen, nicht gut skaliert werden können, wenn die Dinge größer werden. Somit eine größere Lernkurve als Sie vielleicht denken. Sie haben also eine ganze Reihe von Aufgaben, wodurch Sie weniger effizient sind als jemand, der mehr Erfahrung hat. Selbst wenn Sie ein großartiger "was auch immer Ihre Spezialität" für einen College-Studenten sind, wenn Sie einige Jahre lang nicht 8-9 Stunden am Tag damit verbracht haben, diese Fähigkeiten zu üben und anzuwenden, sind Sie bei weitem nicht so gut, wie Sie denken, dass Sie es sind. Egal wie schlau Sie auch sein mögen.

Insbesondere für Software können Sie kein Codebeispiel angeben und die Unterschiede aufzeigen, da es sich um das gesamte System und nicht nur um die Codefragmente handelt. Es ist möglicherweise besser, darauf hinzuweisen, was wahrscheinlich passieren wird, wenn ein neuer Absolvent / Junior-Entwickler nicht die richtige Aufsicht erhält. Die 2 häufigsten Probleme, die ich gesehen habe, sind 1) Sie schreiben absolut großartigen Code, aber er löst das falsche Problem. 2) Sie entwickeln ein Design und einen Code, die ihrer Meinung nach viel besser sind, als es ihnen gesagt wurde. Das Problem ist, dass es nicht mit dem Rest des Systems funktioniert und daher nicht verwendet werden kann.

Ich denke, einer der Hauptunterschiede zwischen einem Junior und einem erfahreneren Entwickler ist oft folgender:

Ich bin ein sehr erfahrener Java-Programmierer (glaube ich).

Ich mache diesen Job seit ungefähr 15 Jahren und was ich immer noch nicht als "sehr erfahrenen Programmierer" betrachte, auch weil sie ständig ändern, womit wir arbeiten!

Ohne banal klingen zu wollen, habe ich mit vielen Junior-Programmierern zusammengearbeitet, die dachten, sie wüssten alles (sie haben es nicht *), und es kann einen kleinen Schritt in der Denkweise erfordern, um zu erkennen, dass es immer mehr zu lernen gibt. und was noch wichtiger ist, Sie müssen möglicherweise auch lernen, Dinge so zu tun, wie es Ihr Arbeitgeber wünscht, und nicht nur das, was Sie für das Beste halten.

'* Um nur zu sagen, Sie haben auch funktioniert mit einer Reihe von sehr guten Nachwuchsentwicklern ...

Ich denke, der größte Unterschied zwischen Junior- und Senior-Entwicklern (oder Senior-Entwicklern, die etwas aus ihrer Erfahrung gelernt haben, und den vielen, die dies nicht getan haben) ist die intuitive Leichtigkeit, mit der sie die richtigen Entwurfsmuster und Best Practices der Branche identifizieren und anwenden . Wenn es um Java-Code geht, sollten Sie das hoch angesehene Buch Effective Java berücksichtigen. Ein guter Entwickler wird dieses Buch oder ähnliches gelesen und geübt haben, was es lehrt, bis es zur zweiten Natur geworden ist. Auf der anderen Seite habe ich gesehen, wie "Profis" mit CS-Abschluss Müllberge produzieren, die gegen jedes einzelne der Software-Design-Prinzipien in diesem Buch verstoßen.

Wie andere angemerkt haben, gibt es noch mehr zu sein ein professioneller Entwickler als Codierung. Vieles davon ist Büropolitik und der Versuch, den Business Case zu finden, um die Dinge richtig zu machen. Ich kämpfe oft für Strategien, die sich auf Zeitskalen von Monaten auszahlen. Wollen wir ein Jahr damit verbringen, etwas richtig zu machen, oder wollen wir in drei Monaten einen Haufen Scheiße herausholen, es tatsächlich neun Monate dauern und dann fünf Jahre damit verbringen, es zu reparieren und Kunden die ganze Zeit zu bluten ? Ich werde nie verstehen, warum Anzüge immer auf Letzterem bestehen ...