Menschen kommen, scheitern und gehen. Der nächste wird besser sein. Es ist eine endlose Suche nach dem einen der diesen ewigen Kreislauf durchbricht. Wobei Suche der falsche Begriff ist. Es ist mehr ein warten. Ein passives Warten. Aber ganz sicher kommt irgendwann der eine oder die eine, die alles mitbringt was man haben will. Jemand der nicht auf die Hilfe der anderen angewiesen ist, die keine Zeit für sowas haben und somit das Scheitern für die meisten schon vorprogrammiert ist. Nein! Ein Mensch wird kommen und genau die Person sein, die man schon immer haben wollte.
Die anderen, die durch die Rotation gegangen sind, ziehen weiter. Zur nächsten Firma und durch den nächsten Rotationszyklus bis auch die Firma sie wieder ausspuckt. Diese Menschen sind das Rauschen, dass die gesuchten verdeckt, ihre Aufgabe ist es ausgesiebt zu werden oder bis sie sich ändern. Aber wenn sie sich ändern könnten, wären sie nicht da wo sie sind. Nicht gefangen in einen immer wieder kehrenden Zyklus von Kommen, Scheitern und Gehen gefangen.
Und somit.. mal gucken ob der nächste Projektmanager, die nächste Projektmanagerin ein weiter Zyklus in der Rotation ist oder diese Rotation durchbrechen kann.
Natürlich könnte man mehr Zeit in Auswahl, Förderung und Aufbau eigener Leute stecken.. aber das bezahlt einen eben niemand.
Auch wenn ich vieles was John Sonmez so sagt, sehr kritisch sehe (Burnout gibt es nicht, man hat nur nicht genug Disziplin.. oder um mehr Zeit zu haben sollte man einfach weniger schlafen) muss ich sagen, dass ich gerade in seinen Artikel von so vor 3 - 2 Jahren sehr viel gelernt und verstanden habe. Es war gerade eine Zeit bei mir wo ich sehr motiviert und auch engagiert an einen Projekt gearbeitet habe. Zuvor war ich Teil von einem doch relativ großen Team, wo alle Probleme und Fehler, die bei großen Teams vorkommen, gerade durch exerziert wurden. Mit einem kleineren und sich damit schneller entwickelten Projekt war ich sehr zufrieden und versucht meine Vorstellung von Vereinfachung und beschleunigter Entwicklung da einfließen zu lassen. Leider scheiterten viele dieser Bemühungen an der Skepsis vor neuen Technologien und der Situation, dass man nicht wirklich Zeitdruck hatte und das sparen von Zeit deswegen nicht wirklich ein Argument war.
Zur selben Zeit versuchte ich die gelernten Lektionen und meine Ideen, die ich dort nicht umsetzen konnte, privat in Text und manchmal auch Code zu konservieren, damit man in späteren Zeiten doch mal darauf zugreifen konnten. Außerdem war damit auch die Hoffnung verbunden von anderen Entwicklern und Firmen beachtet zu werden und irgendwie auch Bestätigung zu bekommen. Der Simple Programmer Blog traf zu der Zeit also bei mir einen Hauptnerv. Einmal wurde dort mein Verständnis davon bestätigt, dass die einfachste (also unkomplexeste Lösung, "Don't be smart!") meist auch die beste Lösung sei und auch wurde dort das Gefühl fest zu stecken und sich nicht mehr weiterentwickeln zu können oft thematisiert.
Dem ersten Tip hatte von mir aus schon umgesetzt und vielen Verbesserungen unterzogen: Schreib einen Blog. Das machte ich und hatte auch einen relativ hohen Output, weil ich vieles aus meinem Job dort verarbeiten konnte. Zusätzlich faste ich auch einfach oft, dass zusammen was ich neben lernte. Anleitung zum Aufsetzen waren auch mehr Merkzettel für mich, weil man dann nicht jedes mal neu überlegen, ob ich alles gemacht und nichts vergessen habe. Aber wohl die größte Inspiration war das Gespräch mit Kollegen. Jeder hat seine Ansichten und Meinungen. Wirklich falsch ist etwas davon nie nur immer aus verschiedenen Sichtweisen. Selbst die Sichtweisen, die Neuerungen und so schwer gemacht haben, waren ja nicht an sich falsch.
Ich fing also auch vermehrt an an privaten Projekten zu arbeiten. Das hatte ich schon vorher getan und mein PHP-Framework hatte auch zu der Zeit schon ein paar Jahre produktiven Einsatz hinter mir. Aber ich lernte von John Sonmez eine ganz wichtige Lektion, die mich wirklich weiter gebracht hat. Wenn man etwas anfängt, muss man es auch zu Ende bringen. Angefangen hatte ich viel, aber an sich ist da alles irgendwann im Sande verlaufen und ich hatte Glück, wenn etwas Prototyp-Status erreichte. Meistens war es dass eine andere Technologie dann wieder spannender war und man die andere Technologie ja irgendwie gemeistert hatte.. das Programm lief ja.. dann wäre so was wie der Go-Live gekommen und man hätte es der Öffentlichkeit präsentieren müssen. Werbung, Support, Pflege.. Kunden.. also der ganze unspannende und nervige Kram. Aber es gehört nun mal dazu und ein Projekt technologisch umzusetzen ist, dass was an sich jeder Entwickler mehr oder weniger gut am Ende hinbekommt. Abhängig davon welche Umgebungsfaktoren und Anforderungen einen so Steine in den Weg legen. Dann genau dieser letzte Teil vom Projekt, ist der der einen weiter bringt und einem Sichtbarkeit verschafft. Projekt, das zwar läuft aber nicht veröffentlicht wurde, ist nicht mehr als Beispiel für Lernzwecke, aber nie am Ende etwas richtiges.
Zu der Zeit entstand neben ein paar kleinen Firefox-OS Apps und mp4togif.com. Genau diese Softskills waren es dann auch, die mich weiterbrachten. Denn ein Projekt selbst durch zuführen ist was ganz anderes als nur Entwickler in einem Projekt zu sein. Man lernt zu Kommunizieren und irgendwie auch etwas zu Manipulieren. Umschiffe Hindernisse mit der richtigen Sprache und in dem man die richtigen Leute anspricht. Dafür muss man proaktiv nach vorne gehen. Du musst die Probleme lösen, die anderen können besten Falls unterstützen oder Hilfen geben. Und wenn man die richtigen Leute um Hilfe fragt, werden sie sich auch an dich erinnern und das nicht negativ.
Also.. Softskills. Lerne Menschen kennen bzw lass anderen Menschen dich kennen lernen. Frage um Hilfe, wenn du sie brauchst und zeige Dankbarkeit für die Hilfe. Auch sollte man genauso seine Hilfe anbieten.
Denn dass ist etwas, was ich zwar wusste, aber erst eimal bewusst forcieren musste. Sei die Person die man um Hilfe fragt. Lerne zu helfen und dein Wissen verständlich und sicher mitzuteilen. Man muss nicht alles wissen, aber man sollte seine Bereiche haben, wo man sich sicher auskennt und dieses auch offensiv nutzen. Wenn jemand ein Problem hat, soll er zu dir kommen. An sich ist das nichts anderes als Kundengenerierung. Man muss sich in eine Position bringen, wo man anderen die Hilfe nicht mehr anbieten muss sondern wo man um Hilfe gefragt wird.
Wichtig hierbei zu beachten ist natürlich: Wer Programmieren liebt und nicht seine Zeit in Meetings verbringen möchte, wo man auch mal deine Meinung zu einen Thema gerne hören würde... dann sollte man es nicht machen. Ich helfe gerne, lerne gerne die Probleme und Lösungsansätze anderer kennen und entwickle gerne Lösungen. Programmieren ist dann nur noch ein letzter Schritt zur Realisierung.
Auch wenn es immer versucht wird zu verhindern, dass sich Wissen in einer Person konzentriert (die Person ohne die bei einem Programm nichts gefixt werden kann, wenn die Person nicht da ist..), sei diese Person, aber sei auch ein Multiplikator, auch erstmal aktiv. Sag in Meetings, dass du eine ähnliche Lösung schon mal gesehen hast und eine Email schreiben wirst oder gib Tipps wo schon mal so etwas gemacht wurde. Das man dann noch mal auf dich zukommt, wenn noch Fragen sind, ist gut, weil dann dein Tipp zumeist gut und hilfreich war.
Man muss dieses Networking und die "richtigen" Menschen kennen nicht so extrem sehen wie John Sonmez und Menschen nur nach Nutzen beurteilen. Aber einige Leute zu erinnern, dass man noch existiert, kann nie schaden. Falls doch mal Hilfe braucht oder sogar man mal auf der Suche nach einem neuen Job ist (Freelancing oder fest angestellt.. egal) kann es hilfreich sein. Würde ein ehemaliger Arbeitgeber merken, dass es doch jetzt Zeit für einen B2B-Webshop wäre und man eine Anbindung (automatisierter Artikel und Bestellungen Abgleich) an ein ERP braucht.. SAP oder.. an sich egal.. würde ich natürlich gerne unterstützen und helfen. Erstens würde es mich darin bestätigen, dass mein Konzentrieren auf diesen Bereich richtig war, dass das was in meine Blog steht mein Fachwissen und Kompetenz gut transportiert hat und ich als Mensch nicht so war, dass man mit mir nicht zusammen arbeiten wollen würde. Wobei ich dann doch so bin, dass mich der letzte Punkt am meistens treffen würde, denn es gibt nur einen mit dem ich nie wieder zusammen arbeiten würde, weil es leider zu unschön aus einander ging und es wohl nie harmonieren würde bei einem erneuten Versuch der Zusammenarbeit.
Denn das habe ich auch von Simple Programmer gelernt. Wenn es nicht geht geh... egal ob man dir bei neuen Bewerbungsgesprächen dumme Fragen stellen könnte. UND die Probezeit ist für beide Seiten da! Auch der Arbeitgeber darf gehen, wenn es nicht passt.
Es gab natürlich auch Tipps, die mir nichts gebracht haben. Z. B. die Promodoro-Technik. Ich kann es nicht. Meine Arbeitsweise passt nicht zu den Zyklen.
Klar mache ich auch kurze oder etwas längere Pausen, um zwischen Workloads den Kopf wieder frei zu bekommen. Aber wenn ich einen Lauf habe will ich nicht unterbrochen werden und ich kann meine Aufgaben immer in 15min Workloads aufteilen. Gerade beim Debuggen an einer Stelle, wo man sich erst einmal hinarbeiten muss, kostet eine Unterbrechung nur unnötig viel Zeit und nervt mehr als zu nutzen.
Treibe Sport! ... jaaaaa... wenn ich wieder Zeit dafür habe... also.. nächstes Jahr? Bzw eines der nächsten Jahre.... TBA.. ja.. TBA.
Aber Ernährung war dann doch wieder besser und kann ich unterstützen. Es bedarf Überzeugung und Motivation, sich Abends was vorzubereiten oder morgens doch noch mal Brote zu schmieren. Ich mag Pizza und Burger und man findet immer jemanden der in der Mittagspause mitbestellen würde. Und selbst den Gang zum Bäcker kann man sich gut reden. Aber am Ende fühlt man sich mit eigenen gesunden (oder nicht ganz ungesunden Essen) leistungsfähiger und fit. Ich trinke auch zu viel Mate und zu wenig Wasser bei der Arbeit. ABER jedes mal wen nicht ein paar Tage doch etwas besser mache, bin ich stolz auch mich und in den letzten Monaten klappt es auch immer ein Stückchen besser: Gesundes Essen am Abend, Smoothis, oder einfach mal ein selbst geschmiertes Brot. Man merkt den Unterschied zu einer fettigen Pizza.
Also.. ich habe von John Sonmez viel gelernt oder wenigsten Hilfe dabei gehabt Sachen deutlicher zu sehen. Die Beiträge von den anderen Autoren haben mich nie wirklich begeistern können. Deswegen ist sein Weggang für mich auch mit das Ende von Simple Programmer für mich. Wirklich Schade, aber was zu sagen war, hat er gesagt und geht nicht verloren.
Außerdem war er neben Kassenzone.de der einzige mir gekannte Blog, der Transkripte der Vlogs und Podcasts hatte. Ich überfliege lieber schnell die Texte zum Filtern nach interessanten Themen als durch ein Video oder Podcast zu spülen und mit etwas Glück die richtige Stelle zu erwischen.
Ich bin bei diesen Artikel bei Heise mal wieder auf das Werben der Arbeitgeber mit Team-Events gestoßen. Dieser Kommentare zeigt aber auch, dass nicht nur ich diese Events auch skeptisch sehe.
Wahrscheinlich will die Masse der Arbeitnehmer einfach irgendwann nach Hause gehen um Zeit mit Freunden und Familie verbringen bzw. Hobbies nachgehen.
Wenn ich ein Job-Angebot mit "regelmäßigen Team-Events" sehe, bin ich eher geneigt, dieses Angebot erst gar nicht in Betracht zu ziehen. Nicht dass ich was gegen die anderen Team-Mitglieder hätte, werden schon nette Leute sein. Nur das Wort "regelmäßig" impliziert für mich, dass auch ein "regelmäßiges" Erscheinen vom Arbeitgeber erwünscht wird.
Wenn man Frau, Haus, Freunde, Familie, Privatleben, etc hat, ist es aber schon so schwer, alles in der Woche unterzubringen, was man erledigen muss. Einkaufen, Putzen, etc und am Ende soll man sich ja auch noch entspannen und für spontane Nachfragen oder Kontrollen von Änderungen von zu Hause soll man ja auch noch zur Verfügung stehen.
Wenn man Single ist und seine Wohnung nur als Ort sieht, den man zum Schlafen aufsucht und sonst seinen Lebensmittelpunkt bei der Arbeit sieht, mögen diese Events schön und toll sein. Für die meisten werden sie aber eher Zeit belegen, die man für andere Dinge gebraucht hätte.
Auf den jährlichen Weihnachtsmarktbesuch mit dem Team würde ich nicht verzichten wollen. So etwas im monatlichen Rhythmus würde ich auch ok finden, wobei ich aber eine Anwesenheitsrate von 50% schätzen würde, die ich realistisch einhalten könnte.
"Du kannst fast immer pünktlich gehen" wäre also für mich viel mehr ein Anreiz als Team-Events. Weil was bringt es mir pünktlich Feierabend zu machen und dann 4h bei einem Team-Event zu verbringen.
Das bei Webentwicklern PHP meistens hinter Java kommt ist bei dieser Statistik wieder eine andere Geschichte...
Manchmal möchte man einfach einen kleinen Thread laufen lassen, der eine kleine Aufgabe erledigt wie z.B. ein Verzeichnis überwachen oder auf SMS-Eingänge horcht. Normal würde man so einen einfach über die CLI starten und laufen lassen. Im WildFly ist es kaum anders nur dass man die CLI-Argumente aus einer Config-Datei lesen muss.
Wenn man die Überschrift liest, klingt es erst einmal seltsam, da man das Programme und Anwendungen ja schon kennt. Das Problem bei komplexen Anwendungen, die in Projekten und der alltäglichen Arbeit verwendet werden, um alles zu managen, dass nicht die eine Art gibt, wie man die verwendet.
Gerade bei sehr kleinen Teams von 2-3 Personen, die eine solche Anwendung einführen und benutzen, entstehen schnell Strukturen und Abläufe, die sich stark an der Arbeitweise und dem Projekt orientieren. Wenn man nun als neue Person hinzukommt und es bekannt ist, dass man mit einer Anwendung schon gearbeitet hat, ist das Erstaunen oft groß, dass man nicht gleich zu 100% in dem System steckt und auch mal nachfragen muss, wie etwas gehandhabt wird.
Ob es nun das behanedeln voon Tickets in Youtrack oder JIRA ist oder auch das Management von Branches in GIT. Es gibt nicht die eine Art und gerade in kleinen Teams, wo es keine Schnittstellen zu anderen Teams und Einblicke in deren Arbeitweisen gibt, entwickelt sich irgendwie ganz schnell die Ansicht, dass man die richtige Arbeitweise erkannt hätte und alle anderne die produkttiv mit der Anwendung arbeiten, zur gleichen Arbeitsweisse gekommen sein müssen.
Deswegen muss man sich immer im klaren sein dass sich das Einarbeiten nie nur auf die grundlegende Bedienung von Anwendungen und dem Kennenlernen von Code beschränkt, sondern viel mehr das Verstehen der Strukuren, Workflows und Ansichten bzw Dennkweisen der Teams bezieht. Wenn man plötzlich mit einer anderen Programmiersprache arbeiten soll ist auch der Syntax das gerinigste Problem und wenn man deren Konzepte verstanden hat, kommt der Syntax fast von allein hinterher.
Man darf also nicht erwarten, dass bloss weil jemand mit einer Anwendung gearbeitet hat, auch genauso damit gearbeitet hat wie man selbst. Das bietet natürlich auch die Gelegenheit mal über den Tellerrand zu gucken und seine eigenen Abläufe noch mal neu zu überdenken und zu optimieren.
Es ist zwar schon etwas her, dass ich diesen Artikel gelesen habe, aber irgendwie lies mir das Thema bis jetzt keine Ruhe. Am Anfang dachte ich mir: "Klar, wenn eine Firma einen verbietet etwas neues zu lernen ist sie eine schlechte Firma." Denn jeder Arbeitgeber will, dass man viel kann und immer auf dem neusten Stand ist, deswegen sollte er einen auch dabei unterstützen dieses Ziel zu erreichen.
Ich habe in einer Firma gearbeitet, da war so etwas kein Problem. Es konnte sein dass plötzlich das Thema auf eine neue Technologie oder eine Alternative zum momentan benutzen kam und der Teamleiter oder Chef einem Anwesenden den Auftrag erteilte sich mal damit zu beschäftigen. Das ist super und ermöglicht einen auch mal einen Blick über den Tellerrand. Ohne so etwas hätte ich mir nie JBoss Seam angesehen oder verschiedene Application-Server. Meistens ist man bei dem geblieben was man hatte. Aber wenn man der Meinung war man hätte etwas, was einen voran bringt oder viel Zeitsparen könnte oder
einfach ein Hype darum gerade zu merken war und man wissen wollte, ob es wirklich so toll sei.... alles kein Problem sich mal 1-2 Stunden dafür Zeit zu nehmen.
Wenn man interne Software entwickelt oder diese verkauft ist das auch möglich. Wenn man für Kunden entwickelt ist oft die Lösung das zunehmen was man hat und kennt. Die Zeit in der man nicht für Kunden arbeitet bringt aber auch kein Geld, deswegen ist diese Zeit möglichst gering zu halten. In den seltensten Fällen wird ein Kunde einem auch die Zeit für die Forschung bezahlen wollen.
Trotzdem würde ich immer dafür sein, jedem Mitarbeiter pro Woche 1-3 Stunden Zeit einzuräumen, wenn nicht extremer Zeitdruck vorliegt, in denen er sich weiterbilden kann. Natürlich sollte dabei im Auge behalten werden, was der Firma auch was bringt. Eine neue Programmiersprache? Wenn man mit Java entwickelt und jemand möchte sich Scala ansehen.. klar. Jemand will Rust oder Swift angucken.. da muss man schon gucken, ob man wirklich Vorteile drauf ziehen kann.
Es geht auch selten um konkrete Sprachen oder Frameworks, die man dann auch einsetzen wird, aber es ist immer gut neue Konzepte kennen zu lernen.
Sollte es aber so sein, dass man bei der Arbeit ein neues Framework verwenden soll und dann so etwas wie "Guck dir das mal zu Hause ausführlich an" dann ist hier klar zu sagen: Was man für die Arbeit lernen muss ist genauso Arbeit wie das Programmieren und Entwickeln selbst und muss natürlich einem genauso angerechnet werden.
Aber bis jetzt habe ich so etwas noch nie erlebt.. nur mal davon gelesen oder mir etwas angesehen, wo ich selbst großes Interesse dran hatte und dann auch gleich ein kleines Projekt hatte, wo ich auch nicht wollte, dass es etwas mit meinem Arbeitgeber zu tun hat.
Fazit:
Sollte ich mal Teamleiter oder Chef sein, würde ich jedem nicht nur diese Stunden pro Woche gönnen, sondern es fast schon verlangen, das sich der Mitarbeiter weiter bildet und lernt. Lernen hält das Gehirn fit!
Blog-entries by search-pattern/Tags:
Möchtest Du AdSense-Werbung erlauben und mir damit helfen die laufenden Kosten des Blogs tragen zu können?
bezahlt von 
Blog: Blog-entries by search-pattern/Tags: