Mein Fachwissen geht in die Breite, abr nicht in die Tiefe

[stadtschrat]

Hallo,

ich bin 40 Jahre alt und seit ca. 10 Jahren Fachinformatiker. Ich stelle immer wieder fest, dass ich meinen Aufgaben nicht gewachsen bin, weil ich nicht systematisch genug vorgehe. Ich unterschätze auch immer wieder die Komplexität von Sachverhalten. Dann bearbeite ich ein Projekt, bis es zu drei Vierteln fertig ist. Aber dann stoße ich auf Probleme, die ich vorher überhaupt nicht gesehen habe, und ich bin nicht in der Lage, meine Aufgabe zu Ende zu bringen. Ich interessiere mich für unheimlich viele IT-Themen, ich kenne OOP, Entwurfsmuster, JSP, Java, C#, Basic, Refactoring, Linux, Mac OS X, Windows, Netzwerke, Office-Anwendungen, programmiere einen Roboter in C, kenne mich mit SQL Server und PostgreSQL aus... aber konkrete Aufgaben kann ich weder zu meiner eigenen, noch zur Zufriedenheit meiner jeweiligen Chefs lösen. Meine Lösungsansätze sehen zwar für andere Programmierer zunächst beeindruckend aus, aber sie taugen einfach nix, denn sie funktionieren nicht. Letzten Endes sind meine Werke stümperhaft. Ich kann einfach nicht diszipliniert genug vorgehen, um wirkliche Erfolgserlebnisse in großen Projekten zu bekommen. Ich liebe Kleinkram, ich löse in 1000 Stunden lieber 1000 kleine Aufgaben von je einer Stunde, als eine große Aufgabe von 1000 Stunden. Nur leider habe ich es mit Letzterem zu tun. Meine größten Erfolgserlebnisse im Büro sind, wenn der Drucker Streifen druckt, und ich das Problem per Druckerhandbuch lösen kann.

Das war mein kleiner Bericht aus meiner aktuellen Arbeitswelt. Ich freue mich über einen Kommentar.

Gruß

stadtschrat

Bearbeitet 8. Februar 2012 von stadtschrat

[DocInfra]

Was ist dein Aufgabengebiet? Anwendungsentwicklung oder Systemintegration? Für was für eine Art Unternehmen arbeitest du? Was hast du VOR deiner Tätigkeit als Fachinformatiker gemacht?

[stadtschrat]

Hallo bla!zilla,

Ich bin Anwendungsentwickler und dokter erfolglos an einer 10 Jahre alten Finanzsoftware herum. Das Unternehmen, in dem ich zurzeit tätig bin, ist im Bereich Finanzwesen. Vor meiner Tätigkeit habe ich meine AE-Ausbildung abgeschlossen (wirklich knapp, im Vierer-Bereich, glaube ich). Und davor habe ich zwei mal versucht, zu studieren: Erst Elektrotechnik 1 Semester, dann BWL 6 Semester ohne Vordiplom.

Gruß

stadtschrat

[DarkMaster]

also bei 1000 Std. Projekten, das entspricht ca. 1/2 Mannjahr, würde ich jetzt mal behaupten, dass ein Projektmanager bzw. Softwarearchitekt sich der Sache annehmen soll.

Ich weiß ja nicht, woran die Projekte genau scheitern, aber ich vermute, hier ist mehr zu tun, als das reine programmieren.

Ich würde dir bzw. du dir selber garkeinen Vorwurf machen. Es liest sich so, als wärst du halt lieber der "klassische" Entwickler als ein Architekt.

Vllt. solltest du mit deinem Chef nochmal deine Aufgabengebiete besprechen, um nicht unnötig (wie ich finde) demotiviert zu sein.

PS: Kopf hoch und nicht in den Sand stecken. Du hast eine abgeschlossene Ausbildung und scheinbar ja auch Ahnung von der Materie. Wie wäre es mit einem Job in der Beratung? Dann musst du die Sachen nicht mehr selber umsetzen...

Bearbeitet 8. Februar 2012 von DarkMaster

[Kwaiken]

Hey, nix gegen Beratung

Beratung ist etwas mehr als "Hier, macht mal!". Spätestens wenn dein Konzept dann umgesetzt werden soll, trennt sich schnell die Spreu von Weizen und dann wird man schauen ob Du deinen Tagessatz von ~1500 EUR wert bist. Da setzt selbst ein kleines Konzept von vielleicht 15PT schnell mal 20-25k in den Sand wenn es nichts taugt. Da kannst Du aber sicher sein, dass das dein letzter Ausflug in dieses Themengebiet war wenn Du dich nicht auf der Straße wiederfindest :floet:

Aber im ernst: vielleicht solltest Du wirklich ein bisschen an deiner Arbeitsweise arbeiten. Nimm Dir ein klitzekleines Projekt vor und mache von A-Z wirklich alles systematisch. Pflichtenheft, Aufwandschätzung, Ablaufpläne, Implementierung und Tests, Abnahme, Dokumentation, Handbuch. Und wenn Du das gemacht hast, kannst Du dich langsam steigern.

Bearbeitet 8. Februar 2012 von Kwaiken

[carstenj]

Hi,

was genau funktioniert denn nicht so wie du dir das vorstellst? Und wann hast du festgestellt, dass es so ist? Was konkret bemängelt denn dein Chef?

zwar für andere Programmierer zunächst beeindruckend aus, aber sie taugen einfach nix, denn sie funktionieren nicht

Was heisst sie funktionieren nicht? Das klingt mir auch alles zu pessimistisch, denn wenn das wirklich so wäre, dürftest du nicht schon 10 Jahre in dem Job arbeiten, weil das ja irgendwann schonmal irgendwem aufgefallen sein müsste. Werd mal konkreter, sonst kann man dir rein gar nichts raten.

[bigvic]

Ich liebe Kleinkram, ich löse in 1000 Stunden lieber 1000 kleine Aufgaben von je einer Stunde, als eine große Aufgabe von 1000 Stunden.

Dann such dir doch so einen Job, bei dem genau diese Skills benötigt werden. Es bringt ja auch nichts sich noch ewig rumzuquälen. Du musst den Job noch 25 Jahre machen und das dir auf einmal Grossprojekte liegen werden (nach 10 Jahren anderer Erfahrung) bezweifle ich stark. Loslassen ist schwer, aber manchmal notwendig - bevor man sich selbst kaputt macht.

[afo]

Stöber einfach mal bei Joel: Joel on Software Hilft vielleicht nicht unbedingt, kann aber erhellend sein.

[MCCornholio]

Bei aller Ernsthaftigkeit - Ich finde das klingt ein wenig nach beginnender Midlife-Crisis

[It-Specialist]

Bei aller Ernsthaftigkeit - Ich finde das klingt ein wenig nach beginnender Midlife-Crisis

Ich verstehe absolut nicht, was jemanden reitet sich über die Probleme anderer lustig zu machen. Ich finde es unangebracht und dreist, so über den TE herzuziehen.Abgesehen davon, hat dies nichts mit Midlife Crisis zutun sondern schlichtweg mit dem falschen Aufgabengebiet, was nicht zum Profil des TE passt.

[stadtschrat]

Hallo,

danke für eure Antworten.

@kwaiken

Das ist die richtige Herangehensweise: Pflichtenheft, Aufwandseinschätzung usw. Aber wird das in der Praxis überhaupt gemacht? - Ich habe in meinen 10 Jahren als Programmierer noch nicht ein Pflichtenheft geschrieben, und auch noch keinen Kollegen erlebt, der eines geschrieben hat. Ich fürchte, das gehört zu den, tja, "Pflichten" eines Programmierers. Nun denn. Aber spaßig ist das wahrscheinlich nicht. Für einige Chefs scheint es auch eher eine Selbstverständlichkeit zu sein, dass man als Programmierer ohne große Planung und ohne konkreten Anforderungskatalog mal eben irgendwelche Superfunktionalitäten aus dem Hut zaubert. Als ob Softwareentwicklung das reine Programmieren sei, ohne planen und vorbereiten zu müssen. Ich stelle mir gerade vor, wie die Häuser eines Architekturbüros aussehen würden, wenn die Architekten ebenso planlos vorgehen würden...

@carstenj: Ich schiebe die Abnahme durch meinen Chef immer so lange wie möglich vor mir her. In meinem aktuellen Projekt habe ich dann den Code noch drei Mal radikal umgeändert, weil mir die interne Struktur nicht richtig erschien. In der ganzen Zeit hat sich niemand für das Projektergebnis interessiert. Das, was ich geschrieben habe, macht mir keine Freude mehr, weil ich so viele sinnlose Stunden Programmierung darin verbraten habe. Es funktioniert zwar teilweise, aber bisher hat niemand das Funktionieren überprüft. Ich habe mir einiges an Funktionalität auch aus den Fingern gesogen, ohne dass es irgendwelche Anforderungen gab. Wer da jetzt Schuld dran hat... egal. Wahrscheinlich beide: Mein Chef und ich auch.

@bigvic und It-Specialist:

Ja, ich werde mich mal umsehen. Ich suche nach einem Job, in dem ich täglich ein kleines Erfolgserlebnis (oder auch nicht) habe, statt jedes halbe Jahr ein großes Erfolgserlebnis (oder auch nicht).

Das Schreiben meiner Forenbeiträge und eure Antworten helfen mir, über meine berufliche Situation nachzudenken. Danke !!

@afo

joelonsoftware.com: Schade, alles englisch. Aber ich werde mal den einen oder anderen Artikel lesen.

Gruß,

der Stadtschrat

[Kwaiken]

Du sagst selbst, dass es dein Problem ist, Du würdest unstrukturiert vorgehen. Was liegt näher als das zu ändern und endlich mal strukturiert vorzugehen? Man kann viele Rechenaufgaben im Kopf lösen. Aber für so manche Gleichung braucht man doch etwas Schmierpapier. So ist es auch mit Projekten. Wenn ich dürfte (Urheberrecht), würde ich Dir gerne meine FernUni-Skripte zum Thema Software Projektmanagement zuschicken. Darf ich nur leider nicht Das hat mir vor einiger Zeit wirklich die Augen geöffnet.

Sobald Du den ersten PAP aufs Papier gebracht hast, wirdst Du deine Fehler im Vorgehen schon vorab erkennen und wenn der PAP mal fertig ist brauchst Du es einfach nur "abzuschreiben". Versuche es einfach mal.

Wenn Du den Ablauf ein, zwei Mal gemacht hast, kannst Du ihn auf deine (Teil-)Projekte im Betrieb entsprechend skaliert anwenden und wirst sehen, dass sich so sehr schnell Erfolgserlebnisse einstellen und der sich durch schlechtes Projektmanagement/schlechte Planung einstellende Frust während oder zum Ende der Codierung bald verschwindet.

Been there, done that. Ich hatte zum Glück einen guten Mentor in der Ausbildung, der hat meine Ansätze anfach mal "loszuhacken" direkt im Keim erstickt und mich "Hello World"-Anwendungen planen lassen.

Bearbeitet 9. Februar 2012 von Kwaiken

[gimbo]

Absolut! Schlecht geplant ist halb gescheitert. Softwareentwicklung besteht eben nicht nur aus Mini-Projekten, die man innerhalb von zwei Tagen ohne Planung ausführen kann. Wenn das dein Maßstab ist, dann bist du bei der jetzigen Stelle definitiv falsch aufgehoben. Ob Planung spaßig ist? Nun ja, macht Programmieren denn immer Spaß? Du willst Freude an den Ergebnissen haben und die sind mit Planung definitiv besser. Letztlich ist das aber auch egal, es gehört einfach dazu. Zeit scheint nicht der limitierende Faktor bei dir zu sein, also was hindert dich daran?

Ich persönlich finde es schon manchmal reizvoll, die Gedankenkonstrukte anderer Personen (oder auch die eigenen) auf Schwachstellen abzuklopfen und so letztlich ein Dokument zu erhalten, dass nur eine natürlichsprachliche Ausführung des späteren Quellcodes ist. Denn selbst wenn ein Pflichtenheft vorliegt, fehlen häufig Erläuterungen WARUM etwas umgesetzt wird und es wird häufig eine potentiell missverständliche Wortwahl verwendet. Viele Dinge in einem Pflichtenheft werden als gegeben hingenommen und daher nicht hinterfragt, Hinweise auf rechtliche Grundlagen fehlen komplett. Das Endergebnis wird dir viel mehr Sicherheit geben und verhindert spätere Diskussionen ("das hatten wir doch anders gesagt, oder?").

Die unstrukturierte Arbeitsweise anderer Menschen sollte sich nicht zu sehr auf die eigene Planung durchschlagen. Wenn dein Chef keine Ahnung von Pflichtenheft hat, dann muss das ja nicht für dich gelten. Leg ihm etwas schriftliches vor, bevor du an die Ausführung gehst. Kunden wissen meist auch nicht so recht, was sie eigentlich wollen. Programmierst du da auch einfach drauf los?

[Pixie]

Kunden wissen meist auch nicht so recht, was sie eigentlich wollen. Programmierst du da auch einfach drauf los?

Da scheint es ein beliebtes Spielchen zu sein, dass der Entwickler erstmal ~irgendwas hinzaubert, was so ~ungefähr in die Richtung geht. Dann setzt man sich davor und bespricht, wo es denn wie anders sein soll. Hinderlich bei so einem Vorgehen ist dann oft, dass dem Kunden optische Details ins Auge springen, die rein gar nichts mit der Funktionalität zu tun haben, an denen er sich dann aber festbeißt... ("das Blau ist häßlich, der Button muss runder, der dritte Menüpunkt muss weiter nach oben" usw etc pp). Kommt man dann mit "aber was ist denn jetzt mit dem Workflow?" ... "ja, also, wenn der dritte Menüpunkt an erster Stelle wäre, dann...."

Oder neulich: Eine Suche hat verschiedene Filtermöglichkeiten, u.a. eine Checkbox für einen boolschen Wert... Kunde meint, er möchte aber auch die dritte Option "alles". Also, was sagt der gute Mensch? "mach doch da statt der Checkbox einfach eine Dropdownliste" - "das ist ein boolscher Wert, der dahintersteht, also nur ja/nein" - "mach halt ne Dropdownliste" - <längere Erklärung: SQL-Abfrage, EntityFramework, Logik-Umbau> ... und nach getaner Arbeit die Frage, was denn so lange dauert, ein Control gegen ein anderes auszutauschen.

*seufz*

[Goulasz]

Da scheint es ein beliebtes Spielchen zu sein, dass der Entwickler erstmal ~irgendwas hinzaubert, was so ~ungefähr in die Richtung geht. Dann setzt man sich davor und bespricht, wo es denn wie anders sein soll. Hinderlich bei so einem Vorgehen ist dann oft, dass dem Kunden optische Details ins Auge springen, die rein gar nichts mit der Funktionalität zu tun haben, an denen er sich dann aber festbeißt... ("das Blau ist häßlich, der Button muss runder, der dritte Menüpunkt muss weiter nach oben" usw etc pp). Kommt man dann mit "aber was ist denn jetzt mit dem Workflow?" ... "ja, also, wenn der dritte Menüpunkt an erster Stelle wäre, dann...."

[...]

Raus.. aus...meinem...Kopf! Mal im Ernst, das ist als ob du beim Montagsmeeting mit dem Vertriebschef spioniert hättest. o_O

[MCCornholio]

Ich verstehe absolut nicht, was jemanden reitet sich über die Probleme anderer lustig zu machen. Ich finde es unangebracht und dreist, so über den TE herzuziehen.Abgesehen davon, hat dies nichts mit Midlife Crisis zutun sondern schlichtweg mit dem falschen Aufgabengebiet, was nicht zum Profil des TE passt.

Ein Smiley alleine reicht ja wohl nicht. Wer Ironie findet darf sie behalten !

[stadtschrat]

Hallo Kwaiken und gimbo, hallo pixie,

Ich plane definitiv zu wenig. Aber ich habe immer den Eindruck, kein Entwickler plant Software! Jedenfalls habe ich einen Programmablaufplan zuletzt vor 10 Jahren in meiner Ausbildung gesehen. Wie machen die das nur alle? Die planen alles im Kopf! Und ich Doof denke immer, ich muss das auch alles im Kopf können. Dabei bin ich ein visuell denkender Mensch, mit visuellen Methoden wie PAPs und UML könnte ich bestimmt ne Menge anfangen/hinkriegen. Aber ich bin immer so unsicher und orientiere mich in meinem Vorgehen immer an meinen Kollegen. Keine Ahnung, wie die ihre Projekte scheinbar ohne Planung und schriftlichem/visuellen Konzept hinkriegen. Einer meiner Kollegen hat tatsächlich das ganze Programm im Kopf - aber auch nur er. Es gibt nix Schriftliches. Wahnsinn. Das beeindruckt mich immer so, was der alles konzipiert, ohne es optisch in Form von Grafiken oder Beschreibungen auf Papier zu bringen. Ich orientiere mich völlig an dieser Vorgehensweise und idealisiere die "papierlose" (konzeptlose) Entwicklung. Merkwürdigerweise kommen die immer zum Ziel.

Zeitdruck habe ich nun wirklich keinen. Zum Konzipieren bliebe mir genug Zeit.

Danke euch. Mir gehen gerade eins bis n Lichter auf.

Gruß

Der Stadtschrat

Bearbeitet 10. Februar 2012 von stadtschrat

[Kwaiken]

Dann wünsche ich deinem Kollegen mal ein par Monate Pause von dem Programm. Wetten, er weiß dann nicht mehr was er wo gemacht hat? Niemand kann komplexe Strukturen komplett im Kopf haben. Um etwas im Kopf zu behalten, muss ich es immer und immer wieder widerholen. Wenn Du den 10. threadless Mini-Webserver hingeklatscht hast, dann brauchst Du dafür auch keinen PAP mehr. Bis dahin jedoch ist der Beginn einer Arbeit vor der Planung zum scheitern verurteilt.

Und etwas nicht schriftliches zu haben (ich gehe davon aus, dass der Code nicht selbst-dokumentierend ist) ist weder beeindruckend, noch wahnsinnig toll. Es ist einfach nur Wahnsinn und ich wäre während meiner Entwicklungszeit wahrscheinlich für so etwas einfach gekündigt worden. Zum sauberen Arbeiten gehört nicht nur irgendwas hinzuklatschen, sondern die Kunst besteht darin es für andere auch lesbar zu tun. Jeder, der sich durch "Ich habe alles in meinem Kopf" unverzichtbar machen möchte ist ein Risiko für das Unternehmen.

Zudem: Du siehst doch anscheinend selbst gut wo deine Schwächen liegen und wie Du diese ausbessern kannst, also was hält dich davon ab es einfach zu tun?

[afo]

Manche sind vielleicht echt so schlau dass sie alles im Kopf amchen können. Manche sind vielleicht so schlau, dass sie ohne vernünftiges Konzept trotzdem was vernünftiges bauen können. Und wir gewöhnlichen sterblichen müssen halt unsere Diagramme malen und Dokus schreiben. Da frag ich mich warum du, wenn du schon um deine "Schwäche" weißt es nicht einfach machst. Es hindert dich doch keiner dran.

[carstenj]

Hi,

es gibt ja auch extrem viele unterschiedliche Progammierkonzepte und Herangehensweisen. Ich kann dir ein super Buch empfehlen:

Der Pragmatische Programmierer: Amazon.de: David Thomas, Andrew Hunt, Steffen Gemkow, Andreas Braig: Bücher

Das Geld ist auf jeden Fall gut investiert. Selbst wenn man nicht jeden Tipp beherzigen kann, nimmt doch jeder, der irgendwas mit Programmierung zu tun hat, immer einen Teil mit. Dort geht es ja gerade darum wie man anfängt, wie man dokumentiert, wie man verbessert, wie man überhaupt Programme schreibt, die sich verbessern und warten lassen. Ich würde dir empfehlen, damit mal anzufangen.

[GoaSkin]

Müsste ich an einer Finanz-Software herum arbeiten, so würde mir spontan eine Sache in den SInn kommen, wo ich meine Grenzen habe (und was vielleicht auch der wichtigste Punkt meiner Grenzen hier bei wäre): ICH HABE KEINE AHNUNG VON FINANZEN.

Spontan nachgedacht würde ich aber auch denken, dass die Anwendung notwendiger Programmier-Techniken das geringere Problem ist, da eine Finanz-Software ebenso wie das durchschnittliche GUI-Programm oder eine dynamische Webseite letztendlich nur mit Hilfe von Standard-Widgets Dateneingaben analysiert, umrechnet und aufbereitet wieder aus gibt. Es müssen keine grundlegend neue Lowlevel-Schnittstellen entwickelt werden.

Aber weil ich keine Ahnung von Finanzen habe wäre mir nicht klar, wie ich ein solches Programm sinnvoll gestalten müsste. Und was die Kalkulationen betrifft, die ein solches Programm durchführt, würde ich von meinem mathematischen Know-How an meine Grenzen stoßen.

IM FAZIT denke ich somit, dass das eigentliche Problem sein könnte, dass die Firma (vielleicht zusätzlich) einen Controller oder BWLer mit Programmiererfahrung bräuchte.

[Pixie]

Ich habe auch einen kollegen, der, wenn er einen Anruf mit einer neuen Anforderung bekommt, mal eben eine rauchen geht und wenn er wieder rein kommt, hat er alle Datenbankänderungen schon im Kopf fertig... damit meine ich jetzt nicht zwei neue Spalten, sondern ~6 neue Tabellen mit Verknüpfungen... Okay, er hat auch etwas zweistelliges mehr an Berufserfahrung, trotzdem kommt man sich immer etwas klein und dumm vor daneben

Planen mit UML o.ä. tue ich eigentlich auch nicht. Da ich aber auch ein visuell orientierter Mensch bin und immer irgendein Blatt Papier für notizen vor der Tastatur habe, kritzel/zeichne ich mir dann doch öfter einige DB-Beziehungen aufs Papier. Das ist keine echte Planung und fliegt auch danach weg... es ist einfach nur die Visaulisierung meiner Überlegungen, an der ich noch einmal überlege, ob alles so paßt.

[flashpixx]

Okay, er hat auch etwas zweistelliges mehr an Berufserfahrung, trotzdem kommt man sich immer etwas klein und dumm vor daneben

Das ist doch ein guter Anfang, frag' nach, wie er das macht, denn für Euch beide ist das auch eine Lernerfahrung.

Da ich aber auch ein visuell orientierter Mensch bin und immer irgendein Blatt Papier für notizen vor der Tastatur habe, kritzel/zeichne ich mir dann doch öfter einige DB-Beziehungen aufs Papier.

Das ist auch ein guter Ansatz, man muss herausfinden, wie man am besten das Problem angeht. Der eine malt sich ne Skizze, der nächste macht UML, der dritte ein Flussdiagramm, usw. Finde für Dich das passende Medium, mit dem Du das Problem für Dich darstellst.

Generell ist es zu empfehlen nicht zu versuchen, direkt "alles" zu lösen, sondern das ganze wie eine Apfelsine zu betrachten, d.h. von außen nach innen. Z.B. im Sinne der UML, welche Klassen braucht man, d.h. gar nicht darüber nachdenken, was jede Klasse können muss. Wenn man dann mal so einen Satz von Klassen hat, überlegt man sich, ob evtl Klassen inhaltlich zusammen gehören (Vererbung). Wenn man dann das hat, schaut man sich jede Klasse an und überlegt was sie für Methoden und Eigenschaften braucht. Hat man das gemacht, dann überlegt man sich den Inhalt der Methoden.

Ich gehe jedenfalls aus meiner Erfahrung davon aus, dass meistens das Problem an dem Weg hängt. Oft muss man erst mal jemanden beibringen, dass er sich das Problem strukturieren und zerlegen muss, als sich direkt eine Lösung für alles zu überlegen. Da Du ja selbst sagst, dass Du viele kleine Probleme besser lösen kannst, als ein großes, spricht das genau dafür, d.h. eigentlich musst Du nur das große Problem in viele kleine Teilprobleme zerlegen und dann kannst Du es auch lösen. Jedes Teilproblem musst Du dann wieder zerlegen, das ganze würde man rekursiv so lange machen, bis man das Problem lösen kann.

Bearbeitet 10. Februar 2012 von flashpixx

[Pixie]

frag' nach, wie er das macht,

Der ist so genial.

Einige kommen mit perfektem Gehör auf die Welt, er halt mit... wie auch immer man das nennt.

[Dox]

Ganz einfach: setze dich mit dem Thema Software-Engineering auseinander. Wenn man noch keine passable Methodik verinnerlicht hat, dann muss man sich eben eine vernünftige Methodik aneignen.

Investiere doch einfach mal ein paar Taler in ein gutes Fachbuch zum Thema Software-Engineering und setze ein kleines Projekt damit um. Und beim nächsten Projekt wiederum.

Bei uns im Studium wurde immer darauf beharrt, dass wir Probleme systematisch angehen. Natürlich will man direkt loslegen, aber oft endet das damit, dass man dann rumfrickelt und alles drei mal neu schreibt.

Letztendlich zahlt es sich aber aus, wenn man erstmal intensiv über eine Problem nachdenkt, dann mit passenden Werkzeugen plant (auch Tests und so weiter plant) und das Ganze dann erst umsetzt.

Je größer das Projekt, umso wichtiger wird die Planung. Also lieber TE, es ist nie zu spät die eigene Methodik zu verbessern. Viel Glück und Erfolg dabei!