Hab grad ne Krise-"Prokrastination"

[Jaiel]

Hey ich hoffe ich mache diesen Thread nciht zu einem "heul dich aus"-thread aber ich hab grad ne kleine Krise.

Ihr kennt das vielleciht mehr oder weniger.

Ich bin noch gar nicht so lange "Programmierer" meine Erfahrung in diesem Bereich ist vllt max. 1,5 Jahre(1 Jahr C++,6 Monate Android, Java)

Und ich merke immer mehr das es mcih davor graust an meinem Projekt zu arbeiten...ich bin mir nciht sicher warum aber denke es liegt an meiner Art und Weise:

Erstens kommt die Unerfahrenheit...ich muss bei vielen Sachen die Neuland sind natürlich googlen und zwar sehr oft weil cih mir was in den Kopf setze umzusetzen und dann merke das viele wege nach Rom führen.

Darüber hinaus ist dann die Sache mit den immer während neuen Ideen im Design, neuen Performanceverbesserungen in meinem Code, neuen Strukturierungsideen der Software. Das überfällt einen einfach mitten im Schreiben. Dann ist es so das ich an dieser oder jenen Klasse /Methode/Alghoritmus schreibe und bämm kommt mir eine idee wie ich ein Problem in einer anderen Klasse lösen könnte. Ich bin einfach hin und hergerissen immer...verteile meine Konzenttration nciht richtig irgendwie.

Mir fällt es auch irgendwie schwer vorher einen Plan zu erstellen weil sich so viel im Kopf aufbaut und ich einfach kein Bock habe das aufs Papier zu bringen.

Ich schreibe zur Zeit an einem Projekt(Spiele app) und habe mcih heute erst nach 2-3 Wochen schreiben daran gesetzt das Design aufs Papier zu bringen(den Workflow der Screens) und da hab ich zu 80% nur das aufgezeichnet was schon vorhanden ist...und ich hab gar keine Lust erst den workflow des Codes aufs Papier zu bringen das amche ich lieber im Kopf und ich schreibe eig relativ sauberen und verständlichen Code(halte mich an die allgemeine vorgehensweise bei der Bennenung von variable/klassen/usw. und schrecke auch nciht von allzu langen Namen zurück da man bei Bedarf auf CopyundPaste zurückgreift um sich tipparbeit zu sparen)
Deswegen brauche ich kaum einlesezeit wenn ich mal cniht mehr weiß was ich da im Code mache

Sehr oft bemerke ich dass falls ich mal etwas auf papier bringe, ich mir die Sachen dann aus dem Kopf schreibe quasi aus den Augen aus dem Sinn übertragenerweise und es mir dann schwer fällt nachzuvollziehen wieso ich gerade auf diese Idee kam. Ich merke dass wenn ich es im Kopf behalte muss ich mcih dazu zwongen wieder logisch darüber nachzudenken anstatt auf einem blatt Papier mein Plan einfach abzutippen...dann komme ich mir nciht so vor als ob ich von einem Fremden seine Ideen umsetze irgendwie.

Und das schlimmste ich muss immer alles Testen anch dem ich es geschrieben habe, verändere ich zum Beispiel eine variable wie z.B. eine geschwindigkeit, eine Layoutgröße, bitmapskalierung muss das sofort getestet werden wie es rüberkommt.

Debuggen mache ich erst recht nciht, dafür gucke ich einfach in den Code da ich ja durch das ständige testen weiß was oder wo ich etwas verändert habe so das plötzlich etwas abstürzt oder nciht richtg funktioniert.

Und dieser Emulator raubtr mir auch den Nerv da hab ich lieber die ganze zeit mein Handy angeschlossen und exportiere einfach die gezeichnete App in 10 sekunden aufs handy und starte es von dort.


Das Alles und ncoh viel mehr führt einfach dazu dass ich manchmal echt einfach Alles hinschmeissen will und lieber andere sachen machen möchte wie z.b. playstation zocken oder ein trinken gehen oder was weiß ich ich.

und ich sag mir immer wieder du hättest dran denken sollen lieber zuerst alles planen und so. Hab sogar alle sachen da auf dem computer. Ein
Prototyper programm (Justinmind), grapheditor für den workflow des codes(yED)und so weiter ist alles da aber ich nutze diese kaum.

Man sagt immer die letzen 20% des Projektes machen 80% der arbeit aus aber die 80% sind bei mir allgegenwärtig und zwar in jedr phase des Projektes.

Bin ich eins chlechter Programmierer? Ein Fauler auf jeden fall!!!

Kennt ihr das so von euch ungefähr?

Ich will und muss das ändern aber der innere Schweiinehund ist sehr stark bei mir was soll ich machen?

 

[missspelled]

Hallo,
vieles was du ansprichst kommt mir bekannt vor
Ich will nicht sagen, dass ich in allen Sachen die Kontrolle über mich bzw. meinen Code habe, aber trotzdem kann ich dir versichern, dass sich das bessert.
Selbst Vollprofis wissen (oft) nicht alles was die Android-Plattform zu bieten hat.

Vielleicht setzt du dir aber auch zu große Ziele und hast noch zu wenig an den Basics gearbeitet. Ich denke, dass das ein Problem ist, das weit verbreitet ist (ich würde mich selbst als mittelmäßig erfahren bezeichnen und bin mir sicher, dass es auch noch einiges Low-Level Wissen gibt, also was die "Basics" angeht, dass mir bis dato absolut fremd ist).
Letztlich entscheidet über "gut" und "schlecht" fast immer die Erfahrung, die jemand mitbringt - deswegen kann ich dir nur den Rat geben eben nicht alles hinzuschmeißen und sich vielleicht noch mal ein gutes Buch zu krallen, das durchzuarbeiten und wieder ein Stück mehr zu durchblicken.

Gibt ein ganz cooles Video von den XDA Devs, da wird praktisch 1:1 die von dir angesprochene Problematik thematisiert. Schau's dir an.

Also: Zähne zusammenbeißen, nicht rumheulen und am Ball bleiben, auch wenns manchmal hart ist.

Beste Grüße

Ergänzung:
Als Emulator kann ich dir Genymotion ans Herz legen, wenn der richtig eingestellt ist, also auch die Gapps geflasht wurden, und dein PC ein bisschen Leistung hat, kannst du damit sehr gut arbeiten - sogar die Maps Navigation lässt sich so testen.. Dementsprechend KEIN Vergleich zu dem was einem Out-Of-The-Box mittels AVD angeboten wird.
Noch ein Gedanke zum Debugger: Auch hier gilt -> beschäftige dich ordentlich mit ihm und du wirst VIEL(!!!) Zeit beim Programmieren sparen - ich kann dir regelrecht versichern, dass es Fehler gibt, die du ohne Debugger nicht finden wirst und um dem aus dem Weg zugehen, kann ich dir nur ganz stark dazu raten den Debugger hin und wieder zu nutzen.
Gerade vor dem Hintergrund, dass du wahrscheinlich auch keine Unit-Tests laufen lässt, ist der Debugger um so wichtiger. Von Log-Ausgaben mal ganz abgesehen...

 

[Jaiel]

hi zufällig kenne ich das video schon...von einer eminer null bock auf alles sessions

Ja danke ich hoffe bessert sich alles vielleicht ab und zu etwas Abstand nehmen von Allem anstatt sich zu quälen wäre auch nicht schlecht.

Bin wohl gerade im "DIP"

 

[missspelled]

Kleiner Tipp wie man sich an die Fehlersuche mit dem Debugger gewöhnt: Debugge erstmal einen Programmabschnitt der funktioniert, schau dir den Scope an und was welche Variable macht, wo es sinnvoll ist Watches zu setzen und nach wenigen Minuten wirst du ein Gefühl dafür haben, wie der Hase läuft.
Sich zum ersten Mal mit dem Debugger zu beschäftigen, wenn das Kind schon im Brunnen liegt ist wirklich eine Quälerei

 

[zumafx]

Also, als erstes könntest du eines machen: Aus deinem derzeitigem "Dilemma" lernen
Dieses einfach drauf los, direkt aus dem Kopf reinhacken kann man evtl. bei kleinen Sachen machen, aber selbst da ist das nicht wirklich gut.
Was du gerade feststellst, ist der Unterschied zwischen Softwareentwicklung und Programmierung
Der Programmierer ist sozusagen nur die "Tippse",während der Softwareentwickler der Architekt ist.
Du schreibst:

Mir fällt es auch irgendwie schwer vorher einen Plan zu erstellen weil sich so viel im Kopf aufbaut und ich einfach kein Bock habe das aufs Papier zu bringen.

Und genau da fängt dein Problem an. Wenn du erstmal deine Ideen auf Papier austobst, bleibt nach ein wenig Übung nachher das beste davon übrig. Größer Projekte entwickle ich z.b. wirklich zuerst auf Papier, bevorzugt Din A5, damit nicht zuviel auf eine Seite passt. Das ergibt dann erstmal einen Wust an Schmierzetteln mit allem, was mir zu dem Projekt so einfällt. Dann lass ich das meist so 1-2 Tage erstmal "ruhen". Danach gehe ich dann dabei und fange an, in das Schmierzettelchaos eine Ordnung zu bringen und trenne dabei gutes von schlechtem und lass was weg oder füge hinzu.
Das mach ich dann meist am Pc und schreibe dort mein Grobkonzept.
Wenn das fertig ist, gehe ich das ganze nochmal durch, ob sich da evtl. was optimieren lässt oder sich ein paar Fehler eingeschlichen haben. Ich mach das auch oft nach dem "Blackbox-prinzip", d.h. ich definiere, was eine Klasse leisten soll, aber nicht WIE. Darum kümmere ich mich wenn ich die dann tatsächlich code.
Und dann endlich fange ich an, die ersten Zeilen Sourcecode zu schreiben, erstmal die Fleissarbeiten (Basisklassen mit settern/gettern/Methoden usw.) So hab ich nach einiger Zeit meine "Puzzelteile" fertig und kann mich dann an die eigentliche Steuerung/Logik machen. Dabei kommt es natürlich immer noch wieder vor, das man Fehler in seiner Logik findet. Aber mit der Zeit wird man darin immer besser, auch beim Software schreiben gilt - kommt Zeit, kommt Erfahrung. Hab noch keinen gesehen, dem das einfach alles so zufliegt.
Jedenfalls sollte man als Programmierer/Softwareentwickler vieles sein, nur nicht schreibfaul. Auch da kommt mit der zeit eine gewisse Automatik. Ich kann heutzutage (nach Jahrzehnte langem Tippen auf Tastaturen) quasi nebenbei meine Gedanken in einen Editor tippen, das geht ganz automatisch, die Finger machen das "von allein", dabei kann ich sogar nebenbei TV gucken. Ich hab lange Azubis gehabt und vielen ist es zwischendurch wie dir ergangen, so eine Art "Mini-Burnout". Mach halt mal Pausen und geh wirklich mal unter Leute oder so, jedenfalls "vergiss" für ein paar Stunden/Tage mal dein Programm. Dann machts auch nachher wieder Spass.
Bevor ich hier nu aber noch eine romanartige Abhandlung verfasse, geh ich nu lieber in die Heia
Lass den Kopf nicht hängen, sondern gönn dir einfach mal eine Programmierpause - da läuft nix weg

Nachtrag:
Das mit Debugger von Missspelled ist ein sehr guter Tipp, das ist immer das erste, was ich mir in einer neuen IDE angucke, weil meiner Meinung nach am wichtigsten.

 

[markus.tullius]

@Jail

Das Los eines Programmeier. Man wird von der Größe des Projekt erschlagen, und hat immer neue Ideen.

Ich habe mir angewöhnt, viele kleine Kommentare in den Programmcode zu schreiben, als Erinnerungsstützen. Nach zwei Monate weiß ich meist nicht mehr, was ich dort genau gemacht habe. Mann kann gar nicht genug kommentieren!!!!!!!!!
Mit der Zeit bekommt man auch ein Blick für den Code.

Einen Debugger benutze ich nicht so gerne. Glaube, das ist auch Geschmacksache. Bin mehr der Fan von Logeinträgen mit Fehlermeldungen.

Planung: Ich bin davon abgegangen, alles genau vorher zu skizzieren. Zwei nachträgliche Kundenwünsche, und alles sieht schon wieder anders aus. Stattdessen versuche ich modularer zu programmieren. Dadurch bin ich flexibler. Und ich kann Code einfacher austauschen, wenn er mir nicht mehr gefällt.

Zu den Thema ist mit letzten ein Buch in die Hand gefallen. Habe es mit wachsenden Interesse gelesen:
Weniger schlecht programmieren

denkspuren: "Weniger schlecht programmieren"

Und Wenn ich nicht mehr weiterkomme, gehe ich spazieren. Hilft meistens.

Noch ein Nachtrag:

Neuland. Das Gefühl wird bleiben. Akzeptiere es.
Es ändert sich immer irgend etwas. Im Endeffekt muss man permanent etwas neues lernen.
Freue dich drauf.

 

[zumafx]

@Jail
Es ändert sich immer irgend etwas. Im Endeffekt muss man permanent etwas neues lernen.
Freue dich drauf.

Wahre Worte, kann ich nur unterschreiben. Aber genau dieses immer wieder etwas lernen
macht zumindest für mich den Reiz aus. Genau genommen hab ich mit dem lernen seit der Schule nicht mehr aufgehört.
Im professionellen Bereich erledigt Software ja fast immer fachspezifische Aufgaben - und die muss man erstmal lernen,
bevor man da überhaupt loslegen kann (Bspw. ohne Buchhaltungskenntnisse eine Buchhaltung zu proggen wird wohl eher nix )

 

[markus.tullius]

Bin ich eins chlechter Programmierer? Ein Fauler auf jeden fall!!!

Gute Voraussetzung. Faule Programmierer schreiben meist kompakteren und einfacheren Code.

Der Frust gehört dazu. Auch dass alles viel länger dauert, als man denkt.
Auf der Arbeit kommt dann noch der Zeitdruck dazu. Abgabetermine usw.

Da hilft es ein Hobby zu haben, das nichts mit programmieren zu tun hat. Um mal auf andere Gedanken zu kommen.

Und 16 Stunden am Tag programmieren bringt nichts. Nach 7 Stunden lässt die Konzentration rapide nach. Alles was man danach programmiert, ist meist nur noch Schrott.

 

[Zoopa]

Ich bin mittlerweile beruflich Softwareentwickler, da lernt man natürlich seeehr viel dazu. Da ich aber vor knapp 3 Jahren noch Student war, kann ich dir mal erzählen, was mir am meisten geholfen hat:

• Etwas an bestehendem Code ändern sollte Spass machen. Oft ist es bei mir so, dass ich auch erst nachträglich auf Ideen komme, die den Code besser/schöner machen. Ich seh das nicht als zusätzliche Arbeit, sondern als Herausforderung, um mich und den Code zu verbessern.
  
• Benutze Tools, die dir ein paar Dinge abnehmen. Das kann auch ein Blatt Papier sein. Was z.B. oft unterschätzt wird, ist eine Todo- oder Bugliste aufzustellen und Dinge zu notieren, die dir beim lesen deines Codes auffallen. Du musst nicht sofort alles verbessern, aber so erinnerst du dich auch später noch daran.
  
• (Unit) Testing: Ganz ehrlich, als Student hat mich das 0 interessiert, und auch im ersten beruflichen Projekt musste ich erst gezwungen werden, Unit Tests (oder Tests allgemein) zu schreiben. Man denkt sich oft:
  • Es ist ja leicht, die Änderungen von Hand zu testen
  • Tests schreiben ist nur zusätzlicher Aufwand
  Wenn du aber erstmal etwas Erfahrung darin hast, kann es einem das Leben soviel einfacher machen. Du kannst Änderungen am Code machen und musst nicht die App kompilieren, installieren, starten und durch die Views klicken, um herauszufinden, ob alles noch funktioniert. Und was ich fast noch wichtiger finde: du kommst nicht mehr in Situationen, wo du Angst hast, ein grosses Stück bestehenden Code zu ändern. Wenn du nämlich etwas falsch machst, sagen dir die Tests sofort, wo etwas nicht mehr funktioniert.
  
• Versionskontrolle (Git, SVN): Wird meiner Meinung nach auch unterschätzt. Selbst wenn man alleine an etwas arbeitet, hilft das sehr. Warst du schon mal in einer Situation, wo du an einer App grosse Änderungen gemacht hast, um dann zu merken, dass etwas doch nicht so funktioniert wie geplant? Dann hattest du vermutlich auch schon das Problem, dass du irgendwie alle Änderungen rückgangig machen musst. Von Hand ist das eine riesen Qual. Natürlich kannst du von Hand Backups deiner App machen, aber das ist dennoch nicht dasselbe. Mit Git/SVN kannst du z.B. auch die History von Files anschauen und sehen, wie sich was im Verlauf der Zeit geändert hat. Klingt nicht nach viel, kann aber enorm hilfreich sein.
  
• Bücher zu fortgeschrittenen Themen: Mir haben einige Bücher viel gebracht. Aber nicht die normalen Bücher wie "Wie lerne ich Java" etc., sondern Bücher zu "fortgeschritteneren" Themen. Zum Beispiel das Buch: Clean Code. Man denkt sich oft, der selber geschriebene Code ist super. Ich habe gelernt, dass ich selbst nach 10 Jahren als Hobby-Programmierer schrecklichen Code geschrieben habe, weil ich einfach nicht gewusst habe, wie viel besser man es machen könnte (wenn man mal die Tricks kennt). Was mir auch viel gebracht hat, ist ein Buch zu Test Driven Development. Man lernt da, wie man zuerst Tests schreibt, bevor man den richtigen Code anfasst. Man lernt dabei vorallem, wie man Code so schreibt, dass er testbar bleibt. Zu guter letzt ein Buch zu Design Patterns. Wenn man die Patterns kennt (und etwas Übung hat), kommt man oft schneller zu einer saubereren Lösung und besseren Architektur

 

[Thyrion]

Gute Voraussetzung. Faule Programmierer schreiben meist kompakteren und einfacheren Code.

Das deckt sich leider nicht so ganz mit meinen Erfahrungen. Viele greifen dann einfach zu Copy+Paste (egal ob sie selbst Geschriebenes duplizieren oder einfach die Lösung, die Google geliefert hat, kopieren) und denken nicht größer über den Code nach.

Wie oft höre ich von Kollegen oder mich selbst sagen: Ohje, der (wohlgemerkt: eigene) Code ist so häßlich, der müsste dringend überarbeitet werden... Yep, das war vor 5 Jahren, der Code ist immer noch häßlich!

 

[zumafx]

Wie oft höre ich von Kollegen oder mich selbst sagen: Ohje, der (wohlgemerkt: eigene) Code ist so häßlich, der müsste dringend überarbeitet werden... Yep, das war vor 5 Jahren, der Code ist immer noch häßlich!

Jedesmal, wenn man seinen (oder reinkopierten) Code betrachtet mit etwas Ruhe, fallen einem noch
verbesserungswürdige Dinge ein. Sei es allein schon, weil es mittlerweile neue Techniken/Features gibt.

Aber:
Im professionellem Bereich geht es in erster Linie um's Geld verdienen, wenn der Code
dabei neben funktionierend auch noch schön ist, super.
In den Jahrzehnten, die ich als Softwareentwickler tätig bin, hat bislang aber noch
kein Auftraggeber gesagt: Mach's schön. Die sagen: Mach's schnell, am besten zu gestern fertig.
Es ist ein ewiger Spagat zwischen schönem (perfektem) Code und der Maßgabe, damit Geld zu verdienen.

 

[reneph]

Mal ganz ehrlich: wenn du Bock auf trinken hast, dann geh trinken (oder mach das, was du lieber machen willst).

Es zwingt dich keiner an einem Hobby-Projekt zu arbeiten, wenn du keine Lust hast. Das wäre auch der falsche Ansatz. Wenn du dich selbst zwingen musst, dann gehst du schon negativ an die Sache ran und dann ist klar, dass der Spaß gegen null tendiert.

Ich kann nur von mir reden, aber ich habe Spaß am programmieren beziehungsweise ich mache das Ganze aus Spaß an der Sache. Dazu gehört auch neues zu lernen, Code ständig zu verbessern (auch wenn man keine neuen Features integriert, kann es Spaß machen Erfolge zu sehen, wenn eine App performanter läuft o.ä.). Und wenn ich keine Lust habe, dann lass ich das Projekt liegen und erfreue mich an anderen Aufgaben, Hobbies etc... Die Lust kommt von allein wieder und dann ist man auch ziemlich produktiv - und wenn sie nicht wieder kommt, dann ist es das Projekt auch nicht Wert...

 

[DieGoldeneMitte]

Ohje, der (wohlgemerkt: eigene) Code ist so häßlich, der müsste dringend überarbeitet werden

Wenn man das zu seinem 5y alten Code sagen kann, beweist das, dass man was in der Zeit dazugelernt hat. Ist also eine gute Nachricht.

 

[Thyrion]

@zumafx: Ja, da hast du natürlich Recht.
Aber wenn du schon weißt, dass du (mehr oder weniger) regelmäßig Anpassungen an dem "häßlichen" Code machen musst, weil das Produkt um Funktionen erweitert werden soll etc., dann verliert man da leider sehr schnell die Lust dran und wünscht sich jedes Mal, man hätte es gleich "schön" gemacht.

EDIT: Die 5 Jahre sind etwas übertrieben. Manche sagen das schon nach 2 Monaten (aber ändern dennoch nichts dran, selbst wenn sie die Zeit dafür hätten...) - ja, das schließt mich manchmal ein wenig mit ein...

 

[markus.tullius]

Hässlicher Code ist so eine Sache. Und manchmal auch eine Glaubensfrage. Jeder Programmierer hat seinen eigenen Stil, den es gibt fast immer mehrere Möglichkeit.

Viel schlimmer ist Code, der nur verbaut wird, weil man es so gelernt hat. Software Pattern sind ein schönes Hilfsmittel, aber der Code sollte sich an den Gegebenheiten orientieren. Häufig reichen die ganz einfachen Lösungen aus der strukturierten Programm.

Noch schlimmer finde ich Entwickler, die sprachspezifische Eigenheiten, in anderen Sprachen umsetzen. Der Code ist zwar recht sauber programmiert, aber so umständlich, das man weinen möchte.

 

[zumafx]

seh ich auch so: Code sollte sich den Gegebenheiten anpassen. Und damit ist nicht nur die Aufgabe,
die es zu lösen gilt, gemeint, sondern auch das Umfeld.
Arbeitet man zB. in einem Team, nutzt es nichts, wenn einer super-duper-Code schreibt, der Rest aber nur mit Mühe
das ganze nachvollziehen kann. Code sollte nämlich auch wartbar bleiben und da gehört neben Namensgebung und
Kommentierung auch Einfachheit dazu.
Mein letztes Projekt hab ich 10 Jahre betreut, knapp 750.000 Zeilen Sourcecode erzeugt und wenn ich da in so manche Datei gucke,
würde ich schwören, das hab ich nicht programmiert (die Versionskontrolle behauptet aber stur und steif das doch ).
Da freue ich mich über jede Zeile, die zwar evtl. wegoptimiert werden könnte, aber es mir leichter macht,
zu verstehen, was ich mir da mal bei gedacht habe.
An 2 Regeln versuche ich mich immer zu halten:
Keep it simple und
Eine Methode sollte nie länger als eine Bildschirmseite sein.

 

[markus.tullius]

Keep it simple, kann ich mich nur anschließen.

Eine Aufgabe, eine Methode.