Das ist doch mal ein schöner Thread.
TroubleTribble hat geschrieben: 23.10.2020 10:58:32
ich suche einen "schonenden" einstieg in die professionelle
Programmierung;
Löblich!
Bedeutet dass, du möchtest sozusagen deinen Lebenslauf für spätere Bewerbungen aufwerten?
TroubleTribble hat geschrieben: 23.10.2020 10:58:32
Offen gesagt traue ich mich nie so recht...
Könnte ja sein, dass ich davon in diesem Fall zu wenig Ahnung habe...
Mehrere Menschen haben zu beginn keine Ahnung und fangen trotzdem an. Du lernst es, während du es tust. Neben den technischen Aspekten, lernst du eben auch viel über Menschen, über Projektorganisation und vor allem über dich selbst.
Spring rein, bleib open-minded und atme öfters mal durch.
Bewerte bei der Projektauswahl nicht vordergründig deine Skills, sondern einfach was dich interessiert. Wofür kannst du brennen!?
Konkret könnte ich dir zwei Python Projekte vorschlagen, bei denen ich selbst mitmische.
Hyperorg konvertiert org(roam) Dateien nach HTML und behält dabei die Verlinkungen zwischen den Dateien bei. Der primäre Anwendungsfall ist seinen
Zettelkasten (oder ein einfache Notiz-Sammlung) in HTML zu haben. OrgRoam Dateien werden mit Emacs geschrieben und verwaltet. Das ist nicht für jeden Nutzer in jeder Situation gangbar. Die HTML-Dateien laufen lokal, ohne Webserver, JavaScript oder sonstigen Schnickschnack. Bei dem Projekt bin ich Gründer, Betreuer und Nutzer. Die Issues sind technisch gut überschaubar und lassen sich gut isoliert abarbeiten.
Back In Time, als zweiter Vorschlag, ist eine grob 15 Jahre alte Backup Software die im Hintergrund
rsync nutzt. Hier bin ich Teil des Betreuerteams in dritter Generation. Die Betreuung ist aus der Not heraus entstanden, weil die Software für meinen Workflow essentiell ist und der vorherige Betreuer einfach nicht mehr alleine weitermachen wollte. Wir haben seit letzten Sommer die Hälfte aller Issues abgearbeitet. Der Code ist alt und schwer durchschaubar. Viel unserer Arbeit besteht derzeit darin, hier einzutauchen, zu dokumentieren und code umzubauen, um besser unit tests dafür schreiben zu können. Sehr spannend.
Bedenke, dass du in so einem Projekt in der Regel nicht alleine arbeitest. Es gibt meist das 4 Augen Prinzip, weshalb du nicht viel kaputt machen kannst. Und wenn doch was kaputt geht, kannst du dank Versionskontrolle (heute i.d.R. git) immer zurückspringen. Bei Back In Time sind wir drei aktive Betreuer, die erst kurz im Projekt sind, den Code nicht selbst geschrieben haben und daher viel kaputt machen können. Wir mergen nur im 4-Augen Prinzip, selbst die unwichtigsten Kleinigkeiten.
Der Weg ist das Ziel.