Da gibt's wohl keine 36 Alternativen. Du musst nur programmieren. Wieweit du das machen kannst, hängt davon ab, wieviel Zeit du dafür einsetzen kannst und willst.
So stimmt das auch wieder nicht. Neben dem Programmieren gehört schon noch etwas mehr zum Umfeld. Um sich aktuell zu halten und auch ein wenig die Trends mitzubekommen solltest Du z.B. ruhig mal den einen oder anderen Feed abonnieren oder die zugehörigen Seiten aufrufen. Hier gibt es spezielle Channels (z.B. Heise Developer, Java Lobby, ZDNet Developer, uvm.) die ganz gerne mal eine Neuerung vorstellen.
Hier kannst Du dann auch lernen, dass vieles neu und toll klingt und sich trotzdem
- Für keines deiner Projekte (aktuell) eignet
- Nicht für einen produktiven Einsatz eignet weil es doch nicht so toll ist oder einfach völlig undokumentiert
- Auf den zweiten Blick doch nicht so toll ist wie gedacht
Das andere ist, dass Du im Arbeitsleben nie alleine arbeiten wirst. Klar, jeder hat so seine Aufgaben und nicht überall wird man Pairprogramming etabliert haben. Trotzdem ist ein Ein-Mann-Team eine Katastrophe für jedes Unternehmen, da man keinen Wissenstransfer vornehmen kann, die Person auch mal krank ist oder Urlaub hat usw. Und Teamarbeit unterscheidet sich deutlich von dem, was man alleine im stillen Kämmerlein schafft.
Das wichtigste ist eben, dass man Kommunikation lernt. Das klingt etwas komisch, da wir uns alle schon mal unterhalten haben und genau darin liegt auch die Gefahr. Nur weil zwei Leute miteinander reden und denken dass sie genau wissen was der jeweils andere gesagt hat heißt das nicht, dass die irgendwas verstanden haben. Häufig verwenden zwei Menschen die gleiche Syntax, gehen aber von völlig unterschiedlichen Bedeutungen aus. Im Team findet man schnell den gemeinsamen Nenner, beim Kunden sieht das dann schon wieder anders aus.
Hier gilt es entsprechend zu lernen, wie man Missverstädnisse minimiert. Dazu gehört, dass man sich möglichst immer eindeutig und einfach ausdrückt. Tolle Buzzwords sind da nahezu tabu, da die gerne völlig sinnfrei missbraucht werden. Kleine Annekdote, ich musste mal einen gerade fertigen Fachinformatiker betreuen, der auf meine Frage warum er seinen Code nicht eingerückt, strukturiert und kommentiert habe antwortete, dass er (ganz alleine) einfach Extreme Programming betreiben würde....
Das andere ist, dass man im Team vorausplanen muss. Wenn Du selber an einem Programm arbeitest, dann wirst Du den Code schon verstehen. Die Struktur ist Dir vertraut, es ist ja Deine. Kommentare schiebt man vielleicht mal auf, man weiß ja was man wo gemacht hat und hey, eine Änderung zieht halt mal viele weitere nach sich, aber ist ja alles nicht schlimm (so ging es mir in meinen jungen Jahren und erfahrungsgemäß gibt es das auch heute noch).
In einem Team geht das alles nicht mehr. Man hat eher einen Styleguide, damit der Code bei jedem gleich aussieht (und möglichst auch um guten Stil zu erreichen und Fehlerquellen zu minimieren!). Nicht kommentiert heißt, dass jmd. anderes nicht weiß was da gemacht wird und viel schlimmer auch nicht warum (so geht es Dir aber auch, wenn Du Deinen Code nach 6 Monaten wiedersiehst). Und Änderungen können nicht mehr beliebig vorgenommen werden. Wenn der eine einen USB-Stecker und der andere eine FireWire-Buchse baut, dann wird das nicht zusammen passen.
Kurzum kann man hier wirklich viel lernen und sollte das auch tun. Und hier gibt es (zum Glück) auch gute Möglichkeiten. Meine Lieblingsempfehlung ist hier Sourceforge. Hier werden auch offen Helfer für bestimmte Projekte gesucht. Das erübrigt die (häufig gestellte) Frage was man für ein Projekt machen könnte. Man stellt nicht den x-millionsten MP3-Player oder Emailclient her, der ungenutzt auf einer Festplatte einstaubt, sondern ist in einem aktiven Projekt mit einer echten Motivation und sieht auch, dass das Produkt genutzt wird. Zudem lernt man mit einem (meist internationalen) Team zusammen zu arbeiten, was zudem die Qualität des Englisch steigern kann. Es gibt natürlich auch ganz analoge Alternativen, nur hat gerade SF auch eine Menge interessanter und Java-lastiger Projekte.
Natürlich heißt das nicht, dass Du nicht programmieren solltest, aber ein Projekt umfasst eben sehr viel mehr als nur das reinhacken von Code. Im Durschnitt spricht man von ca. 10-15 Zeilen Code pro Tag die ein Entwickler gemittelt über ein größeres Projekt erzeugt. Das ist jetzt keine Zahl die man auf die Goldwaage legen sollte, es ist halt nur ein Durchschnittswert, der etwas verdeutlichen soll: Entweder schreiben Entwickler im Alltag sehr langsam und überlegen sehr lange oder es gibt noch etwas anderes was einen nicht geringen Anteil einnimmt (oder beides, ist klar).