Hoe om te gaan met verschil van inzicht op het werk?

[HollowGamer]

..

[ Voor 99% gewijzigd door HollowGamer op 03-12-2020 12:44 ]

[Invisible_man]

Zeer herkenbaar, z'n collega heb ik ook.

Aan het eind van de dag gaan mensen niet snel veranderen omdat jij het wilt en is het óf een kwestie van het afdelingshoofd te overtuigen van wat jij wil en die het laten opleggen (wat de verhoudingen onderling vaak niet ten goede komt), óf je er bij neer te leggen of natuurlijk ander werk zoeken (wat je niet wilt). Je ziet dit vaak tussen jongere mensen die veel bezig zijn met nieuwe technieken te ontdekken en dat graag willen toepassen en oudere mensen die de huidige manier van werken prima vinden. De waarheid ligt vaak ergens in het midden.

[asfaloth_arwen]

Ik begrijp je frustratie, maar probeer die om te zetten in iets bruikbaars. Legacy code of iets zelf ontwikkelen is ansich niet het probleem, maar een symptoon. Probeer het te schetsen vanuit het standpunt van een klant, of je leidinggevende:
- Klant krijgt bij nieuwe versies regelmatig te maken met bugs, wat productiviteit/geld (maak een voorbeeld business case) kost en afbreuk doet aan het vertrouwen in ons product. Hoe kunnen we dit in de toekomst voorkomen? Denk hierbij aan meer automatisch testen, code reviews & verbeteren van CI/CD proces.
- Kennis zit in de hoofden van de huidige ontwikkelaars, instappen voor nieuwe ontwikkelaars is lastig. Dit is een continuiteits risico. Hoe kunnen we dit verbeteren? Denk aan code reviews, automatisch testen etc.
- Functionaliteit bouwen die als open source reeds beschikbaar is? Onder welke licentie? Voldoet dit volledig of moet dit nog aangepast worden? Hoe kan dit geintegreerd worden? Vaak hebben ontwikkelaars ook last van het 'not invented here' syndroom en is dit een prima optie.

[ Voor 15% gewijzigd door asfaloth_arwen op 12-11-2020 11:32 ]

[freggel]

Hmm, balen man.

Heb je geen medestanders op het werk, die je gedachtengoed delen? Het lastige is dat als je de enige bent met deze werkethiek, dat het dan heel moeilijk is (lijkt mij) om er lol in te houden. Zeker als je geen leidinggevende bent.

Het eerste wat in mij opkomt is, zoek een werkgever die aansluit bij jouw werkethiek. Het tweede, zoek medestanders die je gedachtengoed delen en probeer daarmee het een andere kant op te sturen.

Ik zou er wel rekening mee houden dat het een strijd van de lange adem is, dit soort veranderingen kosten in mijn ervaring heel veel tijd..

[_JGC_]

Ik ken je frustratie, en heb er zelf ook wel mee te maken. Ik zit inmiddels 10 jaar op een project van een klant dat stikt van de legacy code. Destijds kneutercode in ASP die opnieuw is gemaakt in PHP, met dezelfde procedures. Klant vraagt, wij draaien en de code wordt uitgebreid tot het een grote pan met kleverige spaghetti is.
Vervolgens komt er een nieuwe medewerker die helemaal gek wordt, want de code is niet meer te doorgronden. Ik ben dat met hem eens en wil ook wel dingen veranderen, maar het vreet tijd om dat te doen en de klant gaat dat niet betalen of heeft hem recht in het gezicht gezegd dat ie maar van het project af gezet moet worden zodat ik een pragmatische oplossing kan bedenken (lees: weer een k*t hack erbij).

De kuil wordt gewoon steeds dieper, op een gegeven moment kom je er niet meer uit en is het niet refactoring meer, maar gewoon helemaal opnieuw beginnen.

[bregweb]

Gooi het in de groep, bespreek het? Misschien eerst uitproberen bij een collega waarvan je denkt dat je die mee kunt krijgen.

Als jouw ideeën echt zo goed zijn, probeer dan de argumenten om je collega's/werkgever te overtuigen op papier uit te werken (werkt bij mij beter dan in mijn hoofd).

Andere werkgever zoeken kan later ook nog wel.

[FreezeXJ]

Bekend probleem, brakke code werkt gewoon goed, het is alleen een hel om te onderhouden. Dat zien managers, en soms collegas, gewoon niet, dus blijven ze ermee zitten want het is wel sneller gebouwd.

Helaas is er ook weinig aan te doen als ze niet eerst keihard onderuit gaan erop (lees: een project moet echt officieel kapot zijn, en niet te fiksen binnen een dagje, en daarna moet iemand met authoriteit zeggen dat de code-kwaliteit echt slecht is) voordat sommigen leren. En zelfs dan...

@_JGC_ Het ergste is nog dat ze straks naar jou gaan wijzen omdat jij die brakke oplossing pushed, en je eerder tegengas had moeten geven (ondanks dat het zinloos is) en jullie het maar even snel moeten oplossen.

[Gethijsem]

Ongeveer wat ik ervaren heb. Bij mij was de uitkomst simpel, het kwam er uiteindelijk op neer dat ik geen klik meer had met de rest van de groep, geen motivatie en snelheid meer had, en vermoedelijk om die reden geen nieuw contract kreeg.

Maak een plan, plan een vergadering in en bespreek het met je collegas. Als je er niet uitkomt, zoek een andere werkgever waar wel professionals werken en waar je wel gehoord wordt. Doe dat wel vanuit je huidige baan, dat solliciteert veel makkelijker.

[Yucon]

Lastig punt. Het is wel belangrijk in je achterhoofd te houden dat perfectie niet haalbaar maar ook niet nodig is. Dit wat betreft een aantal opmerkingen over technical debt hierboven. Dan blijft de vraag over: zijn de problemen hanteerbaar? Is jouw oplossing iets beter, of echt veel beter?

Oh ja, een verhaal over open source is best lastig te verkopen richting management. Maar 'jantje is al 2 maanden iets aan het bouwen dat je gratis kunt downloaden' is een stuk hanteerbaarder.

[ Voor 25% gewijzigd door Yucon op 12-11-2020 11:49 ]

[_JGC_]

@FreezeXJ Die klant is daar niet heel moeilijk in... probleem is dat bugs uitzoeken ook tijd vreet, ik bouw liever wat nieuws dan dat ik bugs zit uit te zoeken.

[Anoniem: 1302638]

Dit wordt een gevecht van de lange adem. Om te beginnen. Kan je de improvements die je voor wilt stellen tijdens een teamoverleg, een call of een ander moment formeel voorstellen?

Als je tijdens zo'n meeting heel veel tegengas krijgt schrijf je alle punten op. Een dag later, heb je een weerwoord of een onderzoekspunt. Je hoeft het niet meteen op te geven.

Stap voor stap kan je bezwaren afpellen. Als er "onderzoek" (lees uitstel) nodig is, voer dit dan ook uit. Is zoiets afhankelijk van het hele team of een grote stap, dan zul je tijd moeten vragen om dat uit te voeren. Mag je X uur claimen om een teststraat in te richten? Laat je dan ook niet afleiden door 'ja maar nu is het anders'. Terug naar de oorspronkelijke vraag / onderzoek: is het gelukt of niet? Het hoeft niet meteen perfect.

Kijk ook of je kan kwantificeren hoeveel tijd het zou kunnen schelen. Per handeling, per mdw, per dag?

[HollowGamer]

freggel schreef op donderdag 12 november 2020 @ 11:36:
Hmm, balen man.

Heb je geen medestanders op het werk, die je gedachtengoed delen? Het lastige is dat als je de enige bent met deze werkethiek, dat het dan heel moeilijk is (lijkt mij) om er lol in te houden. Zeker als je geen leidinggevende bent.

Het eerste wat in mij opkomt is, zoek een werkgever die aansluit bij jouw werkethiek. Het tweede, zoek medestanders die je gedachtengoed delen en probeer daarmee het een andere kant op te sturen.

Ik zou er wel rekening mee houden dat het een strijd van de lange adem is, dit soort veranderingen kosten in mijn ervaring heel veel tijd..

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

bregweb schreef op donderdag 12 november 2020 @ 11:40:
Gooi het in de groep, bespreek het? Misschien eerst uitproberen bij een collega waarvan je denkt dat je die mee kunt krijgen.

Als jouw ideeën echt zo goed zijn, probeer dan de argumenten om je collega's/werkgever te overtuigen op papier uit te werken (werkt bij mij beter dan in mijn hoofd).

Andere werkgever zoeken kan later ook nog wel.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

FreezeXJ schreef op donderdag 12 november 2020 @ 11:42:
Bekend probleem, brakke code werkt gewoon goed, het is alleen een hel om te onderhouden. Dat zien managers, en soms collegas, gewoon niet, dus blijven ze ermee zitten want het is wel sneller gebouwd.

Helaas is er ook weinig aan te doen als ze niet eerst keihard onderuit gaan erop (lees: een project moet echt officieel kapot zijn, en niet te fiksen binnen een dagje, en daarna moet iemand met authoriteit zeggen dat de code-kwaliteit echt slecht is) voordat sommigen leren. En zelfs dan...

@_JGC_ Het ergste is nog dat ze straks naar jou gaan wijzen omdat jij die brakke oplossing pushed, en je eerder tegengas had moeten geven (ondanks dat het zinloos is) en jullie het maar even snel moeten oplossen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Yucon schreef op donderdag 12 november 2020 @ 11:48:
Lastig punt. Het is wel belangrijk in je achterhoofd te houden dat perfectie niet haalbaar maar ook niet nodig is. Dit wat betreft een aantal opmerkingen over technical debt hierboven. Dan blijft de vraag over: zijn de problemen hanteerbaar? Is jouw oplossing iets beter, of echt veel beter?

Oh ja, een verhaal over open source is best lastig te verkopen richting management. Maar 'jantje is al 2 maanden iets aan het bouwen dat je gratis kunt downloaden' is een stuk hanteerbaarder.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 55% gewijzigd door HollowGamer op 12-11-2020 14:21 ]

[freggel]

Nou, je zou nog eens kunnen kijken of je een MT lid mee kan krijgen. Ik denk als je het verhaal open en zo neutraal mogelijk (zonder gelijk met vingertjes te wijzen) kan overbrengen, dat je dan iig een ingang zou moeten kunnen creëren.

En wat @Anoniem: 1302638 zegt. :-)

[JohnR]

Als je je er niet lekker bij voelt, dan zou ik gewoon lekker doorhoppen. Na ongeveer 10 werkgevers kom je er dan vanzelf wel achter dat het ultieme team dat alles goed doet niet bestaat

[Panzer_V]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Greencap]

Ik denk dat je dit eigenlijk bij elk commercieel bedrijf wel gaat tegen komen. Er is simpel weg niet (altijd) tijd om het juist te doen en bovendien worden er veel fouten gemaakt. Als je puur bedrijfsmatig gaat terugkijken bij elke beslissing om iets niet te refactoren, dan zul je zien dat in veel gevallen dat toch de juiste beslissing was. Je kijkt naar de zooi zoals die er nu is, maar niet naar de honderden/duizenden beslissingen die tot die zooi geleid hebben.

De truc is om die schade te herstellen voordat het (praktisch gezien) onherstelbaar wordt. Dit is waar er wel veel onderscheid is tussen bedrijven. Je hebt bedrijven die dit snappen en goed onder controle hebben en de bedrijven waar het echt altijd alleen maar erger wordt.

Dan zit je echter nog in een spagaat, want bij kleine bedrijven is de wil er wel, maar is er vaak geen tijd/geld om hier serieus aandacht aan te besteden (en krijg je als junior vaak ook niet voldoende begeleiding). Bij grote bedrijven moet je vaak eerst je strepen verdienen voordat de gevestigde orde en managers naar je zullen luisteren. In de praktijk is dit dus echt iets waar je (tot op zekere hoogte) mee overweg moet kunnen.

Zie het overigens ook als een kans voor je eigen ontwikkeling. Vaak hebben de oudgedienden toch wel goede argumenten (al is het onbewust) om iets in stand te houden. Probeer daar ook open voor te staan en daar van te leren, al is het zodat je zelf niet dezelfde fout maakt in de toekomst. Bovendien zul je zien dat als je er van die hoek naar gaat kijken er ook veel eerder naar je geluisterd wordt, waardoor je gemakkelijker je afwijkende ideeen kan introduceren.

[Sander B]

Tsja, om even advocaat van de duivel te spelen: niemand houdt van iemand die nieuw binnenkomt en met een stevige lijst aan komt zetten van wat hij vindt dat er allemaal niet goed gaat, oftewel dingen die jij volgens hem al jaren verkeerd aan het doen bent. Dan maakt het niet uit hoeveel gelijk je er ook in hebt, je collega's zullen het allemaal niet zo overnemen omdat dat hun er slecht uit laat zien.

Je hebt aangegeven dat je een hoop ruimte voor verbetering ziet, en het klinkt alsof je al een hele serie voorstellen hebt aangedragen. Dat kan op je collega's niet fijn overkomen. Ik zou je aanraden om op 1 ding tegelijk te focussen. Begin het liefst met iets waar je collega's niet teveel last van hebben. En probeer dat vooral niet te doen op een "nu is het verkeerd" manier, maar op een "zo kan het nog beter/makkelijker/efficienter" manier.

Verder ben ik het eens met @Greencap, het komt best voor dat er rare dingen in code voorkomen waar een prima argument voor was. Soms werkte iets op de logische/correcte manier niet bij een klant, vaak moest er snel een patch komen en wil er nu niemand meer aankomen omdat het nu wel werkt, en vaak wordt code met voortschrijdend inzicht ontworpen en geschreven.

[Jeroenneman]

JohnR schreef op donderdag 12 november 2020 @ 14:57:
Als je je er niet lekker bij voelt, dan zou ik gewoon lekker doorhoppen. Na ongeveer 10 werkgevers kom je er dan vanzelf wel achter dat het ultieme team dat alles goed doet niet bestaat

Of je moet zelf teamleider worden, en men de code gewoon laten herschrijven als er tegen de afspraken in is gewerkt met tabs ipv spaties. Maar dan heb je mensen ook snel tegen je

[HollowGamer]

JohnR schreef op donderdag 12 november 2020 @ 14:57:
Als je je er niet lekker bij voelt, dan zou ik gewoon lekker doorhoppen. Na ongeveer 10 werkgevers kom je er dan vanzelf wel achter dat het ultieme team dat alles goed doet niet bestaat

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Hydra]

Klinkt mij alsof je het bedrijf en de cultuur daarbinnen gewoon ontgroeid bent. Dit ga je niet in je eentje oplossen vrees is, en als je door wil groeien is eigenlijk de enige oplossing op zoek gaan naar een ander bedrijf.

Dit zie je bij wel meer bedrijven; de mensen die 'verder' zijn raken op den duur gefrustreerd en vertrekken. De mensen die geen nieuwe dingen willen leren blijven hangen. En zullen wat ze doen met hand en tand verdedigen, want no way dat een 'nieuwe' het beter weet natuurlijk.

Heb zelf ooit kort bij een bedrijf gewerkt waar ik geprobeerd heb mensen in te laten zien dat testen echt wel een belangrijk onderdeel was. Maar daar was in je eentje niet aan te beginnen als de rest van het bedrijf er niet aan wil.

[ Voor 19% gewijzigd door Hydra op 12-11-2020 20:10 ]

[Hydra]

Jeroenneman schreef op donderdag 12 november 2020 @ 15:28:
Of je moet zelf teamleider worden, en men de code gewoon laten herschrijven als er tegen de afspraken in is gewerkt met tabs ipv spaties. Maar dan heb je mensen ook snel tegen je

Dat is sowieso niet hoe een lead rol werkt. Als je het op die manier aan moet pakken, dan heb je al gefaald.

Dit soort gevallen los je op door gezamelijke afspraken te maken, een gedeelde editor config te gebruiken, en linters in te zetten in je automatische build.

[Furion2000]

Word je al gezien als diegene die een kei is met open-source oplossingen? Heb je al iets bewezen hierin?

Goed voorbeeld doet goed volgen vind ik een mooi gezegde en moest even zoeken, maar moest ook denken aan iets wat ik pas geleden las;

"Moral excellence comes about as a result of habit, We become just by doing just acts, temperate by doing temperate acts, brave by doing brave acts" Aristotle

Ik ben van mening dat je mensen niet overtuigd met discussies, althans niet gemakkelijk, dit kost rete veel energie en vaak elke keer weer. Mensen overtuig je door het goede voorbeeld te geven en te zijn. Bijkomend voordeel is dat je ondertussen zelf ook steeds beter word.

Dus ga aan de slag met open-source, laat je progressie en voordelen constant merken en je voorbeelden zullen steeds beter worden en dus word je steeds overtuigender naar de andere toe.

[ Voor 3% gewijzigd door Furion2000 op 12-11-2020 21:04 ]

[Jeroenneman]

Hydra schreef op donderdag 12 november 2020 @ 20:12:
[...]


Dat is sowieso niet hoe een lead rol werkt. Als je het op die manier aan moet pakken, dan heb je al gefaald.

Dit soort gevallen los je op door gezamelijke afspraken te maken, een gedeelde editor config te gebruiken, en linters in te zetten in je automatische build.

Gezamenlijke afspraken te maken. Succes in het geval van TS. De rest vindt de huidige manier van werken prima.

[HollowGamer]

Furion2000 schreef op donderdag 12 november 2020 @ 21:03:
Word je al gezien als diegene die een kei is met open-source oplossingen? Heb je al iets bewezen hierin?

Goed voorbeeld doet goed volgen vind ik een mooi gezegde en moest even zoeken, maar moest ook denken aan iets wat ik pas geleden las;

"Moral excellence comes about as a result of habit, We become just by doing just acts, temperate by doing temperate acts, brave by doing brave acts" Aristotle

Ik ben van mening dat je mensen niet overtuigd met discussies, althans niet gemakkelijk, dit kost rete veel energie en vaak elke keer weer. Mensen overtuig je door het goede voorbeeld te geven en te zijn. Bijkomend voordeel is dat je ondertussen zelf ook steeds beter word.

Dus ga aan de slag met open-source, laat je progressie en voordelen constant merken en je voorbeelden zullen steeds beter worden en dus word je steeds overtuigender naar de andere toe.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Furion2000]

HollowGamer schreef op donderdag 12 november 2020 @ 22:29:
[...]


***members only***

Vorig jaar liet een architect van een grote bank zijn agenda zien in een presentatie (geloof ook dat dit fake was, maar het ging om het punt) en die had elke vrijdag ochtend 2 uur gereserveerd voor 'playtime'.

Ik denk dat dit wel te regelen is onder het mom van innovatie en als de baas het declarabel wil maken, moet hij je uren onderbrengen in de WBSO regeling

[Transportman]

Dit zal je overal tegen komen. Probeer het met kleine stapjes te doen of in de positie te komen dat je het met wat grotere stappen kan doen. Zelf heb ik een project gedaan waarin ik het voortouw kon nemen, dus ik heb zaken als code reviews wel zoveel mogelijk afgesproken (volgende projecten zal ik het ook af gaan dwingen), voordat mensen gaan bouwen ze wel even een moment laten nemen om uit te laten werken hoe zij denken dat hun code moet gaan werken en dat bespreken voordat ze daadwerkelijk gaan bouwen.

Daarbij heb ik ook wel de afweging gemaakt van hoe erg een punt uit de code review is, want dwars gaan liggen tot alle punten zijn opgelost kan er weer toe leiden dat het project uitloopt of dat iemand heel veel tijd gaat steken in een probleem waar die de kennis niet voor heeft om op te lossen, dus sommige punten zijn op de nazorglijst gegaan om richting het einde van het project opgelost te worden als de druk er minder op staat.

Maar ik heb ook te maken met code die ik overgenomen heb van collega's, en daar zit wel het een en ander in dat ik anders zou doen (gigantische code duplicatie). De klant geeft de ruimte/tijd/budget niet om dat op te ruimen, dus als ik daarin iets moet wijzigen, voelt het iedere keer toch weer van "dit kan anders en beter". Ik heb me er daar maar bij neergelegd, het is niet compleet onwerkbaar maar fijn is anders.

[drooger]

HollowGamer schreef op donderdag 12 november 2020 @ 14:08:
[...]
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Joeddoes]

*spam*

[ Voor 94% gewijzigd door F_J_K op 15-11-2020 19:04 ]

[Sander B]

@HollowGamer Ben je nog verder gekomen met je collega's?