Zitat von stadtschrat

@flashpixx: Die Vorgehensweise, die du beschreibst, klingt einleuchtend (Apfelsinenmodell). Ich muss dringend viel mehr Zeit mit dem Planen verbringen. Wissen Chefs, die selbst keine Programmierer sind eigentlich, dass das Codeschreiben nur einen winzigen Teil der gesamten Arbeit an einem Projekt ausmacht - oder zumindest ausmachen sollte?

Kommt drauf an. Ich kann da bisher eigentlich nur positives berichten. Das Problem ist aber häufig, dass nur das Endprodukt gesehen wird und nicht der Weg, also so lange es irgendwie läuft ist es gut.
Was ich noch zu dem Vorgehen sagen muss, Du musst das Problem "generalisieren", d.h. also Dein Lösungsalgorithmus sollte so flexibel wie möglich sein. Das kommt aber erst mit der Zeit. An einem Beispiel: Du sollst einen Sortieralgorithmus für Zahlen schreiben, d.h. Array bauen und z.B. nen Bubblesort codieren. Wenn Du jetzt aber noch Zeichenketten sortieren willst, dann wird oft Copy-Past gemacht und der Code umgearbeitet. Damit hast Du den Code dupliziert und wenn da nun ein Fehler drin ist, dann musst Du das immer zweimal nachbessern. Eleganter ist es, einmal den Sortieralgorithmus zu schreiben, der z.B. verschiedene spezielle Sortieralgos enthält (Quicksort, Bubblesort, Straight-Selection), darauf dann eine so genannte Comparable Schnittstelle zu setzen, d.h. eine Struktur, die dem Algorithmus sagt, welches von zwei Elementen kleiner bzw. größer ist und dann das ganze mit Hilfe von OOP einzubauen.
Du hast damit dann nur einmal den Code für das Sortieren geschrieben, kannst dann mehrere Algorithmen verwenden. Die Schnittstelle für die Daten ist abstrakt formuliert, d.h. Du kannst jede Art von Daten sortieren. Das was dann individuell ist, ist ggf die Anpassung der Comparschnittstelle für Deine aktuellen Daten.

Sprich im Sinne des Apfelsinenmodells, einmal von außen nach innen gehen und jede Schicht so abstrakt wie möglich sehen. Zusätzlich sollten sich die Inhalte der einzelnen Schichten möglichst nicht vermischen, d.h. strikt die Inhalte trennen (geht in der Praxis nicht immer, aber man sollte es so weit wie möglich versuchen). Keine Codeduplikate erzeugen und ganz klar definieren was welcher Codeabschnitt macht. Sprich Du hast für ein Problem, genau einmal ein Strück Code. Sind Probleme ähnlich solltest Du darüber nachdenken, Deine Algorithmen so zu entwerfen, dass Du beide Probleme mit der gleichen Routine erschlagen kannst.

Zitat von stadtschrat

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.

Na dann versuch doch erstmal, das große Problem in möglichst viele kleine Teilprobleme zu zerlegen.
Oft findet man dann für viele Dinge schon fertige Lösungen die man einfach zusammenbauen kann.

Vielleicht kannst Du ja mal eines Deiner Projekte genauer schildern und erklären, woran Du da
Deiner Meinung nach gescheitert bist.

Evtl. könnt ich mich auch ein wenig als Mentor zur Verfügung stellen.

Zitat von stadtschrat

Meine größten Erfolgserlebnisse im Büro sind, wenn der Drucker Streifen druckt, und ich das Problem per Druckerhandbuch lösen kann.

Vielleicht wäre genu das ja das richtige Aufgabengebiet das richtige für Dich: ebene das "Mädchen für alles"
jemand der für die vielen tausend kleinen Alltagsprobleme eine rasche pragmatische Lösung herzaubern
kann, ohne daß daraus erstmal ein großes Projekt draus wird - solche Leute sind auch wichtig!

Hallo metux,

Zum Scheitern von Projekten:
Aktuell bei mir z.B. folgendes: Ich habe ein Projekt, da geht es darum, aus "meinem" Programm heraus Daten an eine Internetseite zu senden. Man erhält dann später als Antwort PDF- und XML-Dateien von der Seite zurück. Die PDF-Dateien zeige ich dann mit demselben Programm an. Bloß... nach über einem Jahr erfahre ich, dass die PDF-Dateien ziemlich unwichtig sind, aber die XML-Dateien wichtig sind, weil sie zwingend eingelesen werden müssen. Ich muss meinem Chef nun also beichten, dass ich über ein Jahr an einer Sache immer mal wieder ein bißchen rumprogrammiere, aber die grundlegende Funktionalität schlicht fehlt! Bin gespannt auf meine Kündigung! Ziemlich klar: Ich habe zu wenig nachgefragt und den leichten Teil des gesamten Sachverhalts eingebaut (PDF anzeigen) und die XML-Dateien ignoriert. Das war schön einfach. Ich mag Spaß bei der Arbeit ;-) Immer diese komplizierten Sachen. Immer wird alles noch komplizierter! *würg*

Vielleicht hat MCCornholio recht und meine Midlife-Crisis beginnt... sollte ich das feststellen, dann verspreche ich, von diesem Forum zum Forum von med1.de zu wechseln :-)

ich hab mal einen Bericht über einen Microsoft-Programmierer im Fernsehen gesehen, der mit der Entwicklung von Windows-Systemkomponenten steinreich geworden ist (sieht nicht so aus, als würde mir das auch passieren)... Aber irgendwann hat Microsoft ihn mit einer dicken Abfindung aus "betrieblichen Gründen" entlassen. Obwohl er genug Kohle bis zum Letzten seiner Tage hat, war er ein ziemlich enttäuschter und verbitterter Mensch. Er hatte eben nur Geld bekommen und durch seine Beschäftigung auch Anerkennung. Das Geld hat er noch, aber die Anerkennung endete mit seiner Kündigung. Der sitzt jetzt vielleicht immer noch in seiner Supervilla, zeichnet Comics und fühlt sich veräppelt.

Mist... ich klinge wirklich nach Midlife-Crisis. So, ich hör jetzt auf zu schreiben.

metux schrieb:

Vielleicht wäre genu das ja das richtige Aufgabengebiet das richtige für Dich: ebene das "Mädchen für alles"
jemand der für die vielen tausend kleinen Alltagsprobleme eine rasche pragmatische Lösung herzaubern
kann, ohne daß daraus erstmal ein großes Projekt draus wird - solche Leute sind auch wichtig!

Ja, das wäre was für mich!

Gruß
stadtschrat

Hi,

Man erhält dann später als Antwort PDF- und XML-Dateien von der Seite zurück. Die PDF-Dateien zeige ich dann mit demselben Programm an. Bloß... nach über einem Jahr erfahre ich, dass die PDF-Dateien ziemlich unwichtig sind, aber die XML-Dateien wichtig sind, weil sie zwingend eingelesen werden müssen.

mal ernsthaft: Wie kommst du denn an so eine Aufgabe? Das wird dir doch nicht mal eben mehr Mail zugeschustert, oder? Da wird es doch ein oder zwei Besprechungen zu gegeben haben, da wird ein Pflichtenheft erstellt und auf die wichtigsten Dinge explizit hingewiesen worden sein?

Natürlich ist das nicht gerade ein Vorzeigeprojekt deinerseits, aber wenn du tatsächlich ein Jahr lang an einem kleinen Teil des Projektes rumschraubst, ohne auf das Wesentliche zu achten und das fällt KEINEM auf, liegt da aber viel mehr im Argen als deine vermeintliche Inkompetenz. Ich denke wenn das wirklich so ist, sollten da komplette Arbeitsabläufe mal überarbeitet werden, und diesen Schuh muss sich auch dein Vorgesetzter anziehen.

Zitat von stadtschrat

Mist... ich klinge wirklich nach Midlife-Crisis. So, ich hör jetzt auf zu schreiben.

Vielleicht solltest Du Dich mal mit Deinem Arzt besprechen, wenn Du sonst niemanden hast.
Er wird sicher einen Rat wissen, oder dich entsprechend weiter vermittelt
Ich glaube es ist kein fachliches Problem. Es klingt ziemlich ausgebrannt.
Du musst aufpassen, dass Du nicht an der Seele krank wirst.

Viel Glück und halt die Ohren steif....und das andere auch.