Hoe ga je om met een collega die mij de schuld gaf van de bug die zijn fout was

Sommige mensen hebben de neiging om anderen agressief de schuld in de schoenen te schuiven om de aandacht van zichzelf af te leiden. Aangezien je ook relatief nieuw bent, moet het voor hem erg handig zijn geweest om te doen wat hij deed.

Hier is mijn advies. Schrijf een mailtje, beschrijf wat het probleem was, hoe je tot de hoofdoorzaak bent gekomen, wat de uiteindelijke oplossing was en hoe het in de toekomst voorkomen kan worden. Neem alle betrokkenen op in deze mail.

Aan het eind van deze mail schrijf je iets op deze regels,

XYZ,

Kan je deze stappen alstublieft toevoegen in de juiste documentatie of het document met standaardprocedures voor dit stukje code?

Op deze manier wijs je “geen vinger” naar hem, maar roep je expliciet op dat hij de eigenaar is van dit stukje code en dus verantwoordelijk is voor dit stukje code. Roepen is belangrijk omdat niet iedereen (vooral het hogere management) een codebase link zal openen om te zien wie de code heeft vastgelegd.

Een beetje hard, maar hij verdient het.

Ik heb een carrière opgebouwd door niet het schuldgevoel te spelen, maar de waarheid is dat mensen naar de luidste stem luisteren. Echter, als je betrokken raakt bij het verdedigen van jezelf, gaat hij je naar beneden trekken naar zijn niveau en je verslaan met ervaring.

Als je er een kunt vinden, heb je een kampioen nodig. Idealiter zou dit je manager moeten zijn, maar soms is het een andere gerespecteerde ontwikkelaar. Ze zullen voor je gaan knuppelen om de luide te doen zwijgen. Het enige wat je hoeft te doen is een privégesprek met hen te voeren over de feiten (niet de schuld) van wat je hebt gedaan om het probleem op te lossen en hoe ze willen dat je te werk gaat zodat, de volgende keer dat er iets mis is met de service, het probleem sneller kan worden gevonden en opgelost. Dat kan inhouden dat u een klein testprogramma moet schrijven dat de service direct test (zonder gebruik te maken van de code van de andere ontwikkelaars), of wat logging of iets dergelijks, zodat het “ons versus hen” probleem heel snel kan worden vastgesteld. Als ze weten wie er eigenlijk fout zat, kunnen ze je naam zuiveren zonder dat je in direct conflict komt met de luidruchtige.

Ik heb me altijd voorover gebogen om te voorkomen dat andere ontwikkelaars in de verdediging zouden komen. Ik heb dingen gezegd als “Ik heb moeite om het probleem te dupliceren, kun je me alsjeblieft laten weten welke telefoontjes je naar de dienst doet en wat je terugkrijgt, zodat ik de dienst correct kan testen”? Als de ontwikkelaar de moeite neemt om u logsporen te geven van de daadwerkelijke gesprekken en reacties, vraag dan wat ze verwachten terug te krijgen. Meestal zal de ontwikkelaar u echter gewoon hun code laten zien. In dat geval kunt u soms het probleem zien. Zelfs als u dat doet, roep ze dan nog steeds niet op. Ze moeten het probleem zelf vinden. Laat ze de code door een debugger halen en vraag onschuldig wat een bepaalde variabele op een bepaalde regel code bevat. Ik zou door kunnen gaan, maar je krijgt het idee.

Het is een mooie traditie in de IT-industrie (en in sommige andere, zoals in de luchtvaart) dat wanneer iemand een probleem vindt, iedereen samenwerkt om een oplossing te vinden, en idealiter om de hoofdoorzaak te vinden, zodat processen kunnen worden verbeterd, maar niemand krijgt persoonlijke schuld of wordt gestraft voor het maken van de fout. Het resultaat is dat mensen open en eerlijk zijn over hun fouten, in plaats van te proberen deze te verdoezelen, wat in ieders voordeel is.

Het lijkt erop dat er mensen in je winkel zijn die zich niet hebben ingekocht in deze cultuur, en dat is iets wat de aandacht van het management nodig heeft.

Ik vind dat je met je manager moet praten over de manier waarop problemen worden aangepakt, met name prioritaire problemen die de gebruikerservaring beïnvloeden.

In dit geval heb je 2 systemen die met elkaar communiceren en plotseling stopt de communicatie met werken. Wanneer de communicatie uitvalt, is het belangrijk dat beide partijen naar beide systemen kijken. Iedereen zet de focus op uw service, waardoor ze de zaken niet onderzoeken. De grootste tijdverspilling bij het oplossen van een probleem is proberen uit te vinden wat er mis is met een deel ervan ** dat eigenlijk loopt zoals het hoort**.

Dit zijn echter leerervaringen. Ik durf te wedden dat je nu perfect weet hoe je je dienst moet oplossen. Probeer een probleemoplossingsplan op te zetten op basis van uw ervaring, en zet een van de eerste stappen om er zeker van te zijn dat het eigenlijk uw service is die faalt (“Werkt de service die vanaf een andere pagina wordt opgeroepen?”, “Faalt de service gedeeltelijk of geheel?”). Je bent DE web service man, je kunt een beetje vertrouwen hebben in je werk.

Probeer het feit los te laten dat het eigenlijk zijn code was die faalde. Het is een beetje kleingeestig om hem daar op te roepen. Hij had zich niet vanaf het begin zo op jou moeten richten. Zie het als een algemeen probleem binnen het bedrijf met het oplossen van een probleem en behandel het als zodanig met je manager. Je weet ook niet of het eigenlijk zijn code was, hij had het ook kunnen kopiëren van een andere sectie die door een collega is geschreven.

Ik denk dat de suggestie om met je manager te praten een goede is. Je manager moet weten dat je ten onrechte de schuld hebt gekregen.

Maar bovendien wordt je op de proef gesteld. Je eerste instinct is goed. Je moet reageren, anders wordt het nog erger. Ik zou hem direct mailen en hem laten weten dat het probleem in zijn code zat, en dat je voor deze keer niemand anders dan je manager hebt verteld, die je moest vertellen om jezelf te beschermen. En laat hem tot slot weten dat als hij het weer doet, je het openbaar zult maken.

Ik ben een beetje laat met de vraag hier, maar naast het zeer goede advies in Edgar’s antwoord, is er nog een tweede deel.

Als je een mededeling stuurt dat je het probleem hebt gevonden en noteert waar het is opgelost, dan zullen de andere ontwikkelaars waarschijnlijk wel weten waar het probleem ligt (dit is goed), maar het management zal dat waarschijnlijk niet doen.

Als je het zo doet betekent dat je deze kerel een plezier hebt gedaan - hij heeft je publiekelijk gebeld, je hebt het probleem gevonden, hebt het opgelost en hebt hem niet met het management laten vallen. Zo'n vertrouwen opbouwen met je collega’s zal je op de lange termijn goed van pas komen.

• *

Lichte kanttekening - dit hangt natuurlijk een beetje af van de aard van de fout die je in hun werk aantreft. Als wat je vindt zo flagrant fout is dat het duidt op incompetentie van hun kant, dan wil je dit misschien rustig laten escaleren naar je manager - die zal het willen weten en jij bouwt ook vertrouwen met hen op.

Ik stel voor dat je er een nachtje over slaapt voordat je reageert op de persoonlijke aspecten van de situatie. Als je het probleem hebt opgelost en de dingen weer op gang hebt gebracht, dan ben je nog steeds “de man”. Na wat rust zal het makkelijker zijn om genadig te zijn.

Terwijl het hoofdprobleem al uitgebreid aan bod kwam in andere awswers - de andere kerel die je lastigvalt - wil ik graag een ander perspectief naar voren brengen.

De oplossing werd gedaan in de code die de andere kerel bezat, maar meestal had de dienst een groter probleem kunnen voorkomen door conservatiever te zijn in het afhandelen van verzoeken van klanten. Valideert het de invoer? Rapporteert het enige runtime fouten? Is er een testomgeving (dit geldt ook voor de consument)? Soms wachtte een probleem in de service alleen maar om op te duiken, dus ik zou zeggen dat het niet betekent dat dit het hele verhaal is, alleen maar omdat er op één plaats een oplossing is gevonden. Ook voor dit soort zaken is er meer dan alleen code. Er is ook een proces.