Arbeite nicht mehr mit eclipse, aber ich meine Strg + umsch + R da kannst du klassen ?oder dateien? suchen.
Normal kannst du ja überprüfen ob du alles aus dem jeweiligen repository gezogen hast.
wenn du weißt was der code bewirken soll brauchst du nur ein bisschen zeit um rauszufinden wie das strukturiert usw. ist.
Hallo, bekomme mit Absicht issues zugewiesen, um das Team zu fragen. Das sind dann so sachen wie in der Dokumentation steht das, aber programmiert wurde es anders. Da müssen dann die consultants Klarheit schaffen.
Der Code ist auch irgendwie völlig anders strukturiert als man es so von primefaces Dokumentationen kennt, es gibt auch einen query Builder für db abfragen aber der scheint mir noch viel zu kompliziert zu sein
Für mich ist eine sehr gute Eigenschaft bei Entwicklern „kindliche Neugier“. Probiere es einfach aus, schreibe Unittests, spiele einfach mit dem Builder bis du ihn verstehst. Aber immer nur gegen Testumgebungen. Das schlimmste was dort passieren kann, ist dass man ein Backup einspielen muss, und das sollte in einem guten Team kein Weltuntergang sein. Ich wäre eher um jeden froh der sich mit den Sachen aus einandersetzt, statt mir sagt „Ja hab ich verstanden“ und dann einen Bock im Produktivsystem schießt.
Mein Alltag: Aufstehen, Kaffee-Trinken und gleichzeitig Email checken, Nachrichten, Hacker-News und Feedly checken, Colbert vom Vortag anschauen, um 6 ins Auto und lange Fahrt ins Büro. Dort wieder Email checken, danach Meetings, Gequatsche, Telefonate, Telkos und der ganze PL Bullshit. Reports. Am Abend dann heim mit dem Gefühl, dass das alles Scheiße ist aber halt extrem gut bezahlt.
Programmiert hab ich jetzt seit 9 Monaten überhaupt nix mehr.
Kann sein, dass ich ein arrogantes Arschloch bin, aber generell habe ich festgestellt, dass Architekten, Senior-Entwickler, Product Owner, Tester, Scrum-Hansel usw. usf. allesamt ein Haufen mehr oder weniger inkompetenter Vollidioten sind. Was einem da so vorgestellt wird - am liebsten würde ich davonlaufen. Grotesk, irrational, unbrauchbar, fragil - vieles ist Schrott, vor 10 Jahren stehengeblieben, null Wissen über aktuelle Entwicklungen/Designs/Funktionale Sprachen vorhanden. Teilweise auch null Wissen über Netzwerke, Dateisysteme, Linux, HTTP, SQL, Grammatiken, XML, REST, whatever. Aber Buzzwords zum Entwicklungsvorstand hochtragen und dann alles versauen, great.
Aber: gute Miene zum Bösen Spiel machen, man kann ja niemanden feuern - der Arbeitsmarkt ist leer gefegt und eingestellt wird praktisch jeder, der mal an der Uni einen Java-Kurs belegt hat. Dem gibt man dann 50k/Jahr und lässt ihn dahinstümpern und ein paar Tickets lösen, meistens im Schneckentempo.
Der einzige Lichtblicke sind die paar wenigen Entwickler, die wissen was sie tun und die teilweise extrem tiefe Kenntnisse in mehreren Domänen haben. Wenn man die mal gefunden hat in einer Firma, kann man wenigstens ein bisschen was bewegen. Die meisten von denen wollen gar nicht ins Management, sehr verständlich.
Was mich am meistern erschüttert hat in der professionellen SW-Entwicklung durch fest angestellte Mitarbeiter ist die generelle Trägheit, Langsamkeit und das Desinteresse. Aber auch die Inkompetenz: Wenn der A weiß, dass sich der B tagelang völlig vergeblich abmüht (weil Komponente Z gar nicht funktioniert) und dieser A dann da einfach tagelang zuschaut - total gaga. Der A findet gar nichts dabei, der Chef vom A auch nicht - und ich wundere mich da längst nicht mehr.
Sorry für den rant, war jetzt mehr so therapeutisches Geschreibsel.
Starte ab 1.11. als Junior, habt ihr Tipps die ihr auf den Weg geben könnt?
Schau zu dass du nicht mit einem SW-Produkt versauerst, das du in 10 Jahren in- und auswendig kennst, aber dafür alle aktuellen Entwicklungen verpennst. Löse dich rechtzeitig von dem Schwachsinn, der in einem festen Projekt produziert wird - und kündige rechtzeitig.
Bei uns werden die Junior-Entwickler wirklich jahrelang mit einem Mickergehalt ausgebeutet, und viele sind zu unsicher (und zu bequem oder lahmarschig) um einfach zu kündigen. Könnten wo anders längst viel mehr verlangen, bleiben aber stecken und gehören irgendwann zum Inventar, das von früher faselt. Trauriges Ende.
Das wichtigste hab ich ganz vergessen
Wenn deine Firma ein open office floor plan hat (sprich: ein Großraumbüro), dann kündige sofort wieder. Das Gebrüll rings um dich rum treibt dich sonst in den Wahnsinn. Es sei denn, du willst mit Kopfhörern arbeiten (quasi Musik hören bei Coden) - und deinen Arbeitstag als Freak/Autist absitzen.
Kann ich so nicht bestaetigen, die schlimmsten Firmen fuer die ich mal gearbeitet hatte, hatte Einzel- bzw. Doppelbueros.
Ein paar von den „Open Office“ Firmen erlauben/motivieren die Mitarbeitern sogar selber die Moebel zo umzustellen wie man es moechte.
Der Blog den du verlinkt hast, das sieht mir nach einem Kuenstler aus („Independant Designer“) 
Da die meisten „echten“ IT’ler alle im Spektrum sind, ist das keine echte Umstellung, sondern eher Einstellungsvorraussetzung 
@NicoDeluxe mach dich darauf gefasst dass du viel mit Menschen zu tun haben wirst, und die sind dann auch alle „People Challenged“, viele IT’ler waehlen den Beruf weil sie die Maschinen den Menschen bevorzugen, ist immer wieder ein Grund fuer Ueberraschungen wenn sie dann anfangen zu arbeiten.
Ich finde, die beste Einstellung ist: „Es gibt nur Freunde und Trainer“
was soll people challenged sein?
Hallo zusammen, die ersten Tage hinter mich gebracht, schleicht sich langsam ein Gefühl von Alltag ein 
Die erste Aufregung ist zumindest fast weg, nun muss ich den Code verstehen, wie lange habt ihr dafür gebraucht? Das Frontend hab ich im Aufbau schon mal verstanden, einfache Sachen wie Paar Panel einbauen, Spalten verschieben und so bekomm ich alleine hin, aber mir macht der Rest ein wenig Sorgen, kein Design Pattern, in das ich mich zu Haue noch einlesen könnte sondern wirklich alles selber strukturiert. Wenn man drin ist, ist das sicherlich alles kein Problem mehr, aber irgendwie setz ich mich ziemlich unter Druck weil ich kaum durchsehe oder mich irgendwas dann wieder verwirrt und die Dokumentaion teilweise fehlt. Wenn ich die Kollegen Frage klick, klick zack, die wissen wo was wie schon mal ähnlich umgesetzt wurde. Ich muss einen Ansatz finden, wie ich den Code verinnerliche. Will auch nicht dauernd die Kollegen aus der Arbeit reißen, aber anders komme ich im Moment nicht vorwärts, ohne nerviges Fragen. Ging es euch auch so?
Klar, völlig normal.
Ich halte mich an: “Etwas nicht zu können ist kein Grund, es nicht zu tun” (Gordon Shumway)
Was spricht dagegen zu versuchen diese Lücken in der Dokumentation zu schließen? Erstmal selber zusammen schreiben wie man es verstanden hat und dann die Kollegen fragen ob das so korrekt ist und wenn nicht, ob sie es richtig stellen können.
Bei uns gibt es auch immer wieder Lücken in der Doku und neue Mitarbeiter dürfen diese auch gerne füllen. Oft ist einem auch einfach nicht bewusst, dass bestimmte Sachen dokumentiert werden müssen, Stichwort „betriebsblind“, da ist es dann gut, wenn man drauf aufmerksam wird.
Wenn ihr ein daily Standup habt, oder ähnliches, nutze die Chance es dort anzusprechen und zu fragen ob jemand direkt im Anschluss Zeit hat dir noch etwas zu erklären. So reißt du deine Kollegen nicht aus der Arbeit.
Hast du denn jetzt schon eine konkrete Aufgabe, die du umsetzen darfst? Wenn nicht, frag nach einer kleinen Aufgabe die nicht zeitkritisch ist.
Mir hilft am meisten in „fremden“ Code rein zukommen, wenn ich damit arbeiten muss. Ein Bug ist da immer sehr gut, weil man sich dann schön durch den Code navigiert beim Debuggen.