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

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?

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

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

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

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.

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?

Zitat von stadtschrat

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.

Zitat von stadtschrat

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.

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

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

Zitat von MCCornholio

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.

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

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.

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?

Zitat von gimbo

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*

Zitat von Pixie

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