Inwerken bij nieuwe werkgever als software engineer

[D33F]

Beste Tweakers,

Ik vroeg mij af wat een normale duur is om goed ingewerkt te zijn bij een nieuw bedrijf / architectuur / andere techstack?

Na een kleine maand begin ik wel langzaam mijn weg te vinden maar het blijft even een omschakeling om met oudere technologie te werken dan je gewend bent (Van WebApi + Vue naar webforms).

Uit het verleden weet ik dat ik snel leer en zou dan ook graag qua productiviteit op mijn oude niveau willen zitten, vandaar ook deze vraag.

[ Voor 21% gewijzigd door D33F op 05-07-2018 20:49 ]

[EMP]

Het ligt er nogal aan hoe complex de omgeving is. Alles tussen de drie maanden en anderhalf jaar is realistisch voor werk voor een hoger opgeleide techneut imho... voor mbo misschien korter.

[Lethalis]

David Regeling schreef op donderdag 5 juli 2018 @ 19:42:
Na een kleine maand begin ik wel langzaam mijn weg te vinden maar het blijft even een omschakeling om met oudere technologie te werken dan je gewend bent (Van WebApi + Vue naar webforms).

Uit het verleden weet ik dat ik snel leer en zou dan ook graag qua productiviteit op mijn oude niveau willen zitten, vandaar ook deze vraag.

Gecondoleerd.

WebForms is nou ook niet bepaald ideaal qua productiviteit. Op een gegeven moment ben je de hele tijd om de beperkingen ervan aan het heenwerken en krijg je steeds gekkere oplossingen.

Wat wij op de zaak doen met WebForms projecten is NancyFX er aan toevoegen, zodat je makkelijk REST API's kunt maken binnen het bestaande WebForms project. En dan een JavaScript framework zoals AngularJS gebruiken om daarmee te laten praten.

De nieuwe Angular leeft in zijn eigen ecosysteem en kun je niet zo makkelijk in een bestaand project plaatsen. Maar goed, gelukkig zijn er nog andere manieren (React, Vue, etc).

[Croga]

David Regeling schreef op donderdag 5 juli 2018 @ 19:42:
Ik vroeg mij af wat een normale duur is om goed ingewerkt te zijn bij een nieuw bedrijf / architectuur / andere techstack?

Wat is normaal?
Wat is goed ingewerkt?
Wat is een andere techstack?

Alles is relatief. Je praat hier over dusdanige complexe systemen dat hier geen eenduidig antwoord op mogelijk is behalve "Tussen de 4 weken en 2 jaar"....

Daarnaast praat je hier alleen nog over jezelf.. Het kost ook tijd om onderdeel te worden van het nieuwe bedrijf. Het kost tijd om de mensen om je heen te leren kennen en te begrijpen hoe jij daar tussen past. Het kost tijd om je gebruikers/klanten te leren kennen.....

Alles bij elkaar moet je rekenen op grofweg een half jaar voordat je daadwerkelijk presteert binnen een bedrijf. Dan praten we over daadwerkelijk een "performing" medewerker binnen het gehele systeem te zijn.
Na een maand of 2 zou je je redelijk "productief" lid van het team moeten voelen.

(maar again; deze getallen zijn altijd relatief en nooit serieus te nemen :-P)

[MeZZiN]

Geeft mij een maand ik ben ingewerkt op een project (moet ook wel omdat ik freelancer ben) maar als je het hebt over complexe oude systemen buiten je comfort zone dan mag je rustig 6-24 maanden rekenen om je echt ingewerkt te zijn.

Ik zoek mijn klussen meestal in de buurt van wat ik wil (heb wel makkelijk praten omdat ik meer keuze heb)

Maar elke stack kost tijd een java project / frontend project etc. hoe meer enterprise achtig het wordt hoe langer de inwerk tijd. + als de code oud is helpt zeker niet mee.

Dus inwerk tijd is nooit te bepalen. De meeste extreme dat ik meegemaakt heb is dat er 2-3 jaar voor stond om echt in gewerkt te zijn. Was een systeem van 10+ jaar oud geen framework (ja een eigen geknutselde) en 600.000 regels code. 1 grote monoliet. Ik was sneller ingewerkt maar dat kwam om dat ik de boel ging refractoren en verbeteren van het begin af aan. Deze klussen zou ik nooit meer aannemen. No fun.

[gold_dust]

MeZZiN schreef op vrijdag 6 juli 2018 @ 14:16:
Dus inwerk tijd is nooit te bepalen. De meeste extreme dat ik meegemaakt heb is dat er 2-3 jaar voor stond om echt in gewerkt te zijn. Was een systeem van 10+ jaar oud geen framework (ja een eigen geknutselde) en 600.000 regels code. 1 grote monoliet. Ik was sneller ingewerkt maar dat kwam om dat ik de boel ging refractoren en verbeteren van het begin af aan. Deze klussen zou ik nooit meer aannemen. No fun.

Wat ik inmiddels (te) vaak gezien heb is dat het bij bedrijven een grote puinhoop van legacy code is, dat daar in de sollicitatie of kennismakingsgesprek nooit over wordt gepraat en dat er van 'de nieuwe' maar wordt verwacht dat die dit even 'oplost' terwijl eigenlijk de enige realistische optie alles nieuw ontwikkelen is. En als dit 'oplossen' dan niet lukt, ligt het aan de nieuwe medewerker en natuurlijk nooit aan hun eigen totale gebrek aan competentie.

Ik doe dit soort opdrachten inmiddels ook niet meer. Ik zeg het inmiddels ook gewoon van te voren, ik doe alleen software ontwikkeling en geen bug fixing, maintenance, refactoring, of verder ontwikkelen van iemand anders code.

[merauder]

Mijn ervaring is dat 'mee kunnen doen' al vrij snel gaat, maar dat het toch echt wel tussen de 6 maanden en de 5 jaar duurt voordat je de business begrijpt.

Bij nieuwbouw is de inwerktijd overigens wat korter, maar meestal wordt je aan een bestaand project toegevoegd, waarbij het vaak een puinjoopje is.

[D33F]

Lethalis schreef op vrijdag 6 juli 2018 @ 09:31:
[...]

Gecondoleerd.

WebForms is nou ook niet bepaald ideaal qua productiviteit. Op een gegeven moment ben je de hele tijd om de beperkingen ervan aan het heenwerken en krijg je steeds gekkere oplossingen.

Wat wij op de zaak doen met WebForms projecten is NancyFX er aan toevoegen, zodat je makkelijk REST API's kunt maken binnen het bestaande WebForms project. En dan een JavaScript framework zoals AngularJS gebruiken om daarmee te laten praten.

De nieuwe Angular leeft in zijn eigen ecosysteem en kun je niet zo makkelijk in een bestaand project plaatsen. Maar goed, gelukkig zijn er nog andere manieren (React, Vue, etc).

Bedankt voor de tip, wellicht is dit iets om op termijn te implementeren. Op dit moment is het eerder een kwestie van inventariseren en begrijpen hoe alles aan elkaar hangt. Het zal wat tijd en moeite kosten om de bestaande codebase weer een beetje up to date te krijgen.

Anderzijds zie ik dit ook wel als een uitdaging en kan de frisse wind die ik meebreng wellicht perspectieven openen.

[Mugwump]

gold_dust schreef op vrijdag 6 juli 2018 @ 15:10:
[...]

Wat ik inmiddels (te) vaak gezien heb is dat het bij bedrijven een grote puinhoop van legacy code is, dat daar in de sollicitatie of kennismakingsgesprek nooit over wordt gepraat en dat er van 'de nieuwe' maar wordt verwacht dat die dit even 'oplost' terwijl eigenlijk de enige realistische optie alles nieuw ontwikkelen is. En als dit 'oplossen' dan niet lukt, ligt het aan de nieuwe medewerker en natuurlijk nooit aan hun eigen totale gebrek aan competentie.

Ik doe dit soort opdrachten inmiddels ook niet meer. Ik zeg het inmiddels ook gewoon van te voren, ik doe alleen software ontwikkeling en geen bug fixing, maintenance, refactoring, of verder ontwikkelen van iemand anders code.

Ik vind mezelf echt niet bijzonder goed, maar ik schrik vaak echt enorm van het niveau van veel software-ontwikkelaars. Als je bijvoorbeeld in een webomgeving werkt in Java of .Net en je snapt basale concepten uit OOP of het HTTP protocol al niet, dan gaat een fatsoenlijk onderhoudbare codebase produceren ook erg lastig worden.
Wat je dan ook vaak ziet is dat men omdat het te traag gaat er maar wat extra (matige) developers tegenaan gooit wat het probleem alleen maar verergert.

In mijn ogen is software-ontwikkeling ook een proces van continue refactoring. Nieuwe toevoegingen of belangrijke inzichten in je domein vereisen vaak enige herstructurering. Als je dat niet steeds blijft doen en je hebt ook nog eens veel personeelswisseling op een project dan wordt het al snel een zooitje.
Ik heb menig greenfieldproject vrij snel zien veranderen in een enorme brij code die alweer legacy is.
Moet nog een project fors herzien waarbij ik maar gewoon herbouw overweeg omdat in de bestaande codebase wroeten waarschijnlijk meer tijd gaat kosten.

Ik kan zelf vaak binnen een maandje mijn weg ook altijd wel goed vinden in een bestaande codebase, maar greenfieldprojecten hebben echt wel mijn voorkeur.

[ Voor 4% gewijzigd door Mugwump op 07-07-2018 20:55 ]

[Lethalis]

Mugwump schreef op zaterdag 7 juli 2018 @ 20:51:
[...]
Moet nog een project fors herzien waarbij ik maar gewoon herbouw overweeg omdat in de bestaande codebase wroeten waarschijnlijk meer tijd gaat kosten.

Herbouw zie ik altijd als de allerlaatste optie, als er echt geen andere mogelijkheid is.

Meestal zitten er namelijk allerlei uitzonderingen in een bestaande codebase die je gaat vergeten bij herbouw.

Juist als het zo'n brei betreft, zonder documentatie of specificatie wat het überhaupt precies moet doen in welke situatie.

Als ik iets nieuws moet bouwen in een bestaand project, refactor ik het liefst alleen de dingen die ik nodig heb. De rest laat ik met rust

Natuurlijk kan ik het soms niet laten om meer te doen dan dat, maar meestal krijg ik daar spijt van. Het kost toch altijd meer tijd dan verwacht en de kans dat je ergens een bepaald - voor jou onbekend - scenario niet getest hebt, groeit met het aantal regels code die je verbouwt.

Probleem met spaghetti code is dat de ontwikkelaars daarvan ook graag code schrijven die 100 en 1 dingen doet. Het single responsibility principe is ver te zoeken vaak.

[Mugwump]

Lethalis schreef op zondag 8 juli 2018 @ 09:10:
[...]

Herbouw zie ik altijd als de allerlaatste optie, als er echt geen andere mogelijkheid is.

Meestal zitten er namelijk allerlei uitzonderingen in een bestaande codebase die je gaat vergeten bij herbouw.

Juist als het zo'n brei betreft, zonder documentatie of specificatie wat het überhaupt precies moet doen in welke situatie.

Als ik iets nieuws moet bouwen in een bestaand project, refactor ik het liefst alleen de dingen die ik nodig heb. De rest laat ik met rust

Natuurlijk kan ik het soms niet laten om meer te doen dan dat, maar meestal krijg ik daar spijt van. Het kost toch altijd meer tijd dan verwacht en de kans dat je ergens een bepaald - voor jou onbekend - scenario niet getest hebt, groeit met het aantal regels code die je verbouwt.

Natuurlijk is het altijd een kosten / baten kwestie en is complete herbouw niet iets wat je een lichtzinnig besluit. Als het systeem fors is, dan is vaak een strangler pattern een betere optie:
https://docs.microsoft.co...ecture/patterns/strangler

Dat is feitelijk ook wat ik binnenkort ga doen met een bestaand systeem. Belangrijk is in mijn ogen ook dat je geleidelijk een set aan regressietests opbouwt die alle verschillende scenario's testen. Als je dan zoals jij aangeeft "verstopte scenario's" ondervindt omdat er iemand klaagt dat iets niet meer werkt, dan kun je die implementeren en toevoegen aan je testset.
Daarmee heb je gelijk documentatie voor het systeem.

Probleem met spaghetti code is dat de ontwikkelaars daarvan ook graag code schrijven die 100 en 1 dingen doet. Het single responsibility principe is ver te zoeken vaak.

Klopt, ik mag gezellig een volstrekte brij aan procedurele code en stored procedures gaan ontcijferen.

Om ontopic te blijven, dit is zo'n mooi voorbeeld van een codebase waar je eigenlijk niet inkomt. Een goede codebase hanteert logische patronen en modulariteit en reflecteert het business domein waarvoor het systeem bedoeld is. Dit soort systemen reflecteren vooral de vreemde hersenkronkels van "klooien tot het ongeveer werkt en er dan als de sodemieter met je tengels vanaf blijven"-ontwikkelaars.