Ik heb per ongeluk het werk van mijn collega beter gedaan dan hij. Moet ik er iets over zeggen?

Mijn collega en ik werken allebei voor een kleine startup. We hebben beide verschillende secties van het product toegewezen gekregen om aan te werken, met verschillende expertises. We hebben allebei dezelfde baas (de bedrijfseigenaar).

Vorige week kreeg hij de opdracht om een ​​code te maken die ik kon gebruiken. Terwijl ik wachtte tot hij me zijn deel voor integratie in mijn code zou bezorgen, produceerde ik in de tussentijd een code om in te gebruiken, zodat ik kon doorgaan met mijn werk. Ik heb de code niet geschreven. Het werd gegenereerd met behulp van een MATLAB-tool en ik heb zojuist de parameters ingevoegd.

Toen hij zijn definitieve code doorstuurde, zag ik dat mijn MATLAB-gegenereerde code enorm superieur was. Hij gebruikte MATLAB ook om zijn resultaten te genereren, maar hij gebruikte een andere tool met verschillende parameters.

Ik had de indruk dat hij deze resultaten 'met de hand' zou genereren in plaats van de MATLAB-generator te gebruiken. Ik gebruikte de generator gewoon als een snelle oplossing terwijl ik wachtte tot hij klaar was.

Ik weet niet echt wat ik moet doen. Ik was niet van plan om zijn werk voor hem te doen, en dat deed ik niet echt (ik zou dit in elk geval niet met de hand kunnen doen!). Ik wil niet dat hij het gevoel heeft dat ik op zijn tenen sta. Maar tegelijkertijd is er een enorme verbetering in resultaten tussen de mijne en zijn (dat is meetbaar). Ik wil ook geen inferieure code gebruiken als ik weet dat er een beter presterende code beschikbaar is.

Ik wil dit ophelderen en er met iemand over praten, maar ik weet niet hoe ik het onderwerp moet aanpakken zonder een slechte teamplayer tegen te komen, of het werk van mijn collega proberen te saboteren, of iets dergelijks. Hoe praat ik er met hem over? Of breng ik het met onze baas ter sprake?

105
@Lilienthal Ik heb niet het gevoel dat ik voorzichtig om hem heen moet stappen. Ik denk dat ik misschien een beetje gevoelig ben voor dit soort dingen, omdat ik niet veel ervaring heb met het werken aan een team en het liefst werk ik alleen. Ik weet dat teamwerk iets is waaraan ik moet werken. We zijn beiden op hiërarchisch niveau in het bedrijf, maar ik heb geen idee van zijn professionele ervaringsniveau omdat ik niet betrokken was bij het inhuren van hem of iets dergelijks. Ik heb hem altijd net behandeld als iemand die meer weet dan ik.
toegevoegd de auteur Boris Modylevsky, de bron
@ Snickers3192 eh, soms is het handig, soms is het afschuwelijk. Het is een kwestie van weten wanneer je het moet gebruiken en wanneer je het moet vermijden zoals de pest. Sommige van de DSP-tools zijn erg leuk, maar ik zou de HDL-codegeneratie niet aanraken met een 10-voet bakpaal.
toegevoegd de auteur Boris Modylevsky, de bron
@Lilienthal Ik ben niet nieuw op de werkplek, mijn beroepskeuze leent zich gewoon voor individueel werk (wat een van de redenen is waarom ik er zo dol op ben). Ik ben bij dit bedrijf geweest ~ 10 maanden en mijn collega is hier ~ 2 maanden geweest. Ik heb eerder met andere mensen gewerkt (bij andere bedrijven) maar er is altijd een zeer duidelijke scheiding geweest tussen 'mijn' werk en 'van hen'. Ik ben altijd achtergelaten om mijn eigen werk op mijn manier te doen. In dit geval is er meer overlapping van domeinen waardoor dit is toegestaan.
toegevoegd de auteur Boris Modylevsky, de bron
@RonJohn Ik begon het te begrijpen met: "Ik wil ook geen inferieure code gebruiken als ik weet dat er een beter presterende beschikbaar is. Ik wil dit opruimen" maar dat was niet super duidelijk.
toegevoegd de auteur Boris Modylevsky, de bron
@Brandin dus ik sprak met mijn collega en hij noemde eigenlijk iets dat ik had gemist, dus mijn idee was niet zo groot als ik dacht! Hé, daarom is hij aangenomen voor zijn baan en voor de mijne.
toegevoegd de auteur Boris Modylevsky, de bron
@RonJohn ook niet? Ik wil begrijpen (1) waarom mijn resultaten beter zijn en (2) een consensus bereiken over welke te gebruiken in het eindproduct. Ik heb niet het gevoel dat # 2 een gesprek is dat ik alleen kan of zou moeten voeren.
toegevoegd de auteur Boris Modylevsky, de bron
Bent u zeker is uw code beter? Kwaliteit omvat uiteenlopende dingen als prestaties, leesbaarheid en correctheid. Er zijn momenten waarop bubblesort het beste sorteeralgoritme is voor de taak, tenslotte ...
toegevoegd de auteur user32416, de bron
Ben je nieuw op de werkplek in het algemeen of alleen dit team? Of heb je eerder niet veel in een team gewerkt? Als je nieuw bent in dit alles (en je ervaring op papier is ook beperkt), kun je vragen om meer directe feedback over het navigeren omdat dit niet ongebruikelijk is. Maar ik denk dat we hier misschien van het onderwerp af gaan. Ik raad je aan De chat op de werkvloer te bekijken, omdat dit een goede plek zou kunnen zijn om te bespreken hoe je in deze context kunt werken en hoe je meer kunt verdienen vertrouwd/comfortabel om nauw samen te werken met mensen.
toegevoegd de auteur user25739, de bron
Heeft u de indruk dat u zorgvuldig rond deze collega moet gaan? Hoe ziet de teamdynamiek eruit? Ben je op hetzelfde niveau? Is hij senior?
toegevoegd de auteur user25739, de bron
Waarom moet u dit aan iemand noemen? Denkt uw baas dat de geweldige prestaties het gevolg zijn van de code van uw collega? Of wil je "gewoon" erkenning (wat redelijk is)?
toegevoegd de auteur Robert Sederholm, de bron
Stacey: "Ik wil begrijpen (1) waarom mijn resultaten beter waren en (2) een consensus bereiken over wat ik in het eindproduct moet gebruiken. " is niet wat ik van je vraag kreeg . Sorry.
toegevoegd de auteur Robert Sederholm, de bron
@ O.m. als je het een aantal keer laat doen, ongeacht hoe je het genereert, is de door Matlab gegenereerde code niet echt leesbaar: P: D
toegevoegd de auteur davidm_uk, de bron

5 antwoord

Ik raad aan om dit met je collega te bespreken, niet met je baas. Ook al denk je dat je code superieur is, het kan zijn dat je bepaalde specifieke details mist, of dat er situaties zijn waar je niet aan denkt (grotere afbeelding).

Wanneer u met uw collega praat, legt u de situatie uit: u gebruikte code als een snelle oplossing en het geeft verschillende resultaten dan de code van uw collega's. Vraag hem over dit verschil. Je zou graag met hem willen checken of je iets mist.

Ervan uitgaande dat uw collega een teamspeler is, zal hij dezelfde resultaten zien als u en hij zal u vertellen waar dit verschil vandaan komt en waarom zijn code beter is, of hij zal u vertellen dat u gelijk hebt en u kunt gebruiken jouw code. In beide situaties wordt je doel om de best mogelijke oplossing te krijgen bereikt en heb je en/of hij iets nieuws geleerd.

252
toegevoegd
Op deze manier kunnen jullie beiden leren van de ervaring - geen van beide is waarschijnlijk perfect, het combineren van delen van beide zal de dingen nog verder verbeteren. De toolcode kan in sommige gevallen problemen hebben, maar kan in de toekomst een goede basis zijn om vanaf te kunnen beginnen ..
toegevoegd de auteur Jam Ville, de bron
In de technische wereld noemen we dit een "code review" :) Je zou zelfs een betere derde optie kunnen vinden.
toegevoegd de auteur Colin Young, de bron
+1 voor die eerste alinea. Ik dacht ooit dat ik een aantal verbazingwekkende HTML-berichten had geschreven, maar alleen dat ik wist dat ik de toegankelijkheid voor de schermlezer in feite had vernietigd. Krijg altijd de volledige afbeelding.
toegevoegd de auteur wizurd, de bron

Of breng ik dit ter sprake met onze baas?

Nee, dat zou ik niet aanbevelen. Het is echt een klein probleem.

Hoe kan ik er met hem over praten?

Gewoon de feiten. U hebt een vergelijking gemaakt tussen uw code en zijn code en u kiest de betere oplossing tussen de twee.

Ervan uitgaande dat uw collega begrip heeft en er geen grote drukte van maakt, dan is er geen probleem. Tenzij van uw collega bekend is dat hij een slecht humeur heeft, moet u het probleem niet aannemen voordat u er een hebt.

Could you have done better? I'd say yes.

U had uw "tijdelijke oplossing" met uw collega kunnen delen. Op die manier kent hij het doel: zijn werk moet beter zijn dan het uwe.

Ik was niet van plan om zijn werk voor hem te doen.

Dat deed je niet. Je hebt per ongeluk een betere oplossing voor een probleem ontdekt. Dat is gebruikelijk, vooral in onderzoeksgerelateerde gebieden. We zeggen immers K eep I t S uitvoeren S tupid.

Les geleerd:

  1. You have discovered that in certain scenarios, the "quick & dirty" way (in this case, generating results in Matlab) is a better solution. Spending extra time and effort does not necessarily yield a better result.
  2. You can share temporarily fixes with others when they begin working on a better solution, which gives them a frame of reference about how their work quality.
56
toegevoegd
Of een WYSIWYG HTML-generator.
toegevoegd de auteur Codewerks, de bron
Met betrekking tot # 1 zou ik zo ver gaan om te zeggen dat het bijna nooit gebeurt. We zijn niet meer aan het assembleren, compilers doen over het algemeen een veel betere taak bij het optimaliseren dan een enkele persoon kan. Code gegenereerd met een geavanceerde tool zal bijna altijd superieur zijn dan wat je zelf kunt bedenken, simpelweg vanwege de geschiedenis die het heeft.
toegevoegd de auteur user77648, de bron
@FreeMan Ik las de eerste paar woorden en ging je tekeergaan over mijn gebruik van het woord "verfijnd", maar het lijkt erop dat je me daar had :) Ik geef toe dat de opmerking minder feitelijk kon zijn, neem het als een overdrijving als je wilt.
toegevoegd de auteur user77648, de bron
Ik ben geschokt dat er zoveel upvotes zijn, omdat dit antwoord volledig de mogelijkheid mist dat de OPs-code helemaal niet beter is. In feite maakte de follow-up van het OP duidelijk dat er iets was dat ze over het hoofd zagen met hun code, dus het is heel goed mogelijk dat het nemen van dit advies zou hebben geleid tot problemen op de weg.
toegevoegd de auteur ieXcept, de bron
Soms kan menselijke optimalisatie beter zijn als het iets fundamenteels is in het ontwerp in plaats van de daadwerkelijke stappen om daar te komen. D.W.Z. een heel ander algoritme op basis van dingen die een computer niet zou detecteren en die niet voor een onervaren persoon duidelijk zou zijn.
toegevoegd de auteur The Great Duck, de bron
@kevin - Ik was het grootste deel van mijn reactie voordat 'verfijnd' me echt uit de strijd gooide, dus het was bijna geldig!/OT
toegevoegd de auteur FreeMan, de bron
@kevin - u hebt natuurlijk nooit een macro opgenomen in een MS Office-product. De VBA-code die functioneel functioneert, is vreselijk in termen van efficiëntie, uitvoeringssnelheid en goede codeergewoonten. Oh, mijn slechte ... je zei "geavanceerde" tool!
toegevoegd de auteur FreeMan, de bron

Je hebt niets verkeerds gedaan.

Ik ben het er niet mee eens dat je op de een of andere manier verantwoordelijk bent voor het niet communiceren over je stub-implementatie. Stubs maken is standaard.

"Ik heb gemerkt dat uw implementatie en degene die ik gebruikte als tijdelijke maatregel overeenkomsten vertoont. Kunnen we een half uur duren en ze allebei controleren?"

Ervan uitgaande dat uw collega hiermee instemt, kunt u uw kwantificering bij u hebben, maar informeel presenteren, niet als een hamer. Al te vaak kan de uwe MAAR beter zijn, maar het alternatief heeft misschien betere stukken, en de beste oplossing maakt het combineren van het beste van twee oplossingen onmogelijk.

Uitpraten helpt niet alleen betere oplossingen te benaderen, maar helpt tegelijkertijd bij het vormen/definiëren van werkrelaties. Als hij erover spreekt, ben je op een goed pad. Als hij dat niet wil, dan heb je daar ook nuttige kennis ...

Als er geen vergadering in het midden is, controleer dan uw code op de zijne. Uw bewijslast is niet hoger dan die van hem, en als uw oplossing superieur is, is het beter voor het bedrijf. Net voordat je dat doet, spreek met het management over je plan om dat te doen, maar dat je niet naar hen op zoek bent om in te stappen, alleen om je toneelstuk te ondersteunen. Als het management het er niet mee eens is, is het goed om de inferieure implementatie goed te keuren, niet jij.

Goede medewerkers, of het nu implementators of managers zijn, zullen altijd beter werk herkennen en waarderen door open communicatie. Arme, nou, dat zal niet, en er is geen verandering in hen. Doe je best, elke keer, en de beste mensen houden je vast.

5
toegevoegd

Ik kan mijn collega de situatie laten zien en hem uitleggen wat je hebt gedaan. Ik zou van tevoren niet willen beweren dat je denkt dat je werk beter is, omdat dat hem misschien defensief maakt. Ik zou het als een leerervaring inlijsten: "Dit ziet er beter uit, maar ik zou graag willen weten waarom dit niet zo is", en laat hem zijn code verdedigen. Als hij dat niet kan, dan kun je zijn zegen ontvangen omdat je zijn werk niet zonder kwade gevoelens hebt gebruikt, en hij heeft misschien een aantal nieuwe technieken voor de toekomst geleerd, en als hij dat kan, dan heb je geleerd dat je eerste buikreactie waarop code is beter moet misschien wat worden opnieuw gekalibreerd.

4
toegevoegd

Hoe kan ik er met hem over praten?

- Hé Jim, ik heb een implementatie van X gegenereerd die sneller lijkt te werken (produceer nauwkeuriger resultaten, enzovoort, wat je ook bedoelt met "superieur") dan die van jou. Wil je het zien?

Dan kan uw collega de implementatie verbeteren op basis van uw input, of besluiten om de implementatie te bekrassen en door te gaan met de uwe. Of misschien willen ze je versie helemaal niet zien.

Wat de uitkomst ook is, ik raad u aan de implementatie te behouden die uw collega met zich meebrengt in het eindproduct. Ze hadden de opdracht om het te doen en zijn er verantwoordelijk voor. Als er later een fout wordt ontdekt in de implementatie die u zelf hebt verstrekt, bent u de enige schuldige.

1
toegevoegd