Hoe snel productief zijn als developer?

[D33F]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Mint]

Ik zou me geen zorgen maken. Je mededevelopers snappen echt wel dat het tijd kost om de codebase te leren kennen, vooral als je een bult moet refactoren.

Ik merk het zelf ook, een taak die ik binnen een uurtje kan fixen kan een nieuwe collega makkelijk een week kosten. Als je van tevoren precies weet wat je moet doen, waar dat precies zit en wat er kan omvallen van je wijzigingen dan ben je altijd makkelijker af dan dat je ergens nieuw binnenkomt en het product en/of de codebase nog moet leren kennen.

Het is makkelijker gezegd dan gedaan, maar begin er gewoon aan en vraag collega's als je er niet uit komt. Ben niet bang om fouten te maken, als senior developer maak ik ook fouten of doe ik langer over taken dan collega's. Van fouten maken leer je.

[D33F]

Mint schreef op maandag 10 januari 2022 @ 19:34:
Ik zou me geen zorgen maken. Je mededevelopers snappen echt wel dat het tijd kost om de codebase te leren kennen, vooral als je een bult moet refactoren.

Ik merk het zelf ook, een taak die ik binnen een uurtje kan fixen kan een nieuwe collega makkelijk een week kosten. Als je van tevoren precies weet wat je moet doen, waar dat precies zit en wat er kan omvallen van je wijzigingen dan ben je altijd makkelijker af dan dat je ergens nieuw binnenkomt en het product en/of de codebase nog moet leren kennen.

Het is makkelijker gezegd dan gedaan, maar begin er gewoon aan en vraag collega's als je er niet uit komt. Ben niet bang om fouten te maken, als senior developer maak ik ook fouten of doe ik langer over taken dan collega's. Van fouten maken leer je.

Dank voor je reactie .

Gelukkig ben ik al een eind opgeschoten in een dag, maar het voelt wel vervelend als je domme vragen stelt juist omdat je zo zenuwachtig bent en men wellicht verwacht dat je zo zelfstandig mogelijk moet werken (wat ik ook zonder problemen kan zodra ik weet hoe het precies in elkaar steekt).

[Tk55]

Het voordeel van nieuw zijn is dat juist nu niemand gek opkijkt als je ‘domme’ vragen stelt Neem je tijd en relax. Je collega’s hebben heus wel geduld.

[aawe mwan]

Precies met de vragen die je stelt, laat je je professionaliteit zien.
De goede vragen stellen, zo vroeg mogelijk. Geen vragen stellen = niet professioneel.

In het begin zal je vast een opdracht krijgen waarvan iedereen in het bedrijf weet dat een nieuweling onvoldoende kennis heeft om hem in z'n eentje af te ronden. Het gaat er meer om hoeveel maanden je nodig hebt om wel op het normale tempo (begripniveau) van het bedrijf te komen.

[D33F]

aawe mwan schreef op maandag 10 januari 2022 @ 19:59:
Precies met de vragen die je stelt, laat je je professionaliteit zien.
De goede vragen stellen, zo vroeg mogelijk. Geen vragen stellen = niet professioneel.

In het begin zal je vast een opdracht krijgen waarvan iedereen in het bedrijf weet dat een nieuweling onvoldoende kennis heeft om hem in z'n eentje af te ronden. Het gaat er meer om hoeveel maanden je nodig hebt om wel op het normale tempo (begripniveau) van het bedrijf te komen.

Exact, maar anderzijds denk ik dan gezien ik nog in de proeftijd zit men toch wil kunnen meten wat voor vlees ze in de kuip hebben, derhalve dat ik ook redelijk nerveus werd van de genoemde schatting.

[TweakerVincent]

Dat er geen domme vragen bestaan is bullshit, die bestaan zeer zeker wel. Gewoon gerichte vragen stellen en kennis die je wss zou moeten beheersen gewoon opzoeken s'avonds . En niet teveel vragen stellen, dat werkt juist averechts.

[ Voor 6% gewijzigd door TweakerVincent op 10-01-2022 20:07 ]

[Anoniem: 1302638]

Hou een dagboek bij. Schrijf eind van de dag kort op wat je hebt gedaan, wat je hebt gevraagd, wat je erbij voelde (nerveus, OK, blijk, etc).

Klinkt superzweverig misschien maar super waardevol, als ze over een maand vragen hoe het was, hoe het ging. Dan zal je zien hoeveel details er verloren gaan uit je geheugen zonder zo'n dagboekje.

En als ze roepen "wat deed je er lang over" kan je per dag kort laten zien wat je deed en hoe het ging.

[ Voor 13% gewijzigd door Anoniem: 1302638 op 10-01-2022 20:13 ]

[naitsoezn]

Een klus die hij (je collega-developer) in een uurtje zou kunnen oplossen klinkt toch juist als een klein instapklusje? En als de code alle lagen van de applicatie raakt, dan klinkt dat juist als de ideale taak om de codebase te leren kennen zonder dat je doelloos door code aan het browsen bent.

Kortom: Gebruik je tijd om de code te leren kennen, stel vragen wanneer je ergens vast loopt, en refactor ondertussen de code die je inmiddels begrijpt. In dit geval zou ik zeggen: De reis is belangrijker dan het doel

[ Voor 6% gewijzigd door naitsoezn op 10-01-2022 20:21 ]

[D33F]

naitsoezn schreef op maandag 10 januari 2022 @ 20:20:
Een klus die hij (je collega-developer) in een uurtje zou kunnen oplossen klinkt toch juist als een klein instapklusje? En als de code alle lagen van de applicatie raakt, dan klinkt dat juist als de ideale taak om de codebase te leren kennen zonder dat je doelloos door code aan het browsen bent.

Kortom: Gebruik je tijd om de code te leren kennen, stel vragen wanneer je ergens vast loopt, en refactor ondertussen de code die je inmiddels begrijpt. In dit geval zou ik zeggen: De reis is belangrijker dan het doel

Dat klopt dat het een ideale taak is om de codebase te leren kennen, maar schrok wel van dat uurtje zeg maar.

Bij mijn oude werkgever was iets soortgelijks ook wel pak en beet binnen die tijd gelukt maar dan wel zonder de zenuwen en de kennis die je over de jaren hebt opgedaan over het systeem.

[Limaad]

Wat je ook kan doen, is een uur van zijn tijd claimen voor pair programming. Jij zit aan de knoppen en hij gaat meer vertellen over wat waar staat.
Ik zie daar altijd enkel voordelen in. Je leert elkaar beter kennen, hij kan beter zien wat je skills zijn en het komt de kwaliteit van de code enkel ten goede.

En afhankelijk van hoeveel vertrouwen de omgeving voor je geeft, kan je je ook kwetsbaar opstellen en aangeven dat je er best tegen op kijkt. Dan krijg je heel waarschijnlijk bevestigende woorden dat je echt wel je tijd kan pakken. En als je die niet krijgt, dan is het ook mooi voor jezelf dat je nog in je proefperiode zit

[ConQuestador]

Allereerst wil ik zeggen: Een complete refactor, en er een uur voor uit trekken is gewoon bizar. Inclusief unittesten aanpassen, de functionaliteit daadwerkelijk testen, code netjes maken, etc. Reken ik toch al snel op een halve dag, zelfs als je ervaring er mee hebt.

Dat gezegd hebbende, terug naar je vraag:

Ik ben inmiddels zo'n 20 jaar developer, en werk nu als senior freelance developer. Als ik ergens nieuw kom, en mij wordt zo'n opdrachtje gegeven dan zeg ik heel rustig: Prima, ik ga er mee aan de slag.
Vervolgens neem ik alle tijd van de wereld om alle code eens goed te bekijken, begrijpen hoe dingen zitten, desnoods compleet andere repo's uitchecken omdat die toevallig ook aangeraakt worden. En uiteindelijk ga ik doen wat ik moet doen.
Tijdens de eerstvolgende standup zeg je heel rustig "Ik ben met die refactor story bezig, maar aangezien het allemaal nieuw is neem ik eerst de tijd alles goed te begrijpen, zodat ik zeker weet dat ik het juiste doe".

Als je het vervolgens in 2 dagen aftikt, hoef je je nog steeds totaal niet te schamen. Je hebt die tijd namelijk vooral geinvesteerd in kennis van het platform, die je later kan gebruiken als er weer een opdrachtje voorbij komt.

Ik heb nog nooit meegemaakt dat iemand hier moeilijk over deed, en als ze daar wel moeilijk over doen dan hebben ze simpelweg geen realistisch beeld wat software ontwikkelen inhoudt.

(En die 1e developer die zegt "ik doe dit in een uurtje".... Dat soort types heb je bij ieder bedrijf: Supergoede ontwikkelaars in hun eentje, maar zodra ze in een team moeten werken heb je er niks aan )

[Khallouki]

Ik kan beamen wat de mede-tweakers hier zeggen en vooral veel vragen stellen!

[Morty]

Beste manier van inwerken is gewoon meteen mee draaien en normale taken oppakken. Een beetje in het diepe gooien en dan kom je er vanzelf wel achter of iemand kan zwemmen of niet.

Maar iedereen begrijpt dat je nog niet de efficiëntie hebt van een al ingewerkt iemand, en dat je veel vragen stelt. Juist het aangeven wat je niet weet en vragen daarover stellen of aangeven wat je nodig hebt aan ondersteuning is een teken van professionaliteit. Dat wordt alleen maar gewaardeerd.

Het ligt aan het project natuurlijk, maar in mijn huidige project rekening ik een tijd van 6 maanden tot een jaar om volledig op-to-speed te komen. Desondanks is het wel gewoon vanaf dag 1 taken op pakken en in de code werken.

[418O2]

Enige domme wat je kan doen is tegen dingen aan lopen en niet om hulp vragen op dit moment

[Morty]

418O2 schreef op dinsdag 11 januari 2022 @ 10:36:
Enige domme wat je kan doen is tegen dingen aan lopen en niet om hulp vragen op dit moment

Inderdaad, mensen die zeggen dat ze iets niet weten of vragen stellen vind ik eigenlijk nooit dom (of het moet wel heel basic zijn..). Maar genoeg mee gemaakt dat iemand maar zelf door blijft modderen zonder iets te zeggen, dat zijn juist de mensen die problemen geven binnen een team.

[PainkillA]

een onboarding kan makkelijk weken kosten. Het bedrijf moet een goede documentatie hebben dus alles wat je niet weet vragen zodat management /teamleads vanzelf gaan regelen dat al die vragen gedocumenteerd staan voor de volgende onboarding.

Verder niets van aantrekken. Nu is het moment om de tijd te pakken om alles te doorgronden. Over 6 a 12 maanden is die tijd er minder/niet en wordt wel verwacht dat je enigszins productief bent maar de 1e maand zeker niet.

Wat ook niet vergeten moet worden is dat je nu met een versie blik "outside of the box" visie hebt op zowel de code als het product. Schrijf alles op wat je vreemd vind of anders zou doen en bespreek dit op een bepaald moment met je manager. Die gaat dat zeer waardevol vinden

[ Voor 23% gewijzigd door PainkillA op 11-01-2022 10:59 ]

[Fisheke]

Los van alle (goede) adviezen hier - probeer ook te beseffen dat het Impostor Syndrome (Wikipedia: Impostor syndrome) gangbaar is in dit soort situaties. Bijna iedereen komt daar mee in aanraking (zeker in onze sector, in meer of mindere mate), da's normaal.

Ik ben zelf ook senior freelance dev (java kant), en sta elke keer als ik bij een nieuwe klant kom opnieuw verstomd hoe dom ik wel ben...

[downtime]

Ik ben geen developer maar wel IT’er en ik wantrouw mensen die in de eerste weken niet (veel) vragen stellen. Er is dan altijd een probleem: Gebrek aan interesse, ze durven niks te vragen (want onzeker) of het zijn mensen die niet in een team kunnen werken.

[millerman_sf]

IT Manager hier: ik verwacht niet dat nieuwe medewerkers in de eerste 2 maanden volledig productief zijn. Dat bouw je langzaam op. Je moet de omgeving leren kennen, de codebase, de werkprocessen en -afspraken. Natuurlijk hangt het af van jouw specifieke kennis en achtergrond of het sneller gaat of niet, maar het kost gewoon tijd om echt volledig mee te draaien.

Laat zien dat je het voldoende snapt door gerichte vragen te stellen en juist door te vragen over context, ook al is het voor je taak niet direct al noodzakelijk. Als je iets vaker vraagt of aan verschillende mensen, krijg je vaak niet altijd exact hetzelfde antwoord en het blijft uiteindelijk beter bij je hangen. Voor mij geen tekenen van zwakte, maar juist van interesse en basiskennis over de aard van de werkzaamheden. Geef ook duidelijk aan wat jij nodig hebt om het je eigen te maken, zoals tijd van anderen om vragen te kunnen stellen.

[Brandaris01]

De andere persoon lijkt me ook een niet al te vriendelijk/sociaal vaardig persoon.

Dus als dit zo blijft, zoek het niet alleen maar bij je eigen onzekerheid/onkunde. Misschien ligt het probleem ook wel (deels) bij hem.

[D33F]

Brandaris01 schreef op dinsdag 11 januari 2022 @ 13:15:
De andere persoon lijkt me ook een niet al te vriendelijk/sociaal vaardig persoon.

Dus als dit zo blijft, zoek het niet alleen maar bij je eigen onzekerheid/onkunde. Misschien ligt het probleem ook wel (deels) bij hem.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 3% gewijzigd door D33F op 11-01-2022 19:01 ]

[init6]

Er zijn zo veel dingen die ik kan zeggen over dit soort situaties, maar een aantal dingen om rekening mee te houden is:
- Van alle honderden mensen waarmee ik gewerkt heb waren er 2 in staat om binnen twee weken productief te zijn.
- Als je in loondienst bent zullen ze moeten gaan investeren in je ontwikkeling, de tijd om de codebase, tooling en setup te leren kennen is wel het minste. Dat kan je niet in een week tijd als medior en zelfs dan nog had ik nooit de verwachting dat een senior dat zou kunnen. Of ze nou freelancer, senior of expert zijn. In die derde week wil ik wel wat zien, maar verwacht ik niet dat iemand gaat refactoren.
- Als ik zelf geen tijd indicatie heb gegeven over werkzaamheden die ik moet uitvoeren dan is de tijd die ze er voor geven een probleem van degene die de indicatie gemaakt heeft. In dat geval kan je niet meer dan je best doen.
- Zodra ik in een discussie zit met een product owner of stakeholder over een indicatie dan is het de tijd die ik denk dat er nodig is x 4. Het komt erg weinig voor dat je daarmee de mist in gaat, en als je eerder klaar bent dan is dat mooi meegenomen. Stukje verwachtingsmanagement. Dus als ik denk dat ik er een uur mee bezig ben dan is dat 4 uur. De reden daarvoor is dat: Dingen moeten gedocumenteerd worden, die makkelijke setup blijkt niet lekker geschreven te zijn, swagger start niet, de pipeline is net effe naar de krek etc.

[Furion2000]

D33F schreef op dinsdag 11 januari 2022 @ 18:44:
[...]


***members only***

Ondanks dat ik heel veel waardevolle praktische dingen lees schiet mij nog 1 minor ding te binnen.

Slimme gasten of gasten die zichzelf slim vinden, hebben altijd gelijk volgens zichzelf. Klinkt negatief, maar als je hiermee om kunt gaan kun je het werk zeker gewoon fijn laten zijn.

Je kunt dus in zo'n initiële taak eerst een paar uur rond gaan neuzen en een soort kort plan maken (e.g. deze class moet verplaatst worden, deze UT moet aangepast worden, ik denk dat een eigen module beter is) en dit dan verifiëren bij zo'n persoon op een positieve manier. 'He ik heb even zitten rondneuzen, ik denk dat dit moet gebeuren, zou je dit ook zo aanpakken'?

Je kunt ook zelf halverwege de refactorslag even een review laten doen om te vragen of hij vind dat je op de goede weg zit.

Beide kan en een beetje aanvoelen ook wat die begeleidend developer het meest fijn vind. Als hij niet van veel vragen houdt dus mogelijk weer wel snelle review cycles en als hij niet van reviewen houdt, meer sparren.

Beide manieren laten de begeleidend developer 'in control' en 'belangrijk' voelen en dat is denk ik wat iedereen fijn vind en een goede indruk achter laat. Jij een bonk van positiviteit en enthousiasme en hij diegene die het mag dicteren. Als je hem eenmaal aan je kant hebt, verdwijnt dat dicteren vaak, want dan heeft heb je zijn vertrouwen

Zelf houd ik van snelle cycles, dus in hoofdlijnen. Zo snel mogelijk werkend krijgen en even sparren (ugly) en dan met de kennis die je dan hebt (vaak vele male beter dan puur kijken) steeds een beetje mooier maken totdat het goed is (perfect kost te veel tijd). Dan verander je eigen changes mogelijk een aantal keer, maar daar word je 1. ook steeds sneller in en 2. je kiest vaker de goede oplossing omdat je eigenhandig hebt geprobeerd wat niet werkt.

Ik denk dat als je met je productiviteit bewust bezig bent dat het door goede inzet sowieso goed gaat komen hoor. Succes!

[CVTTPD2DQ]

ConQuestador schreef op dinsdag 11 januari 2022 @ 09:57:
Allereerst wil ik zeggen: Een complete refactor, en er een uur voor uit trekken is gewoon bizar. Inclusief unittesten aanpassen, de functionaliteit daadwerkelijk testen, code netjes maken, etc. Reken ik toch al snel op een halve dag, zelfs als je ervaring er mee hebt.

Oorspronkelijk betekende 'refactoren': het herschrijven van code met automatische tooling, waarbij de klasse-invariant ongewijzigd blijft. Dat kan natuurlijk in een minuut.

Tegenwoordig mag je al blij zijn als zo'n lokaal genie weet wat een invariant is, laat staan dat je tooling hebt die er mee om kan gaan.

En dat is eigenlijk het grootste probleem, 'refactoren' betekent nu eigenlijk 'herschrijven van code naar eigen smaak', waarbij die smaak vrijwel volledig subjectief is. Als je collega vindt dat er maar een paar kleine dingetjes veranderd hoeven te worden, is een uurtje niet zo gek.

[Furion2000]

CVTTPD2DQ schreef op woensdag 12 januari 2022 @ 08:59:
[...]


Oorspronkelijk betekende 'refactoren': het herschrijven van code met automatische tooling, waarbij de klasse-invariant ongewijzigd blijft. Dat kan natuurlijk in een minuut.

Tegenwoordig mag je al blij zijn als zo'n lokaal genie weet wat een invariant is, laat staan dat je tooling hebt die er mee om kan gaan.

En dat is eigenlijk het grootste probleem, 'refactoren' betekent nu eigenlijk 'herschrijven van code naar eigen smaak', waarbij die smaak vrijwel volledig subjectief is. Als je collega vindt dat er maar een paar kleine dingetjes veranderd hoeven te worden, is een uurtje niet zo gek.

Automatische tooling is toch ook subjectief geschreven? Vind dat tegenstrijdig wat je daar zegt en zie niet echt het grootste probleem hier als je het wat positiever omschrijft naar 'Verbeteren van code naar de kennis van nu'.

Maar hoe zou jij dit probleem willen oplossen dan? Want daar moet je ook aan gedacht hebben als je het ziet als grootste probleem.

[CVTTPD2DQ]

Furion2000 schreef op woensdag 12 januari 2022 @ 09:45:
Automatische tooling is toch ook subjectief geschreven? Vind dat tegenstrijdig wat je daar zegt en zie niet echt het grootste probleem hier als je het wat positiever omschrijft naar 'Verbeteren van code naar de kennis van nu'.

Ik denk dat ik me onhandig heb uitgedrukt; er is niet zoveel mis met refactoren zoals het nu bestaat, of met subjectiviteit. Wat wel lastig is is als je beoordeeld wordt (of het gevoel hebt dat je beoordeeld wordt) op een taak die een grote subjectieve component heeft.

Overigens kan het wel een interessante manier zijn om iemands manier van werken te leren kennen; laat die persoon een stuk code herschrijven naar eigen inzicht, en praat dan over de aanpassingen. Maar ik kreeg niet de indruk dat dat hier de opzet was.

[frickY]

D33F schreef op maandag 10 januari 2022 @ 20:04:
Exact, maar anderzijds denk ik dan gezien ik nog in de proeftijd zit men toch wil kunnen meten wat voor vlees ze in de kuip hebben, derhalve dat ik ook redelijk nerveus werd van de genoemde schatting.

Het is goed om zelfstandig te kunnen werken, maar als je 3 dagen stuk slaat op iets wat je met 1 "domme" vraag kunt voorkomen, dan is vragen de juiste route.

[D33F]

CVTTPD2DQ schreef op woensdag 12 januari 2022 @ 08:59:
[...]


Oorspronkelijk betekende 'refactoren': het herschrijven van code met automatische tooling, waarbij de klasse-invariant ongewijzigd blijft. Dat kan natuurlijk in een minuut.

Tegenwoordig mag je al blij zijn als zo'n lokaal genie weet wat een invariant is, laat staan dat je tooling hebt die er mee om kan gaan.

En dat is eigenlijk het grootste probleem, 'refactoren' betekent nu eigenlijk 'herschrijven van code naar eigen smaak', waarbij die smaak vrijwel volledig subjectief is. Als je collega vindt dat er maar een paar kleine dingetjes veranderd hoeven te worden, is een uurtje niet zo gek.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 4% gewijzigd door D33F op 12-01-2022 18:36 ]

[D33F]

Furion2000 schreef op woensdag 12 januari 2022 @ 08:35:
[...]

Je kunt ook zelf halverwege de refactorslag even een review laten doen om te vragen of hij vind dat je op de goede weg zit.

Beide kan en een beetje aanvoelen ook wat die begeleidend developer het meest fijn vind. Als hij niet van veel vragen houdt dus mogelijk weer wel snelle review cycles en als hij niet van reviewen houdt, meer sparren.

Beide manieren laten de begeleidend developer 'in control' en 'belangrijk' voelen en dat is denk ik wat iedereen fijn vind en een goede indruk achter laat. Jij een bonk van positiviteit en enthousiasme en hij diegene die het mag dicteren. Als je hem eenmaal aan je kant hebt, verdwijnt dat dicteren vaak, want dan heeft heb je zijn vertrouwen

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 3% gewijzigd door D33F op 13-01-2022 17:43 ]

[Morty]

D33F schreef op donderdag 13 januari 2022 @ 17:42:
[...]


***members only***

Dat zijn behoorlijke red flags.

Twee dagen is natuurlijk nog erg kort, maar wellicht kan je voorzichtig beginnen met bij anderen/leidingevende aangeven dat je met meer support effectiever op stoom zou komen (zonder direct je collega af te vallen).

[Lethalis]

D33F schreef op woensdag 12 januari 2022 @ 18:33:
[...]
***members only***

VB.Net?

Sterkte Ik werk (o.a.) ook aan 2 grote projecten in VB.Net waar code inzit van soms wel 20 jaar oud (geschreven door ex VB6 developers).

Bij het switchen van baan zou ik er overigens nooit meer voor kiezen. Dan maar een andere baan Het is dat ik hier al erg lang werk en de overige voorwaarden prima zijn, maar het werk zelf is inhoudelijk gezien soms best frustrerend (spaghetti code, oude meuk, technical debt everywhere etc).

Ik heb gelukkig ook C# projecten in .Net 5 en Angular om te voorkomen dat ik doodongelukkig word

PS
Option Strict is your friend. Zet dat zoveel mogelijk aan. Anders krijg je te maken met VB "magic"

[ Voor 11% gewijzigd door Lethalis op 13-01-2022 18:38 ]

[Lethalis]

D33F schreef op maandag 10 januari 2022 @ 20:04:
[...]

Exact, maar anderzijds denk ik dan gezien ik nog in de proeftijd zit men toch wil kunnen meten wat voor vlees ze in de kuip hebben, derhalve dat ik ook redelijk nerveus werd van de genoemde schatting.

Als het je enigszins geruststelt: mijn werkgever ziet eigenlijk de duur van het gehele tijdelijke contract (vaak 6 maanden) als proeftijd, omdat 1 maandje veel te kort is om iemand te beoordelen (je moet het wel heel bont maken om de proeftijd niet te halen).

[Lethalis]

Brandaris01 schreef op dinsdag 11 januari 2022 @ 13:15:
De andere persoon lijkt me ook een niet al te vriendelijk/sociaal vaardig persoon.

Dus als dit zo blijft, zoek het niet alleen maar bij je eigen onzekerheid/onkunde. Misschien ligt het probleem ook wel (deels) bij hem.

Voordeel van dat soort mensen is dat ze jou ook met rust laten en je maar al te graag op jouw eigen eiland plaatsen.

Ik vind het meestal niet erg, want dan heb je vrij snel jouw eigen projecten etc en niemand die over jouw schouders meer meekijkt.

@D33F
Geef het simpelweg wat meer tijd dus. Relax.

[D33F]

Lethalis schreef op donderdag 13 januari 2022 @ 19:01:
[...]

Voordeel van dat soort mensen is dat ze jou ook met rust laten en je maar al te graag op jouw eigen eiland plaatsen.

Ik vind het meestal niet erg, want dan heb je vrij snel jouw eigen projecten etc en niemand die over jouw schouders meer meekijkt.

@D33F
Geef het simpelweg wat meer tijd dus. Relax.

Dank voor de tip en wijze woorden Zeker geef ik het meer tijd no worries .

Anderzijds zie ik het ook als een mooie uitdaging, maar goed eerlijk is eerlijk en hoop wel dat er een moment gaat komen dat ik de skills van de afgelopen jaren weer veelvuldig kan inzetten en slijpen

[Lethalis]

D33F schreef op donderdag 13 januari 2022 @ 19:14:
[...]
Dank voor de tip en wijze woorden Zeker geef ik het meer tijd no worries .

En ik herhaal het volgende nog een keer, want als je als C# developer VB.Net gaat doen, is het echt belangrijk:

Option Strict moet aan!

Kun je instellen in de project settings, maar ook per bestand. Combineren met Option Infer is wel prima.

Ik heb 4 jaar als C# developer gewerkt, voordat ik VB.Net ging doen. En ik was mij daar veel te laat van bewust. C# is namelijk altijd strict.

Dit gaat een hoop hoofdpijn voorkomen

Mochten de bestaande projecten dermate gammel zijn dat ze niet compileren met Option Strict, kun je hem ook op waarschuwen instellen en zo de code gaandeweg verbeteren.

Succes

[bwerg]

ConQuestador schreef op dinsdag 11 januari 2022 @ 09:57:
Allereerst wil ik zeggen: Een complete refactor, en er een uur voor uit trekken is gewoon bizar. Inclusief unittesten aanpassen, de functionaliteit daadwerkelijk testen, code netjes maken, etc. Reken ik toch al snel op een halve dag, zelfs als je ervaring er mee hebt.

En daaraan gerelateerd is ook nog overschatting een mogelijkheid: iemand die inderdaad maar een uurtje uittrekt, maar het dan niet zo nauw neemt met het ontwerp of het testen. Met daarna wat bugs of spagetti als gevolg.

Ook een simpel ding netjes doen, even uitschrijven zodat je zeker weet dat je alle randjes netjes hebt weggewerkt, en testen zodat de functionaliteit is vastgelegd kost dan al snel een paar uurtjes. Laat staan als je ook nog code-reviews hebt, tel de tijd dan maar dubbel. De gevallen die ik zelf op een uurtje inschat zijn echt enkel de one-liners waar je maar 5 seconden naar hoeft te kijken om te zien dat het klopt.

D33F schreef op donderdag 13 januari 2022 @ 17:42:
[...]


***members only***

Zeker ook niet alleen gaan trekken bij degene die je inhoudelijk nodig hebt, maar ook bij je leidinggevende. Regelmatig bespreken hoe het gaat en gewoon feitelijk aangeven waar de pijnpunten liggen en dat je wel veel moeite hebt om het in je eentje allemaal uit te zoeken met X contactmomenten per week. "Ik kan van nieuwe functionaliteit nog lastig zeggen waar dat in de code terug te vinden is" of "ik kan nog lastig beoordelen of ik zaken mis" en dergelijke, en vragen wat daar structureel een oplossing voor is.

Alleen een slechte leidinggevende zal van mening zijn dat dat aan jou ligt ("programmeren is programmeren, toch?" als een vakkenvuller met ervaring bij de AH die na een kwartier inwerken ook bij de Jumbo mee kan draaien). Een goede manager is blij als iemand zegt dat er ergens risico's liggen (gaten in unit tests waardoor je geen idee hebt of je bugs introduceert, kennis die bij een enkel persoon ligt, communicatieproblemen, etc.).

[ Voor 35% gewijzigd door bwerg op 14-01-2022 12:53 ]

[Furion2000]

D33F schreef op donderdag 13 januari 2022 @ 17:42:
[...]


***members only***

Ben je nu even die mouse in a bucket of cream, leer je ook weer dingen van. Zoals de rest ook zegt kun je tijdens de retrospective aankaarten dat het sneller was geweest als er een snellere feedback loop was (e.g. review of sparren). Alternatief is ook niet erg natuurlijk, maar dan duurt het wat langer. Dat mag ook gezegd worden toch? Beide kan positief zijn? Dat ze maar bewust kiezen, het weten en er ook eerlijk geoordeeld kan worden.

Misschien heeft die gast wat langer nodig om te ontdooien, maar er zijn maar weinig gasten die na een langere periode constante dosis enthousiasme en interesse afzijdig blijven. Dan pas kun je concluderen dat je pogingen (let op meervoud) niet geholpen hebben. Na de conclusie altijd kijken wat je dus de volgende keer zelf beter kan doen in zo'n situatie.

Door corona valt het sociale ook wel eens weg, dus ik probeer ook bij elke call tussendoor even wat small talk te doen. Dat helpt ook doordat men op een gegeven moment niet meer weet of het een gezellig gesprekje gaat zijn of even zijn hoofd leeg vissen is (of beiden )

[ Voor 7% gewijzigd door Furion2000 op 14-01-2022 13:22 ]