Il fondatore ha risposto che stanno reagendo in modo eccessivo, e che ha una fiducia assoluta nelle capacità del nuovo lead, sulla base del suo CV e del colloquio, ed è proprio per questo che ha assegnato a questa persona il ruolo di lead developer in primo luogo.

Il capo ha parlato. Non è un governo o un partito politico. Non si può buttare fuori nessuno o guidare un'insurrezione.

Se non si è disposti ad affrontarlo, si ha davvero una sola possibilità. Potete riunirvi e minacciare di ritirarvi a meno che non succeda qualcosa.

Dico che potete, non che dovreste. Ci sono ottime probabilità che non finisca bene. In pratica stai cercando di metterti davanti al capo che ha preso la sua decisione e ai responsabili non piace che vengano messi in discussione.

Suppongo che la cosa “corretta” da dire sia trovare tecniche che lo incoraggino a vedere il tuo modo di pensare. Ma non ho intenzione di farlo. Sono uno sviluppatore senior di 30 anni e posso dirvi che sono diventato in gran parte impostato nei miei modi fondamentali. No, non sono un luddista come questo ragazzo e sì, accetto suggerimenti. Abbraccio le nuove tecnologie e così via. Questo ragazzo si sbaglia chiaramente su un sacco di cose. Tuttavia, quello che posso dirvi è che quando sono fissato su qualcosa e sono convinto di prendere la decisione giusta, mi attengo ad essa. Non prendo bene le minacce e la coercizione o la manipolazione è ancora peggio.

Il mio punto è che è convinto di essere “Gesù programmatore” (che è un triste atteggiamento sfortunato) e non lo cambierai mai, non in questa fase della sua carriera. È convinto di avere ragione e pensa che la sua esperienza lo supporti. Purtroppo, anche il capo lo pensa.

Onestamente, probabilmente non vale la pena di stressare te e la tua squadra. Suggerirei a ciascuno di voi di iniziare a cercare un nuovo lavoro e di andarvene quando ne avrete trovato uno. Quando una persona se ne va, assicuratevi che dica al capo il perché. Alla fine potrebbe farsi un'idea. Anche allora, non è una garanzia.

RUN Seriamente, non so perché qualcuno vorrebbe essere lì. Chiedetevi: c'è qualcosa in quello che ci avete detto che non sia un destino per il prodotto? Sono sicuro che lo sapete. Metto in dubbio l'intelligenza di base del fondatore per questo. Gli sviluppatori di solito fanno dei pessimi project/program manager. Si tratta di un insieme di competenze a parte e devono trovare un equilibrio tra loro. È come dire “non abbiamo bisogno di tester separati, i test degli sviluppatori funzionano benissimo”. Entrambe sono ricette per il disastro. Buona fortuna. Dico sul serio.

De beschrijving van de situatie in het OP is waarschijnlijk eenzijdig. Dat is ok.

Ik ben een ouder wordende ontwikkelaar (~54 yo) die in een bedrijf wordt gebracht om niet te regeren, maar om wat ervaring op te doen. (De IT baas zei eigenlijk “grijze haren”, hé.) Het dev personeel was far bedrevener, op de balans, dan elk team waar ik eerder mee had gewerkt. Ze leerden me veel, vooral over nederigheid! Maar we vonden plaatsen waar hun technologische tovenarij de problemen niet oploste en in sommige gevallen verborg ze die problemen, waardoor ze uiteindelijk nog erger werden. Dit is waar ik echt een bijdrage heb kunnen leveren.

Uw voorsprong klinkt zwaar autocratisch. Het klinkt alsof hij een mandaat heeft gekregen van de eigenaar. De eigenaar is ontevreden over het personeel en heeft deze “hardnekkige no-nonsense doorzetter” ingeschakeld om de leveringssnelheid te verbeteren.

Kijk eerst eens naar je personeel. Hebben jullie zwakkelingen - ontwikkelaars die niet “de Matrix zien”? Zo ja, vind ze nieuwe functies binnen het bedrijf of geef ze een goede referentie voor een werkgever die hun unieke vaardigheden nodig heeft.

Hij haat IDE’s

Ik ken er een paar die dat wel doen. Het doet me mijn ogen rollen, maar uiteindelijk kan het me niet schelen. Als mensen produceren met behulp van vi, dan is dat ok. Ik hou van mijn IDE’s.

Hij refactoren de code niet, en geeft niet om de stijl (die inconsistent is over zijn eigen code)

Rode vlag op het eerste deel. Is hij een copy-paster? Ik ben ook schuldig aan het niet geven om stijl, maar dat komt omdat ik mijn IDE gebruik om mijn Python code direct PEP8 compliant te maken. Maar hij gebruikt geen IDE…

Terzijde, stijl werd eerder gecontroleerd door een nachtelijke build, die begon te mislukken sinds de komst van de nieuwe lead.

Hij verwerpt het idee van een nachtelijke build, evenals geautomatiseerde tests. Volgens hem “test elke professionele ontwikkelaar zijn code toch met de hand, dus er is geen reden om tijd te verspillen aan het schrijven van geautomatiseerde tests”. De nachtelijke bouw is volgens hem ook tijdverspilling.

Dit zet ook een rode vlag uit, maar om andere redenen dan je zou verwachten. Hoe vaak is de eigenaar, voordat deze man werd ingehuurd, verteld dat hij geen X kon doen (een demo geven, het systeem gebruiken, enz.) omdat de nachtelijke bouw mislukte? Wat als de eigenaar merkt dat de nachtelijke bouw het probleem is? Wat denk je dat hij de Lead zou vertellen om te doen?

Maar ik maak me zorgen over de houding van de Lead; geautomatiseerde testen zijn verbazingwekkend. De baas begrijpt de waarde van de testen misschien niet, maar hij weet zeker dat Y% van het personeel van de ontwikkelaar er voor betaalt. Toen ik bij mijn huidige bedrijf aankwam, had de “100%-testmaffia” het dev-personeel overgenomen en de kosten waaaay opgebracht. Een slechte appel later en het dev personeel was weer aan het spinnen.

Hij denkt dat versiebeheer meestal nutteloos is…

Dit is een rode vlag van de hoogste orde. Hij heeft het zo fout mogelijk. Hij is onverantwoordelijk met het geld van de eigenaar.

Hij overdrijft het belang van code-optimalisatie.

Vroeger kon code-optimalisatie een verschil maken. Nu zijn machines zo snel dat het minder belangrijk is. In plaats daarvan moeten we ons nu zorgen maken over de prestaties van de database en de doorvoersnelheid van het netwerk. Maar zijn “code optimalisatie” gewoonte is moeilijk te doorbreken, geloof me. Ik moet mezelf niet preoptimaliseren. Zijn gedrag is in dit geval tenminste niet destructief, behalve dan voor de tijd die het kost. (Heb je cijfers voor zijn “de helft van zijn tijd” of is dit een overdrijving?) Als u uw leidinggevende bekritiseert, kan er geen overdrijving worden toegestaan. Je moet pathologisch objectief zijn.)

Hij schrijft alle SQL met de hand, en verwerpt het idee van een ORM.

Schuldig als geladen! Ik begrijp de angst van mensen voor SQL niet. Ik begrijp niet dat het begraven van SQL, dat is drop-dead simple, onder lagen van ORM die verdoezelen. Kan je hier niet helpen :-D Maar alsjeblieft, dump al je SQL op een plaats - verdeel niet alles in je code.

en twee van de vijf ontwikkelaars hebben nog nooit SQL gebruikt.

Dat is onacceptabel. Dit is 2016. Ze moeten zich bekwamen.

Hij verwerpt frames en bibliotheken van derden, gezien het feit dat het veel gemakkelijker is om dingen vanaf nul te schrijven.

Hij kan het niet meer mis hebben. Ik betwijfel of uw bedrijf zo speciaal is dat uw hulpprogramma’s intern moeten worden geschreven. We hadden een paar ontwikkelaars die 3rd party tools zouden omarmen - totdat ze iets deden op een manier die de dev niet leuk vond. Het was een excuus om de tool weg te gooien en hun eigen te schrijven. Dit draagt alleen maar bij aan de belasting van het personeel van de ontwikkelaar, waardoor ze verder worden vertraagd. Deze nutteloze code is duur om te schrijven, te testen, te debuggen en te onderhouden. We hebben zoveel geld uitgegeven voor -nul-voordeel. Deze ontwikkelaars zijn nu weg.

Hij besloot alle JavaScript bibliotheken en frameworks te laten vallen, behalve jQuery, omdat hij beweerde dat toen hij vijftien jaar geleden begon te programmeren in JavaScript, er geen frameworks waren, en het leven veel gemakkelijker was.

Deze is niet zo duidelijk gesneden. De reden is dat het leven 15 jaar geleden veel gemakkelijker was, is dat de zakelijke vraag was veel eenvoudiger. Dat is waar het probleem vandaan komt. Het web is uitgevonden als een batchsysteem (vul een formulier in, verstuur het, krijg een reactie, herhaal) en nu proberen we web apps te schrijven die zich gedragen als desktop apps. Zijn observatie is juist, de dingen zijn nu moeilijk. Maar hij beseft niet waarom. De complexiteit van de tools is een antwoord op een meer gecompliceerde zakelijke vraag. Dus hij maakt slechte keuzes.

We gebruiken AngularJS en het lijkt fatsoenlijk te zijn. Zoals alle krachtige tools kan het gebruikt worden voor goed of kwaad.

Hij denkt dat mobiele apparaten (inclusief tablets) slechts een hype zijn, dus er is geen reden om kostbare tijd te verspillen om de compatibiliteit van de site met die apparaten te garanderen en om een responsief ontwerp te maken. Het product is een publieke webapplicatie die naar verwachting niet veel gebruikt zal worden vanaf mobiele apparaten.

Hij heeft het weer mis. Ze zijn geen hype. Ze zijn hier om te blijven omdat ze nuttig zijn. Maar het bedrijf heeft het niet nodig. Ontwikkel geen dingen die je niet nodig hebt. Het is duur.

Responsive design, echter, kan zeer interessant zijn om te hebben voor deze app,…

Is het zo interessant dat je persoonlijk zou betalen voor de ontwikkeling? Als dit een goed idee is, zou je het idee aan de eigenaar moeten kunnen verkopen. Geef er anders geen cent aan uit.

Hij vraagt het team om te stoppen met het gebruik van internet (vooral StackOverflow) en te vertrouwen op hun hersenen, de offline documentatie (ik wist niet eens dat Microsoft nog steeds MSDN CD’s verkoopt!) en de boeken.

Hij heeft het mis. Het internet is hier geweldig voor. Als de medewerkers van de ontwikkelaars Stackoverflow kopiëren zonder te begrijpen hoe de code werkt, dan hebben ze het ook mis. Is er tijd voor training en persoonlijke verbetering in het ontwikkelingsschema? Het is moeilijk om niet robotisch te copy-pasten als je altijd onder het pistool zit.

• *

Hoewel ik beperkte informatie heb, zijn er hier veel problemen. Het klinkt alsof de eigenaar niet zo snel de code heeft gekregen waar hij voor betaalt als hij verwacht. Het klinkt alsof hij veel excuses heeft gehoord over dingen waar hij niets om geeft; hij is gefocust op het resultaat. Als ik gelijk heb, heb je een zelf toegebrachte wond en heb je die meer dan eens heropend. Deze Lead is de oplossing van de eigenaar voor het probleem dat het personeel van de dev heeft gesteld, en gezien zijn beperkte informatie, is het begrijpelijk.

Ik wed ook dat je een non-agile shop runt en een slechte definitie van de eisen hebt die verandert als de wind waait. Er is geen laagje isolatie tussen het personeel en de eigenaar. Behalve deze Lead.

Nu, wat kun je doen?

1) Train de leiding dat het gebruik van geautomatiseerde testen en code management de manier is om te gaan. Het kan tijd kosten om geloofwaardig over te komen bij hem - de eigenaar heeft hem waarschijnlijk verteld dat het personeel gebrekkig is. Kijk of je kunt voorkomen dat hij vegen mandaten maakt zoals “verwijder al dat nutteloze testgedoe en herbruik de SVN-server”. Dit geeft je de tijd om de waarde te tonen.

2) Ga door met het gebruik van codebeheer op een persoonlijk niveau. Dan kunt u in ieder geval herstellen van uw eigen fouten. Vertel hem niet dat je dit doet, maar lieg ook niet tegen hem.

3) Ga door met geautomatiseerd testen (unit tests, als het niet anders kan) op persoonlijk niveau. Vermeld het niet zoals voorheen, maar verberg het niet.

4) Werk samen met de Lead om te bepalen wat de werkelijke gepercipieerde problemen zijn. Wees open minded; ik durf te wedden dat er echte problemen zijn met het personeel. Werk met de Lead om de problemen aan te pakken, niet de symptomen.

5) Bespreek met de Lead verschillende ontwikkelingsonderwerpen, zoals de voordelen van waterval en agile. Geen van beide is perfect. Stel hem vragen als: “Onder welke omstandigheden zou geautomatiseerd testen de moeite waard zijn”? Als hij een dubieus antwoord geeft, vraag hem dan hoe succesvol bedrijven als Google desondanks hebben kunnen gedijen.

Dus je kunt zien dat ik er alles aan doe om de Lead te engageren en te zien waar zijn hoofd staat. Vertrouwen opbouwen. Overeenkomen over problemen versus symptomen. Dit is niet altijd gemakkelijk, zeker niet als je het gevoel hebt dat hij net als Godzilla is en je werk uit elkaar haalt.

Er is een kans dat hij geen compromissen kan sluiten. Hij zal geautomatiseerde testen verpletteren. Code management is voor onzorgvuldige mensen. My Way of de Highway.

Als het zover is, is het echter tijd om te vertrekken. Werken in een gereedschaploze winkel, en dan bedoel ik software en software engineering tools - bouwt je cv niet op. Je zult op dezelfde manier beginnen te rotten als de Lead heeft gerotzooid. In dat geval, ga verder.

vijfentwintig jaar in IT […] verander zijn houding

Niet werken, sorry.

Je echte probleem is niet de incompetente hoofdontwikkelaar. Dat probleem is onbeduidend in vergelijking met het echte probleem dat je beschrijft:

Je oprichter vertrouwt een incompetente* vreemdeling meer dan hij zijn bestaande werknemers vertrouwt.

Je moet uitzoeken hoe het team zijn vertrouwen heeft verloren, en hoe je het kunt terugwinnen. Dit zou makkelijker zijn geweest als het was gedaan voordat de vreemdeling was ingehuurd. Nu is dit moeilijk, want elk goed werk zal worden toegeschreven aan de nieuwe teamleider, en elk slecht werk zal worden toegeschreven aan jullie allemaal - dus je kunt het niet oplossen door harder te werken.

Er zijn maar 2 dingen die ik kan bedenken, om de situatie op deze baan te verbeteren:

1. 1. Zoek een bemiddelaar. Zijn er meerdere oprichters, of zoiets als bestuursleden?
2. Misschien is het vertrouwensprobleem een zichtbaarheidsprobleem. In dat geval helpt alles wat de zichtbaarheid helpt. Maak bijvoorbeeld sprint demo’s spannend en interessant genoeg dat de oprichter daadwerkelijk aanwezig is en leert over de status en de voortgang van het team.

• *

*De meeste punten die door de OP aan de orde worden gesteld maken de vreemdeling niet per se incompetent, zijn benadering van Versiecontrole en Continue Integratie in een 5-persoons team doet dat zeker wel.

Dit antwoord is misschien ongunstig en wordt door sommigen als crassig beschouwd, maar…

• *

De eerste rode vlag is For a few years, the founder was unhappy about the technical skills of the employees

Hebben de medewerkers geprobeerd het ongeluk te verhelpen?

• *

De tweede rode vlag is two of the five developers never used SQL before

Het is moeilijk om een efficiënt systeem te creëren als de ontwikkelaars niet bekend zijn met de kerntechnologieën en echt begrijpen wat de ORM maskeert.

• *

Het is moeilijk voor te stellen dat I worked for twenty-five years in this industry, and you? What have you done? You've been a code monkey for three years. So shut up, you, moron! Nobody cares about your opinion, a ******. daadwerkelijk werd geuit, maar ik neem het op zich en geloof je.

Maar denk wel aan de eerste rode vlag die ik noemde en het “ongeluk” waar de oprichter al jaren mee te maken heeft gehad.

Hieraan voeg ik toe: jullie weten al jaren van het ongeluk van de oprichter?!

Hoe werd deze informatie aan jullie onthuld?

• *

Ik ben geneigd te denken dat deze kerel nauwkeurig doet waarvoor hij werd ingehuurd; jullie in vorm brengen.

Jullie in vorm brengen verwijst niet naar het aannemen van de slechte praktijken van de nieuwe kerel, maar het houdt wel in dat jullie uit jullie comfortzone worden gegooid om op een dieper niveau te leren.

De oprichter was enkele jaren ontevreden over de technische vaardigheden van de medewerkers en nam onlangs een senior developer in dienst voor de dubbele rol van technisch hoofd en projectmanager. Hij was de enige die een interview deed, en de enige die besloot deze persoon aan te nemen.

Klinkt alsof de oprichter je niet vertrouwt.

Het team heeft zijn profiel echter in twee maanden tijd veel minder gewaardeerd. Ik had de kans om met drie van de vijf leden van dit team te praten, en ze benadrukten allemaal drie zaken:

• Volgens hen is de man een eikel, en heeft hij geen respect voor de andere leden van het team. Een recent citaat van hem dat hij met een junior programmeur voor het team praat is zeer illustratief: “Ik heb vijfentwintig jaar in deze industrie gewerkt, en jij? Wat heb je gedaan? Je bent drie jaar lang een code-aap geweest. Dus hou je mond, jij, idioot! Niemand geeft om jouw mening, maar het lijkt erop dat je maar één kant van het verhaal krijgt. Ik kan me een paar situaties voorstellen waarbij ik zelf een jonge kennis moet neerslaan, en dat heb ik gedaan. Ik speel gewoon de advocaat van de duivel, maar het klinkt alsof hij geprovoceerd is. Wat was de provocatie?

• In het verleden werden beslissingen genomen door alle teamleden. Als de leden het niet eens waren, bespraken ze het allemaal samen en kwamen ze tot een overeenkomst, of legden ze tenminste de redenering uit aan degenen die het niet eens waren.

heeft blijkbaar in het verleden niet de resultaten opgeleverd die de oprichter wilde.

Nu worden alle belangrijke beslissingen uitsluitend genomen door de hoofdontwerper. Deze beslissingen kunnen niet in twijfel worden getrokken of besproken, zelfs als alle vijf de teamleden vinden dat een beslissing geen zin heeft.

opnieuw klinkt het als een motie van wantrouwen van de oprichter. Hij heeft dit type persoon met een reden binnengehaald. Klinkt alsof de reden was om de rest van het personeel in vorm te brengen.

1. Hij haat IDE’s, auto-completion, en functies die bedoeld zijn om programmeurs te helpen sneller code te schrijven, en beweert dat het team Notepad++ moet gebruiken om productief te zijn. Hoewel het in verschillende omstandigheden zinvol is, is het moeilijk voor te stellen dat C#-ontwikkelaars plotseling afzien van Visual Studio voor Notepad++.

IDE’s kunnen je vertragen als je een snelle programmeur bent. Notepadd++ is superieur aan sommige voor snelle codering. Het idee is dat je je code schrijft en dan in de IDE laat vallen voor snelle correctie in plaats van constante onderbrekingen.

1. Hij refactoren de code niet, en geven niet om de stijl (die inconsistent is over zijn eigen code), de reden daarvoor is dat "hij alleen maar geeft om dingen die er echt toe doen”. Terzijde, stijl werd eerder gecontroleerd door een nachtelijke build, die begon te mislukken sinds de komst van de nieuwe lead.

Shop standaards zijn iets om te bespreken met de oprichter, vooral omdat je het door de nachtelijke build laat lopen. Maar nogmaals, als je tussen de regels door leest, lijkt het erop dat de oprichter je niet vertrouwt.

1. Hij verwerpt het idee van een nachtelijke bouw, evenals geautomatiseerde tests. Volgens hem “test elke professionele ontwikkelaar zijn code toch met de hand, dus er is geen reden om tijd te verspillen aan het schrijven van geautomatiseerde tests”. De nachtelijke bouw is volgens hem ook tijdverspilling.

Hij heeft gelijk geautomatiseerde tests zijn niet verantwoordelijk voor het pure genie van een dwaas die iets doet wat nooit bedoeld is. Ik heb persoonlijk verschillende programma’s gebroken die door geautomatiseerde testen gingen.

1. Hij vindt dat versiebeheer meestal nutteloos is, en lijkt verkeerd te begrijpen hoe je er een moet gebruiken. Dit leidt tot de situaties waarin hij een functie alleen ontwikkelt voor drie tot vijf dagen, en wanneer hij uiteindelijk zijn veranderingen vastlegt, “neemt hij de mijne” voor alle conflicten. Als andere teamleden klagen dat hun code is gewist, nodigt hij hen uit om deze te herschrijven. Bij verschillende gelegenheden hebben andere leden hetzelfde gedaan, waarbij ze de code van de hoofdontwikkelaar hebben gewist. Hij keek verbaasd (het lijkt erop dat hij niet weet hoe hij svn log of diffs moet gebruiken), en deed zijn veranderingen opnieuw, klaagde dat “ze op mysterieuze wijze verloren waren” en gaf SVN de schuld voor het verknoeien ervan.

Iedereen is hier in de fout. Heeft niemand een back-up? Als hij problemen heeft met versiebeheer, is het de verantwoordelijkheid van het team om als een team te werken en hem er niet alleen moeite mee te doen.

1. Hij overdrijft het belang van code-optimalisatie. Zijn aanpak is correct, d.w.z. hij draait een profiler, bepaalt een knelpunt en lost het op; het probleem is dat er geen niet-functionele prestatie-eisen zijn, en geen elementen die aangeven dat de gebruikers de applicatie als traag kunnen beschouwen (en gehost worden op laagwaardige ontwikkelings-VM’s, de app voelt zeer responsief aan). Hij, aan de andere kant, besteedt bijna de helft van de tijd aan het optimaliseren van de code.

Er is geen manier om het belang van code-optimalisatie te overdrijven. Het doel van code-optimalisatie is niet om ervoor te zorgen dat het goed draait vandaag het doel is om het te optimaliseren zodat je bent niet bezig met het oplossen van een of ander probleem drie jaar later, wat voorkomen had kunnen worden met code optimalisatie.

Als je alleen maar geeft om de gebruikers die vandaag gelukkig zijn, ga je ze morgen op je deur laten bonzen.

1. Hij schrijft alle SQL met de hand, en verwerpt het idee van een ORM. Men dient op te merken dat het huidige product gebaseerd is op Microsoft’s ORM Entity Framework, en twee van de vijf ontwikkelaars hebben nog nooit SQL gebruikt.

Twee van de vijf ontwikkelaars zouden dan ontslagen moeten worden. Als je op een ORM vertrouwt, zul je nooit in staat zijn om onder de motorkap te komen en dingen handmatig te repareren. Ik begin te begrijpen waarom hij iemand uit frustratie een ‘code-aap’ noemde. ORM’s zijn prima en goed, maar je moet de SQL begrijpen als je ooit verder gaat dan de beperkingen van een ORM.

1. Hij verwerpt kaders en bibliotheken van derden, gezien het feit dat het veel gemakkelijker is om dingen vanaf nul te schrijven. Hij besloot alle JavaScript bibliotheken en frameworks te laten vallen, behalve jQuery, en beweert dat toen hij vijftien jaar geleden begon te programmeren in JavaScript, er geen frameworks waren, en het leven veel gemakkelijker was.

Hij heeft gelijk. Frameworks en bibliotheken van derden hebben beperkingen, en als je niet genoeg begrijpt om er zelf in te gaan en het te repareren, begrijp je de code niet. Er kan hoe dan ook een argument worden aangevoerd. Als echter niemand in het team kan coderen zonder gebruik te maken van de frameworks, dan heb je een heel zwak team.

1. Hij denkt dat mobiele apparaten (inclusief tablets) slechts een hype zijn, dus er is geen reden om kostbare tijd te verspillen om de compatibiliteit van de site met die apparaten te garanderen en om een responsief ontwerp te maken. Het product is een publieke webapplicatie die naar verwachting niet veel gebruikt zal worden vanaf mobiele apparaten. Responsive design kan echter zeer interessant zijn voor deze app, aangezien het zelfs op desktops wordt weergegeven op zowel 19-inch monitoren als grote high-res monitoren.

Van alles wat je hebt gezegd, klinkt het alsof hij is binnengehaald om schoon schip te maken. Als mobiele apparaten geen grote speler zijn voor de applicatie(s), dan is te veel tijd verspillen. Hoewel het misschien een “nice to have” op een desktop is, is een “nice to have” geen noodzaak voor de uitrol.

1. Hij vraagt het team te stoppen met het gebruik van internet (vooral StackOverflow) en te vertrouwen op hun hersenen, de offline documentatie (ik wist niet eens dat Microsoft nog steeds MSDN CD’s verkoopt!) en de boeken.

Goed voor hem. Het lijkt erop dat hij wil weten wie zijn eigen huiswerk kan maken en wie er vals speelt.

Teamleden klaagden bij de oprichter van het bedrijf over hun nieuwe leiding over deze drie zaken. De oprichter antwoordde dat ze overreageren, en dat hij op basis van zijn CV en het interview een absoluut vertrouwen heeft in de vaardigheden van de nieuwe leider.

Wat moet het team doen om:

• Ofwel de leider uit het team of het bedrijf te gooien,

• ofwel hem te dwingen om zijn houding ten opzichte van het team te veranderen?

Wat dacht je ervan om met hem te werken en niet elke beweging te saboteren?

In alle eerlijkheid, het klinkt alsof hij naar een schoon huis is gebracht, gezien wat je hebt gepost, klinkt het meer dan terecht.

De eigenaar is NIET tevreden met je prestaties. Het zou je goed doen om het advies van deze kerel op te volgen voor wat het waard is. We hebben een beetje ervaring met relikwieën en we weten wat de boeken je nooit zullen leren. Toch, in plaats van dit te zien als een kans om te leren en te groeien, heeft je team een enorme hebbelijkheid.

Dus ik weet niet hoe lang je teamleden hebben geklaagd bij je baas over de hoofdrolspeler. Maar heb je een goed rondetafelgesprek met hen gehad? Leg de problemen die je hebt met de hoofdrolspeler uit aan je baas en laat hem zijn kant van het verhaal hebben.

Stoppen zou een laatste redmiddel moeten zijn.

De eigenaar moet een personeelsmanager

inhuren Andere antwoorden hebben hierop gezinspeeld, maar de olifant in de kamer is dat de eigenaar (begrijpelijkerwijs) moeite lijkt te hebben met het succesvol uitvoeren van personeelsfuncties als inhuren, trainen, ontslaan, enz. Voorbeeld: de eigenaar heeft een ondermaats presterend team, neemt ze jarenlang mee, huurt vervolgens een 25 jarige veteraan in om dingen te repareren, en huurt vervolgens een consultant in als de 25 jarige veteraan niet in staat is om dingen te repareren. De eigenaar lijkt niet te weten hoe hij de personeelskant van het bedrijf moet runnen. Dat is oké, er zijn mensen die dit doen voor de kost, en daarom hebben de meeste organisaties people managers. De eigenaar moet één statuut aannemen. Dit zal de eigenaar vrijmaken om zich te concentreren op de strategische kant van het bedrijf, dus het is een overwinning._

Misschien kan OP helpen met het interviewen (de eigenaar lijkt immers hulp nodig te hebben in dit opzicht)?

Een “rimpel” die ik hier nog niet gezien heb. Het is vrij gebruikelijk voor mensen met veel ervaring om defensief te zijn over het niet op de hoogte zijn van de huidige ontwikkelingen. Vroeger kreeg ik hetzelfde voor elkaar met mensen die praatten over hoe verschrikkelijk VB6 was in relatie tot het prachtige .net, toen die mensen gewoon dingen herhaalden die ze over VB6 hadden gehoord en er niet echt veel van wisten.

Zoals je zegt, een heleboel dingen die de leider zegt staan op punt. Maar dat betekent niet dat ze dat allemaal zijn, zoals u zegt. Misschien kan meneer 25 jaar zijn geest openen en zijn aanpak samenvatten met het beste van de status-quo, maar niet als hij bang is om minder dan perfect te zijn en in ontkenning over bang zijn. Wat mij betreft is dat het eigenlijke probleem hier. Er kunnen andere problemen zijn met de junioren (bijvoorbeeld defensief over hun gebrek aan expertise), maar dat lijkt hier het onderliggende probleem te zijn.

Als iedereen bij elkaar komt en hun angsten op een open en eerlijke manier aanpakt, dan moeten ze zich in een positievere richting gaan bewegen. Ik kan niet zeggen dat het klinkt als een hoge waarschijnlijkheid, maar het is wat er gedaan moet worden.

1. 1. Heeft het hele team samen met deze ontwikkelaar gesproken en geprobeerd de voordelen van zaken als versiebeheer en IDE’s uit te leggen? Een openhartige discussie en masse kan

2. helpen. Ik ben het ermee eens dat het beledigen van andere ontwikkelaars onprofessioneel is en dit moet krachtig aan hem worden uitgelegd. Vraag hem of hij blij is als anderen dezelfde toon aanslaan

3. Vraag hem of hij in eigen land stress ondervindt of een gezondheidsprobleem heeft zoals Diabetes waardoor hij geïrriteerd raakt

4. Vraag hem of hij blij is om oud te worden en een chagrijnige oude gozer met een geest die atrofieert omdat hij niets nieuws leert.

5. Als al het andere faalt zeg dan dat al zijn fouten gedocumenteerd zullen worden om je eigen huid te redden en dat gesprekken met hem opgenomen kunnen worden.