Persoonlijke ontwikkeling van junior naar medior developer

[Furion2000]

Goedemiddag tweakers,

in november zit ik een jaar in de IT wereld als junior java developer en ook al ben ik nog maar net begonnen ben ik nu op het moment beland dat ik redelijk wat zelf kan doen, de snelheid van werken bij bekende dingen vrij hoog kan zijn en bij nieuwe dingen nog steeds wat tijd kost.

Ik heb bij mijn eerste voorgangsgesprek aangegeven dat ik richting medior developer wil groeien en nu ben ik benieuwd hoe jullie de standaarden van medior developer interpreteren dus:

• Wat is voor jullie een medior developer en het verschil met een junior developer?
• Wat zijn de specifieke competenties en hoe zouden jullie deze ontwikkelen?
• Last but not least, hoe zouden jullie die competenties aankaarten tijdens je werk en tijdens de beoordeling? Een beetje op sociaal vlak laten zien dat je dat stapje extra zet, want ik heb zelfs al eens een collega gehad die veel goede dingen deed die niemand zag en zelfs als 'lui' bestempeld werd omdat zijn werk er onder leed. Extreem geval, maar om het belang te schetsen van deze vraag

Dit wel binnen een bedrijf dat een software pakket ontwikkelt en niet een consultancy club, want ik heb meermaals vernomen dat consultancy clubs iets coulanter zijn qua medior eisen, cru gezegd, omdat de winstmarge op een medior hoger is. Niet om af te geven op die bedrijven, maar om duidelijk te zijn dat het hier om een wat stroevere club gaat waar ze promoties niet voor jou plannen en het inhoud dat alleen ZIJ jou meer betalen.

Volgens de standaarden van het bedrijf en in een notendop is een medior iemand die kan meedenken met oplossingen, op de hoogte is van de markt en de technieken, kennis heeft van het product en goed functioneert.

In mijn voortgangsgesprek samen de volgende doelen uitgezet:

• Snelheid en kwaliteit van code verbeteren
• Boek lezen van Clean code by R.C. Martin

Dat eerste is meer een gevolg van lerend werken en betrokken zijn, dus ik werk 5 dagen op kantoor en praat veel met en luister veel naar de seniors binnen het bedrijf en zodra ik iets tegenkom waar ik nog niet veel mee heb gestoeid ga ik er mee stoeien totdat het lukt (e.g. legacy JSP pagina's, SQL queries).

Het boek gaat mij helpen om beter na te denken over de kwaliteit van de code en zodra hij binnen is knal ik daar door heen, want ben sinds ik werk weer steeds meer met plezier gaan lezen.

Zodra dit boek uit is, wil ik dus iets om handen hebben wat mij die verbeterde beoordeling kan geven en helpen aan de weg richting medior developer. Dit is puur op technisch vlak, want zelf ben ik hiernaast ook bezig met een softskill traject wat leuke insights geeft qua sociaal functioneren binnen een bedrijf.

Lijkt me leuk om te horen hoe jullie dit aanpakken en ik denk dat er wel meer junioren in hetzelfde schuitje zitten van 'het gaat goed, maar ik heb ambitie om een stapje extra te zetten en wil dat graag goed doen'.


Alvast bedankt voor het lezen, want het is zomaar een lang verhaal geworden

[JohnR]

Wat mij betreft is het voor iedere functie hetzelfde
- Junior: heeft begeleiding nodig
- Medior: kan zelfstandig werken
- Senior: slaagt erin om anderen te begeleiden

Verder is het volgens mij gewoon een soort interpretatie en zijn er geen objectieve criteria voor de betiteling junior, medior en senior

[Furion2000]

Lijkt mij vrij kort door de bocht, dat een medior zelfstandig kan werken en dan een punt. Er moeten toch bij veel bedrijven iets meer competenties er aan vasthangen.

Lijkt mij ook sterk en dat er geen gedachte, ervaringen of meningen zijn over het process van junior naar medior. Nu klinkt het als 'je moet het gewoon doen'

Zijn er ook geen voorbeelden van dingen die junioren extra hebben ondernomen, wat de leidinggevenden erg op prijs stelde en jou sneller naar medior hebben gepushed? Dit als voorbeeld.

[ Voor 22% gewijzigd door Furion2000 op 03-08-2018 10:39 ]

[Spectaculous]

Furion2000 schreef op vrijdag 3 augustus 2018 @ 10:38:
Lijkt mij vrij kort door de bocht, dat een medior zelfstandig kan werken en dan een punt. Er moeten toch bij veel bedrijven iets meer competenties er aan vasthangen.

Lijkt mij ook sterk en dat er geen gedachte, ervaringen of meningen zijn over het process van junior naar medior. Nu klinkt het als 'je moet het gewoon doen'

Zijn er ook geen voorbeelden van dingen die junioren extra hebben ondernomen, wat de leidinggevenden erg op prijs stelde en jou sneller naar medior hebben gepushed? Dit als voorbeeld.

Soms moet je gewoon geluk hebben met een situatie. Als je als Junior onder begeleiding van een Senior ergens aan werkt, en de Senior valt uit door bijv. ziekte om vervolgens het project zelf af te ronden met de klant, dan laat dat natuurlijk een goede indruk achter. Je moet hier dan natuurlijk wel klaar voor zijn.

Bij ons had je ook Seniors die niet perse iemand konden begeleiden, maar gewoon zeer specialistisch en ervaren op een bepaald gebied waren, maar verder kan ik me best vinden in het rijtje van JohnR.

Het ligt een beetje aan de bedrijfscultuur hoe dit in z'n werk gaat, maar als de ruimte daarvoor is kan je natuurlijk gewoon je baas vragen "what does it take".

[SmurfLink]

Het wisselt denk ik vrij veel per omgeving.. hier is inderdaad een Medior iemand die zelfstandig kan werken. Je werkt ook wat aan persoonlijke competenties, maar welke dit zijn wisselt per persoon. Het hangt allemaal af van je persoonlijke ontwikkelplan. Dit stel je op aan het begin van het jaar, halverwege een checkup, einde van het jaar evaluatie. Trainingen vindt mijn bedrijf ook belangrijk, als je er daar regelmatig wat van doet geef je aan je ontwikkeling belangrijk te vinden, dan heb je al een streepje voor.

[DeSire]

De labels junior, medior en senior betekenen naar mijn mening nog wel eens wat anders per organisatie. Doorgaans geldt zo'n 3 jaar ervaring en zelfstandig werken in de rol als developer als richtlijn.
Ik zou mij hier vooral niet al te blind op staren. Het is overigens wel goed dat je groeipad in eigen handen neemt. Probeer voor jezelf duidelijk te hebben dat je persoonlijke groei belangrijker is dan het etiketje van medior developer

Bij het werken aan je groeipad zou je nog een aantal dingen kunnen doen:

• Stel jouw eerste vraag ook aan je werkgever. Informeer eens wat jouw werkgever van jou als toekomstige medior verwacht. Maak dit zo concreet mogelijk zodat je hier op beoordeeld kunnen worden in een beoordelingsgesprek.
• Vraag ook eens een senior developer wat hij onder een medior verstaat en waaraan jij nog kunt werken om hier te komen
• Vraag eens aan een senior developer welk groeipad hij of zij zelf heeft doorlopen. Hij/zij is tenslotte zelf ook op een bepaald moment een junior geweest.
• Verzamel feedback van collega's ter voorbereiding op je beoordelingsgesprek. Je kunt je manager sneller overtuigen met feedback van goede mede-devers
• Als je het idee hebt dat je je functie ontgroeit bent, geef dat voor je beoordelingsgesprek duidelijk aan, met het liefst een verwijzing naar je verkregen feedback. Tijdens je beoordelingsgesprek kan je manager dan niet anders dan hier op terug te komen.

Hopelijk heb je hier iets aan.

[Dido]

Ik denk dat je twee dingen los van elkaar moet zien.

In elk vak, maar zeker als developer, geldt vaktechnisch ongeveer het rijtje van JohnR. Hou er daarbij wel rekening mee dat een en dezelfde persoon zowel senior als junior tegelijkertijd kan zijn. Toen ik na 14 jaar professioneel programmeren de overstap maakte naar .NET was is senior developer, en junior .Netter. Uiteraard ging de doorstroom naar medior/senior toen iets sneller dan toen ik begon.
Die vaktechnische classificering is vooral voor jezelf van belang - je moet zelf goed kunnen inschatten of je hulp nodig hebt, en wanneer. Een goed begrip van je vaktechnische senioriteit helpt je bij het maken van keuzes voor jobs, opdrachten, projecten, en om de juiste (meest productieve en voor jezelf meest comfortabele) plek in een team te vinden.

Dan heb je daarnaast de HR-variant van senioreit. Die verschilt indertijd per bedrijf. Zoals je terecht opmerkt, bij veel consultancy-toko's ben je senior zodra ze dat enigszins denken te kunnen verkopen, in sommige hard-core hierarchische organisaties is het een meerjarenplan waarbij je misschien wel stap voor stap door een salarisschaal of twee, drie heen mag wandelen.

Bedenk je dus goed wat je in die beide varianten kunt doen: voor de eerste variant is persoonlijke ontwikkeling belangrijk. Doe (online) cursussen, maak eigen projecten, wewrk mee aan open-sourceinitiatieven, etc.
Voor de tweede variant bekijk je eerst het personeelshandboek, je CAO, of andere HR-bronnen. Bekijk vervolgens hoe je in het gegeven stramien door kunt stromen. Veelal gaat het domweg om een combinatie van twee dingen: tijd (dat wordt vaak gelijkgesteld aan ervaring) en opbouwen van aantoonbare skills (en dat wordt dan vaak afgemeten aan afgeronde cursussen, certificaten, etc.)

Daarnaast geldt bij veel bedrijven een variant op de regel "don't dress for the job you have, dress for the job you want". Als jij graag op papier medior/senior wilt worden, gedraag je dan niet als een junior met ambitie, maar als een medior/senior in de verkeerde schaal. Dat is makkelijker gezegd dan gedaan, maar het komt er vaak op neer dat je bepaalde kansen ziet en aangrijpt. Neem (tijdelijk) zaken over van mediors en seniors als ze met vakantie zijn. Bouw (domein)specifieke kennis op binnen het bedrijf (als iedereen naar jou komt met vragen over applicatie X, dan ben je de facto de senior op die applicatie.
Als (en dat komt vaak voor) juniors alleen coden, mediors daarnaast ook meewerken aan FO's/TO's, en seniors meewerken aan de (software)architectuur, trek dan zo mogelijk wat van de documentatiewerk naar je toe. Maak eens een opzet voor een TO. Lever input voor een architectuurdocument. Draag ideeen aan voor frameworks of tools.

Als je collega's je op meerdere punten niet meer als junior zien wordt het eenvoudiger om ook op papier af te dwingen dat je dat niet meer bent. De genoemde feedback is daar heel belangrijk bij.

[Hahn]

[q]In mijn voortgangsgesprek samen de volgende doelen uitgezet:

• Snelheid en kwaliteit van code verbeteren
• Boek lezen van Clean code by R.C. Martin

Zijn dit de volledige doelen, of heb je ze concreter (meetbaar) gemaakt? Want een boek lezen op zich bereik je niks mee. Je hebt er pas wat aan als je iets met die nieuw vergaarde kennis doet.

En 'snelheid en kwaliteit van code verbeteren' is ook zo vaag dat je er niks mee kunt als je daar niet duidelijkere afspraken over maakt. Want er ontbreekt bijvoorbeeld hoeveel snelheid en hoeveel kwaliteit je denkt te gaan verbeteren.

[Azer]

Hahn schreef op zondag 5 augustus 2018 @ 15:12:
[...]

Zijn dit de volledige doelen, of heb je ze concreter (meetbaar) gemaakt? Want een boek lezen op zich bereik je niks mee. Je hebt er pas wat aan als je iets met die nieuw vergaarde kennis doet.

En 'snelheid en kwaliteit van code verbeteren' is ook zo vaag dat je er niks mee kunt als je daar niet duidelijkere afspraken over maakt. Want er ontbreekt bijvoorbeeld hoeveel snelheid en hoeveel kwaliteit je denkt te gaan verbeteren.

Eens, bovendien is kwaliteit van code lastig te meten en erg subjectief. Wat de ene programmeur hoge kwaliteit vind, zal de ander lage/middelmatige kwaliteit vinden.

Wat ik je als tip wilt meegeven en wat mij veel geholpen heeft om carrière te maken is om ervoor te zorgen dat zichtbaarheid binnen het bedrijf goed is. Zorg ervoor dat iedereen weet wie jij bent en met wat voor problemen ze bij jou langs mogen komen. Je kan nog zo goed zijn in je werk, als de mensen boven jou niet weten wie jij bent ga je nooit promotie maken. Pak credits waar je ze verdiend hebt en werk aan je sociale vaardigheden.

[Mugwump]

Azer schreef op maandag 6 augustus 2018 @ 11:04:
[...]


Eens, bovendien is kwaliteit van code lastig te meten en erg subjectief. Wat de ene programmeur hoge kwaliteit vind, zal de ander lage/middelmatige kwaliteit vinden.

Nou ja, als je bij een bedrijf werkt waar seniors ook daadwerkelijk fatsoenlijk code kunnen schrijven (niet bepaald een gegeven in de IT helaas), dan kun je dat middels reviews o.i.d. wel toetsen. In tegenstelling tot wat sommige mensen denken is er wel degelijk enigszins objectief te oordelen of code voldoet aan gangbare maatstaven.
Onlangs nog een collega gehad die de legendarische woorden "Goede code hoef je niet te documenteren" sprak tegenover een groep met stomheid geslagen collegadevelopers, waarna ik hem maar te kennen heb gegeven dat hij dan maar eens moest beginnen met het schrijven van goede code. Zelden iemand gezien die zulke slechte code produceerde en ook nog zo'n enorme plaat voor z'n kop had.

Wat ik je als tip wilt meegeven en wat mij veel geholpen heeft om carrière te maken is om ervoor te zorgen dat zichtbaarheid binnen het bedrijf goed is. Zorg ervoor dat iedereen weet wie jij bent en met wat voor problemen ze bij jou langs mogen komen. Je kan nog zo goed zijn in je werk, als de mensen boven jou niet weten wie jij bent ga je nooit promotie maken. Pak credits waar je ze verdiend hebt en werk aan je sociale vaardigheden.

Het zal ook een beetje afhangen van het soort bedrijf waar je zit, maar dat is meestal wel een goed advies ja. Pak waar mogelijk ook initiatief. Gezien je positie kun je denken aan wat initiatief nemen / voorstellen doen op het gebied van CI/CD eens een nieuw frameworkje bekijken en de kennis delen en meer van dat soort zaken.
De meeste bedrijven hanteren voor medior een definitie die grofweg neerkomt op het zelfstandig kunnen implementeren van een voorgeschreven ontwerp of specificatie. Ik denk dat TS voor doorstroming dan ook vooral dat hard moet kunnen maken.

[Furion2000]

Ah kijk bedankt voor de reacties, die ik eigenlijk al niet meer verwacht had . De discussie die ik wilde starten met 'niet-collega's'.


Het puntje van het measurable maken is zeker waar, ik kwam hier ook later achter, want voor mij is het qua gevoel misschien zo dat mijn kwaliteit en snelheid verbeterd, maar zonder concrete mijlpalen en resultaten is dit misschien minder duidelijk voor de beoordelaar (auto correct, ik dacht toch zeker dat het 'beoordeler' was ). Ik ga hierover nadenken hoe ik deze twee puntjes meetbaar kan maken, maar misschien hebben jullie alvast tips?


Dan vraag ik mij het volgende nog af, want het gesprek is al geweest:
Is het dan aan te raden dat je dan voor je leidinggevende de 'verassingsfactor' gaat benutten en het duidelijk laat merken dat je meer dan verwacht hebt gedaan wanneer je het daadwerkelijk hebt gedaan?
OF
Is het beter om aan te geven dat je dat extra stukje gaat doen en dat ze als het ware nog kunnen bijsturen?


Het stukje verassen ben ik altijd voorstander van geweest, gewoon omdat ik dat altijd leuker vond, maar effectiviteit is belangrijker en dus is dat tweede misschien wel veel slimmer om te doen.


Met kansen ben ik ook bezig.
Voor het achterhalen van de fout bij het vastlopen van het systeem bij de klant ondersteund er altijd 1 developer applicatie beheer. Dit is vrij nieuw omdat diegene die het altijd vast deed nu de taak overzet naar het hele team. Een taak waar niemand echt tijd voor had op dat moment en heb ik mijzelf aangeboden en komen de mensen met de 'duty' van die week nu ook geregeld naar mij. Kleine taak, maar een begin dacht ik zo.


De kans die zich nu voor doet is REACT, er word door een team architecten onderzocht hoe we onze verouderde eigen framework gaan uit faseren en waarschijnlijk gaan we dit doen aan de hand van REACT. Privé wilde ik al front-end kennis gaan vergaren met VUE, omdat ik daar al over gelezen had en ik het cooler vind ogen, maar het plan is nu om met REACT te gaan klooien zodra ik zeker weet dat dit de keuze gaat worden. Iedere Java-developer word hier basically full-stack opgeleid.


Qua softskills, dat wat @Hahn beschrijft als de andere kant van medior/seniority, het sociale aspect, ben ik ook heel bewust bezig. Vooral doordat het op dit vlak lekker loopt heb ik ook het idee dat er meer uit de halen valt. Dus mijzelf op het technische vlak ontwikkelen om mijn complete ontwikkeling een boost te geven. Persoonlijk heb ik ook het gevoel dat mijn niveau op dit vlak ook automatisch mee groeit wanneer ik meer technische kennis vergaar en dit blijf bespreken met mijn collega's.


Ook weten wanneer je om hulp moet vragen en moet overleggen met anderen loopt lekker en kreeg ik complimenten over tijdens het gesprek. Circle of influence etc. word ons tijdens de softskill cursus bijgebracht en heb ik de afgelopen 6 weken het Covey en de Rose van Leary boeken gelezen en ben ik op dit moment bezig met een boek wat de 'ja maar' beschrijft en je laat omdenken naar een 'Ja en' . Puur om mijzelf hier beter in te verdiepen.


Dus samengevat, zit ik nog met de volgende puntjes:

• Op technisch vlak tips om vergaarde kennis, kwaliteit en snelheid van code meetbaar te maken
• Verassen met ontwikkeling of meenemen in het proces tot ontwikkeling?

Edit: zag dat er tussentijds al wat ideeën/inzichten over code kwaliteit etc. zijn geopperd. Daar zal ik later op reageren.

[pjottum]

Dingen SMART maken helpt je altijd. (Google dat anders ff..)

Daarnaast is het handig uit te zoeken wat je bedrijf wil. En wat voor bedrijf het is. Een programmeur bij detacheerder24 ontwikkeld zich anders dan die van zeg maar een grote supermarktketen uit Brabant. Dus je organisatie heeft een HR met ontwikkeltrajecten etc.

Overigens geldt voor elke promotie die je maakt dat je achteraf pas zelf goed kan bedenken: “oh, maar die junior, die is nog geen medior, want ...” (is mijn ervaring dan he)

[Furion2000]

pjottum schreef op maandag 6 augustus 2018 @ 15:13:
Dingen SMART maken helpt je altijd. (Google dat anders ff..)

Door studie een enorme afkeer voor ontwikkeld door de frequentie van de plannen die je maakt, maar steeds komt het terug als je een goed plan wil maken haha. Het measurable maken van kwaliteit en snelheid is de bottleneck.

Ik denk nu dat dat meer een gevoel is en zojuist verzonnen om misschien op meerdere plekken dan alleen je werk je code laten zien om dat stukje, je weet niet of de senioren wel goede code schrijven, weg te kunnen strepen.

[Bejit]

Hier is een idee. Zijn er bedrijven die je nu zou aannemen als medior?

Zo ja, dan kan iig overstappen naar een medior functie en vind dit al een veel sterker argument, dan dat je aan eisen/competenties a, b, c voldoet.

Competenties die mensen geven aan junior/medior/senior zijn zeer subjectief. Je focust je teveel op het inhoud van het werk, want dit soort zaken zijn vaak interne politieke aangelegenheden.

Vaak worden promoties toch gegeven op gevoel of iemand medior/senior is en of ze deze persoon tevreden moeten houden/of er ruimte voor is. Er zijn zat senior developers die niet veel beter programmeren dan een goede junior/medior.

Heb regelmatig van banen gewisseld in mijn carriere en bijna altijd een stapje naar boven qua functie. Zodra ik moet gaan argumenteren/moeilijk doen na goed overleg voor een promotie, terwijl je boven verwachting presteert/toe bent aan promotie(Lees: de markt biedt je dit) dan stap ik over. Ben er altijd beter van geworden en je hebt niet "je hebt net promotie" label op je voorhoofd staan, die je het jaar daarop weer nekt.

[pjottum]

Furion2000 schreef op maandag 6 augustus 2018 @ 15:23:
[...]

Door studie een enorme afkeer voor ontwikkeld door de frequentie van de plannen die je maakt, maar steeds komt het terug als je een goed plan wil maken haha. Het measurable maken van kwaliteit en snelheid is de bottleneck

.

Waarom?
Ik kan prima indicatoren voor je bedenken, (maar geen programmeur) maar je weet hopelijk zelf waar goede code aan voldoet (niet van stackoverflow gecopieerd, ofzo).

Door het op een of andere manier meetbaar te maken, kan je zelf gaan sturen op wat je wilt. Noem het smart, noem het dom, noem het overdreven, maar jij wil verder komen. Dan zal je zeker dingen moeten doen die aan voorgaande typeringen voldoen.

Ik denk nu dat dat meer een gevoel is en zojuist verzonnen om misschien op meerdere plekken dan alleen je werk je code laten zien om dat stukje, je weet niet of de senioren wel goede code schrijven, weg te kunnen strepen.

Ik snap niet wat je hier zegt? Ga je er nu vanuit dat seniors goede code schrijven? Dat dat een senior maakt? Zijn hier senior programmeurs die durven te zeggen dat ze echt goede code maken? Wat is goed? Goed genoeg?

[Anoniem: 1101689]

Reageer s.v.p. inhoudelijk of reageer niet.

[ Voor 84% gewijzigd door defiant op 06-08-2018 21:15 ]

[merauder]

Een goede developer doet zoveel meer dan alleen goede code afleveren. Denk aan het neerzetten van een ontwerp / architectuur, overleggen met de stakeholders van een project, of het begeleiden van collega-programmeurs.

[Furion2000]

Bejit schreef op maandag 6 augustus 2018 @ 16:28:
Hier is een idee.

Dat is ook een sterk idee, de markt laten bepalen wat je waard bent en ook al zou je willen blijven kun je een aanbod als argument gebruiken. De dilemmas die aan het wisselen van baan hangen zijn voor een ander topic, alleen het is zeker iets om rekening mee te houden en een goede andere kijk.

@pjottum
Daar zijn volgens mij erg veel meningsverschillen over en krijg het idee dat je dat uiteindelijk voor jezelf moet beslissen en ontwikkelen met de input van anderen en het zien van veel code

Dat zeg ik niet, ik bedoelde dat het een goed idee is om ook buiten je werk met de code bezig te zijn met andere mensen vanuit andere bedrijven, zodat je wat meer input van verschillende kanalen krijgt.

Ook bedoel ik niet dat ik SMART slecht is, in tegendeel, je komt er steeds naar terug. Ik zei wel dat ik tijdens mijn studie voor elke scheet SMART moest gebruiken en daardoor op een gegeven moment alles koos behalve SMART, gewoon andere technieken. Nu is de frequentie wat afgezwakt en kan ik het weer rustig gebruiken

@Anoniem: 1101689
Super bedankt voor je uitmuntende advies

@merauder
Je voegt veel hard-en softskills samen in een samenvatting, waar goede code afleveren 1 van is en uitgelicht werd. Je hebt zeker gelijk dat ontwikkelen meer in houd dan alleen code typen.

[ Voor 22% gewijzigd door Furion2000 op 06-08-2018 20:52 ]

[merauder]

@Furion2000
Bij veel bedrijven is de promotie vooral afhankelijk van een totaalpakket. Om van bijvoorbeeld Junior naar Medior te gaan zul je ook op persoonlijk vlak een aantal stappen moeten doorlopen.

Als Senior zal je bijvoorbeeld ook moeten snappen dat er situaties zijn dat je niet de tijd hebt om alles netjes te programmeren, maar om de winkel door te laten draaien je een beetje moet 'vals spelen'.

[Qwerty-273]

Maak in ieder geval niet de klassieke junior (of zelfs pre-junior) fout om alles beter te weten
(niet dat ik dat denk op basis van je berichten hier, maar meer in het algemeen)

Ook jij kan kijken naar de groentjes van het HBO/WO die de eerste dag het bedrijf binnenstappen en pochen de wijsheid in pacht te hebben. En alles wel even beter zullen doen.

Zoals al eerder aangegeven worden deze termen bij elk bedrijf toch net wat anders ingevuld. Bij een detacheerder / consultancy club ben je inderdaad een aantal weken junior (de tijd om kennis van het product op te nemen) om dan vervolgens weggezet te worden als medior. Zelfstandigheid is wat ik zou toekennen aan een medior, zowel op de techniek maar ook de organisatorische kant. Een senior gaat daar zowel organisatorisch breder overheen als ook dieper in op de techniek. Het komt gewoon neer op ervaring.

[Hahn]

merauder schreef op maandag 6 augustus 2018 @ 20:59:

Als Senior zal je bijvoorbeeld ook moeten snappen dat er situaties zijn dat je niet de tijd hebt om alles netjes te programmeren, maar om de winkel door te laten draaien je een beetje moet 'vals spelen'.

Ha, hier gaan we al Ik vind dat je als junior al moet snappen dat je soms concessies moet doen, maar dat je wel voor kwaliteit moet gaan om op de lange termijn het werkbaar te houden.

En juist als senior moet je je meer hard maken om zaken op de goede manier op te lossen, om jezelf niet in de voet te schieten en er later last van te krijgen, als je het mij vraagt