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

[It-Specialist]

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

Was von meinem Beitrag hast du nicht verstanden? Ob mit Smiley oder nicht - der TE schildert hier Probleme die ihn belasten, über die er reden möchte. Glaubst du, er braucht dann irgendjemanden der da drüber dumme Sprüche macht? Ich glaube wohl kaum.

Tu mir einen Gefallen, wenn du dich über andere Leute lustig machen möchtest, dann troll auf anderen Foren rum. Das FI-Forum erfreut sich großer Beliebtheit, gerade weil hier drauf geachtet wird, dass der Grad an sinnvollen und angebrachten Beiträgen die übliche Quote von Vollpfosten übersteigt.

Das hast du offensichtlich nicht verstanden, darum solltest du nochmals genau überlegen, ob es denn wirklich angebracht ist in solchen Situationen Witze zu machen.

Manchmal ist weniger mehr, wenn du nichts sinnvolles zu sagen hast, dann lass es einfach bleiben, dich zwingt keiner dazu hier Kommentare zu verfassen.

[Eleu]

Hallo stadtschrat,

also wenn ich mir ein Konzept für ein Programm überlege, erstelle ich einen grafischen Ablaufplan.

Z.B. hiermit:

Programm Ablauf Plan Designer als Freeware | VHPD Blog

Einarbeitungszeit ca. 10min. bei halbwegs vorhandener Transferleistung

Zuerst mache ich eine Grobplanung was dem Hauptprogramm entspricht und dann erstelle ich die Unterprogramme, was einer immer feiner unterteilten Feinplanung entspricht

So kann ich mich intensiv mit den Details auseinandersetzen, ohne letztendlich den Gesamtüberblick zu verlieren.

Das Ganze ist auch eine gute Grundlage für ein Pflichtenheft.

Vielleicht mal so als Anregung.

Wie heißt es so schön.

Nur das wahre Genie überblickt das Chaos.

Gruß

Eleu

[stadtschrat]

Kwaiken schrieb:

Jeder, der sich durch "Ich habe alles in meinem Kopf" unverzichtbar machen möchte ist ein Risiko für das Unternehmen.

Da stimme ich dir zu. Chefs sollten darauf achten, dass sie nur Leute einstellen, die bereit sind, ihr Wissen zu teilen.

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?

Vielleicht, dass ich fürchte, dass die Anerkennung für das Planen ausbleibt. Sowieso hat es mein Chef nicht so mit Anerkennung. In meinem Kopf klebt der Gedanke: "Wieso soll ich etwas tun (Planen), was nur Zeit beansprucht, und was für meinen Chef unsichtbar bleibt?" Dann erzeuge ich lieber sofort sichtbares, aber nicht funktionierendes Blendwerk.

@carstenj: Ich habe mir die Leseproben und Rezensionen des Buchs "der pragmatische Programmierer" durchgelesen. Das gefiel mir, da habe ich es bestellt.

GoaSkin schrieb:

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.

Je nach fachlichem Thema, für das man programmiert, ist meine Motivation auch mal höher und mal geringer. Ich habe mal Software für Garten- und Landschaftsbauer geschrieben, und weil mir der Garten- und Landschaftsbau sympathisch ist, habe ich mich gern dafür ins Zeug gelegt. Mit der Ahnung sehe ich das anders: Ich glaube, man kann als Programmierer fast in jedes fachliche Thema einsteigen. Man muss ja kein Experte auf dem Gebiet werden, sondern nur über das Fachwissen (z.B. Finanzen, Häuser, Lager, Restaurants o.ä.) verfügen, was man zum Programmieren benötigt.

@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?

@dox: Ich bin soo chaotisch, ich hoffe, ich finde jemals zu einer eigenen Methodik. Was mich auch immer verwirrt, ist, dass mir viele Sachen gleich wichtig erscheinen, und ich nicht weiß, womit ich anfangen soll, welchem Teilaspekt ich die höhere Priorität zuteilen sollte. Dann habe ich ein riesiges Chaos von scheinbar gleich wichtigen Dingen im Kopf.

Wenn ich so über meine bisherige Vorgehensweise nachdenke:

• Eine halbe Minute nachdenken
  
• Gleich ran und programmieren
  
• Bei thematischen Unsicherheiten: Nicht nachfragen, sondern selbst vermuten, wie es sein könnte und weiterhacken
  
• Nach zwei Monaten: "Mist, das geht so ja gar nicht"
  
• Wieder eine halbe Minute nachdenken
  
• Die Hälfte wieder komplett löschen und nach einer anderen Systematik neu programmieren
  
• Nach weiteren zwei Monaten: Wieder unlösbare Konzeptschwächen
  
• Nachbessern
  
• Workarounds sozusagen mit Tesafilm rankleben, damit es doch halbwegs funktioniert
  
• Und dann: Frust, weil ich Monate meines Lebens in diese Sache investiert habe, und weil das ursprüngliche Konzept so schlecht war, dass es in der letzten Version nunr noch ansatzweise zum Tragen kommt.
  

Was ich auch immer schwierig finde ist: Dass dieser Job so virtuell ist. Es ist etwas ganz anderes bei einem Möbeltischler, der einen Schrank fertigt. Als Programmierer hat man nur dieses Ungreifbare aus Buchstaben und Zahlen, was dann ein "Programm" darstellt - das ist das Gegenteil von etwas Handfestem.

Sicher, ansatzweise hat auch eine schöne, leistungsfähige Klasse etwas von einem gelungenen Schrank, Stuhl o.ä. ... aber für mich ist es trotzdem ein großer Unterschied.

Bearbeitet 13. Februar 2012 von stadtschrat

[hmaas]

Es ist etwas ganz anderes bei einem Möbeltischler, der einen Schrank fertigt.

Aber der Möbeltischler "plant" den Schrank auch vorher. Er wird zum. eine Skizze des Schrankes erstellen, wahrscheinlich einen Zuschnittplan und sich über die Detailes wie Verbindungen und Beschläge Gedanken machen.

Wenn der Möbeltischler nach dem Kundengespräch direkt an die Maschine geht und anfängt das Plattenmaterial zu zuschneiden, kannst du dir doch selber ausmahlen, wie der Schrank am Ende aussehen wird.

Früher bin ich auch immer "losgestürmt" und musste hinterher feststellen, das ich einen unstrukturieten, nicht wart- bzw. änderbaren Code erzeugt hatte. Heute denke ich vorher über die zu lösende Aufgabe nach. Kleine Programme werden zwar immer noch ohne große Planung umgesetzt, aber auch dort gibt es bestimmte Strukturen, die eingehalten werden, um die Wartbarkeit zu erhöhen.

Bei größeren Projekten wird der Planungsanteil wichtiger und größer. Spätestens wenn man mit mehreren an einem Programm/Projektarbeitet ist die Planung unverzichtbar.

Gruß Pönk

[carstenj]

Hi,

@stadtschrat:

Deine Vorgehensweise eruinnert mich an Prototyping:

Prototyping (Softwareentwicklung)

Also zuerst irgendwas programmieren was irgendwie funktioniert, ohne Rücksicht auf Genauigkeit und Performance. Die daraus gewonnen Erfahrungen kann man hinterher, beim neu Programmieren, nutzen.

Was natürlich gar nicht geht:

Bei thematischen Unsicherheiten: Nicht nachfragen, sondern selbst vermuten, wie es sein könnte und weiterhacken

Ich finde es aber sehr gut, dass du die Probleme erkennst du so konkret nennen kannst, denn das ist ja ein großer Teil zur Lösungsfindung. Beim Programmieren selber macht man das ja auch so, nämlich ein großes Problem in mehrere kleinere Probleme aufteilen, die dann einfacher umzusetzen sind.

Für kleinere Probleme ist die Vorgehensweise, einfach drauf loszuprogrammieren (natürlich geht das ganz ohne Vorplanung nie) oft auch gar nicht so verkehrt. Wenn man es dann noch schaft, die Erkenntnisse und Fallstricke aus diesem "Prototyp" in dem Endprodukt zu vermeiden, ist man schon einen großen Schritt weiter.

Bearbeitet 13. Februar 2012 von carstenj

[flashpixx]

@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.

[metux]

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.

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!

[stadtschrat]

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

Bearbeitet 23. Februar 2012 von stadtschrat

[carstenj]

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.

[Eleu]

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.