Nooit alleen maar een probleem

presenteren Ik nam een snelle blik op je profiel en merkte dat je een tijdje in de StackExchange-community bent geweest. U zult ongetwijfeld gemerkt hebben dat de vragen die hier het beste beantwoord worden, degene zijn die het probleem presenteren en de redenering die ze al hebben gevolgd in een poging om de vraag te beantwoorden.

Work life is precies zo. Als je een vraag stelt dan wil je zeker weten dat je hen ook laat weten wat je hebt gedaan om te proberen de vraag zelf al te beantwoorden. Dit komt je op een aantal manieren ten goede:

• Het laat zien dat je niet onnodig vraagt. Als je je redenering blootlegt dan laat je de persoon weten dat je een poging doet voordat je een vraag stelt en niet alleen maar lui bent.
• *Je krijgt waarschijnlijk feedback die je denkprocessen ten goede komt. * Als een collega naar mij toekomt met een probleem en blootlegt hoe ze geprobeerd hebben een vraag te beantwoorden, zal dat niet alleen helpen om hen op het juiste pad te begeleiden, maar zal ik hen ook helpen om te begrijpen hoe ze zelf over de vraag hadden kunnen nadenken om er te komen. Hoe meer je je denkproces en redenering blootlegt, hoe meer andere mensen je kunnen helpen om op hen te bouwen voor toekomstige problemen.

Er zijn een paar punten om uit te pakken.

Ik nam aan dat iedereen bij een technisch bedrijf graag over technologie praatte…

Niet noodzakelijkerwijs. Veel technische mensen zullen praten over technologie die relevant is voor de taak die ze nu doen, maar misschien hebben ze geen interesse in iets anders.

Ik denk dat je misschien verward raakt tussen dit en:

Ik werd ook uitgescholden voor “de verkeerde weg gaan” wanneer ik probeerde een probleem op te lossen waar ik niet bekend mee was in plaats van iemand te vragen die

was Beschouw de jongen die wolf huilde :) Als je de tijd van iemand anders besteedt aan het praten over dingen die niet relevant zijn voor wat ze doen, dan kan het zijn dat als je ze een relevante vraag stelt, ze het gevoel hebben dat ze al genoeg productiviteit bij je kwijt zijn.

Ik probeer zo'n beetje altijd zelf problemen op te lossen voor minstens een uur. Is dit te kort?

In veel gevallen, ja, is het te kort. Tenzij het probleem dat je probeert op te lossen eenvoudig is, dan zou je meer tijd moeten investeren in het zoeken naar en proberen van verschillende permutaties. Als het probleem is eenvoudig, dan moet een passende web search de juiste resultaten opleveren.

Zet dit alles bij elkaar, en wat ik zie is een jonge programmeur die wat problemen heeft met oordeelsvorming, dat is wat uw HR persoon u heeft verteld. Het is niet onoverkomelijk, maar er zijn een aantal dingen waar je over na moet denken.

• Bespaar hypothetische technische vragen voor de lunchroom. Het is niet gepast tenzij je de mensen goed kent om zowel jouw als andermans tijd te verspillen aan irrelevante vragen.
• Leer hoe u betere zoektermen op het web kunt toepassen. Als u wordt verteld dat u te veel vragen stelt en te veel tijd neemt om te vragen, dan stelt u duidelijk de verkeerde vragen.
• Als u een vraag stelt, laat dan zien wat u hebt geprobeerd. Klassieke Stack Overflow-mentaliteit. Als u niets heeft om te laten zien als een gezamenlijke inspanning om een probleem op te lossen, dan hebt u niet hard genoeg geprobeerd. Wees in feite niet bang om middelen te gebruiken _ zoals_ Stack Overflow als er iets tastbaars te vragen is dat in het publieke domein kan liggen. En tot slot;
• Bespaar vragen voor bedrijfsspecifieke vragen. Vraag niet hoe u uw programmeertool moet aansturen, maar do vraag naar domein- of milieuspecifieke zaken die niet in het publieke domein zullen liggen.

Er zijn hier veel dingen die u kunt doen om te verbeteren. Het kan zijn dat de PIP een zeer waardevol hulpmiddel is om u te helpen een betere ontwikkelaar te worden :)

Het probleem is dat wanneer je iemands werk onderbreekt, hij niet alleen de 5-15 minuten verliest die hij nodig heeft om te antwoorden. Ze verliezen veel meer tijd, omdat ze zich weer moeten concentreren. En dat kan behoorlijk frustrerend zijn.

Ik zat in een situatie zoals die van jou. Ik ging vroeger naar mensen toe en stelde ze meteen vragen. Zelfs als ze iets deden dat me zou blokkeren. Dat kan zelfs andere mensen in de buurt hebben onderbroken.

Mijn manager gaf een oplossing: gebruik e-mail en instant messaging, zelfs als de persoon naast je zit. Op die manier denk je meer na over hoe je de vraag kunt formuleren, en tijdens dat proces mag je zelf antwoorden. Ook kan de andere kant je antwoord geven als ze wat vrije tijd hebben.

Een andere optie is om een vergadering in te stellen, waar alle zaken worden opgehelderd.

Ik ga proberen te antwoorden vanuit het perspectief van het bedrijf. Ik ben niet dat bedrijf, dus er kunnen dingen zijn die ik niet zie, maar ik heb dit eerder gezien bij mijn eigen bedrijf.

Te veel vragen

De meeste van uw verwarring lijkt te komen van het feit dat u niet begreep dat het stellen van vragen een gevaarlijk spel is. Het is!!!

Als je een vraag stelt, geef je toe dat je niets weet, en dat je er niet uit kunt komen. Als softwareontwikkelaar is het één van je taken om het uit te zoeken. Je beledigt het “huidige” ontwikkelteam door te vragen: “Dus je hebt hier zo'n onzinnige code geschreven dat ik er niet achter kan komen hoe het te lezen of wat het doet, dus ik ga je nodig hebben om het me uit te leggen.”

Nu het lastige deel hier, is dat dat soms precies het geval is en dat je vragen zou moeten stellen. Het is gewoon belangrijk om te onthouden dat, wat er ook gebeurt, er een negatieve kant aan die vragen zit.

Een ander ding dat ik denk dat ik voel in je OP is dat je veel te vroeg vragen stelt. Het is absoluut prima voor een nieuwe ontwikkelaar om daar een hele dag te zitten lezen, en onderzoek te doen, om 2 regels code te schrijven. In feite, met 14 jaar ervaring, doe ik dat nog steeds. Het schrijven van professionele code gaat niet over “hoeveel” gedaan wordt, maar over “hoe goed” het gedaan wordt, en het kunnen herhalen van dat succes. Ik betwijfel of iemand je zal aanklagen omdat het 100 keer langer duurt om een tiende van het werk als getrainde en gevestigde ontwikkelaar te doen. In feite, als ik iemand aanneem, schrijf ik de eerste maand af als niet echt werk te verwachten, en de eerste zes maanden als niet veel te verwachten.

Niet genoeg tijd besteden aan je eigen

Dit is een biggie!!! Als je een teamlid om hulp vraagt, trek je ook de productiviteit van die persoon omlaag. Je beïnvloedt hun proces en beledigt ze tegelijkertijd (zie boven). Er is geen manier voor u om te winnen, als u om hulp moet vragen. Denk aan elke vraag, als een verloren strijd. Je kunt nog steeds de oorlog winnen, maar je hebt deze strijd verloren.

Er zijn een aantal dingen die je kunt doen om het probleem te verzachten:

1. Vraag het in e-mail, nooit in persoon of chat. Chat is misschien de beste manier om het “officieel” te doen, maar email is leuker omdat de ontvanger het in zijn eigen tijd kan afhandelen.
2. 2. Benader het vanuit een “lagere” houding. Jij bent hier de bedrieger. Doe wat kruipen. Het is oké. Een klein beetje zal je geen pijn doen en zal de ontvanger laten zien dat je wel om hun tijd geeft, dus “Ik weet dat je het erg druk hebt, maar ik kan er niet achter komen hoe je met je API kunt integreren. Als je een paar momenten hebt, kun je me dan laten zien wat ik mis?” Het laat zien dat je het mis hebt, niet met hen. Het is belangrijk.
3. Maak een lijst van de stappen die je in je eentje hebt genomen. “Het API-document zegt dat je in een String die het id van de gebruiker weergeeft. Ik heb geprobeerd de user.id eigenschap en de gebruikersnaam door te geven, maar geen van beide werkte.” Dit laat zien dat je tenminste iets hebt geprobeerd, en dat je in het algemeen het product begint te “krijgen”.

Beter oordeel Bij het stellen van vragen

Dit klinkt voor mij alsof je tegen iemand “zeurde”, en ze hadden geen leuke manier om te zeggen, “Je verveelt iedereen met je kreupele vragen. Hou op. Met andere woorden, ik denk dat dit geen probleem is. Als je eenmaal je andere zaken hebt gecorrigeerd, zal dit weggaan.

Bad Documentatie

Ahem! Dat is weer een persoonlijke belediging. Zeg dat nooit. EENDER WAAR!!!!! Nogmaals, je zegt dat de kwaliteit van hun code zo slecht is dat je er niet achter kunt komen. Hun antwoord zal altijd zijn "werkt voor iedereen, dus jij moet de idioot zijn, niet ik!”

Ook is dit een beetje “welkom in de echte wereld”. In de echte wereld betalen klanten voor werkende applicaties en niet voor code of documentatie (meestal), dus het is heel gebruikelijk dat documentatie in de loop van de tijd afneemt.

Als je denkt dat documentatie slecht is en aangepakt moet worden, breng dat dan rustig ter sprake, met je teamleider. Laat hen maar beslissen.

Ik zeg dit wel. Hoe slecht de documentatie ook is, met de broncode recht voor je zou je het niet nodig moeten hebben. Het is echt leuk om te hebben, begrijp me niet verkeerd, maar je kan zonder werken.

Being Late

Uiteraard, wees niet te laat. Dat is een no brainer. In feite, in jouw situatie nu, wees 30 minuten te vroeg!! Geen excuses. Je verpest elke hoop op het vinden van je volgende baan met deze. Als ik de HR-afdeling daar belde en vroeg naar je aanwezigheid, en ze zeiden “Hij was vaak te laat” of “Hij werd opgeschreven omdat hij te laat was” dat is een instant rode vlag. Ik noem dit, want of je nu deze baan houdt of een nieuwe krijgt, dit meer dan iets anders zal je ervan weerhouden om die volgende baan te krijgen.

Lage kwaliteit Code

Dit is waarschijnlijk waar. Gezien het probleem met de vraag, ben je waarschijnlijk geen goede code aan het schrijven. Je bent echter nieuw, en dat is te verwachten. Ik vind dat de hogescholen niets leren over echte wereldcodering. Ik heb nog nooit iemand rechtstreeks van de universiteit ingehuurd en een “goede ontwikkelaar” gekregen. Dat betekent niet dat ze geen goede ontwikkelaars zijn. Ze beginnen gewoon niet op die manier. Goede code schrijven betekent op de hoogte blijven van de laatste trends en technieken. Je bent constant aan het leren. Het moment dat je stopt is het moment dat je begint te zuigen.

Tot slot

Deze post is ruw geweest, maar ik wilde duidelijk laten zien wat de houding van een bedrijf kan zijn. Vaak verpakken ze (bedrijven) hun opmerkingen in zoveel “managerspraatjes” dat het misschien moeilijk te begrijpen is. Ik heb geprobeerd om de managerspraatjes in deze post zo veel mogelijk te reduceren, maar dat betekent dat het een beetje ruw is.

Je belangrijkste stappen om je falende carrière op te knappen:

1. 1. KOM VROEG NAAR JE WERK!!!! (Ik kan dat niet genoeg benadrukken)
2. 2. Stel vragen met een geestesgesteldheid dat je de persoon die je vraagt al beledigd hebt. Laat je werk zien. 4. Geef bij het stellen van een vraag duidelijk aan wat je al gedaan hebt.
3. 4. Besteed meer tijd aan het leren in je eentje. Het is belangrijk om veel meer tijd te besteden aan het onderzoeken van dingen dan aan het vragen van dingen. Eerlijk gezegd 3-4 dagen iets opzoeken in je eentje, zal meer gerespecteerd worden dan een vraag van 30 seconden.

Ik wilde hier een schepje bovenop doen vanuit het oogpunt van management.

Een PIP is een veelomvattend iets

Het is zeer waarschijnlijk dat de prestatieverbetering een verzameling is van de dingen die je management heeft benadrukt, allemaal samen gedaan. Ik vermoed dat als je de persoon was die veel en veel vragen stelde, maar vroeg kwam, laat bleef en goed werk leverde bij het schrijven van code, het team de vraagstelling als een persoonlijke gril zou behandelen, of dat je uitzonderlijk grondig bent.

Maar als het team moet helpen meer bugs in je code te vinden en te repareren, na het beantwoorden van meer dan de gebruikelijke hoeveelheid vragen, en ze zien dat je minder uren werkt of te laat komt opdagen zonder voorafgaande kennisgeving, zullen het team en de manager het gevoel hebben dat je niet bijdraagt aan het niveau dat je moet zijn, en dat je geen extra tijd inbrengt om op de hoogte te komen. De vraagstelling kwam waarschijnlijk naar voren in het licht van de andere problemen, want als je probeert de kwaliteit van de code te verbeteren door MEER vragen te stellen, zal het team dit niet volhouden.

Elk uur telt

Een nieuwe college grad IS een investering in teamtijd. Elke manager die je anders vertelt heeft nooit een nieuwe college grad aangenomen, of liegt, of heeft echt uitzonderlijke teamleiders die voor hem/haar werken. Elke nieuwe aanwerving is sommige investering, maar college grads zijn MEER tijd. Meestal is de afweging de moeite waard, hoewel - maar wees ervan bewust dat college grads do meer vragen stellen dan meer doorgewinterde ontwikkelaars.

Echter - elk uur telt. Een team van ontwikkelaars krijgt meer gedaan in een bepaalde week als iedereen op de hoogte is, de code kent en niet veel vragen stelt. Ook zal een team in deze gegeleerde staat in staat zijn om zeer snel vragen te stellen en te beantwoorden - wat ook de productiviteit versnelt.

Het beantwoorden van vragen doet tijd in beslag nemen. En elke keer als een ontwikkelaar stopt met het schrijven van code en begint met het beantwoorden van vragen, is er een contextschakelaar. Dus zeer interrupt gedreven vragen beantwoorden is veel meer een productiviteitskiller dan een uurtje zitten en een verzameling vragen beantwoorden.

Ik zou veilig zijn met het argument dat elke context switch 1 uur kost, dus zelfs als je een 5 minuten durende vraag hebt, heb je het team een uur gekost als iemand stopt om je vraag te beantwoorden. Dat betekent dat het 1 uur duren en het niet krijgen, dan kost het vragen om hulp eigenlijk meer tijd dan het nemen van 2-4 uur.

Er is niet zoiets als “het zal de andere man slechts 5 minuten kosten om mij een uur te besparen”. Gezien de metriek van minstens een uur per onderbreking, kan de andere man je beter 2-4 uur besparen.

Tips voor het stellen van vragen Goed:

• Begrijp en stel vragen in overeenstemming met de urgentie - als je absoluut een probleem in een uur moet hebben opgelost, dan is het een goed idee om bijna iedereen die je kan helpen te onderbreken. Als je een deadline van 3 weken hebt gekregen, dan is het een beter idee om minder te onderbreken en je eigen problemen meer op te lossen. Dit betekent dat mensen in een noodsituatie vaak veel vragen stellen die ze anders zelf zouden onderzoeken. Omdat het absoluut noodzakelijk is om het antwoord zo snel mogelijk te hebben.
• Gebruik de vragenforums voor hun gedefinieerde doel, of intuïtief het doel van bestaande vragen/antwoorden. Stack Exchanges, bijvoorbeeld, hebben een vrij uitgebreide set van basisregels die vrij goed gedocumenteerd zijn, en een bepaalde verwachting dat gebruikers voorafgaand aan het vragen naar eerdere antwoorden zoeken. Een ander forum kan herhaalde vragen verwachten, maar alleen over een zeer smal gebied.
• Onderzoek uw vraag. Verwacht dat het schrijven van een goede vraag evenveel tijd kan kosten als het geven van een antwoord - in veel gevallen beschrijf je (tersely!) de stappen die je op het punt hebben gebracht dat je het probleem niet meer kunt beantwoorden. Ook documenteer je waarschijnlijk alle symptomen van het probleem.
• Richt je vragen - zoek uit wie daadwerkelijk vragen kan beantwoorden als dat mogelijk is in plaats van iedereen te vragen. Niet elke vraag is een discussie waard.
• Verzamel een grote stapel vragen - vooral als je nieuw bent, neem dan een dag de tijd om het probleem en de code te bekijken. Verzamel uw vragen in een lijst met opsommingstekens met onderwerpen die samengevoegd zijn. Vraag dan aan een mentor of maatje waar hij/zij terecht kan om hulp te krijgen. Het is zeer waarschijnlijk dat de meeste vragen in uur #1 worden beantwoord per uur #6. Vragen die in uur #1-2 kwamen en niet per uur #8 konden worden beantwoord staan waarschijnlijk bovenaan je lijst omdat je weet dat je er in 8 uur niet uitkwam.
• Code is niet “zelfdocumenterend” maar een heleboel informatie kan worden geleerd door het te lezen. Ik heb veel ongedocumenteerde systemen geleerd door met een notitieboekje te zitten en mijn versie van het ontwerp te tekenen. Als je niet meerdere niveaus boven en meerdere niveaus onder het gebied waarin je werkt hebt gelezen en je hebt de docu’s van externe API’s die je gebruikt niet goed genoeg onderzocht.
• Als je probeert een antwoord te vinden, gaat het een heel eind als je kunt mogelijkheden te suggereren, in plaats van het antwoord te vragen. “Zou dit de juiste manier zijn om het te doen?” is beter dan “Hoe doe ik het?” - zelfs als het antwoord is “je doet het helemaal verkeerd” - kun je nog steeds vragen “waarom is mijn manier verkeerd?” en de meer meta “hoe zou ik leren om het goed te doen herhaaldelijk”? Dit is de “leer een man om te vissen” benadering - leer hoe je moet vissen, stel geen vragen die je maar 1 vis opleveren.
• Vermijd vragen die slechts een beleefde manier zijn om het oneens te zijn. Er is een lijn tussen “is mijn manier om dit te doen werkbaar?” versus “Ik begrijp niet (d.w.z. ben het eens met) waarom je het op jouw manier deed?” Dat zijn mooie gesprekken, maar ze kunnen beter informeel gevoerd worden nadat je mensen hebt leren kennen.
• Gematigde vragen - dit zijn meestal de “waarom” vragen. Nieuwe mensen hebben het recht om veel “waar” & “wie” vragen te stellen (waar is de docs, waar is het proces hiervoor, waar is de plaats in de code waar ik misschien naar wil kijken? wie kan dit beantwoorden? wie nodig ik uit voor de recensie?) en een aantal “hoe” vragen - is dit hoe ik het moet benaderen? hoe kan ik uw goedkeuring krijgen? Maar “waarom” zoals in “waarom hebben we het zo opgebouwd?”, “waarom documenteren we de code niet meer?”, “waarom is dit geen prioriteit?” - ze zijn legitiem, maar totdat je meer ervaring hebt met het werk en de zaak, zijn het niet de meest noodzakelijke vragen. Ze kunnen GROOT zijn voor een 1 op 1 met je baas waar je geen andere dringende problemen hebt, maar als het “waarom” de waar, wie en hoe dan je niet gericht bent op je werk.

In precies dezelfde situatie.

Probleem

Wat je beschrijft is het probleem waar de meeste pas afgestudeerden mee te maken hebben. De meeste universiteiten leren je alleen basiskennis of concepten, terwijl je in de praktijk veel meer nodig hebt.

De meeste bedrijven die pas afgestudeerden in dienst nemen, hebben een opleidingsplan dat je, als je het volgt, binnen een jaar of zo moet kunnen uitvoeren. Maar sommige mensen worden wel nieuwsgierig, als je ze een eenvoudige taak geeft om een klein onderdeel in een systeem te repareren, krijgen ze die pas als ze het hele systeem onder de knie hebben en ik geloof dat jij daar een van bent…

Ik denk dat je vragen stelt omdat,

• Je voelt dat je meer dan redelijke tijd nodig hebt om een taak te voltooien, omdat je een deel van het systeem niet begrijpt.

• Je bent gewoon nieuwsgierig om het systeem volledig te begrijpen

• Je bedrijf heeft je niet de juiste training gegeven

Oplossing

Als mijn veronderstellingen juist zijn, stop dan met vragen stellen, tenzij je moet (punt - op dit moment)

• Begin meer tijd te besteden aan het begrijpen van het systeem (niet slechts 8 uur)

• Gebruik in plaats daarvan SO of andere gerelateerde sites (na het doen van uw onderzoek gedeelte)

• Vraag uw bedrijf om u goed te trainen @gebieden waar u hulp bij nodig heeft.

heb ik hierboven gevolgd en werk nu na 5 jaar in hetzelfde bedrijf en ik kan beweren dat ik meer weet dan wie dan ook hier.

Er zijn hier al genoeg antwoorden, maar ik wil een paar specifieke onderdelen van uw vraag behandelen.

Hoewel ik ook werd uitgescholden dat ik niet genoeg tijd besteed aan het zelf uitzoeken van de dingen voordat ik anderen om hulp vraag. Dit is echter niet waar, en ** mijn manager zou nu niet weten hoe lang het duurt vanaf het moment dat ik een probleem heb tot het moment dat ik iemand om hulp vraag**. Ik probeer zo'n beetje altijd een uur lang alleen problemen op te lossen.

Is dit te kort? Wat is een redelijke hoeveelheid tijd om aan een probleem te besteden voordat je het aan een collega vraagt die het antwoord weet?

Nadruk toegevoegd is van mij.

Om te beginnen, ja, een uur is waarschijnlijk te kort van de tijd. Ik zeg waarschijnlijk wel… het hangt echt af van het probleem. En het hebben van een tijdslimiet is goed, maar je moet meer vertrouwen op indicatoren dat je aan een muur zit dan alleen een tijdslimiet. Maar belangrijk is dat als je klaar bent om vragen te stellen, de ontvanger van je vragen in staat moet zijn om het onderzoek dat je hebt gedaan naar je probleem te zien door het soort vraag dat je stelt.

En dan komen we bij het gewaagde deel van de offerte. Je hebt technisch gezien gelijk. Niemand, maar je kunt wel precies weten hoeveel tijd je in een probleem hebt gestoken voordat je om hulp vraagt.

Maar op basis van welke vraag je stelt, welke informatie je bij de vraag geeft, de context van de vraag, en hoe gemakkelijk ik het antwoord kan vinden met een eenvoudige Google-zoekopdracht, kan ik vrij goed inschatten hoeveel moeite je hebt gedaan om het probleem zelf op te lossen.

Als je een vraag stelt, en de eerste Google-zoekopdracht die ik probeer levert jouw oplossing op als het nummer één resultaat, dan is dat in principe twee strikes voor jou. Het maakt niet uit of je 10 minuten of 10 maanden aan het probleem hebt gewerkt. Je had die pagina al moeten bestuderen en het heeft of je probleem opgelost, of je vertelt me over deze pagina en waarom het je probleem niet heeft opgelost.

Maar bovendien, wat voor soort vragen stel je dan? Vraagt u om een volledige oplossing? Of vraag je om een duwtje in de goede richting? Soms is de muur waar je voor staat dat je je totaal niet bewust bent van een of andere bibliotheek of een bestaand deel van de codebasis die het oplossen van je probleem eenvoudig zal maken.

Ik zou zeggen dat je hebt geleerd over wat dit bedrijf verwacht door de school van harde klappen. Vragen op deze plaats zijn een no-no.

Ik denk dat je belangrijkste probleem zichtbaarheid is. Vragen stellen over slapte is iets wat veel mensen kunnen zien; zelfs als ze zich niet gedwongen voelen om te antwoorden, kan dat nog steeds invloed hebben op hun oordeel over jou. Als je ondertussen een dag doorbrengt met het uitzoeken van een enkele functie op je bureau, ziet niemand dat wiel draaien. U verschijnt iets verkeerd te doen, in plaats van alleen maar op de sleutels van uw bureau te slaan, wat lijkt op werk. Tuurlijk, misschien in wekelijkse, maandelijkse of jaarlijkse beoordelingen zal uw productiviteit slecht tot uiting komen. Maar je slappe vragen worden meerdere malen per dag gezien, terwijl je werkelijke productiviteit veel minder vaak wordt gemeten.

Ik was in een positie zoals de jouwe. Ik werd ingehuurd om bugs te repareren in een propriety CMS terwijl de lead (lees: alleen) ontwikkelaar als een gek door elkaar ging om functies voor klanten toe te voegen. We hadden een grote achterstand. De codebase was niet in versiebeheer, en elke kant had zijn eigen op maat gemaakte versie. Het was een complete puinhoop.

Naief, ik dacht dat het beter was om 10, 20 of 30 minuten van de mijne en de lead’s tijd te chatten zodat hij dingen aan mij kon uitleggen, in plaats van een halve dag, een hele dag, of zelfs enkele dagen te besteden aan reverse-engineering van een functie om erachter te komen 1. wat er moest gebeuren, 2. hoe het moest werken, en 3. hoe de bug te repareren.

Blijkt, toen mijn baas (een van de twee partners) dit te weten kwam, dat het me slecht uitkwam dat ik niet in staat was om de code zelf op te lossen, en dat ik de tijd van onze kostbare hoofdontwikkelaar nam. (De hoofdontwikkelaar leek het leuk te vinden om te praten over hoe zijn codebase werkte– hij klaagde er in ieder geval niet over bij mijn baas, zoals hij me vertelde). Dus, ik stopte met vragen stellen, en mijn productiviteit daalde waarschijnlijk tot 10% van wat het was. Ik werd ongeveer een maand later losgelaten.

Hoe dan ook, dit bedrijf vertelt je, op een slechte manier, dat ze geen waarde hechten aan deze tijdsefficiëntie en documentatie neveneffect. Dus doe het niet.

Breng een dag door met het uitzoeken van iets. Breng een paar dagen door… een week! Wie kan het wat schelen? Niet dit bedrijf. Wat je ook doet, stel geen vragen, want dat is iets waar ze zich do zorgen over maken. Of het nu het management is, of je collega’s die klagen, het maakt niet uit. Het bedrijf heeft je verteld wat voor soort cultuur het kweekt.

Dus als je nadenkt over je situatie, met traagheid en slechte kwaliteit code, zou het laten vallen van de productiviteit wel eens te veel kunnen zijn. In plaats van te wachten tot de bijl valt, zou je misschien op zoek moeten gaan naar een plek die beter bij jou en je stijl past. Een plek die misschien wat code commentaar en documentatie heeft, om te beginnen.

Dus hoe is mijn verhaal terecht gekomen? Na een periode van werkloosheid kreeg ik een nieuwe baan. Behalve dat de codebase veel beter is (we gebruiken een standaard CMS, we hebben versiebeheer, we hebben dev, staging en prod-omgevingen, etc), zijn mijn collega’s uitstekend en stimuleert mijn bedrijf het leren. We hebben een wiki, waar we onze informatie delen en voorkomen dat we wielen opnieuw uitvinden. We chatten de hele dag op slappe, praten over werk, stellen vragen, brainstormen, delen nieuws, info en ontdekkingen. We starten projecten om onze processen te verbeteren, zoals agile, vagrant en het implementeren van continue integratie. We leren elkaar en leren van elkaar. We gedragen ons als collega’s en medewerkers; niet als concurrenten. We hebben een on-boarding en oriëntatie voor nieuwe medewerkers en aannemers, die we zonder deze cultuur niet zouden kunnen hebben. Dat is een goede zaak, want in de tijd dat ik hier ben, zijn we gegroeid van twee (ikzelf inbegrepen) naar acht, en ook contractanten in drukke tijden.

Ons bedrijf stuurt ons op trainingen, conferenties, en stimuleert het nemen van tijd voor web-based lessen en casts. Ik heb hier in deze tijd meer geleerd dan in welke andere periode van mijn carrière dan ook, met name in onderwerpen waar ik niet specifiek in werk. Het is prachtig; ik ben hier al 4,5 jaar, en zie niet veel reden om weg te gaan, behalve om een nieuwe technologie te leren. De cultuur op mijn nieuwe plek is echt gericht op het leren, begrijpen en implementeren van best practices, wat leidt tot productiviteit. Het is een win-win.

Serieus, er zijn betere plekken om voor te werken. Dit is niet de plek voor jou, en jij bent niet de persoon voor hen.

Als je niet-werkgerelateerde vragen stelt, dan kan het beschouwd worden als een luizige chit-chat, wat in de ogen van je bazen een slechte zaak is, dus stop ermee.

Echter, het stellen van werkgerelateerde vragen is een goede zaak, omdat het laat zien dat je geïnteresseerd bent in je werk en jezelf wilt verbeteren.

Als je beschuldigd wordt van het verspillen van andermans tijd, dan stel ik voor dat ze hun tijd beter beheren en je vertellen dat ze het druk hebben in plaats van vragen te beantwoorden wanneer ze andere dingen zouden moeten doen. Echter, een beter antwoord zou zijn om te vragen of ze tijd hebben om een vraag te beantwoorden voordat je die vraag stelt.

Klinkt voor mij alsof je baas een beetje dom is, of dat hij gewoon van je af wil om wat voor reden dan ook. Ze gaan falen omdat ze de dingen niet documenteren, wat een recept is voor een ramp als hun hoofdontwikkelaar(s) weggaan, er zijn geweest, het gedaan hebben.

Soorten werkvragen:

1. Hoe doe ik iets wat ik moet leren om het werk te doen.

2. 1. Hoe doe ik iets wat ik moet leren om het werk te doen, maar het is me al verteld.
3. 1. Hoe doe ik iets dat ik al zou moeten weten.

4. Hoe doe ik iets dat niet op het doel af is, en ik weet dat het niet op het doel af is.

5. Hoe doe ik iets dat niet op het doel af is, en ik weet niet dat het niet op het doel af is.

6. Hoe doe ik iets dat niet op het doel af is. Grappige vragen en praatjes.

Dus…

Je kunt zoveel #1’s vragen als je wilt. Ze denken misschien dat je vervelend bent, maar het is een goed/slimme vervelende. Je zou hier niet voor opgeschreven worden.

Als je #2s vraagt dan denken ze dat je een begrijpend probleem hebt. Of je stelt gewoon graag vragen maar luistert niet. Dit wordt tot op zekere hoogte opgevangen en wordt snel oud.

Afhankelijk van je positie en wat voor rare dingen je in het team #3s brengt kan het goed zijn - je kent een specifiek gebied goed, je bent goedkoop, wat dan ook. Je kunt echter beter niet #2s vragen nadat je een #3.

vraagt Er is geen twijfel over mogelijk dat de #4s niet goed zijn. Je kunt wegkomen door een aantal van deze te vragen, maar niet als nieuwe werknemer. Medewerkers zouden verwachten dat je #1s (en sommige #2s) vraagt voordat je aan #4s denkt. Als je veel van #4s vraagt, denken ze dat je er helemaal klaar voor bent.

Dit is het ergste. Alleen al het vragen van een paar #5’s kan je afschrikken voor elk teamlid. Het betekent dat je het niet krijgt en waarschijnlijk niet de aanleg hebt om het te krijgen.

Hmmm… #6s zijn afhankelijk van de persoon. Veel mensen kunnen tonnen #6s vragen of ze vermakelijk of grappig zijn. Aan de andere kant, als je niet #6s bent, kan het echt slecht zijn, vooral als je #2-5s vraagt.

Als je bij jezelf denkt waarom kunnen ze niet gewoon aardig tegen me zijn en me helpen als ik problemen heb en de hele tijd #2-5s vraag. Omdat ze iemand anders kunnen inhuren die meer weet en geen domme vragen stelt. Als ik jou was zou ik meer gaan opletten, misschien zelfs wel altijd een notitieblok bij je dragen, en als iemand iets beantwoordt zorg je ervoor dat je 100% zeker bent dat je het krijgt of vraag je ter plekke om opheldering.

Dit antwoord gaat over het nemen van feedback (de andere antwoorden gaan al heel goed over het stellen van vragen).

Hoewel ik ook werd uitgescholden voor “het verkeerde pad inslaan” bij het proberen op te lossen van een probleem waar ik niet bekend mee was in plaats van het te vragen aan iemand die dat wel was. Toen ik vroeg naar de tegenstrijdigheid, zeiden mijn manager en HR dat ik gewoon beter moest inschatten wanneer ik vragen moest stellen. Ik heb me nooit gerealiseerd dat het stellen van vragen zo gevaarlijk kan zijn.

Dat was een slechte reactie van uw kant. Stel jezelf even voor in hun plaats. Je weet dat een werknemer slecht presteert, en je vertelt hen wat ze moeten verbeteren. Zonder de moeite te nemen om na te denken over wat je hen vertelt, zonder enige interesse te tonen in je feedback, laat staan je te verontschuldigen voor het feit dat je niet aan de verwachtingen voldoet, beweert die werknemer ten onrechte dat je jezelf tegenspreekt.

Wanneer je feedback ontvangt, in het bijzonder als die negatief is, moet je eerst luisteren, dan proberen te begrijpen (verduidelijkende vragen stellen als dat nodig is), en alleen dan antwoorden.

Dat komt omdat, tenzij je het opzettelijk verknald hebt, jij en je baas het niet eens zijn over de vraag of je het verknald hebt. Of je baas heeft het mis, of jij bent het (of jullie beiden). Je zou de mogelijkheid moeten overwegen dat jij het bent, want het is zeer onwaarschijnlijk dat je baas het helemaal mis heeft, en jij hebt helemaal gelijk - en zelfs als je dat bent, kun je je baas alleen maar overtuigen dat hij het mis heeft door hem te laten zien waar hij het mis heeft, en dat vereist ook dat je naar hem luistert.

Je zou ook advies kunnen vragen over hoe je het beter zou kunnen doen.

Bijvoorbeeld, nadat je hebt gehoord dat je zowel te veel als te weinig vragen stelt, heb je misschien gevraagd:

Dus ik heb beide onnodige vragen gesteld en heb de nodige vragen niet gesteld. Hoe moet ik bepalen welke vragen nodig zijn? Dat wil zeggen, wat voor soort vragen zou ik meer moeten stellen, en wat voor soort vragen zou ik minder moeten stellen?

De volgende feitelijke discussie zou waarschijnlijk hebben laten zien wat u moet doen om te verbeteren.

Is dit gebruikelijk? Is het niet de bedoeling dat de nieuwe persoon bij een bedrijf nieuwsgierig is of vragen stelt die niet direct verband houden met zijn of haar werk?

In hoeverre het stellen van vragen wordt verwacht of gewenst verschilt per werkplek. Misschien wilt u zich aanpassen aan de cultuur van uw werkplek, die u kunt ontdekken door uw collega’s te observeren, kennis te nemen van de manier waarop mensen op uw handelingen reageren (irriteren ze zich aan uw vragen, of zijn ze er blij mee?), of ze vragen om hun feedback (“Mag ik dat wel vragen?”).

Ik denk dat als je jong bent zoals ik je mentaliteit is om tijd te besparen en het antwoord te vinden en dan door te gaan naar het volgende probleem. Maar bij de oudere generaties vind ik dat geen zorg of prioriteit voor hen. Dus ja, het duurt een uur om een probleem op te lossen is te kort voor iemand die ouder is, maar het lijkt je misschien te lang. Ik stel voor om de generatiekloof te observeren en het voorbeeld te volgen, zelfs als je het er niet mee eens bent. Uiteindelijk zul je met meer ervaring sneller in het oplossen van problemen komen.

Wat betreft het in de problemen komen voor het stellen van vragen probeer ik de uitleg te gebruiken van ik wil zien hoe het moet, of ga naar bedrijfsnormen. Ook bij oudere generaties heb ik gemerkt dat dit om een of andere reden irritant is. Ik denk dat oudere mensen denken dat ik dit zelf heb opgelost en dat ik geen hulp heb gekregen, zodat ze minder bereid zijn om te helpen. Ze voelen zich ook onderbroken. Zoals iemand die hierboven genoemd is, probeert het juiste moment te vinden om hulp te vragen, terwijl hij het ego streelt, IE “Ik heb gehoord dat jij de man bent waar je naartoe moet gaan over dit….” “Iemand zei dat jij de expert bent op….” Hopelijk zal dat hen een onderbreking doen vergeten en zullen ze meer bereid zijn om te helpen omdat je hen iets te bewijzen hebt gegeven. Wees voorzichtig met dat laatste advies, want ik weet zeker dat het in sommige gevallen een averechtse uitwerking kan hebben.

Ik vind het moeilijk om precies te definiëren, maar ik heb met een aantal junior devs gewerkt, en sommigen van hen stelden vragen die zeer bevredigend waren om te beantwoorden, en sommigen van hen deden dat niet. Het beantwoorden van je vragen leidt je collega’s af van hun werk, en dat is oké, als er iets goeds van komt en het bedrijf er op de lange termijn van profiteert. Dat betekent dat je de juiste persoon moet vragen, de juiste vraag moet stellen en naar een plek moet gaan waar je inzicht hebt gekregen waardoor je aanzienlijke vooruitgang kunt boeken. Als je daar een talent voor hebt, zullen mensen het gevoel hebben dat de tijd die ze besteden aan het helpen van jou, goed besteed is, en dat je een waardevolle medewerker bent. Zo niet, dan zullen ze je waarschijnlijk vervelend vinden.

Natuurlijk als er veel is dat je niet weet, dan zit je in een delicate situatie, maar houding en bekwaamheid maken een groot verschil. Niemand verwacht dat je alles weet, maar ze geven er wel om hoe je ermee omgaat. Anderen hier hebben de dingen die je kunt doen om de meeste knal voor de bok te krijgen als je wel een senior duivenhokje hebt, dus ik zal hun advies niet herhalen; ik probeer alleen maar wat licht te werpen op de gevoelens van je collega’s die tot deze situatie hebben geleid, zodat je het in de toekomst kunt begrijpen en vermijden.

Dit is bijna meer een suggestie voor je werkgever, maar misschien kun je het voor je laten werken.

Hebben ze je een mentor toegewezen toen je begon? Het is een goed idee om een nieuwe werknemer een toegewezen mentor te geven, iemand waar ze met hun vragen naartoe kunnen gaan. Dit geeft hen iemand die al ervaring heeft in het bedrijf en voorkomt dat de nieuwe man constant iedereen lastigvalt. :-)

De mentor zal ook de juiste mensen kennen om te vragen en de juiste plaatsen om te zoeken naar zaken als documentatie. Sommige projecten hebben bijvoorbeeld Google Doc-documenten, een ander heeft ze op een interne bestandsserver en een derde heeft ze vastgelegd in het bronarchief. Terwijl andere projecten helemaal geen docs hebben.

Een andere tip is dat als je aan een nieuw project begint, je om een rondleiding vraagt. Een solide blok van vier uur tijd met jou en een ervaren persoon kan je op snelheid brengen zonder dat je die vier uur tijd nodig hebt als onderbrekingen verspreid over meerdere maanden.

Een ding om te onthouden: code is als grammatica. Mensen weten misschien dat die van hen slecht zijn, maar ze vinden het niet leuk om dat te horen. Als ik er bijvoorbeeld op wees dat u herhaaldelijk “oordeel” verkeerd heeft gespeld, zou u zich kunnen ergeren omdat ik er niet echt iets constructiefs aan toevoeg. Nou ik heb het toch maar gedaan :)

Maar koppel dat aan het feit dat veel doorgewinterde programmeurs de neiging hebben om een diva-houding aan te nemen. Wat je bedoelt als oprechte vragen die geworteld zijn in de logica, kan zeer bedreigend zijn voor hen. Ik heb met talloze voorbeelden gewerkt (en misschien ben ik er zelf ook wel een) die dezelfde oude klote code handhaven die al 15 jaar niet meer relevant is. Ze weten dat er tegenwoordig een betere manier is om het te doen, maar ze hebben geen interesse of motivatie om nieuwe dingen te leren, dus alleen al je aanwezigheid als volgende generatie is een bedreiging voor hen. Als ze de prima donna act trekken, lach je het jezelf gewoon uit en vergeet niet dat jij degene bent met de echte kracht - je hebt nog vele jaren voor de boeg om met de technologie van de toekomst te werken en de uiteindelijke richting die je carrière inslaat ligt nog steeds in jouw handen. Dat is meestal niet het geval voor de doorgewinterde snobs.

Ik ben het eens met anderen die zeiden dat dit niet klinkt als een goede incubator voor aspirant-ontwikkelaars. Dit is echter wel gebruikelijk. Het kost tijd en ervaring om je niche te identificeren, een werkgever te vinden die goed bij je past en te bepalen wat voor jou het belangrijkst is. Dus betaal daar je loon, neem je brokken, plan je carrière en stap uit nadat je een paar jaar stevig werk hebt verricht. Neem nu gewoon het advies aan voor wat het waard is, maak je geen zorgen over de PIP en blijf jezelf eraan herinneren dat je huidige situatie slechts een middel is om een doel te bereiken. Je begeleiders verwachten dat je op tijd in- en uitklokt alsof je bij Wendy’s werkt. Zo hoeft het niet te zijn, zelfs voor onervaren nieuwe ontwikkelaars, zodat er elders een veel mooiere toekomst kan zijn.

Ik heb geprobeerd ze precies te vertellen wat ik jullie hier heb verteld. Ze werden gewoon boos op me omdat ik met hen “tand en tand” heb geruzied en hun advies niet goed heb opgevolgd. Ik zei dat ik gewoon probeerde mijn standpunt te verwoorden… ze werden meer geërgerd.

Ik denk dat ik kan verklaren waarom ze geërgerd waren: ze willen gewoon geen feedback. Je manager heeft je niet uitgenodigd om je mening te geven, hij zei alleen maar, met dit “verbetering nodig” plan, dat je een slecht gedrag hebt en dat je het moet verhelpen, “voor je eigen bestwil”.

Wie bepaalt wat slecht gedrag is? De mensen die je betalen en die je kunnen ontslaan, alleen. Wanneer je hun beslissingen bekritiseert, worden ze geïrriteerd, omdat ze je betalen om hun orders op te volgen, niet om hun orders in twijfel te trekken. Zij zijn niet “onpartijdige rechters”, zij zijn degenen die je betalen. En als je hen bekritiseert op het moment dat ze je een serieuze en formele waarschuwing geven “verander of ga weg” (wat ze “advies voor verbetering” noemden), kan dit ertoe leiden dat ze denken dat je geen verlossing hebt.