Hallo David, ein Zeitschätzungsvideo wäre toll, das kommt bei mir öfter vor und dann wird man bei der Schätzung auch noch runtergehandelt um später zu nörgeln, weil es doch nicht reicht und wenn es reicht, dann muss man sich hierfür total unter Druck setzen. Kannst du hier mal ein Video dazu machen? LG
Zunächst mal gute Besserung für deinen Rücken! Meine Nerv-Aufgaben: - unnötige Unterbrechungen durch Kollegen, die ins Büro kommen oder Anrufen; dann konzeptionell wieder von vorne beginnen (beim Debugging von Spaghetti-Code besonders spaßig), obwohl das Thema entweder völlig unnötig oder mit einer Mail oder einem Ticket ohne Störung hätte erledigt werden können - fehlende oder ungenügende Anforderung die zu Feedback Loops führen - Debuggen von legacy Code, wo man sich nach dem 10ten Bug denkt "in der Zeit hätte ich das ganze Modul besser neu geschrieben"
Meine fünf "Nerv"-Themen: * Unterbrechungen durch Kollegen/Kunden - Besonders das Telefon. Wenn es nicht brennt reicht eine E-Mail. * Unklare Anforderungen vom Kunden oder PO/PM * Zu hoher Zeitdruck - neue Prioritäten * Unwissenheit der Kollegen / Fortbildungsstatus * Kryptische Fehlermeldungen von (Fremd)komponenten - Gerade erst zwei gehabt wo man sich hätte Stunden sparen können wenn die Fehlermeldung aussagekräftig wäre. Bezüglich PCs ist es zweischneidig. Wenn der eigene PC super schnell ist treten die Performanceprobleme bei einen selber kaum auf sondern erst beim Kunden. Aber der Rechner sollte auch keine 5 Jahre alt sein ;-) Ansonsten stimme ich den weiteren Punkten zu.
Hey Marco, danke für Deine Punkte, hatten wir ja FAST alles - bei den "unklaren Anforderungen" bin ich grade selbst total überrascht, dass das nicht genannt wurde - guter Punkt! Gruß David
Ich bin noch Azubi, aber meine sind: - Die Kommunikation mit Kollegen. Die ist echt anstrengend. Jeder versucht schlauer als der andere zu sein und würft wahllos mit "Fachbegriffen" um sich die gar keine sind. - alter Quellcode, der selbst damals sinnfrei sein musste. - veraltete Entwicklungs-Standards, neue Technologien haben kein Platz, da sich kaum einer rein arbeiten möchte und der Chef auch nur seine Expertise in dem alten Zeug hat - zu viele Kommunikationswege: interner Chat, Ticketverwaltung, E-Mail, Telefon, mündlich. Man muss jeden Dialog in einem Gruppenchat verfolgen, da es irgendwann einem selber betreffen könnte - Meetings, in denen zu viel rumgelabert wird ohne die wichtigen Themen zu besprechen - keine empathische Führung von oben oder Blockaden durch den Flaschenhals Chef, da er keine Entscheidungsgewalt teilen möchte
Hey, 1. Oh ja, das kenne ich :) 2. Richtig, auch ein guter Punkt! 3. Auch gut und sehr sehr gefährlich ;) 4. Stimmt auch, den Punkt hatte ich gar nicht auf dem Plan! 5. Den auch nicht, das ärgert mich etwas - das wär echt gut gewesen :) Danke für Dein Feedback :) Gruß David
Für eine Rollentrennung zwischen Entwickler, Anforderungsmanager, 1st, 2nd und 3rd Level Support sind wir viel zu wenig Leute mit einem viel zu breiten fachlichen Spektrum. Das machen wir alles quasi in Personalunion. Lediglich für größere Anforderungen haben wir einen Kollegen, der dies vorstrukturiert und koordiniert. Hardware war noch nie mein Problem. Die Anwendungen laufen (und compilieren) auf dem Server. Und ich mache ja Softwareentwicklung und keinen Videoschnitt. 🙂 Was am meisten stört, sind Kollegen, die mich hartnäckig in ein Gespräch verwickeln wollen, obwohl ich signalisiere, dass es gerade nicht passt und ich mich später melde. - Nachteil der Vor-Ort-Arbeit.
Hey Ole, ok, also die nervigen Kollegen - ich habe das Problem früher immer mit Kopfhörern gelöst. Egal wo ich bei Kunden entwickel und ob ich Musik höre oder nicht, ich habe immer Kopfhörer auf :) Gruß David
Ist bei mir ähnlich. Nur ein kleines Team aus Chef, Mediengestalterin und meiner Wenigkeit. Da ist man natürlich für alles was mit der Technik irgendwie zu tun hat verantwortlich. Hat seine Vor- und Nachteile. Meine Top1 ist definitiv Chef, da er fast immer mit irgendwelchen Problemen ankommt, wenn man gerade konzentriert am proggen ist. Dicht gefolgt von Telefon. Da gibt es Tage, da geht es, da nur wenige Anrufe und an anderen Tagen klingelt es quasi pausenlos. Wenn man sich dabei konzentrieren muss, ist das echt anstrengend. Hardware ist für mich egal, da ich in der Webentwucklung arbeite und somit keinen Code schreibe der kompiliert werden muss. Nicht desto trotz habe ich letztes Jahr einen neuen I5 mit SSD und 16 GB RAM bekommen. Bis jetzt habe ich keine Performance-Probleme. Sollte das irgendwann ein Problem sein, wird der PC entweder aufgerüstet oder getauscht. Das Problem mit den Kollegen habe ich nicht, da ich wie erwähnt neben meinem Chef nur eine Kollegin habe. Die fragt nur selten nach.
Irgendwie kenne ich einiges, aber manches ist doch schon recht lange her. Als Bsp. die langsame Hardware. Bei uns sind seit Jahren Entwicklungs- und Testrechner virtualisiert, das hat bisweilen zwar eizelne Einschränkungen (bspw. sieht die GUI Applikation nicht alle Tastatur-Keys). Virtualisierung war aber bei Corona der Matchwinner. Dank der vSphere macht es absolut keinen Unterschied ob ich im Geschäft oder von zu Hause aus arbeite. Bzgl. Performance, den Einzelmaschinen auf der vSphere kann man die Anzahl der Prozessoren, den Speicher- und Plattenplatz einfach zuordnen, die Entwicklungsmaschinen sind dabei eher schmalbrustig (da läuft eh nur eine Entwicklungsumgebung und es wird gemächlich editiert). Für das Übersetzen gibt es Compileserver, die das deutlich schneller durchführen, oft werden auch weitere Aktionen drangehängt (z.B. Code-Checker oder Blackbox Tests). Bei den Testsystemen: wenn ein System in Maintenenace ist bekommt man die Maschine genannt und man kann schnell selber drauf nachschauen, bzw. man bekommt die Maschine direkt und man kann dem Fehler selber nachstellen (ohne sich eine Ersatzumgebung aufbauen zu müssen). Bzgl. Support, da haben wir ein Skript welches automatisiert die komplette Umgebung des Kunden in ein tar File packt. Der Kunde weiß wie man dieses Skript aufruft und das File uns zur Verfügung stellt. Dazu beschreibt er noch was er gemacht hat und was seiner Meinung falsch ist. Die Fehleranalyse kann anschließend größtenteils ohne weiteren Kundenkontakt erfolgen. Und wenn wir weitere Infos brauchen (meistens Lifedaten jenseits der Logs, Corefiles, Config, etc.) dann fragen wir gezielt nach, bei manchen Kunden kommen wir sogar per Remote Access sogar direkt auf deren Maschinen. Nun ja, und was nervt mich? Ziemlich oft Windows und Office (z.B. Requirement Dateien des Kunden).
Hi David, ich wäre dir für das angesprochene Video(-s) zur Aufwandsschätzung sehr dankbar. Da ich mir persönlich als Junior noch sehr, sehr, sehr schwer damit tue und gerne darin besser werden würde. Gerade Aufwandsschätzungen die Themen betreffen mit denen ich zuvor noch nie einen Berührungspunkt hatte sind besonders schwer. Aber auch bei Themen wo ich eig. eine Aufwandsschätzung abgeben könnte, da ich in bspw. mit dem jeweiligen Modul oder Abschnitt der Software zu tun hatte, dann fühle ich mich jedes Mal ein wenig Unwohl wenn ich meine Schätzung abgeben muss. Da das für mich dann immer so einen faden Beigeschmack hat von: "Was solange brauchst du dafür?! Ich würde nur so lange brauchen..." also das egal wie die Schätzungen nie passen. Also ich wäre dir und auch den anderen Entwicklern hier, die schon ein wenig länger mit dabei sind, sehr dankbar dafür wenn Sie mir Ihre konkreten Tipps mitteilen könnten. Da ich wirklich, wirklich gern besser darin werden würde. Da es ja auch wie du im Video gesagt hast ein vollkommen legitimes Thema ist, von dem jenigen der ein bestimmtes Feature implementieren soll eine ungefähre zeitliche Aufwandsschätzung bekommen zu können, um die Planung besser machen zu können.
Definitiv war oder ist es das Telefon. Solche Unterbrechungen können von "bisschen stören" bis zum "riesen Problem" reichen. (Bei 0:07 sagst Du "Ich habe mal 20 Entwickler ... angerufen" ;-) ) Dokumentieren nervt, da zähle ich auch zu den 2/3. Aber ich sehe auch die Vorteile einer guten Dokumentation. Und wenn eine Frage kommt, die durch die Dokumentation beantwortet werden kann, dann reicht oft ein "rtfm" als Antwort ;-)
Hey Carsten, oh mein Gott, da hab ich wohl meine eigenen Tipps torpediert - ich bin eben aus dem Lachen gar nicht mehr rausgekommen, als ich Deinen Kommentar gelesen habe.... :D Gruß David
Also der Punkt der mich am meisten nervt ist schlechte Kommunikation egal ob mündlich, schriftlich eine fehlende Dokumentation oder auch teilweise falsche Kommentare. Dadurch verliert man immer viel Zeit.
Die Entwickler wissen also nicht welche Daten die bewältigen müssen... was machen die dann den ganzen Tag? Ich will ja gar nicht daran denken, "Wer" es denn wissen "soll", wenn es nicht mal die Entwickler wissen. 😂😂😂🤣 klar, die Putzfrau weiß es.
Hey Leschek, ich habe nur in Scrum-Teams gefrage (fällt mir grade auf), deshalb ist der Punkt total untergegangen, aber hast recht - das kann echt nerven! Gruß David
mich nervt es wenn mich der chef zwingt, mit diesem kackscheiss mikroschrott windoof zu arbeiten. ich will als betriebssystem linux und sonst nix. und frameworks gehen mir auch schon immer mechtig aufn keks. fazit: selbstendig machen. wenn mir der scheff eine depperte tastatur mit furs programmieren total unpraktische german layout hinstellt, dann kauf ich mir einfach SELBER eine mit dem furs programmieren und computerarbeiten einzig wahren praktischen US-layout. und alle scheiss storenden tasten werden einfach rausgeschmissen ausgebaut: nervige tab-taste, menu und windowslogo tasten. und eine firma die den leuten nicht mehr als 2 Monitore gibt, is ein reiner gratlerladen. man braucht 3 monitore. und auch maus ohne back-button is einfach eine realitetsferne frechheit.
Hallo David, ein Zeitschätzungsvideo wäre toll, das kommt bei mir öfter vor und dann wird man bei der Schätzung auch noch runtergehandelt um später zu nörgeln, weil es doch nicht reicht und wenn es reicht, dann muss man sich hierfür total unter Druck setzen. Kannst du hier mal ein Video dazu machen? LG
Hey Steven,
setze mich die Tage mal hin und schaue was man da alles machen könnte :)
Gruß David
Zunächst mal gute Besserung für deinen Rücken!
Meine Nerv-Aufgaben:
- unnötige Unterbrechungen durch Kollegen, die ins Büro kommen oder Anrufen; dann konzeptionell wieder von vorne beginnen (beim Debugging von Spaghetti-Code besonders spaßig), obwohl das Thema entweder völlig unnötig oder mit einer Mail oder einem Ticket ohne Störung hätte erledigt werden können
- fehlende oder ungenügende Anforderung die zu Feedback Loops führen
- Debuggen von legacy Code, wo man sich nach dem 10ten Bug denkt "in der Zeit hätte ich das ganze Modul besser neu geschrieben"
Meine fünf "Nerv"-Themen:
* Unterbrechungen durch Kollegen/Kunden - Besonders das Telefon. Wenn es nicht brennt reicht eine E-Mail.
* Unklare Anforderungen vom Kunden oder PO/PM
* Zu hoher Zeitdruck - neue Prioritäten
* Unwissenheit der Kollegen / Fortbildungsstatus
* Kryptische Fehlermeldungen von (Fremd)komponenten - Gerade erst zwei gehabt wo man sich hätte Stunden sparen können wenn die Fehlermeldung aussagekräftig wäre.
Bezüglich PCs ist es zweischneidig. Wenn der eigene PC super schnell ist treten die Performanceprobleme bei einen selber kaum auf sondern erst beim Kunden.
Aber der Rechner sollte auch keine 5 Jahre alt sein ;-)
Ansonsten stimme ich den weiteren Punkten zu.
Hey Marco,
danke für Deine Punkte, hatten wir ja FAST alles - bei den "unklaren Anforderungen" bin ich grade selbst total überrascht, dass das nicht genannt wurde - guter Punkt!
Gruß David
Ich bin noch Azubi, aber meine sind:
- Die Kommunikation mit Kollegen. Die ist echt anstrengend. Jeder versucht schlauer als der andere zu sein und würft wahllos mit "Fachbegriffen" um sich die gar keine sind.
- alter Quellcode, der selbst damals sinnfrei sein musste.
- veraltete Entwicklungs-Standards, neue Technologien haben kein Platz, da sich kaum einer rein arbeiten möchte und der Chef auch nur seine Expertise in dem alten Zeug hat
- zu viele Kommunikationswege: interner Chat, Ticketverwaltung, E-Mail, Telefon, mündlich. Man muss jeden Dialog in einem Gruppenchat verfolgen, da es irgendwann einem selber betreffen könnte
- Meetings, in denen zu viel rumgelabert wird ohne die wichtigen Themen zu besprechen
- keine empathische Führung von oben oder Blockaden durch den Flaschenhals Chef, da er keine Entscheidungsgewalt teilen möchte
Hey,
1. Oh ja, das kenne ich :)
2. Richtig, auch ein guter Punkt!
3. Auch gut und sehr sehr gefährlich ;)
4. Stimmt auch, den Punkt hatte ich gar nicht auf dem Plan!
5. Den auch nicht, das ärgert mich etwas - das wär echt gut gewesen :)
Danke für Dein Feedback :)
Gruß David
Hi, ich bin neugierig: Was für "Fachbegriffe" sind das zum Beispiel?
JA! Bitte unbedingt ein Estimation/Aufwandschaetzungsvideo
Auch dieses ist wie immer sehr lehrreich
C# Extention methods und Clean Code - meinst du, das passt zusammen?
Auf ein Video zu Zeitschätzungen warte ich schon lange! Ich wäre mehr als dankbar :)
Moin Jonas,
ok, dann packe ich das mal auf die Liste :)
Gruß David
Für eine Rollentrennung zwischen Entwickler, Anforderungsmanager, 1st, 2nd und 3rd Level Support sind wir viel zu wenig Leute mit einem viel zu breiten fachlichen Spektrum. Das machen wir alles quasi in Personalunion. Lediglich für größere Anforderungen haben wir einen Kollegen, der dies vorstrukturiert und koordiniert.
Hardware war noch nie mein Problem. Die Anwendungen laufen (und compilieren) auf dem Server. Und ich mache ja Softwareentwicklung und keinen Videoschnitt. 🙂
Was am meisten stört, sind Kollegen, die mich hartnäckig in ein Gespräch verwickeln wollen, obwohl ich signalisiere, dass es gerade nicht passt und ich mich später melde. - Nachteil der Vor-Ort-Arbeit.
Hey Ole,
ok, also die nervigen Kollegen - ich habe das Problem früher immer mit Kopfhörern gelöst. Egal wo ich bei Kunden entwickel und ob ich Musik höre oder nicht, ich habe immer Kopfhörer auf :)
Gruß David
Ist bei mir ähnlich.
Nur ein kleines Team aus Chef, Mediengestalterin und meiner Wenigkeit. Da ist man natürlich für alles was mit der Technik irgendwie zu tun hat verantwortlich. Hat seine Vor- und Nachteile. Meine Top1 ist definitiv Chef, da er fast immer mit irgendwelchen Problemen ankommt, wenn man gerade konzentriert am proggen ist. Dicht gefolgt von Telefon. Da gibt es Tage, da geht es, da nur wenige Anrufe und an anderen Tagen klingelt es quasi pausenlos. Wenn man sich dabei konzentrieren muss, ist das echt anstrengend. Hardware ist für mich egal, da ich in der Webentwucklung arbeite und somit keinen Code schreibe der kompiliert werden muss. Nicht desto trotz habe ich letztes Jahr einen neuen I5 mit SSD und 16 GB RAM bekommen.
Bis jetzt habe ich keine Performance-Probleme. Sollte das irgendwann ein Problem sein, wird der PC entweder aufgerüstet oder getauscht.
Das Problem mit den Kollegen habe ich nicht, da ich wie erwähnt neben meinem Chef nur eine Kollegin habe. Die fragt nur selten nach.
Irgendwie kenne ich einiges, aber manches ist doch schon recht lange her.
Als Bsp. die langsame Hardware. Bei uns sind seit Jahren Entwicklungs- und Testrechner virtualisiert, das hat bisweilen zwar eizelne Einschränkungen (bspw. sieht die GUI Applikation nicht alle Tastatur-Keys). Virtualisierung war aber bei Corona der Matchwinner. Dank der vSphere macht es absolut keinen Unterschied ob ich im Geschäft oder von zu Hause aus arbeite.
Bzgl. Performance, den Einzelmaschinen auf der vSphere kann man die Anzahl der Prozessoren, den Speicher- und Plattenplatz einfach zuordnen, die Entwicklungsmaschinen sind dabei eher schmalbrustig (da läuft eh nur eine Entwicklungsumgebung und es wird gemächlich editiert). Für das Übersetzen gibt es Compileserver, die das deutlich schneller durchführen, oft werden auch weitere Aktionen drangehängt (z.B. Code-Checker oder Blackbox Tests).
Bei den Testsystemen: wenn ein System in Maintenenace ist bekommt man die Maschine genannt und man kann schnell selber drauf nachschauen, bzw. man bekommt die Maschine direkt und man kann dem Fehler selber nachstellen (ohne sich eine Ersatzumgebung aufbauen zu müssen).
Bzgl. Support, da haben wir ein Skript welches automatisiert die komplette Umgebung des Kunden in ein tar File packt. Der Kunde weiß wie man dieses Skript aufruft und das File uns zur Verfügung stellt. Dazu beschreibt er noch was er gemacht hat und was seiner Meinung falsch ist. Die Fehleranalyse kann anschließend größtenteils ohne weiteren Kundenkontakt erfolgen. Und wenn wir weitere Infos brauchen (meistens Lifedaten jenseits der Logs, Corefiles, Config, etc.) dann fragen wir gezielt nach, bei manchen Kunden kommen wir sogar per Remote Access sogar direkt auf deren Maschinen.
Nun ja, und was nervt mich? Ziemlich oft Windows und Office (z.B. Requirement Dateien des Kunden).
Entwickler bekommen oft nicht mal eigene PCs sondern irgend so einen Citrix Client und das wars.
Ich finde viel Arbeitsspeicher ist bei der Hardware sehr wichtig.
Dokumentation für den Anwender schreiben.
Hi David, ich wäre dir für das angesprochene Video(-s) zur Aufwandsschätzung sehr dankbar. Da ich mir persönlich als Junior noch sehr, sehr, sehr schwer damit tue und gerne darin besser werden würde. Gerade Aufwandsschätzungen die Themen betreffen mit denen ich zuvor noch nie einen Berührungspunkt hatte sind besonders schwer. Aber auch bei Themen wo ich eig. eine Aufwandsschätzung abgeben könnte, da ich in bspw. mit dem jeweiligen Modul oder Abschnitt der Software zu tun hatte, dann fühle ich mich jedes Mal ein wenig Unwohl wenn ich meine Schätzung abgeben muss. Da das für mich dann immer so einen faden Beigeschmack hat von: "Was solange brauchst du dafür?! Ich würde nur so lange brauchen..." also das egal wie die Schätzungen nie passen.
Also ich wäre dir und auch den anderen Entwicklern hier, die schon ein wenig länger mit dabei sind, sehr dankbar dafür wenn Sie mir Ihre konkreten Tipps mitteilen könnten. Da ich wirklich, wirklich gern besser darin werden würde. Da es ja auch wie du im Video gesagt hast ein vollkommen legitimes Thema ist, von dem jenigen der ein bestimmtes Feature implementieren soll eine ungefähre zeitliche Aufwandsschätzung bekommen zu können, um die Planung besser machen zu können.
Gute Besserung, aber hoffe, du bist wieder hergestellt.
Autschn. -> Ich hoffe das ist nicht dein Auto im Hintergrund :D
Mich nerven Kollegen, die nur debuggen statt sich einmal wirklich den Code ansehen.
Denn meist ist das Ergebnis nur Spaghetti-Code.
Auf jeden Fall ein Video zur Zeitschätzung machen.
Definitiv war oder ist es das Telefon. Solche Unterbrechungen können von "bisschen stören" bis zum "riesen Problem" reichen.
(Bei 0:07 sagst Du "Ich habe mal 20 Entwickler ... angerufen" ;-) )
Dokumentieren nervt, da zähle ich auch zu den 2/3. Aber ich sehe auch die Vorteile einer guten Dokumentation. Und wenn eine Frage kommt, die durch die Dokumentation beantwortet werden kann, dann reicht oft ein "rtfm" als Antwort ;-)
Hey Carsten,
oh mein Gott, da hab ich wohl meine eigenen Tipps torpediert - ich bin eben aus dem Lachen gar nicht mehr rausgekommen, als ich Deinen Kommentar gelesen habe.... :D
Gruß David
Meetings ohne Nährwert. Meetings mit Nabelschau .
Dinge die mich nerven: Warten auf Ausführung eines Codes, Dokumentation, regelmäßige Meetings
Also der Punkt der mich am meisten nervt ist schlechte Kommunikation egal ob mündlich, schriftlich eine fehlende Dokumentation oder auch teilweise falsche Kommentare.
Dadurch verliert man immer viel Zeit.
Die Entwickler wissen also nicht welche Daten die bewältigen müssen... was machen die dann den ganzen Tag? Ich will ja gar nicht daran denken, "Wer" es denn wissen "soll", wenn es nicht mal die Entwickler wissen. 😂😂😂🤣 klar, die Putzfrau weiß es.
Kollegen die nicht fragen.
Amen 1:44
Doku, Besonders Benutzerdoku. Als Entwickler kann man die eh nicht gut aus Benutzersicht schreiben.
In altem schlechten (aber notwendigen und produktiven) Code "herumfuschen", der nur schwer zu verstehen ist und null dokumentiert ist.
Grundsätzlich zu viele Termine. Elon Musk hat mal gesagt, dass Termine schei... sind. 🤷
Weiterhin Gute Besserung David!
Gruß Les. 😉
Hey Leschek,
ich habe nur in Scrum-Teams gefrage (fällt mir grade auf), deshalb ist der Punkt total untergegangen, aber hast recht - das kann echt nerven!
Gruß David
Mich nervt scrum und die damit verbundenen Termine.
Lieber Dokumentieren als Support 😉
mich nervt es wenn mich der chef zwingt, mit diesem kackscheiss mikroschrott windoof zu arbeiten. ich will als betriebssystem linux und sonst nix.
und frameworks gehen mir auch schon immer mechtig aufn keks.
fazit: selbstendig machen.
wenn mir der scheff eine depperte tastatur mit furs programmieren total unpraktische german layout hinstellt, dann kauf ich mir einfach SELBER eine mit dem furs programmieren und computerarbeiten einzig wahren praktischen US-layout. und alle scheiss storenden tasten werden einfach rausgeschmissen ausgebaut: nervige tab-taste, menu und windowslogo tasten.
und eine firma die den leuten nicht mehr als 2 Monitore gibt, is ein reiner gratlerladen. man braucht 3 monitore. und auch maus ohne back-button is einfach eine realitetsferne frechheit.
Entwickler bekommen oft nicht mal eigene PCs sondern irgend so einen Citrix Client und das wars.