Solliciteren bij bedrijven met legacy code

[Gonadan]

Het is om nogal onrealistisch en ondankbaar om te verwachten dat als je ergens binnen komt alleen maar leuke en nieuwe dingen mag doen. Alle software heeft onderhoud nodig dus bugs fixen en zaken optimaliseren hoort er gewoon bij.

Daarbij is er altijd oude meuk aanwezig. Sterker nog, een ontwikkelaar vindt iets bestaands altijd flink voor verbetering vatbaar, zelfs als hij het zelf een jaar eerder geschreven heeft.

Het is met name belangrijk wat hierboven al genoemd wordt. Is er ruimte voor zaken als versiebeheer en verbetering. Werk je uiteindelijk ook aan nieuwe dingen of blijft het onderhoud?

Zo heb ik ook wel sollicitanten gehad. Met oud spul willen ze niet werken, alleen leuke nieuwe dingen. Wie is er dan niet flexibel? Zoek dan maar verder.

[NMe]

Als je bij een nieuw bedrijf begint is een belangrijke eerste stap om te achterhalen wat je precies kan, en dat is beter te zien bij een reeds bestaand project dan bij een nieuw. Het onderhouden van een bestaand project kan immers meestal zonder klant (of die nou intern is of extern) die in je nek hijgt, wat betekent dat het bedrijf jou in alle rust kan inwerken.

Dit geldt natuurlijk in mindere mate voor bedrijven waar je slechts aan één product werkt, maar daar kies je in dat geval zelf voor. Als je afwisseling wil moet je gaan werken voor een bedrijf dat werkt op projectbasis en zelfs daar zul je jezelf dus eerst echt moeten bewijzen.

[jip_86]

Kom je soms net van school af? Vind altijd nog wel de grootste beperking dat je nooit geleerd word met een bestaand systeem te werken. Je komt dan met je bagage, netjes ontwerpen, documenteren testen in een bedrijf werken. Maar daar blijken ze dat ineens allemaal niet te gebruiken en mag je inderdaad bugs van anderen oplossen.

[gold_dust]

Gonadan schreef op zaterdag 31 december 2016 @ 13:41:
Het is om nogal onrealistisch en ondankbaar om te verwachten dat als je ergens binnen komt alleen maar leuke en nieuwe dingen mag doen. Alle software heeft onderhoud nodig dus bugs fixen en zaken optimaliseren hoort er gewoon bij.

...

Zo heb ik ook wel sollicitanten gehad. Met oud spul willen ze niet werken, alleen leuke nieuwe dingen. Wie is er dan niet flexibel? Zoek dan maar verder.

Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit. En vragen naar ontwikkel proces, versiebeheer, design patterns, ontwerp, is er een architect en een lead developer, achtergrond en kwalificaties van potentiële collega's en dan maar het risico te nemen om veeleisend en arrogant over te komen.

En even verder zoeken is dan inderdaad de betere optie. Wat ik overigens al doe, inmiddels al meerdere functies afgewezen toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

[jeroen3]

gold_dust schreef op zaterdag 31 december 2016 @ 11:20:
[...]
Mijn concrete vraag is, hoe zien andere ontwikkelaars dit en hoe ga je hier mee om?

Daar blijf je vanaf, en huur je de oude mensen weer voor in. Is dat niet mogelijk, dan tel je de reverse-engineering tijd bij je tijdprognose op.

Afgelopen week kreeg ik dus "even" een Visual Basic database voorraad programma op mijn tafel geschoven om te onderhouden. Want developer ging weg. Het programma is geschreven door een student elektrotechniek welke nog nooit iets met software gedaan had. Hij heeft er een 1.5 jaar over gedaan.
Zelf heb ik nog nooit met visual basic gewerkt, of met databases, maar omdat ik zo goed was in embedded C, kon ik dat wel gaan onderhouden. Fijn .

Waarom voor zoiets überhaupt een DIY oplossing gekozen is blijft mij een raadsel. Nu kost het >20k aan loon, en dan heb je straks iets wat "een beetje" functioneert. Maar nee, het is zeker goedkoper.

Zo worden dergelijke project dus geboren.

[ Voor 4% gewijzigd door jeroen3 op 31-12-2016 15:06 ]

[Gonadan]

gold_dust schreef op zaterdag 31 december 2016 @ 14:49:
Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit. En vragen naar ontwikkel proces, versiebeheer, design patterns, ontwerp, is er een architect en een lead developer, achtergrond en kwalificaties van potentiële collega's en dan maar het risico te nemen om veeleisend en arrogant over te komen.

Een drive naar kwaliteit zal nooit als arrogant of veeleisend gezien worden, een weigering om legacy of minder leuke klussen op te pakken wel degelijk.

Het is juist positief als een sollicitant vraagt naar wat hij kan verwachten en dat zekere eisen voor stelt. Passieve chagrijnen die het achteraf niets blijken te vinden hebben we al genoeg. Het toont initiatief en ambitie, dus vooral doen.

Daarbij kan je ook gerust vragen wat later de perspectieven zijn. Gewoon aangeven dat legacy aanpakken geen issue is, maar dat je ook vooruit wilt blijven kijken. Een goede werkgever zal ook daar het positieve van inzien. En dan heb jij duidelijkheid.

En even verder zoeken is dan inderdaad de betere optie. Wat ik overigens al doe, inmiddels al meerdere functies afgewezen toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

Word wakker, je zult _altijd_ problemen van anderen fixen. Of ga je ook weigeren in een team te werken?

Het klinkt nu alsof jij zelf denkt eindbazen code te schrijven en dat de halve wereld troep maakt. Dan kom je dus wel arrogant over.

En uiteraard zitten er ook bedrijven tussen die wel gewoon prutswerk hebben draaien en dat goedkoop opgelost willen hebben. Daar moet ik je wel gewoon in geven, maar het klinkt alsof je ze al veel te snel in die categorie wilt schuiven.

[Dets]

Wat ik met legacy code bedoel is in code die in ieder geval een van volgende eigenschappen heeft:

- geen/gebrekkige documentatie
- geen tests
- geschreven door mensen zonder software engineering achtergrond
- geen behoorlijke version control
- geen OOD of gestructureerd ontwerp
- geen onderliggende architectuur
- oud en geschreven door mensen die het bedrijf al lang verlaten hebben
- vol met magic numbers
- maakt gebruik van legacy libraries
- etc.

Nu ik aan het solliciteren ben merk ik uit de gesprekken dat verschillende bedrijven weer verwachten dat ik code ga optimaliseren, bugs ga fixen, problemen ga oplossen van mensen die vertrokken zijn, etc. Afgezien van dat dit niet mijn interesse heeft vind ik het ook nogal onrealistisch en ondankbaar om van een nieuwe werknemer te verwachten dat die in ongedocumenteerde, slecht geschreven code van jaren oud bugs gaat lopen fixen. Ik heb zoiets van: dan had je meteen maar goede mensen moeten aannemen.

Mijn concrete vraag is, hoe zien andere ontwikkelaars dit en hoe ga je hier mee om?

Tja, dat is legacycode. De levensduur van software wordt schromelijk onderschat. Hoe goed je je best ook doet van jouw code wordt over een aantal jaren hetzelfde gezegd. Bijna alle punten die jij aandraagt zijn gewoon tekenen van "slijtage". Bij een iets grotere organisatie ontkom je er niet aan. Nieuw en (heel) oud staan naast elkaar. Als je alleen maar greenfield werk wil doen dan leer je nooit wat je als erfenis achterlaat.

[jip_86]

gold_dust schreef op zaterdag 31 december 2016 @ 14:49:
[...]toen het fixen van de problemen van anderen aan bod kwam. Dat ze geen goede mensen kunnen vinden of er niet voor willen betalen is niet mijn probleem.

Dus jij laat een collega gewoon stikken als die er niet uit komt? Je laat je baas gewoon zitten als een collega een weekje ziek is en er nog een bug in zijn code zat? Kan zo een lijst aan redenen bedenken waarom je niet altijd de leuke klusjes zal moeten doen of waarom een bedrijf iemand zoekt om een bestaand project over te nemen.

[QvTzKwCi]

Bekend probleem dit; er zit gewoon meer budget aan het begin van een project dan helemaal aan het einde.

Meestal is er zelfs helemaal geen budget meer aan het einde, als de kennis allang vertrokken is. Dan moet het op het budget van beheer - die moet het erbij doen. Maar dat is natuurlijk onrealistisch, want beheer is iets anders dan ontwikkeling en bugfixing. Meestal is beheer wel goed, maar typisch in zo'n scenario dan is ook beheer al gekort in budget. Je ziet dan ook dat het vooral uit de goodwill van werknemers moet komen. Ik bedank meestal, want daar is geen eer te behalen aan zo'n klus.

[FreezeXJ]

Eens met bovenstaande, en zoals een prof van mij ooit zei "het is makkelijker om een scheikundige te leren programmeren dan een programmeur scheikunde te leren". In principe heeft hij gelijk, maar de rotzooi-code die dat oplevert moet daarna wel door een goede programmeur onderhouden worden, anders heb je alsnog niks. Echter, het hangt dan van het bedrijf af of daar budget voor is, en hoe goed ze het achteraf willen hebben.

Je gaat zoals al door anderen aangegeven waarschijnlijk overal legacy-code zien, de vraag is hoe ze ermee omgaan. Vraag dus of er budget is om dat aan te pakken, schrijf een dekkende set unit-tests voor de essentiele stukken, en vraag of ze willen verbeteren (en wie de leiding daarover heeft/krijgt). Roepen dat het beter moet gebeurt overal, maar daadwerkelijk aanpakken is meestal het probleem, dus als je wat wilt, kijk dan of je je bedrijf over de hindernis krijgt. Lukt dat niet, dan wordt het tijd om verder te kijken.

[P1nGu1n]

Perfecte code zal je maar weinig tegen komen (als het al bestaat). Ik begrijp dat je niet wil dat al die punten die je opnoemt, van toepassing zijn, dat zou ik ook absoluut niet doen. Maar wanneer één punt van toepassing is het bedrijf al meteen afschrijven, dat lijkt me wel overdreven. Zolang de basis er al is (dus wel een redelijke architectuur), kan je die legacy library wel vervangen, project in VC zetten of wat documenteren.

downtime schreef op zaterdag 31 december 2016 @ 12:22:
[...]

Dat dus. Of ga mobile apps ontwikkelen. Die zijn veelal ook nieuw. [...]

Juist niet. Mobile apps bestaan inderdaad pas slechts een aantal jaar (8/9 jaar), dus heel oud is de code niet. Maar juist omdat het nog zo relatief nieuw is, gaat de ontwikkeling keihard en is code veel sneller 'legacy'. Zo is bijvoorbeeld het gros van de iOS apps in Objective-C geschreven, wat inmiddels alweer een opvolger heeft: Swift.

[ Voor 19% gewijzigd door P1nGu1n op 31-12-2016 18:58 ]

[Yucon]

P1nGu1n schreef op zaterdag 31 december 2016 @ 18:31:
Perfecte code zal je maar weinig tegen komen (als het al bestaat).

Ik denk dat dat het belangrijkste aspect is, en daarmee mag je 'code' wat breder zien incl zaken als documentatie. Daar zullen we het mee moeten doen maar veel belangrijker is of het bedrijf in kwestie het met de zaken uit de OP eens is. Als je tijdens het gesprek het onderwerp deze kant op weet te krijgen en vervolgens eens een 'als het werkt, dan werkt het' proefballon op laat krijg je vanzelf een idee hoe men er in staat. Als men het wel prima vindt zolang het werkt zul je de afweging moeten maken of je dat acceptabel vindt en daar wel wil werken. En als je merkt dat men het zelf ook niet heel geweldig vindt en er voor open staat er iets aan te doen dan ligt er misschien een mooie uitdaging voor je, tenminste als je het interessant vindt om ook eens naar de onderliggende procedures te kijken en daar in mee te denken.

[WhiteDog]

Tja programmeren is "nu" eenmaal gemakkelijker dan vroeger. Vaak genoeg kan ik nu honderden lijnen code vervangen door één functie uit het framework opdracht een 3rd party library.

Vind het net een uitdaging om legacy code te onderhouden en te verbeteren.

[Bossie]

Yucon schreef op zaterdag 31 december 2016 @ 22:22:
[...]

Ik denk dat dat het belangrijkste aspect is, en daarmee mag je 'code' wat breder zien incl zaken als documentatie. Daar zullen we het mee moeten doen maar veel belangrijker is of het bedrijf in kwestie het met de zaken uit de OP eens is. Als je tijdens het gesprek het onderwerp deze kant op weet te krijgen en vervolgens eens een 'als het werkt, dan werkt het' proefballon op laat krijg je vanzelf een idee hoe men er in staat. Als men het wel prima vindt zolang het werkt zul je de afweging moeten maken of je dat acceptabel vindt en daar wel wil werken. En als je merkt dat men het zelf ook niet heel geweldig vindt en er voor open staat er iets aan te doen dan ligt er misschien een mooie uitdaging voor je, tenminste als je het interessant vindt om ook eens naar de onderliggende procedures te kijken en daar in mee te denken.

Ik denk dat de definitie van perfecte code ook behoorlijk zal verschillen als je dit vraagt aan een ontwikkelaar of een PM

Mijn ervaring is dat documentatie zowel altijd minimaal hebt, als je nu een custom app hebt of een packaged applicatie van een van de grote vendors. Zodra je gaat lezen is toch altijd high level meuk dat in keurig gestandaardiseerde templates is gegoten.

@TS, stroop je mouwen op, het klinkt juist als een rol waar jij het verschil kan maken juist door de genoemde dingen te implementeren.

[DutchKel]

Ik werk intussen 7 jaar als Developer bij een groot bedrijf en intussen mag ik ook legacy code gaan herschrijven omdat de code hopeloos achterhaald is.

De techniek blijft niet stil staan mijn eerste projecten waren in .net 2.0 en intussen ben ik het grootste deel aan het omzetten naar 4.6.2 met alle optimalisaties die er zijn.

Ik heb echter wel als voordeel dat ik mijn eigen code mag herschrijven en als ik die code af en toe zie dan vraag ik me soms wel af hoe ik zoiets hopeloos heb bedacht. Toch kan ik aan de structuur zien dat het mijn eigen code is. Sommige projecten moet ik gewoon even kijken wat er precies gebeurd en dan begin ik vanaf 0 opnieuw.

Heel vroeger heb ik alles netjes gedocumenteerd en overal unit testen van gemaakt, dit heb ik een half jaar volgehouden. Toen kreeg ik bij het beoordelingsgesprek te horen dat ik sneller projecten moest opleveren en ben ik gaan bezuinigen op de documentatie en de unit testen. Dit heeft goed uitgepakt, er werd wel op het einde een integratietest gedaan die het grootste deel testte.

Dit was dus hoe in mijn situatie hetgeen ontstaat waar TS mee zit. Collega's deden hetzelfde en sommige zijn intussen inderdaad vertrokken.

Version control is er wel altijd geweest, eerst dmv mis source safe, erna git en nu via devstash/git incl octopus voor deployment

Nu zijn we wat gegroeid qua developers en zijn we een slag professioneler gaan werken met de deployment zoals met octopus werken en devstash. Maar veel oude projecten zijn ook nog steeds in gebruik.

Als iedereen denkt zoals TS dan worden er bij ons geen nieuwe ontwikkelaars aangenomen. Je krijgt bij ons wel de kans om een project opnieuw te maken maar het moet wel in een redelijk termijn af zijn. Je mag dan denken: dat is niet mijn probleem... Maar dan zit je waarschijnlijk snel zonder werk. Of je daar nou zo gelukkig van wordt.

Beter is om te vragen hoe ze met legacy code omgaan. Mag je het herschrijven vanaf scratch? Of moet je het onderhouden as-is?

[gold_dust]

FreezeXJ schreef op zaterdag 31 december 2016 @ 17:30:
Eens met bovenstaande, en zoals een prof van mij ooit zei "het is makkelijker om een scheikundige te leren programmeren dan een programmeur scheikunde te leren". In principe heeft hij gelijk, maar de rotzooi-code die dat oplevert moet daarna wel door een goede programmeur onderhouden worden, anders heb je alsnog niks. Echter, het hangt dan van het bedrijf af of daar budget voor is, en hoe goed ze het achteraf willen hebben.

Ik kan niet overal op reageren maar dit is ook wat ik nu al 10 jaar zie. Het hele probleem met slechte code is ook alleen maar een oorzaak van alle prutsers die er rondlopen en niet iets wat op zichzelf staat. Het terecht komen in een bedrijf waar ik dit soort code moet onderhouden en debuggen is juist wat ik absoluut niet zoek, dan hadden ze in de eerste plaats maar goede mensen aan moeten nemen.

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

[naitsoezn]

Als je vooraan wilt staan bij het ontwikkelingen van nieuwe toepassingen / toevoegen met een sterk technisch / wetenschappelijk karakter, zul je toch meer moeten weten dan ontwerppatronen, versiebeheer en grondig testen. Je zult vooral thuis moeten zijn in de achtergrond van de toepassingen (bv die chemische / fysische hoek).

offtopic:
Bovendien vind ik je insteek erg negatief, zwart/wit en een tikkeltje ongepast arrogant.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 12:30:
[...]

Ik kan niet overal op reageren maar dit is ook wat ik nu al 10 jaar zie. Het hele probleem met slechte code is ook alleen maar een oorzaak van alle prutsers die er rondlopen en niet iets wat op zichzelf staat. Het terecht komen in een bedrijf waar ik dit soort code moet onderhouden en debuggen is juist wat ik absoluut niet zoek, dan hadden ze in de eerste plaats maar goede mensen aan moeten nemen.

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

Dus iemand die aan onderhoud doet, is volgens jou per definitie geen ontwikkelaar? Of vanwaar anders de schampere aanhalingstekens? De noodzaak voor onderhoud is zeer zeker niet enkel aanwezig door het bestaan van prutsers, wat hierboven al meermaals is geprobeerd aan je uit te leggen. Niet alleen slechte code hoeft onderhouden te worden.

Zoals ook al eerder gezegd, "greenfield"-projecten (nieuwe projecten zonder bagage) zijn zeldzaam. Als je vraag is hoe je op zulke projecten terechtkomt: jezelf eerst bewijzen door (is 'ie weer) onderhoud uit te voeren, en zo te laten zien dat je een fijne collega bent die weet waar 'ie het over heeft, die het bedrijfsproces begrijpt en dan hopen dat er een stuk verouderde techniek op het punt staat om vervangen te worden, of dat er in een nieuwe nood voorzien moet gaan worden.

Je komt zonder indrukwekkend cv niet zomaar ergens binnen om in een zandbak vrijgelaten te worden om volledig losstaand van de rest van het bedrijf (of althans: de in gebruik zijnde ontwikkelprocessen en bestaande systemen) een nieuw project tot uitvoering te brengen. Zo wel, dan is het project waarschijnlijk al niet interessant genoeg.

[ Voor 8% gewijzigd door CodeCaster op 01-01-2017 13:07 ]

[Hydra]

Ik vind het wel wat makkelijk stellen dat dit "overal" zo is. Er is nogal een verschil tussen grote complexe systemen en systemen waar men jarenlang er met de pet naar gegooid heeft. Ik zit zelf bij een klein gespecialiseerde (Java) consulting club en projecten in de eerste categorie doen wij wel. Projecten in de 2e categorie bedanken wij voor.

Mijn ervaring is dat dergelijke prutssoftware vooral het gevolg is van een prutscultuur. Het is voor developers erg makkelijk om het altijd maar op management af te schuiven; management wil features en geen tests. M.i. is dat complete kolder; tests e.d. zijn een onderdeel van mijn werk. Software engineering is een vak. Je gaat van een chirurg ook niet accepteren dat 'ie z'n handshoenen in 't lichaam achterlaat en maar de helft van het aantal hechtingen dat nodig is gebruikt. Software is niet anders; voor alles complexer dan een PoC heb je een fatsoenlijke test coverage nodig want anders flikkert de hele bende om als je iets moet aanpassen.

[CodeCaster]

Hydra schreef op zondag 1 januari 2017 @ 13:10:
Ik vind het wel wat makkelijk stellen dat dit "overal" zo is. Er is nogal een verschil tussen grote complexe systemen en systemen waar men jarenlang er met de pet naar gegooid heeft. Ik zit zelf bij een klein gespecialiseerde (Java) consulting club en projecten in de eerste categorie doen wij wel. Projecten in de 2e categorie bedanken wij voor.

Mijn ervaring is dat dergelijke prutssoftware vooral het gevolg is van een prutscultuur. Het is voor developers erg makkelijk om het altijd maar op management af te schuiven; management wil features en geen tests. M.i. is dat complete kolder; tests e.d. zijn een onderdeel van mijn werk. Software engineering is een vak. Je gaat van een chirurg ook niet accepteren dat 'ie z'n handshoenen in 't lichaam achterlaat en maar de helft van het aantal hechtingen dat nodig is gebruikt. Software is niet anders; voor alles complexer dan een PoC heb je een fatsoenlijke test coverage nodig want anders flikkert de hele bende om als je iets moet aanpassen.

Je realiseert je toch wel dat je daarmee een uitzondering bent? Er lopen gewoon een héleboel middelmatige ontwikkelaars rond, die het belangrijker vinden om de baas of de klant zo snel en goedkoop mogelijk te pleasen en betaald te krijgen dan om een netjes opgezet, goed onderhoudbaar systeem neer te zetten.

Als de kritische massa van een team uit zulke mensen bestaat, kan er nog zo veel moois worden beloofd tijdens om het even welke vergadering, het eindresultaat komt toch weer neer op "het werkt toch?".

Dan nog, de topicstarter is blijkbaar op zoek naar zo'n bedrijf als het jouwe. Vertel hem dan ook hoe je bij jullie binnenkomt of hoe hij zulke bedrijven kan vinden.

[Hydra]

CodeCaster schreef op zondag 1 januari 2017 @ 13:35:
Je realiseert je toch wel dat je daarmee een uitzondering bent?

Nouja. Ik hoop meestal van niet. Maar het is inderdaad wel iets wat me enorm stoort. De cultuur van middelmatigheid bij de meeste software bedrijven. "It compiles, ship it!" zou een grap moeten zijn, niet de harde realiteit.

Dit neemt niet aan dat het is hoe het hoort en stellen dat het "vrijwel altijd" zo gaat vind ik te kort door de bocht en veel te cynisch. Ik zit zelf bij de ING bijvoorbeeld en daar, hoewel er zeker sprake is van legacy en een hoop oude applicaties, gaan ze er wel een heel stuk beter mee om.

Als de kritische massa van een team uit zulke mensen bestaat, kan er nog zo veel moois worden beloofd tijdens om het even welke vergadering, het eindresultaat komt toch weer neer op "het werkt toch?".

Dat is zeker herkenbaar. Ik ben op intake geweest bij een bedrijf waar al 2 collega's een jaar zaten. Ik wist al hoe het er aan toe ging dus ik had er al weinig zin in, maar onze account manager wou, gezien het op de route van een andere intake was, er toch ff langs. Het was zo dramatisch dat we ons als bedrijf daar teruggetrokken hebben; er is weinig dat je kan doen als de meeste andere developers en de architecten (die ons nota bene gevraagd hadden) niet willen veranderen.

Dan nog, de topicstarter is blijkbaar op zoek naar zo'n bedrijf als het jouwe. Vertel hem dan ook hoe je bij jullie binnenkomt of hoe hij zulke bedrijven kan vinden.

Er zijn genoeg grote bedrijven waar het tempo gewoon wat lager ligt en je de tijd krijgt dingen goed te doen. Daarnaast zijn er genoeg kleine consulting clubs die zich specialiseren in echte vakmensen. Ik ben geen grote fan van hier m'n eigen bedrijfsnaam te noemen maar als de TS aangeeft waar z'n interesses liggen kan ik misschien wel suggesties doen.

[psychodude]

Persoonlijk werk ik in een totaal andere tak van sport (geneeskunde en medisch-wetenschappelijk onderzoek). Maar overeenkomstig is zo nu en dan wel het feit dat je het niet altijd eens bent met het eerdere verrichte werk van anderen of de begrijpelijkheid / documentatie soms ver te zoeken is. Belangrijk daarin te realiseren is wel dat dit ook net zo goed vice versa kan zijn. Wat voor jou misschien als eenvoudig en begrijpelijk wordt ervaren, kan voor een ander tenslotte een volkomen raadsel zijn.

Zelf reflectie is ook altijd een mooie. Zo kun je ook prima eigen werk van een aantal jaar geleden terug voorbij zien komen, en jezelf afvragen hoe je dit ooit als dusdanig zo hebt kunnen doen.

Nu kan ik mij prima voorstellen dat je meer zoekt in je werk dan enkel en alleen puin ruimen. Maar ik denk ook zeker niet dat je alles op alles moet zetten om het uit de weg te gaan. Maar het juist ook moet aangrijpen als mogelijkheid om het zelf anders / beter aan te pakken. En ik kan mijzelf ook goed voorstellen dat zodra jij toonbaar kunt laten zien dat jij ook hierin kunt accelereren, je gemakkelijker hogerop kunt komen en ook op die wijze je voet tussen de deur kunt krijgen tot ontwikkeling van nieuw bovenop onderhouden van het oude.

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 13:04:
Dus iemand die aan onderhoud doet, is volgens jou per definitie geen ontwikkelaar? Of vanwaar anders de schampere aanhalingstekens? De noodzaak voor onderhoud is zeer zeker niet enkel aanwezig door het bestaan van prutsers, wat hierboven al meermaals is geprobeerd aan je uit te leggen. Niet alleen slechte code hoeft onderhouden te worden.

Inderdaad, dat vind ik al meer onder beheer vallen. Op zich is het niet erg dat de meeste bedrijven en 'ontwikkelaars' beheer doen maar communiceer dan ook duidelijk over in een sollicitatieprocedure dat je beheerders zoekt in plaats van net te doen alsof je ontwikkelaars zoekt.

Zoals ook al eerder gezegd, "greenfield"-projecten (nieuwe projecten zonder bagage) zijn zeldzaam. Als je vraag is hoe je op zulke projecten terechtkomt: jezelf eerst bewijzen door (is 'ie weer) onderhoud uit te voeren, en zo te laten zien dat je een fijne collega bent die weet waar 'ie het over heeft, die het bedrijfsproces begrijpt en dan hopen dat er een stuk verouderde techniek op het punt staat om vervangen te worden, of dat er in een nieuwe nood voorzien moet gaan worden.

Ik verwacht geen 'Greenfield projecten', vrijwel niemand ontwikkelt nog volledig van scratch en dat is ook niet zinvol. Er zijn voldoende goede open source frameworks te vinden die volwassen, gedocumenteerd, en getest zijn die je kan toepassen. Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
[...]
Inderdaad, dat vind ik al meer onder beheer vallen.

Dus iemand die een pull request indient voor een opensourceproject is geen ontwikkelaar meer, maar een beheerder? Dan is het probleem dat hier speelt eenvoudigweg een definitiekwestie, waarbij jij het bij het verkeerde eind hebt. Dat gaat uiteraard voor problemen zorgen tijdens je zoektocht. Dat is verder niet erg, kan gebeuren.

Verder houdt greenfield niet in dat je zonder libraries of frameworks werkt, maar juist dat je niet gebonden bent aan eerdere projecten binnen het bedrijf.

[ Voor 19% gewijzigd door CodeCaster op 01-01-2017 15:47 ]

[CurlyMo]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

Ik neem aan dat je hier met Open Source ook de gratis beschikbare projecten bedoelt. Vanuit die aanname is het juist niet gek dat dat kan. Een OSS project kan eisen dat code volgens een bepaalde kwaliteit wordt opgeleverd, omdat ze geen targets te halen hebben, geen klanten om tevreden te stellen binnen een bepaalde tijd, ze hebben op de eerste plaats hun eigen plezier en kwaliteit te bewaken.

In mijn vrije tijd probeer ik regelmatig bijdragen te leveren aan OSS projecten. Laatst nog bezig geweest met het integreren van interrupt ondersteuning in libuv (NodeJS eventing library). Het hele proces heeft me misschien totaal 8 uur gekost (over meerdere weken), met 100de review commentaren. Dat lag deels aan mijn gemakzucht. Liever horen dat een bepaald haakje anders geschreven dient te worden in hun code stijl, dan dat ik dat allemaal van tevoren had uitgezocht.

In de organisatie waar ik werk wordt veel OSS gebruikt. Ook passen we veel OSS aan. Er dient dus budget vrij gemaakt te worden om code terug te brengen upstream, want dat kost (door de eisen die OSS projecten kunnen stellen) nu eenmaal veel tijd en dus geld.

[RagingPenguin]

gold_dust schreef op zondag 1 januari 2017 @ 15:32:
[...]
Ik verwacht geen 'Greenfield projecten', vrijwel niemand ontwikkelt nog volledig van scratch en dat is ook niet zinvol. Er zijn voldoende goede open source frameworks te vinden die volwassen, gedocumenteerd, en getest zijn die je kan toepassen. Gek genoeg zit het met veel open source projecten dan wel weer vrij goed met de kwaliteit van de code maar lukt het veel bedrijven intern niet op dit op orde te krijgen of om enigszins competente ontwikkelaars te vinden.

Al begin je een nieuw project met een framework is het nog steeds een Greenfield project. Een Greenfield project houd in dat je geen balast hebt van een bestaand systeem en zegt verder niets over hoe je het nieuwe project aanpakt.

En zoals men boven mij ook al zei: onderhoud is gewoon development. Maar zelfs binnen een bestaand systeem kan je prima nieuwe dingen bouwen. Beheerders zijn voor de dev gewoon gebruikers die verder niets aan de code veranderen (hoop je )

[gold_dust]

Onderhoud/bugs fixen vind ik geen development, uitbreiding van een bestaand systeem wel. Daar ligt denk ik ook het probleem in de software sector: er wordt geen duidelijk onderscheid gemaakt tussen onderhoud/beheer van software enerzijds en development anderzijds. Dat is al iets nuttigs wat er uit dit topic is gekomen en waar ik bij een volgend gesprek gericht naar zal vragen.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development

Daar verschil jij dan van mening over met een heleboel ontwikkelaars.

Maar waaróm dan niet? Hoef je bij bugfixes geen analyse, ontwerp, tests, implementatie en uitrol- en eventueel rollback-plan te maken? Wat is er zo significant anders aan bugfixing dan aan het ontwikkelen van nieuwe features of nieuwe projecten? Of vind je het gewoon niet leuk om aan oude code te zitten, of soms te moeten reverse engineeren omdat iets niet volledig is afgetest en/of -gespect?

Ik zou bij eventuele sollicitaties in ieder geval niet dezelfde bewoordingen gebruiken als hier, inclusief sarcastische aanhalingstekens. Zoals naitsoezn al aangaf komt dat nogal denigrerend over. Dus niet: "Wordt er van mij verwacht dat ik moet gaan 'ontwikkelen' oftewel bugfixen, of zijn jullie serieus op zoek naar een developer?" of iets in die trant.

Door bugfixing expliciet géén ontwikkeling te noemen, ga je in ieder geval geen hoge ogen gooien op je intakes.

[ Voor 9% gewijzigd door CodeCaster op 01-01-2017 17:10 ]

[NMe]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development,

Dus alle code die jij schrijft is perfect, en blijft altijd werken ongeacht nieuwe beperkingen die door veranderingen in andere hard- of software door de jaren heen worden opgelegd? Met zo'n instelling waarbij je je te goed voelt om bestaande producten te onderhouden ga je het ver schoppen, hoor...

[Bossie]

NMe schreef op zondag 1 januari 2017 @ 17:08:
[...]

Dus alle code die jij schrijft is perfect, en blijft altijd werken ongeacht nieuwe beperkingen die door veranderingen in andere hard- of software door de jaren heen worden opgelegd? Met zo'n instelling waarbij je je te goed voelt om bestaande producten te onderhouden ga je het ver schoppen, hoor...

De code die ik schrijf, is op dat moment perfect, of beter gezegd, fit for purpose
Ik kijk er nu al naar om binnenkort een aantal items te herschrijven die ik drie jaar geleden heb gemaakt.

Niet omdat de code slecht is, maar bijvoorbeeld omdat ik nu als developer nu drie jaar verder ben en door andere ervaringen/projecten zie hoe ik een x-aantal oudere items kan optimaliseren.

Ben ik nu een uitzonderlijke developer
Overigens is 2/3 in mijn werk onderhoud/changes van oude code, niet omdat de code niet goed is, maar omdat de ondersteunende bedrijfsprocessen of bijvoorbeeld KPI-definities ook veranderen.

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 16:48:

Daar verschil jij dan van mening over met een heleboel ontwikkelaars.

Ik ken verschillende ontwikkelaars, internationaal, en ik ken niemand die zich ontwikkelaar noemt en gericht op zoek gaat naar functies die voornamelijk bestaan uit het fixen van bugs en het refactoren van code. Helemaal als als het om een erfenis gaat van een spreekwoordelijke scheikundige die denkt dat hij kan programmeren en die inmiddels het bedrijf verlaten heeft. Dat je je eigen bugs fixt en code onderhoudt vind ik dan wel weer evident.

Of vind je het gewoon niet leuk om aan oude code te zitten, of soms te moeten reverse engineeren omdat iets niet volledig is afgetest en/of -gespect?

Zoals Hydra ook al benoemd, bepaalde systemen is zo met de pet naar gegooid dat je dat die beter links kan laten liggen. Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

[CodeCaster]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]

ik ken niemand die zich ontwikkelaar noemt en gericht op zoek gaat naar functies die voornamelijk bestaan uit het fixen van bugs en het refactoren van code

Ik ook niet, maar zo begonnen we niet. Jij noemde mensen die bugs fixen "ontwikkelaars", inclusief aanhalingstekens. En dat is gewoon denigrerend en gaat je geen steek verder helpen. Hier op het forum niet, en bij je sollicitaties al helemaal niet.

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken.

Dat ben ik helemaal met je eens, en de kwestie hóe je dat nu goed kunt bepalen vind ik ook een interessante. De rest van je opmerkingen vind ik alleen nogal een beetje onnodig kwetsend richting een heleboel mensen.

[ Voor 33% gewijzigd door CodeCaster op 01-01-2017 17:35 ]

[orf]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]
Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

Een dag meedraaien in een team. Je kan dan precies zien hoe de werkwijze is, zonder dat het mooier gemaakt wordt door iemand in een sollicitatiegesprek. Voor het bedrijf kan het ook een mooie manier zijn om te zien wat ze met jou in huis halen, hoe je omgang met toekomstige collega's was, etc.

[NMe]

gold_dust schreef op zondag 1 januari 2017 @ 17:26:
[...]

Zoals Hydra ook al benoemd, bepaalde systemen is zo met de pet naar gegooid dat je dat die beter links kan laten liggen. Het is soms lastig om vooraf te bepalen waar je wel of niet moet gaan werken. Ik ben inderdaad niet het type dat de rommel van anderen gaat lopen opruimen en daar wil ik inderdaad graag van de voren duidelijkheid over hebben.

Het soort bedrijf dat jou op je eerste werkdag aan het werk zet op een nieuw project zonder een goed beeld te hebben van wat je kan is nou net het type bedrijf waar dat soort brakke code geschreven wordt die niemand meer wil onderhouden. Je leidinggevende heeft dan totaal geen idee van wat je nou écht kan maar laat je wel meteen los op een nieuw project, daar krijg je nogal makkelijk slecht onderhoudbare code van. En als je vervolgens na je proeftijd geen vast contract krijgt zitten ze met die code te kijken.`

[jip_86]

Daar moet je dan ook beheerders voor in dienst nemen

[gold_dust]

CodeCaster schreef op zondag 1 januari 2017 @ 17:33:
Ik ook niet, maar zo begonnen we niet. Jij noemde mensen die bugs fixen "ontwikkelaars", inclusief aanhalingstekens. En dat is gewoon denigrerend en gaat je geen steek verder helpen. Hier op het forum niet, en bij je sollicitaties al helemaal niet.

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

[Tsurany]

Volgens mij heb jij totaal geen idee welke complexiteit kan komen kijken bij het toevoegen van features, het fixen van bugs en vervolgens het implementeren hiervan in grote applicaties in bedrijfskritische omgevingen.

Het is prima dat jij liever vanaf nul begint, maar schrijf dan niet alle andere ontwikkelaars weg als mensen die nergens over na hoeven te denken. Dat is onnodige generalisatie, daar kom je echt niet ver mee.

De meeste bedrijven zijn op zoek naar ontwikkelaars om systemen te onderhouden en uit te breiden simpelweg omdat vrijwel geen enkel bestaand bedrijf zich kan veroorloven om elke twee jaar alle applicaties weg te gooien en een compleet nieuw software landschap neer te zetten. Een bedrijf heeft nu eenmaal zijn applicaties die al jaren draaien en waar ze enorm afhankelijk van zijn. Juist in zulke situaties kan het een hele uitdaging zijn om features toe te voegen en bestaande bugs te fixen vanwege de complexiteit.

Als jij enkel vanaf scratch wilt werken moet je kijken naar startups, bedrijven die echt vanaf niks beginnen. En dan natuurlijk na twee jaar vertrekken aangezien je anders features moet gaan toevoegen aan bestaande code.

[orf]

Tsurany schreef op maandag 2 januari 2017 @ 00:52:
De meeste bedrijven zijn op zoek naar ontwikkelaars om systemen te onderhouden en uit te breiden simpelweg omdat vrijwel geen enkel bestaand bedrijf zich kan veroorloven om elke twee jaar alle applicaties weg te gooien en een compleet nieuw software landschap neer te zetten. Een bedrijf heeft nu eenmaal zijn applicaties die al jaren draaien en waar ze enorm afhankelijk van zijn. Juist in zulke situaties kan het een hele uitdaging zijn om features toe te voegen en bestaande bugs te fixen vanwege de complexiteit.

Hier een mooi (maar oud) artikel over het herschrijven van code:

The idea that new code is better than old is patently absurd. Old code has been used. It has been tested. Lots of bugs have been found, and they’ve been fixed. There’s nothing wrong with it. It doesn’t acquire bugs just by sitting around on your hard drive. Au contraire, baby! Is software supposed to be like an old Dodge Dart, that rusts just sitting in the garage? Is software like a teddy bear that’s kind of gross if it’s not made out of all new material?

https://www.joelonsoftwar...u-should-never-do-part-i/

[CurlyMo]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Vergeet niet dat ze in veel bedrijven onbekend onbekwaam zijn. Men vraagt dus naar wat jij ontwikkelaar type 2 noemt, omdat ze niet weten dat ze daadwerkelijk ontwikkelaar type 1 nodig hebben.

Je komt dus zoals je zelf beschrijft in een organisatie terecht met "legacy code", omdat men simpelweg niet beter weet. Het zijn ook zoals je zelf zegt de onderzoekers die hebben leren programmeren. Weten zij veel van unit tests, OOP, design patterns enz. Men weet dus simpelweg niet hoe belangrijk ontwikkelaar type 1 is, omdat ze die wereld niet kennen.

Ik heb wel gemerkt hoe flexibel dit type collega daarbij is. Iemand die in staat is zijn onderzoekskennis om te zetten naar (brakke) code laat zien dat er een zekere potentie zit. Ik vind het te gek om te zien dat niet-programmeurs met bepaalde ICT tools toch tot een oplossing kunnen komen. Ze hebben alleen de juiste kaders nodig zoals jij ook beschrijft.

Naar mijn mening vervul je je rol pas echt goed als je vanuit type 2 een organisatie binnenkomt en je jezelf in een type 1 ontwikkelaar kan brengen, omdat je de organisatie heb kunnen laten zien dat dat type ontwikkelaar nodig is, en je daarin tevens je collega's kan meenemen. Zij hebben immers de inhoudelijke (onderzoeks)kennis die je zult moeten extraheren.

In mijn organisatie heb ik een jaar lang als type 2 ontwikkelaar gewerkt. Zo leerde ik de systematiek, (on)bekwaamheid van mijn collega's, (gebrek aan) documentatie enz. kennen zonder mijn collega's tegen het hoofd te stoten. De output die men wist te generen was echt van hoge kwaliteit, alleen de weg er naartoe erg inefficiënt. Er zat heel veel kennis die alleen niet goed tot uiting kwam (d.w.z. slechte programmatuur, documentatie, tests). Daarna ben ik langzaam verbeteringen aan gaan brengen en heb ik deze in een proof-of-concept gezet. Daar werd het management enthousiast van waarna ik ben doorgegroeid naar jouw ontwikkelaar type 1. Dat vraagt alleen wel een andere houding, zoals velen hier ook beschrijven.

Nu werken we in een structuur waarin collega's aan het documenteren zijn geslagen, unit tests aan het uitdenken zijn, schema's ontwerpen. Strict gezien allemaal niet eens perse ICT, maar gewoon een juiste structuur aanbieden. De techniek komt pas om de hoek zodra iets daadwerkelijk in een technische implementatie moet worden omgezet, het uitdenken daarnaartoe kan prima met niet programmeurs zolang je ze maar helpt. Nu ben ik zelf de schakel tussen het ruwe ICT programmeerwerk en het onderzoek. Ik vertaal al het denkwerk naar technische implementaties, maar de uitwerking wordt dan weer gedaan door echte programmeurs.

Dat is voor mij dan ook de belangrijkste meerwaarde van Agile werken. Niet persé snel ontwikkelen, maar samenwerking en communicatie op gang brengen en houden.

[ Voor 5% gewijzigd door CurlyMo op 02-01-2017 11:20 ]

[Tarkin]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Je begaat een denkfout. In jouw ogen is elke bug al doodgeanalyseerd en moet de developer enkel nog de code aanpassen. Uit ervaring weet ik dat het zo niet is.

Het begint meestal met een mooi uitgebreid ticketje van de helpdesk: applicatie xyz crasht... (en ja dat is het hel ticket). En bij sommige legacy kan je dan een paar dagen analyseren uitzoeken waarom dat gebeurt, overleggen wat de juiste oplossing is om binnen de gekende muren toch de boel deftig te fixen,... Er is enorm veel uitdaging te vinden in bugfixing, je leert er ook de systemen en de domeinkennis veel beter door.

In al mijn verschillende jobs is het altijd al beide geweest, nieuw development maar ook bugfixing. Soms was dat gewoon standaard 30% van de week bugfixing en 70% van de week nieuw development. Op andere jobs was dat wat meer flou.

Ik moet wel eerlijk zeggen dat als jij met zo'n arrogantie in mijn team komt, je er ook niet lang gaat zitten. Of het nu enkel nieuw development is of niet, je komt me een beetje over als de "rockstar programmer", je vind van jezelf dat enkel jij goede code kan schrijven en dat al de rest shit is...

[Ryur]

Tarkin schreef op maandag 2 januari 2017 @ 11:25:
[...]


Je begaat een denkfout. In jouw ogen is elke bug al doodgeanalyseerd en moet de developer enkel nog de code aanpassen. Uit ervaring weet ik dat het zo niet is.

Het begint meestal met een mooi uitgebreid ticketje van de helpdesk: applicatie xyz crasht... (en ja dat is het hel ticket). En bij sommige legacy kan je dan een paar dagen analyseren uitzoeken waarom dat gebeurt, overleggen wat de juiste oplossing is om binnen de gekende muren toch de boel deftig te fixen,... Er is enorm veel uitdaging te vinden in bugfixing, je leert er ook de systemen en de domeinkennis veel beter door.

In al mijn verschillende jobs is het altijd al beide geweest, nieuw development maar ook bugfixing. Soms was dat gewoon standaard 30% van de week bugfixing en 70% van de week nieuw development. Op andere jobs was dat wat meer flou.

Ik moet wel eerlijk zeggen dat als jij met zo'n arrogantie in mijn team komt, je er ook niet lang gaat zitten. Of het nu enkel nieuw development is of niet, je komt me een beetje over als de "rockstar programmer", je vind van jezelf dat enkel jij goede code kan schrijven en dat al de rest shit is...

Ben het volledig met jou eens!

Ik zelf werk bij een bedrijf waar ik ook zo'n 30/70 verhouding heb (momenteel zelfs meer nieuwe ontwikkelingen omdat dat even meer prio heeft, is al verkocht aan de klant).

De bugfixes die ik doe komen binnen, en dan moet je uitzoeken waar het ligt. Omdat de systemen waar ik mee werk bedrijfkritisch is (werk in de ERP-wereld) kan ik niet zomaar een fix opleveren zonder het zeer uitgebreid te testen/documenteren. Als het mis gaat bij mijn bugfix kan het zo zijn dat ik 1 miljoen euro heb verspilt bij de klant (of zelfs nog meer).
Dus ja ik moet een uitgebreide analyse maken: hoe kom ik zo dat de bug triggert, welke randvoorwaarden zijn er nodig; wat is mijn besloten oplossing (ontwerp); implementatie & daarna het allerbelangrijkste: testen op een lokale omgeving, en daarna als ik volledig zeker ben: testen op de accept omgeving.
En dan dit allemaal documenteren, want mocht er dus een fout zijn gemaakt, dan moet er snel achterhaalt kunnen worden wat de wijzigingen zijn (en vooral WAAROM!).

En ik ben het volledig eens wat hier wordt gezegd over de houding.

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 00:07:
[...]

Het wordt nu meer een semantische discussie over wat een ontwikkelaar is maar er zit een groot verschil tussen enerzijds iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt. Ik kan me eigenlijk niet voorstellen dat je dit verschil niet ziet.

Uit de reacties haal ik dat de meeste ontwikkelaars van het laatste type zijn en ook de meeste bedrijven zijn op zoek naar dat type ontwikkelaar. Dat is prima, maar dus niet wat ik wil ga doen.

Serieus, get over yourself. Het is een totaalpakket. Als programmeur ben je niet alleen maar bezig met nieuw spul schrijven, je moet ook zorgen dat reeds bestaande software maar eens blijft werken. Als je je daar te goed voor voelt niet je dat zelf weten maar hou asjeblieft op met al dat gesteek onderwater naar al die "inferieure ontwikkelaars" die zich wel "tot dat niveau verlagen." Er is hier maar één iemand die totaal geen team player lijkt te zijn en daardoor inferieur zou zijn als ontwikkelaar. In het bedrijf waar ik werk zou je met deze instelling waarschijnlijk al niet door de sollicitatieprocedure heen komen.

Je gaat echt waar je ook terecht komt bedrogen uitkomen als je denkt niet met enige regelmaat bugs te hoeven fixen, al dan niet in andermans code.

[Lethalis]

gold_dust schreef op zondag 1 januari 2017 @ 16:33:
Onderhoud/bugs fixen vind ik geen development, uitbreiding van een bestaand systeem wel.

Ik zal het doorgeven aan de helpdesk hier, kunnen ze de bugs zelf gaan oplossen voortaan

Natuurlijk is bug fixen development. Sterker nog, het kan een stuk complexer zijn dan nieuwe code schrijven. Daarnaast vind ik de speurtocht ook wel interessant.

Het is ook gewoon een verlengde van jouw eigen werk. Als jij applicatie X bouwt en oplevert, vervolgens constateren mensen daar problemen in, dan is het toch logisch dat jij deze ook oplost?

Dat hoort gewoon bij jouw werk. Jij bent immers ook de "information expert" ( ). Jij hebt de code geschreven, dus jij weet het beste hoe je de bug moet oplossen.

[CurlyMo]

Ik denk dat de discussie die TS aanhaalt niet helemaal onzin is. Natuurlijk zit er wel een verschil tussen "software architect" of een "php ontwikkelaar". Helemaal als ze in de hiërarchie van junior naar senior worden gezet of in opleidingsniveau. Een WO software architect heeft nu eenmaal veel meer taken en verantwoordelijkheden dan een MBO php programmeur. In dat kader gezien is het niet gek dat TS zo denkt.

[...] iemand die kort gezegd requirements analyseert, hier voor algoritmen ontwikkelt, een software ontwerp uitdenkt, dit in een klasse hiërarchie omzet, een implementatie schrijft, over performance nadenkt en code optimaliseert, tests ontwikkelt, documentatie schrijft en anderzijds iemand die dit alles gegeven krijgt en verder niet niet over dit alles hoeft na te denken en kleine features toevoegt en bugs fixt.

De vraag is alleen of je de scheidslijn zo zwart / wit kan maken. Als jij als software architect in het verleden een stukje code hebt geschreven waar een bug in zit, ga je dan aan je junior ontwikkelaar vragen om er dagen op te zwoegen terwijl je het zelf misschien in een uurtje hebt opgelost, omdat het nu eenmaal jouw code was toen je zelf nog ontwikkelaar was en je nu eenmaal veel meer ervaring hebt.

Ik kan echter niet voor TS beoordelen of hij/zij de kennis en/of ervaring heeft om direct in een senior architecten functie terecht te komen of niet. Alleen kan je nooit afdwingen dat je geen rot klusjes doet, of je nu senior bent of niet en of je nu in een WO functies zit of niet. Die dingen horen er nu eenmaal altijd bij.

Daarnaast willen veel organisaties eerst de kat uit de boom kijken. Ben je wel geschikt om door te groeien naar een betere functie met die verantwoordelijkheden of straal je teveel arrogantie uit om een team te kunnen leiden van ontwikkelaars. Zoals je merkt heb je met je vraag al de nodige weerstand gecreëerd, dus beschouw dat als een les voor hoe je het beter niet kunt aanpakken

[gold_dust]

Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

[BCC]

NMe schreef op zondag 1 januari 2017 @ 18:02:
[...]
Het soort bedrijf dat jou op je eerste werkdag aan het werk zet op een nieuw project zonder een goed beeld te hebben van wat je kan is nou net het type bedrijf waar dat soort brakke code geschreven wordt die niemand meer wil onderhouden. Je leidinggevende heeft dan totaal geen idee van wat je nou écht kan maar laat je wel meteen los op een nieuw project, daar krijg je nogal makkelijk slecht onderhoudbare code van. En als je vervolgens na je proeftijd geen vast contract krijgt zitten ze met die code te kijken.`

Soms gaat het wel goed hoor Bijvoorbeeld bij de zogenaamde innovatie factories: kruising tussen een startup en enterprise. Daar zijn er een paar van in Nederland bijvoorbeeld Nedap of TKH Groep of Philips.

Nedap zoekt nog ontwikkelaars trouwens: http://lifeatnedap.com/

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 14:05:
Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

Het is geen "type." Het is deel van elke developmentbaan. Je houdt jezelf voor de gek.

[Hydra]

Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:



Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Ik herken mij dan ook zeker in de OP in dat ik het liefst in die initiele fase zit; dat is waar de belangrijke architecturele beslissingen genomen worden. Dat is waar je het meeste "hoe gaan we dit oplossen" werk gaat vinden.

Als je als developer met alle plezier in een product dat in de 3e fase zit werkt; helemaal prima. Maar het is gewoon een stuk minder leerzaam en uitdagend omdat het grootste deel van wat de applicatie kan en hoe het gedaan wordt wel vast staat. Natuurlijk kunnen sommige bugs lastig te vinden zijn en zal je regelmatig nieuwe features moeten bouwen. Maar het is compleet wat anders dan een product from scratch bouwen. En ja, dat soort banen zijn een stuk lastiger om te vinden. De makkelijkste manier is via consulting clubs; bij grote bedrijven worden de initiatie gedaan door gespecialiseerde clubs waarna het 'afmaakwerk' in-house of door een grotere integrator gedaan wordt.

NMe schreef op maandag 2 januari 2017 @ 14:12:
Het is geen "type." Het is deel van elke developmentbaan. Je houdt jezelf voor de gek.

Nou nee. Ik krijg meer het idee dat een hoop mensen hier het vervelend vinden te horen dat ze niet het maximale uit hun ontwikkeling halen. Dat is an sich prima maar als je gaat stellen dat er geen verschil is in product fases, dan hou je jezelf pas echt voor de gek.

[ Voor 13% gewijzigd door Hydra op 02-01-2017 14:15 ]

[CurlyMo]

gold_dust schreef op maandag 2 januari 2017 @ 14:05:
Bedankt voor de reacties zover. Wat wel duidelijk is geworden is dat verreweg de meeste ontwikkelaars van het type 'software onderhouden en bugs fixen is' en dat bedrijven ook bijna uitsluitend op zoek zijn naar dit type ontwikkelaar. Niet dat daar iets mis mee is, maar ik was me hier eigenlijk niet zo bewust van. Dit inzicht is zeker iets waar ik wat mee kan tijdens mijn volgende sollicitatiegesprekken, ik heb er al weer 4 gepland voor deze en volgende week .

Je blijft het maar zwart/wit maken. In de meeste bedrijven begin je als dat type ontwikkelaar, omdat ze nu eenmaal eerst willen weten wie je bent en of je wel geschikt ben om aan grote projecten van scratch af aan deel te nemen of ze te leiden. Op die manier leer je de werkwijze van een bedrijf ook het best kennen. Daarnaast zal het gewoon nooit voorkomen dat je nooit meer bugs fixed of software onderhoudt. Er bestaat dus geen ontwikkelaar van type 1 of type 2 zoals jij ze typeert. Alleen ontwikkelaars met een focus op het één of het ander. Waar je focus ligt is afhankelijk van je kennis, ervaring en de tevredenheid die men met je heeft binnen het bedrijf. Zoals ook in het plaatje hierboven geschetst.

[Hydra]

CurlyMo schreef op maandag 2 januari 2017 @ 14:14:
Je blijft het maar zwart/wit maken. In de meeste bedrijven begin je als dat type ontwikkelaar, omdat ze nu eenmaal eerst willen weten wie je bent en of je wel geschikt ben om aan grote projecten van scratch af aan deel te nemen of ze te leiden. Op die manier leer je de werkwijze van een bedrijf ook het best kennen. Daarnaast zal het gewoon nooit voorkomen dat je nooit meer bugs fixed of software onderhoudt. Er bestaat dus geen ontwikkelaar van type 1 of type 2 zoals jij ze typeert. Alleen ontwikkelaars met een focus op het één of het ander. Waar je focus ligt is afhankelijk van je kennis, ervaring en de tevredenheid men met je heeft binnen het bedrijf. Zoals ook in het plaatje hierboven geschetst.

Dat is dus gewoon niet waar. Accenture bijvoorbeeld heeft hier aparte teams voor; die zijn vaak sterk gespecialiseerd in een bepaald gebied (bijvoorbeeld identity management) en zetten de basisarchitectuur neer waarna als het eenmaal staat de rest van het werk door meer algemeen ervaren developers gedaan wordt.

In de bankenwereld worden bedrijven als Xebia (en dit is ook waar wij vaak in zitten) uitgenodigd voor de initiele architectuur. De nieuwe Wehkamp big data architectuur bijvoorbeeld is ook neergezet door een stel Xebianen waarna de zaak overgenomen wordt door in-house developers.

[NMe]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

[afbeelding]

Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Het punt is helemaal niet dat die fases niet zouden bestaan. Het punt is dat de TS zich te goed voelt om naast het werk in de eerste twee fases ook die andere twee te doen. Daarmee creëert hij alleen werk in die andere twee fases voor alle andere developers die ooit voor dat bedrijf gaan werken.

[jeroen3]

Mensen zoals TS zijn de reden dat mensen zoals TS geen werk naar wens kunnen vinden.
Of is dat te kort door de bocht?

Maar leuke moraalridders zijn jullie, volgens mij er is een verschil tussen de situatie waar jullie het hebben over "met enige regelmaat bugs fixen" en het "hopeloos legacy systeem" waar gold_dust over praat.

Ik ken de situatie prima, ik fix regelmatig andermans code. Echter is er ook software welke ooit in elkaar geflanst door een lang vertrokken collega in een taal welke al >10 jaar antiek is. Om het leuk te maken koppelt dat programmaatje een legacy ERP pakket met inmiddels legacy printer server via een legacy databaseconnector.
Met 0 commentaar, 0 ontwerp en 0 versiebeheer allemaal nog met form1, button1 standaardnamen. Je kunt gewoon niet verwachten dat iemand hierin bugs gaat oplossen zonder omscholing tot archeoloog.
Wat moet je daar nu mee doen, beste moraalridders?

Dit is helaas de real-world situatie, en mede hierdoor is er dus een "tekort aan programmeurs", of een overschot aan "hopeloze legacy systemen". Kies maar.

waarom zit de toon voorbeel knop toch zo dichtbij de verstuur knop

[ Voor 86% gewijzigd door jeroen3 op 02-01-2017 14:24 ]

[Hydra]

NMe schreef op maandag 2 januari 2017 @ 14:17:
Het punt is dat de TS zich te goed voelt

Je stelt je enorm aan naar mijn mening. Hij heeft gewoon een voorkeur voor een bepaald soort werk. Niks mis mee. Ik ook; da's de reden dat ik in de consulting hoek zit.

Ik heb jaren terug een sollicitatie gedaan bij Cap Gemini (meer om te zien wat ik waard was maargoed) en dat was ook een onderhoudstoko. Die deden inderdaad niks anders dan software maintenance. Nieuwbouw werd daar gewoon door een andere club binnen Cap gedaan. Dus je had daar al binnen een redelijk middelmatige integrator een club met developers die het liefst beheer op bestaande software deden. Tja. Dan vind je het maar arrogant dat ik zo iets van "nee laat maar" heb...

[ Voor 42% gewijzigd door Hydra op 02-01-2017 14:23 ]

[Tarkin]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

[afbeelding]

Er is een enorm verschil tussen development in de eerste fase en development in de laatste fase. Sorry maar als je in die laatste 'sterfhuis' fase van een product zit (dat is waar vrijwel alle COBOL developers nu zitten bijvoorbeeld) ben je echt heel ander werk aan het doen. En dat is ook gewoon niet het meest uitdagende werk.

Ik herken mij dan ook zeker in de OP in dat ik het liefst in die initiele fase zit; dat is waar de belangrijke architecturele beslissingen genomen worden. Dat is waar je het meeste "hoe gaan we dit oplossen" werk gaat vinden.

Als je als developer met alle plezier in een product dat in de 3e fase zit werkt; helemaal prima. Maar het is gewoon een stuk minder leerzaam en uitdagend omdat het grootste deel van wat de applicatie kan en hoe het gedaan wordt wel vast staat. Natuurlijk kunnen sommige bugs lastig te vinden zijn en zal je regelmatig nieuwe features moeten bouwen. Maar het is compleet wat anders dan een product from scratch bouwen. En ja, dat soort banen zijn een stuk lastiger om te vinden. De makkelijkste manier is via consulting clubs; bij grote bedrijven worden de initiatie gedaan door gespecialiseerde clubs waarna het 'afmaakwerk' in-house of door een grotere integrator gedaan wordt.


[...]


Nou nee. Ik krijg meer het idee dat een hoop mensen hier het vervelend vinden te horen dat ze niet het maximale uit hun ontwikkeling halen. Dat is an sich prima maar als je gaat stellen dat er geen verschil is in product fases, dan hou je jezelf pas echt voor de gek.

Ik heb momenteel beide werelden. Ik ben actief aan het ontwikkelen aan een nieuwe applicatie, daarnaast beheer ik er nog een stuk of 5 (bugfixes, maandelijkse maintenance). Het is daarmee dat het niet zo zwart wit is, Ik hou er ook niet van om veel bugs op te lossen maar dat compenseert wel aangezien ik ook met toffe zaken bezig ben (zoals nieuw ontwikkeling met the latest and greatest...).

Als hij enkel fase1 ontwikkeling wil doen, dat hij dat dan maar zoekt, helaas zit zijn ego in de weg om te beseffen dat hij deel van het probleem is. Dat wij dagelijks code van zulke mannetjes mogen oplossen. Want eenmaal de initiele fase voor bij (bv in productiestelling) dan zijn zulke mensen ook als eerste weer weg. En dan kunnen andere mensen alle shit oplossen.

En elke developer die beweert dat hij geen bugs schrijft, tja dan weet ik ook hoe serieus ik die moet nemen,

Hydra schreef op maandag 2 januari 2017 @ 14:17:
[...]


Dat is dus gewoon niet waar. Accenture bijvoorbeeld heeft hier aparte teams voor; die zijn vaak sterk gespecialiseerd in een bepaald gebied (bijvoorbeeld identity management) en zetten de basisarchitectuur neer waarna als het eenmaal staat de rest van het werk door meer algemeen ervaren developers gedaan wordt.

In de bankenwereld worden bedrijven als Xebia (en dit is ook waar wij vaak in zitten) uitgenodigd voor de initiele architectuur. De nieuwe Wehkamp big data architectuur bijvoorbeeld is ook neergezet door een stel Xebianen waarna de zaak overgenomen wordt door in-house developers.

dus als ik het goed versta zitten de meer ervaren developers in-house? Ik lees tussen de lijnen door dat er gewoon een halve assemblage lijn is opgezet bij accenture waar dan bepaalde mensen veel hetzelfde doen (architectuur opzetten) en van zodra het geraamte opstaat gaan ze toch voor interne developers? Wat is dan de meerwaarde van in zo'n team te zitten? Dat je 1 bepaald soort architectuur per jaar kan opzetten maar je developt niets?

[ Voor 17% gewijzigd door Tarkin op 02-01-2017 14:27 ]

[NMe]

Hydra schreef op maandag 2 januari 2017 @ 14:19:
[...]

Ik heb jaren terug een sollicitatie gedaan bij Cap Gemini (meer om te zien wat ik waard was maargoed) en dat was ook een onderhoudstoko.

Er is niks mis met niet bij bedrijven willen werken die alleen aan onderhoud doen. Maar dat is niet wat de TS zegt. Hij wil onder geen beding onderhoud plegen aan bestaande software. Dat bestaat gewoon niet, in geen enkele baan.

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 14:23:
En elke developer die beweert dat hij geen bugs schrijft, tja dan weet ik ook hoe serieus ik die moet nemen,

Het zou fijn zijn als mensen stromannen achterwege zouden laten. De TS beweert nergens dat hij geen bugs produceert; dat doet iedere dev. Waar hij het over hebt is devs / teams die technical debt produceren. En dat is compleet iets anders en daarnaast een software killer.

Serieus iedereen; kom op. Op iedere conferentie zijn dit soort zaken gewoon enorm populaire onderwerpen. Hoe ontwikkel je software die ook op de lange termijn werkbaar blijft. Als je als bedrijf hier gewoon met de pet naar gooit en alleen maar developers aanneemt en houdt die zo snel mogelijk 'features' bouwen zonder daarbij te testen en te refactoren ben je slecht bezig. Het is niet meer dan normaal dat een bepaalde categorie developers die dit soort shit serieus neemt dan niet voor je wil werken.

[gold_dust]

@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

[Tarkin]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Wat je dan zoekt is werken in een agile omgeving met een "you build it, you maintain it" manier.

Als je het in die richting verwoord, ga je misschien wat meer kans hebben om het kaf van het koren te scheiden op je sollicitatie.

Puur uit interesse, over hoeveel ervaring langs jouw kant spreken we? Medior/senior/iets anders?

[Hydra]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen.

Don't worry. Dit is een normale fase waar veel developers doorheen gaan als ze hun vak erg (/ te ) serieus gaan nemen. Ik zit zelf ook altijd 't liefst in de eerste fase, dan kun je het nog goed op zetten. De meeste van m'n consultant collega's zitten er een beetje hetzelfde in; als je het goed opzet (goeie test coverage, test automation, continuous integration / deployment) heb je daar de rest van je lifecycle profijt van. Als dat niet gebeurd is en het een een grote teringzooi dan ben je 2 weken bezig met een feature die je een dag zou moeten kosten gewoon omdat iedere keer alles omdondert.

Het fijne aan projecten met een hoge mate van maturity is dat je nooit terug hoeft te komen in de avonden / weekenden. Shit werkt gewoon. Software gaat echt niet 'zomaar' opeens in de avond stuk. Dan was het al stuk en was je d'r gewoon nog niet achter gekomen. Voor dat soort software pas ik ook; dan laat ik met alle plezier de mensen die de rotzooi gemaakt hebben die ook opruimen.

[NMe]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

En hoe bepaal je op je solliciatiegesprek zonder inzage gehad te hebben in het bestaande systeem of het goed geschreven code is?

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 14:23:
dus als ik het goed versta zitten de meer ervaren developers in-house?

Nee, ik beschreef het onduidelijk (sorry): wat ik bedoel is developers met ervaring die meer in de breedte zit dan in de diepte. Dus minder gespecialiseerd en vaak ook minder ervaren.

Ik lees tussen de lijnen door dat er gewoon een halve assemblage lijn is opgezet bij accenture waar dan bepaalde mensen veel hetzelfde doen (architectuur opzetten) en van zodra het geraamte opstaat gaan ze toch voor interne developers? Wat is dan de meerwaarde van in zo'n team te zitten? Dat je 1 bepaald soort architectuur per jaar kan opzetten maar je developt niets?

Nee. Wat je meestal ziet is dat een X aantal externe developers aangenomen worden om de eerste 6-12 maanden ofzo het begin neer te zetten. Incluus alle laatste best practices e.d. (project waar ik nu op zit is een microservice architectuur met Java, Spring Boot, Docker, Kubernetes, extreem hipster ). Na verloop van tijd worden externen langzamerhand vervangen door internen waarbij een tijd in parallel gewerkt wordt zodat deze best practices overgedragen worden.

Er wordt vaak erg lacherig gedaan over "consultants" en als je alleen maar met mensen van Cap of Logica gewerkt hebt snap ik dat ook wel. Maar over het algemeen zijn dit soort mensen juist door een uitgebreide ervaring (de meeste van mijn collega's zitten ook meer dan 10 jaar in 't vak) wel erg goed in wat ze doen. En kunnen de in-house developers hier veel van leren.

NMe schreef op maandag 2 januari 2017 @ 14:38:
En hoe bepaal je op je solliciatiegesprek zonder inzage gehad te hebben in het bestaande systeem of het goed geschreven code is?

Gewoon vragen om eens mee te kunnen kijken (eventueel indien nodig na tekenen van een NDA). Waarom zou een bedrijf jou de hemd van 't lijf mogen vragen maar niet hun eigen shit op tafel moeten leggen?

[ Voor 12% gewijzigd door Hydra op 02-01-2017 14:42 ]

[CodeCaster]

Hydra schreef op maandag 2 januari 2017 @ 14:27:
Hoe ontwikkel je software die ook op de lange termijn werkbaar blijft. Als je als bedrijf hier gewoon met de pet naar gooit en alleen maar developers aanneemt en houdt die zo snel mogelijk 'features' bouwen zonder daarbij te testen en te refactoren ben je slecht bezig. Het is niet meer dan normaal dat een bepaalde categorie developers die dit soort shit serieus neemt dan niet voor je wil werken.

Volgens mij stelt niemand hier dat ter twijfel.

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt

Dat heb ik je al in een paar posts proberen uit te leggen: omdat je begrippen misbruikt om jouw ongenoegen kenbaar te maken. Mensen die onderhoud plegen op bestaande software zijn wél ontwikkelaars. Code die perfect is opgezet maar niet gedocumenteerd is géén legacy. Mensen die bugs fixen zijn niet per definitie ondergeschikt aan mensen die nieuwe systemen ontwerpen.

Begrijp me niet verkeerd, ik kan me verder helemaal vinden in je verhaal. Volgens mij vindt niemand het leuk om ongeteste, ontestbare, veel te lange lappen code te onderhouden die van toevalligheden aan elkaar hangen en waar iedere collega al jaren met een grote boog omheen loopt. Volgens mij solliciteert niemand bewust op een rol waarin ze op een doodlopende techniek met een slecht opgezet stuk software moeten gaan werken. Dat is namelijk niet goed voor je persoonlijke ontwikkeling, voor je stressniveau, voor de eer van je werk en voor je toekomstkansen.

Het enige dat ik, en enkele anderen met mij hier, proberen te vertellen is dat je moet stoppen met zo schamper te doen over onderhoud. Het hóórt bij het vak, en imperfecties in het proces en product zijn een gegeven. Zo niet, dan mag je je in je handen wrijven dat je een fijne werk- of opdrachtgever hebt gevonden, maar in mijn ervaring (nu zeven jaar fulltime werkzaam bij uiteenlopende werk- en opdrachtgevers) zijn die uitzonderlijk zeldzaam.

Dus als je vraag nu is hoe je zo'n baas vindt: dat is een goede vraag, en de nuttige tips dáárover druppelen nu in de laatste paar reacties het topic binnen. De rest is ruis.

[ Voor 15% gewijzigd door CodeCaster op 02-01-2017 15:00 ]

[Tarkin]

Bij ons is het helaas de andere kant van de medaille.

Het huidig project waar ik nu zit kan met alle moeite van de wereld geen inhouse developers vinden (België en toch een niet al te kleine partij in de sociale zekerheid). Dus wat doen ze, ze huren vrolijk externe mensen in.

Er heerst ook nog steeds een hoog cowboy gehalte bij ons, iedereen die binnenkomt wilt natuurlijk vooral nieuw development doen en heeft duidelijke ideeën wat hij wil en waar hij naartoe wil. Met als gevolg dat we een gigantische verscheideneid aan stacks hebben. Noem alle hypes van de laatste 15 jaar in java gebied en we hebben wel een applicatie die we ondersteunen. Heel veel van de mensen blijven ook maximum 2 jaar, daarna zijn ze weg met als gevolg dat er een gigantische legacy hell is.

Er komen weer nieuwe developers bij en die zien dan wat een troep het allemaal is, ze zagen en klagen er over en ze krijgen een nieuw projectje (want ze willen de externen ook een beetje te vriend houden zodat ze er toch op z'n minst een jaartje zitten) en die gaan dan ook hun eigen inzichten erin steken. Iedereen weet dat we het aantal technologien moeten verminderen en toch blijven we jaar na jaar vrolijk hetzelfde doen.

90% van deze issues komt door mensen zoals TS hier. Ze hebben van zichzelf een heel hoge dunk, hebben geen zin om een teamplayer te zijn (want mijn idee is het enige goede idee, afspraken die de code quality bevorderen gebeuren niet want dan moeten ze misschien iets doen waar ze principieel tegen zijn). Na 2 jaar zijn ze weg wegens niet interessant genoeg meer en kan de rest van het bedrijf de shit opkuisen.

Om dan nog eens hier op een techforum te komen doen alsof 95% van de developers 2erangs developers zijn, tjah dan ga je hier en daar wel een tegenwoord krijgen. Maar hoge bomen vangen nu eenamal veel wind. Daarom dat ik benieuwd ben naar zijn ervaring en zijn verwezelijkingen. Misschien is het wel de nieuwe Martin Fowler of Kent Beck, who nows?


edit: even ter verduidelijking ik ben ook een externe hier

[Hydra]

CodeCaster schreef op maandag 2 januari 2017 @ 14:53:
Dat heb ik je al in een paar posts proberen uit te leggen: omdat je begrippen misbruikt om jouw ongenoegen kenbaar te maken.

Mensen zouden ook eens kunnen proberen uit te vogelen wat een ander bedoelt in plaats van maar lekker Hollands meteen in de verdediging te schieten. Ik ben het er best mee eens dat de TS het niet goed verwoord heeft maar het was ook overduidelijk gewoon niet goed verwoord. Als je (niet jij persee maar mensen hier in het algemeen) dan meteen boos gaat lopen wezen dan heeft dat het effect dat je ook niet meer probeert te zien wat iemand nu echt bedoelt.

Komt nog eens bij dat "software in maintenance mode" gewoon een compleet bekende algemene term is. Dus het is de normaalste zaak van liever niet willen werken aan software in maintenance mode. Dat mensen dit hier dan opvatten als geen bugs willen fixen (of nog erger, je eigen bugs niet willen fixen) licht echt compleet aan de mensen die kennelijk om een of andere reden die terminologie niet kennen. Dat is dus wat anders dan geen "maintenance" willen doen.

[ Voor 24% gewijzigd door Hydra op 02-01-2017 15:04 ]

[Tarkin]

Hydra schreef op maandag 2 januari 2017 @ 15:01:
[...]


Mensen zouden ook eens kunnen proberen uit te vogelen wat een ander bedoelt in plaats van maar lekker Hollands meteen in de verdediging te schieten. Ik ben het er best mee eens dat de TS het niet goed verwoord heeft maar het was ook overduidelijk gewoon niet goed verwoord. Als je (niet jij persee maar mensen hier in het algemeen) dan meteen boos gaat lopen wezen dan heeft dat het effect dat je ook niet meer probeert te zien wat iemand nu echt bedoelt.

Geef toe dat hij dan toch echt beter zijn best kan doen, als je zegt dat het grootste deel van de developers tweederangs zijn, dan krijg je inderdaad dat soort reacties

Ik zie in ieder geval een verschil tussen een ontwikkelaar die nieuwe dingen ontwikkelt en iemand die alleen maar onderhoud en bug-fixing doet en dan vaak ook nog in de puinhoop die door iemand anders is achtergelaten. Uit de reacties hier peil ik dat veel 'ontwikkelaars' van het tweede type zijn en bedrijven ook naar dit type 'ontwikkelaar' op zoek zijn. Daar was ik me tot nu eigenlijk niet bewust van en het is gewoon niet wat ik zoek.

[Tsurany]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Waarom daar zo op gereageerd wordt is omdat jij developers die niet aan deze fasen werken weg zet als mensen die mindere ontwikkelaars zijn, minder capaciteiten hebben en tevreden zijn met "simpel werk". Dat is een groot bord voor je kop hebben.


Ik vind de eerste fase van projecten ook veel leuker. Met een geheel nieuw team vanaf scratch beginnen en kijken welke uitdagingen je tegen komt, hoe je dat gaat oplossen en hoe je een architectuur gaat neerzetten die meerdere jaren mee kan. Dat is persoonlijke voorkeur, dat kan prima. Dat betekent echter niet dat ik developers die in een andere rol zitten weg ga zetten als mindere developers. In welke fase van een product je zit zegt namelijk helemaal niks over je kwaliteiten als developer.

Ik heb genoeg goede developers gezien die een mainframe systeem keurig overeind kunnen houden en kunnen debuggen en uitbreiden wanneer nodig inclusief testen en documentatie. En ik heb genoeg developers gezien die met nieuwe technieken een project opstarten, nieuwe applicatie neerzetten en een ongedocumenteerde puinhoop achterhalen waar niets mee aan te vliegen is.

[Hydra]

Tarkin schreef op maandag 2 januari 2017 @ 15:11:
Geef toe dat hij dan toch echt beter zijn best kan doen, als je zegt dat het grootste deel van de developers tweederangs zijn, dan krijg je inderdaad dat soort reacties

Het tweederangs deel is jouw interpretatie. Een test automation engineer doet ook compleet wat anders. Maakt hem dat tweederangs? Nee. Daarbij snap ik best dat hij na al die aanvallen hier wat gepikeerd reageert; men gooit continue met stromannen om hun eigen boze reacties te kunnen plaatsen. Voorbeeld:

Ik kan niet overal op reageren maar dit is een goede. Ik zal voortaan tijdens een sollicitatiegesprek direct vragen of het gaat om voornamelijk bux-fixen en onderhoud of nieuwe ontwikkeling, waarbij het ene het andere natuurlijk niet helemaal uitsluit.

Over het "voornamelijk" wordt voor het gemak maar even heengelezen. De TS zegt niet dat hij niet wil bugfixen. Als mensen gewoon eens goed lezen wat de TS daadwerkelijk zegt en plaats van het in hun eigen hoofd te laten escaleren naar "als je bugs fixt ben je geen developer".

Er is, nogmaals, een enorm verschil tussen software in maintenance mode (of erger; in sterfhuis mode) en software in de initiele fase. En zo is er ook een groot verschil in developers die een voorkeur voor de eerste of de laatste hebben. Die reacties hier tonen volgens mij aan dat de meeste mensen uberhaupt nog nooit van product life cycle gehoord hebben.

Tsurany schreef op maandag 2 januari 2017 @ 15:13:
Waarom daar zo op gereageerd wordt is omdat jij developers die niet aan deze fasen werken weg zet als mensen die mindere ontwikkelaars zijn, minder capaciteiten hebben en tevreden zijn met "simpel werk". Dat is een groot bord voor je kop hebben.

Komop zeg. Niet inzien dat er een enorm verschil is in een architectuur neerzetten en een beetje de laatste issues in een pakket dat volgens jaar vervangen gaat worden; dat is pas een bord voor je kop hebben.

En sorry maar als je als developer continue werkt aan een systeem dat met duct-tape aan elkaar hangt en bij iedere release er aan alle kanten dingen stuk gaan, waarom blijf je dan doorsukkelen? Als developers neem je of je werk serieus of niet. Als je je werk wel serieus neemt ga je volgens mij de situatie verbeteren; dus door je team een kant op te krijgen of (als het eerste niet lukt) het ergens anders te zoeken. Is het nu zo moeilijk gewoon eens de OP nog eens goed te lezen in plaats van te gaan hakke-takken over terminologie?

[ Voor 26% gewijzigd door Hydra op 02-01-2017 15:25 ]

[Soundless]

Even de topic geskimt:

Is het voor OP niet een idee om dan te solliciteren bij bedrijven die klantspecifieke producten maakt en niet bij bedrijven die 1 groot product hebben waarop voortborduurt wordt.

Je komt dan waarschijnlijk in de web of mobile wereld terecht. Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).

Voor de rest ben ik het wel met de meesten hier eens dat het een totaalpakket is. Ook bij bedrijven waar nieuwe producten worden gemaakt, moet nog onderhoudt gepleegd worden aan oudere producten. En daar ga je geheid ook aan werken.

Succes iig met je zoektocht

[Cloud]

Hydra schreef op maandag 2 januari 2017 @ 15:21:
Komop zeg. Niet inzien dat er een enorm verschil is in een architectuur neerzetten en een beetje de laatste issues in een pakket dat volgens jaar vervangen gaat worden; dat is pas een bord voor je kop hebben.

Dat verschil zien we allemaal wel toch? Het probleem was dat de TS de scheiding legde tussen 'architectuur neerzetten' is ontwikkelen en al het andere is 'beheer'. Zelfs toen er voor de duidelijkheid nóg eens naar gevraagd werd. Dat schoot vermoedelijk veel mensen in het verkeerde keelgat

En zo is er ook een groot verschil in developers die een voorkeur voor de eerste of de laatste hebben.

Volgens mij is er geen ontwikkelaar die de voorkeur geeft aan sterfhuis software, toch? Of ontwikkelaar die het liefst onderhoud pleegt op een product dat nu actief is. De meeste ontwikkelaars zullen het liefst aan nieuwe dingen werken maar het meeste developmentwerk (uitzonderingen daargelaten) is dat simpelweg niet. Of je krijgt situaties zoals Tarkin beschrijft en dat wil je óók niet. Althans als bedrijf moet je dat niet willen.

Die reacties hier tonen volgens mij aan dat de meeste mensen uberhaupt nog nooit van product life cycle gehoord hebben.

Dat is wel heel kort door de bocht en niet de reden dat het topic de kant op ging die het ging.

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Je komt dan waarschijnlijk in de web of mobile wereld terecht. Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).
[...]

Detachering vraag ik me af of dat wel zo vaak zo is. Mijn ervaring (via een kennis die in die wereld zit) is dat detacheerders er vaak pas bij gehaald worden als het mis dreigt te gaan, dus als projecten niet gaan zoals ze moeten gaan. Dan is die mooie 'schone lei'-fase al lang voorbij. Maar goed, er zijn ongetwijfeld ook detacheerders die niet in die fase werken maar daar moet je dan wel op letten

[scrappy.doo]

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Of je moet je detacheren, daar is dat volgens mij ook zo dat je vooral nieuwe dingen maakt (geen ervaring mee).

Paar jaartjes detachering gedaan en dat is over het algemeen hartstikke leuk, omdat je zo in een relatief korte tijd veel verschillende aspecten van het vak en verschillende bedrijven kan ervaren. Het heeft mij zeker geholpen om te ontdekken wat ik nu echt leuk vind.

Het is echter zeker geen garantie dat je als detacheerder vooral nieuwe dingen maakt. Voor mij persoonlijk was het 50/50 nieuwe projecten vs legacy (waaronder ook echt 3/4 jaar niks anders dan bugs fixen wat gewoon niet leuk is en demotiverend werkt, voor mij in ieder geval)

[Hydra]

Soundless schreef op maandag 2 januari 2017 @ 15:30:
Is het voor OP niet een idee om dan te solliciteren bij bedrijven die klantspecifieke producten maakt en niet bij bedrijven die 1 groot product hebben waarop voortborduurt wordt.

Het probleem is juist dat er in die "web agency" wereld veel prutsers actief zijn. Daar wordt ook veel meer op kosten gezeten dan bij de clubs waar je aan grote complexe software werkt.

scrappy.doo schreef op maandag 2 januari 2017 @ 16:15:
Het is echter zeker geen garantie dat je als detacheerder vooral nieuwe dingen maakt. Voor mij persoonlijk was het 50/50 nieuwe projecten vs legacy (waaronder ook echt 3/4 jaar niks anders dan bugs fixen wat gewoon niet leuk is en demotiverend werkt, voor mij in ieder geval)

Het is een beetje afhankelijk van waar je werkt. De kleinere gespecialiseerde clubs hebben over 't algemeen meer werk dan mensen en doen er alles aan om hun mensen niet weg te jagen. Dus daar heb je over het algemeen een stuk meer inbreng wat betreft welke klus je krijgt dan bij de grote handelaren in warm vlees.

[ Voor 25% gewijzigd door Hydra op 02-01-2017 17:13 ]

[CurlyMo]

Hydra schreef op maandag 2 januari 2017 @ 14:17:
[...]


Dat is dus gewoon niet waar. [...] die zijn vaak sterk gespecialiseerd in een bepaald gebied [...]

Hierop terugkomende, je hebt helemaal gelijk, maar dat zijn zoals je zegt gespecialiseerde clubs. Mijn punt gaat nu juist over een reactie een stukje later:

Hydra schreef op maandag 2 januari 2017 @ 15:21:
En sorry maar als je als developer continue werkt aan een systeem dat met duct-tape aan elkaar hangt en bij iedere release er aan alle kanten dingen stuk gaan, waarom blijf je dan doorsukkelen? Als developers neem je of je werk serieus of niet. Als je je werk wel serieus neemt ga je volgens mij de situatie verbeteren; dus door je team een kant op te krijgen of (als het eerste niet lukt) het ergens anders te zoeken. Is het nu zo moeilijk gewoon eens de OP nog eens goed te lezen in plaats van te gaan hakke-takken over terminologie?

Punt is nu juist dat TS afhaakt wanneer code 'legacy' blijkt te zijn, terwijl je je kwaliteit ook kan inzetten om verbeteringen aan te brengen in de code of het werkproces. Ik vind dat zelf kort door de bocht.

Ik zie in mijn eigen organisaties het juist daar mis gaan. ICT'ers worden binnen gebracht als zendelingen: "Wij gaan met slimme ICT oplossingen je probleem oplossen" en het antwoord is dan "Ik wist niet dat ik een probleem had". Oftewel, vaak een onbewuste onbekwaamheid. In mijn organisatie is er juist veel behoefte aan het type ICT'er die de verbinding kan leggen met de medewerker die ook de legacy code schreef én er nog wel werkt. Hem of haar proberen mee te nemen in een nieuw werkproces.

Het staat TS vrij om daar af te haken, maar dan mis je ook mooie kansen.

[mekkieboek]

Hydra schreef op maandag 2 januari 2017 @ 14:13:
Ik snap echt niet waarom mensen hier nu zo buitengewoon agressief reageren. Nog nooit van de product lifecycle gehoord kennelijk:

Voor agile / iteratief ontwikkelen, wat je steeds vaker ziet, is dit model niet meer correct of zelfs achterhaald. Je itereert in feite doorlopend door fase 2, 3 en 4. Dat betekent dat je als architect, ontwikkelaar en tester voorturend in een mix zit van ontwerp / ontwikkeling, bugfixing, refactoring, code af laten sterven.

Het is trouwens interessant om te zien of agile / iteratief ontwikkelen op termijn gaat leiden tot minder spaghetti code. Dit omdat je minder in een kortlopend project een grote bak met code ontwikkelt (binnen budget en na jou de zondvloed). Maar meer over langere tijd features toevoegt en toe moet kunnen blijven voegen. En door die langere tijdspanne dus ook de voordelen gaat merken van (bijvoorbeeld) onderhoudbare code. Voeg daaraan toe pair programming waarbij devvers zich aan elkaar kunnen optrekken naast het voorkomen van (ontwerp)fouten.

[onetime]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Tot en met het onderstreepte zullen de meeste mensen geen probleem met je mening hebben.

De haren gaan overeind staan bij het vette deel, met namen het door jou zelf al gecursifeerde deel.
Over het algemeen zijn er coderingsstandaarden. Als het daar niet aan voldoet, zou het niet geaccepteerd behoren te zijn. Alles wat geaccepteerd is is dus per definitie voldoende netjes. En daar twijfel jij aan...?

[RagingPenguin]

onetime schreef op maandag 2 januari 2017 @ 22:02:
[...]

Tot en met het onderstreepte zullen de meeste mensen geen probleem met je mening hebben.

De haren gaan overeind staan bij het vette deel, met namen het door jou zelf al gecursifeerde deel.
Over het algemeen zijn er coderingsstandaarden. Als het daar niet aan voldoet, zou het niet geaccepteerd behoren te zijn. Alles wat geaccepteerd is is dus per definitie voldoende netjes. En daar twijfel jij aan...?

"Voldoende netjes" is natuurlijk een erg rekbaar begrip. En ik denk dat als je er van uit gaat dat ieder bedrijf strikt omgaat met codestandaarden dan ben ik bang dat je iets te optimistisch bent.

[CMD-Snake]

Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen. Alleen maar leuke dingen doen en geen zin hebben in onderhoud van bestaande zaken. Als je een toetje wil zal je ook eerst je groente moeten opeten.

Geen idee of TS net uit de schoolbanken is met die houding, maar let erop als je solliciteert. Als het hier er vanaf druipt, dan merkt elke interviewer dat ook. Met zo'n houding kan je heel eenvoudig een sollicitatie verpesten. Die enorme hautain over andermans code kan heel snel in het verkeerde keelgat schieten.

[Harm_H]

OP, je hebt helemaal gelijk. Je moet zeker streven naar transparante, version-controlled, otap apllicaties!

Het meest irritante is als er niet objectief wordt besproken. 'Senioriteit' an sich is geen argument (te lui om uit te leggen waarom x zo gaat, of bang om vervangen te worden).

Hoe vind je gedegen code omgeving?
- Niet, want ben je dan nodig?
- Start-up
- Game developer
- Website bouwer (mits nieuw)
- Apps (veelal nieuwe technologie)

Ps. Als je ook echt goed bent moet je simpelweg bij een premium detacheerder gaan werken, xebia, werd al genoemd, die zijn te duur voor bug fixing en onderhoud.

[ Voor 16% gewijzigd door Harm_H op 03-01-2017 03:11 ]

[BarôZZa]

CMD-Snake schreef op maandag 2 januari 2017 @ 23:24:
Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen. Alleen maar leuke dingen doen en geen zin hebben in onderhoud van bestaande zaken. Als je een toetje wil zal je ook eerst je groente moeten opeten.

Geen idee of TS net uit de schoolbanken is met die houding, maar let erop als je solliciteert. Als het hier er vanaf druipt, dan merkt elke interviewer dat ook. Met zo'n houding kan je heel eenvoudig een sollicitatie verpesten. Die enorme hautain over andermans code kan heel snel in het verkeerde keelgat schieten.

Wat een ramp. Als je een beetje kan programmeren dan is een sollicitatiegesprek vooral om te kijken of het bedrijf iets voor jou is. Niks mis met beleefde eerlijkheid.

Als je gevoel al slecht is, dan moet je er nooit aan de slag gaan. Als het werkelijk zo slecht is dan is de kans groot dat:

1.Het enorm slecht voor je ontwikkeling is. Je leert niks van baggercode doorspitten en waarschijnlijk is er weinig kennis in huis om van te leren. Er is ook een risico dat je jezelf verkeerde gewoontes gaat aanleren.
2. Dat je in de toekomst niks hebt aan de kennis van die legacy libraries en dat je een achterstand hebt opgelopen omdat je beter iets anders had kunnen leren.
3. Dat de bedrijfsvoering chaotisch zijn en de werksfeer niet zo geweldig is. Klinkt als zo'n bedrijf waarbij alles gisteren al klaar had moeten zijn, waarbij elk dubbeltje omgedraaid moet worden en er druk uitvoeren om iets maar snel erin te hacken in plaats van dat je de tijd krijgt om een goede oplossing uit te denken.

Snap het gezeur richting de TS niet echt.Ik heb zat developers meegemaakt die liever geen echt nieuwe dingen maakten of grote beslissingen namen, maar zich comfortabeler voelden bij het fixen van bugs en dergelijke. Die liever concreet afgebakende problemen oplosten en weinig met abstractie hadden.

Andere developers leggen de lat wat hoger. Dat heeft weinig met een houding te maken. Het is dood normaal om ambities te hebben en een baan op het juiste niveau te willen.

Dat is overigens wel zuur aan de cultuur hier in Nederland. Heb zelf liever iemand als TS in m'n team die duidelijke doelen stelt, zich uit durft te spreken en kwaliteit belangrijk vindt. Helaas hebben mensen liever dat niemand boven het maaiveld uitsteekt. Vooral niks uitspreken, maar je aanpassen aan de meute. Baggerwerk wordt goed gepraat omdat het zo'n harde werker is, terwijl iemand die kwaliteit nastreeft de arrogante betweter is.

Tarkin schreef op maandag 2 januari 2017 @ 14:53:
Iedereen weet dat we het aantal technologien moeten verminderen en toch blijven we jaar na jaar vrolijk hetzelfde doen.

90% van deze issues komt door mensen zoals TS hier. Ze hebben van zichzelf een heel hoge dunk, hebben geen zin om een teamplayer te zijn (want mijn idee is het enige goede idee, afspraken die de code quality bevorderen gebeuren niet want dan moeten ze misschien iets doen waar ze principieel tegen zijn). Na 2 jaar zijn ze weg wegens niet interessant genoeg meer en kan de rest van het bedrijf de shit opkuisen.

Je maakt jaar op jaar dezelfde fouten, maar het is de schuld van de nieuwe developers die blijkbaar alle vrijheid krijgen omdat er geen structuur of visie is .

Als het fijn werken is en ze er genoeg kansen zijn om je door te ontwikkelen, dan zullen ze wel langer blijven. Dat teamplayergelul is helemaal vermoeiend als het over development gaat. Ik heb liever een groep getalenteerde mensen die kritisch naar elkaars werk kijken dan dat je een hecht teampje van middelmaat dat het altijd met elkaar eens is. Sowieso de term 'team' bij development. Standaard op het sollicitatiegesprek. Hecht en gezellig team. Alleen zit iedereen altijd doodstil achter z'n eigen bureau aan z'n eigen zaken te werken. Wat een onzin.

[ Voor 48% gewijzigd door BarôZZa op 03-01-2017 07:13 ]

[Hydra]

mekkieboek schreef op maandag 2 januari 2017 @ 21:14:
Voor agile / iteratief ontwikkelen, wat je steeds vaker ziet, is dit model niet meer correct of zelfs achterhaald.

Absoluut niet. Je verwart de product lifecycle met het waterval model. Producten hebben over het algemeen een bepaalde levensduur. Hoe je dat product ontwikkelt heeft daar helemaal niks mee te maken.

CMD-Snake schreef op maandag 2 januari 2017 @ 23:24:
Als ik zo de reacties van de TS lees lijkt het van een enorme ego te getuigen.

Ik zie hier vooral een flink aantal mensen zich om een of andere reden bijzonder aangesproken voelen en dat dan vooral maar persoonlijk gaan maken naar de TS toe. Er is niks mis met een voorkeur hebben voor nieuwbouw (er zijn niet voor niets teams en bedrijven die zich daarin specialiseren) en er is niets mis met klaar zijn met pruts bedrijven waar pruts developers vooral technical debt creeeren.

Als je bij een dergelijk bedrijf werkt en je de TS mateloos arrogant vindt moet je toch echt eens bij jezelf gaan kijken of je niet al een paar jaartjes compleet stil staat in je ontwikkeling; zoals een hele grote groep developers in Nederland compleet stil staat.

BarôZZa schreef op dinsdag 3 januari 2017 @ 07:01:
Dat is overigens wel zuur aan de cultuur hier in Nederland.

Absoluut. En dat is wel iets dat enorm Nederlands is. Vooral overal op lopen zeiken maar ondertussen zelf een enorme zesjesmentaliteit hebben. Kijk ook maar in dat Logica/CMG/Whatever-tegenwoordig topic waar mensen jarenlang lopen te emmeren over hoe slecht het is als werkgever maar er wel gewoon blijven werken.

[ Voor 15% gewijzigd door Hydra op 03-01-2017 08:06 ]

[Tarkin]

BarôZZa schreef op dinsdag 3 januari 2017 @ 07:01:
[...]


[...]

Je maakt jaar op jaar dezelfde fouten, maar het is de schuld van de nieuwe developers die blijkbaar alle vrijheid krijgen omdat er geen structuur of visie is .

Als het fijn werken is en ze er genoeg kansen zijn om je door te ontwikkelen, dan zullen ze wel langer blijven. Dat teamplayergelul is helemaal vermoeiend als het over development gaat. Ik heb liever een groep getalenteerde mensen die kritisch naar elkaars werk kijken dan dat je een hecht teampje van middelmaat dat het altijd met elkaar eens is. Sowieso de term 'team' bij development. Standaard op het sollicitatiegesprek. Hecht en gezellig team. Alleen zit iedereen altijd doodstil achter z'n eigen bureau aan z'n eigen zaken te werken. Wat een onzin.

Nope dat is de fout van de seniors in het team. Die denken van al het oude is troep en daar kijken we niet meer naar om, maar dat laatste nieuwe hier, dat gaan we gebruiken.

Als je een deftige product lifecycle hebt, dan kan je nog met de latest and greatest werken, maar dan heb je misschien 2 stacks die je moet onderhouden en geen 35 zoals we nu doen. Die enorme kortzichtigheid is waarom we nu op deze puinhoop werken. Ik kan nu inderdaad zeggen van meh, bekijk het maar, maar ik doe dat niet. Ik probeer het van binnenuit te veranderen, bepaalde oude technologieen laten afvloeien, kijken wat we kunnen uitschakelen (sommige applicaties draaien al 5 jaar zonder dat iemand ze ooit nog gebruikt bv).

Qua teamplayergevoel. In de teams waar dat echt heerste (je weet wel, een Agile extreme programming omgeving met veel pair programming) ging het echt goed vooruit, iedereen kon werken aan code dat iemand anders geschreven heeft, weinig problemen, weinig haantjes gedrag ook. Nu waar ik nu zit kan ik geen 2 applicaties opendoen en de coding stijl is nooit hetzelfde, zelfs de manier warop de projecten zijn opgezet.
Dus we hebben nu jouw visie, 10+ developers die op hun eigen eilandje zitten te coden en die van hunzelf vinden dat ze de beste zijn. Dat kan misschien waar zjin maar dat is nooit het beste voor het bedrijf. Waar jij middelmatigheid verfoeid is dat iets wat er meer moet komen juist. Ipv altijd opnieuw het wiel uit te vinden (ik heb gevallen van code waar ze keer op keer zelf iets uitgevonden hebben dat perfect al in 1 of ander framework zat, dat we dan ook gebruikten!). Het hele coderen is helemaal nog niet matuur.


Wat iemand anders hierboven ook zei, als je agile werkt zit je eigenlijk constant alles te doen. En dat is net een van de sterktes hiervan. Geen lesson's learned op het einde van een waterfall project om er dan daarna nooit meer iets te doen, nee elke 2 weken (of einde van de sprint) een retro om te zien waar we goed zijn geweest en waar we de mist zijn ingegaan. Dat heeft veel meer mijn voorkeur.

[Hydra]

Tarkin schreef op dinsdag 3 januari 2017 @ 08:33:
Nope dat is de fout van de seniors in het team.

Meer een management issue m.i. Als het goed is heb je een architectuur lead / CTO die dit soort overkoepelende zaken bepaalt.

[mekkieboek]

Hydra schreef op dinsdag 3 januari 2017 @ 08:03:
Producten hebben over het algemeen een bepaalde levensduur. Hoe je dat product ontwikkelt heeft daar helemaal niks mee te maken.

Afgezien daarvan, hier laat ik het bij, dit topic is mij te gepolariseerd.

[BarôZZa]

Tarkin schreef op dinsdag 3 januari 2017 @ 08:33:
[...]

Qua teamplayergevoel. In de teams waar dat echt heerste (je weet wel, een Agile extreme programming omgeving met veel pair programming) ging het echt goed vooruit, iedereen kon werken aan code dat iemand anders geschreven heeft, weinig problemen, weinig haantjes gedrag ook. Nu waar ik nu zit kan ik geen 2 applicaties opendoen en de coding stijl is nooit hetzelfde, zelfs de manier warop de projecten zijn opgezet.
Dus we hebben nu jouw visie, 10+ developers die op hun eigen eilandje zitten te coden en die van hunzelf vinden dat ze de beste zijn. Dat kan misschien waar zjin maar dat is nooit het beste voor het bedrijf. Waar jij middelmatigheid verfoeid is dat iets wat er meer moet komen juist. Ipv altijd opnieuw het wiel uit te vinden (ik heb gevallen van code waar ze keer op keer zelf iets uitgevonden hebben dat perfect al in 1 of ander framework zat, dat we dan ook gebruikten!). Het hele coderen is helemaal nog niet matuur.


Wat iemand anders hierboven ook zei, als je agile werkt zit je eigenlijk constant alles te doen. En dat is net een van de sterktes hiervan. Geen lesson's learned op het einde van een waterfall project om er dan daarna nooit meer iets te doen, nee elke 2 weken (of einde van de sprint) een retro om te zien waar we goed zijn geweest en waar we de mist zijn ingegaan. Dat heeft veel meer mijn voorkeur.

Wat een warrige conclusies maak je.

Die van zichzelf vinden dat ze de beste zijn? Mensen die in zichzelf blijven investeren en het hoogste resultaat willen behalen zijn juist diegene met de meeste zelfkritiek, dat is tenslotte waarom ze verbeteren. En juist die mensen zie ik meestal anderen helpen omdat anderen met vragen naar ze toekomen.Ik herken dat rare geschetste beeld niet echt.

Nieuwe oplossingen bedenken is simpelweg een andere kwaliteit dan fouten opsporen in al een bestaande oplossing. Het is vrij logisch dat als je je uitdaging vindt in het eerste, dat het dan onaantrekkelijk wordt om vooral het tweede te moeten doen. Er zijn weinig zaken die deprimerender en frustrerender zijn dan werk onder je niveau te moeten doen als je op zoek bent naar de intellectuele uitdaging.

Extreme programming werkt alleen goed als tenminste één van de twee een goede programmeur is. Bij minder goede programmeurs heb je er niet zoveel meer aan. Het is inderdaad zo dat er meestal maar één oplossing is die het meest optimaal en efficiënt is. De democratische weg heeft weinig zin.. Dat betekent overigens niet dat dat er geen samenwerking mogelijk is of dat er geen afspraken gemaakt kunnen worden. Het is alleen dat dat ik alleen dat ik altijd wat ongemakkelijk word van zo'n geforceerd teamgedoe, terwijl programmeren in de essentie toch een vrij eenzaam beroep is.
Als je het al als een team ziet, dan moet je optimaal gebruik maken van de kwaliteiten en niet iedereen geforceerd hetzelfde laten doen. Een software architect de hele dag bugs laten fixen is net zoiets als Van Nistelrooy op doel zetten. En dat van Nistelrooy niet op doel wil staan is niet omdat hij zich beter voelt dan iedereen, maar omdat hij zijn kwaliteiten kent. Een team kan zich omhoogtrekken aan een goede programmeur, maar het niveau van de programmeur omlaag trekken zodat hij maar gelijk is aan de rest is een slecht plan. Maar verder is het meer een estafetteloop dan een een echte teamsport.

Het verband met het wiel opnieuw uitvinden volg ik ook niet echt. Al is het begrijpelijk dat je geen 35 frameworks gaat doorspitten. Maar ik heb voor de rest geen idee over wat voor code het gaat. Ik weet ook niet waar je vandaan haalt dat middelmatigheid zou betekenen dat ze alle frameworks van voor tot einde kennen en het dan niet meer zou voorkomen.

Maar waar het uiteindelijk over ging is dat mensen hier dol worden omdat ze denken dat ze tweederangsdevelopers worden genoemd. Dat heb ik nergens gelezen, maar er is toch ook een duidelijk verschil in niveau in de meeste gevallen? Ik snap niet waarom mensen op de kast zitten als het over werk gaat.

[spacy]

Ik werk zelf voor een grotere detacheerder, en heb inmiddels al in een aantal projecten meegewerkt waar we iets nieuws konden bouwen. Dit soort partijen hebben vaak grote bedrijven en overheden als klant, die hele specifieke maatwerk software willen. Dit beantwoord mogelijk je vraag waar je eens zou moeten zoeken.

Aan de andere kant in dit soort nieuwe projecten, is het een illusie te denken dat alles vlekkeloos gaat, een team bestaat uit een combinatie van ervaring en expertise, en tja niet iedereen is groot fan van documentatie, of werkt soms niet erg netjes zijn. Ik heb mij ook meerdere keren geërgerd, of plaats vervangende schaamte gehad voor bepaalde bugs door het team gecreeerd. Maar ook vaak genoeg mezelf moeten verslijten voor sufferd die op een niet al te helder moment van een dag toch een crappy oplossing bedacht had.

Bovendien ben ik in onderhoudssituaties ook leuke uitdagingen tegen gekomen, neem een productie versie van een webservice, waar maar weinig tests van waren, laat staan documentatie. De tests kon ik dus flink kunt uitbreiden, code refactoren, en daarmee uiteindelijk problemen rondom stabiliteit kunnen herleiden naar de juiste oorzaken.

Ook is er nog de vraag welke werkwijze de teams toepassen. Als je in een DevOps omgeving terecht komt, is bestaande code beheren uiteraard een deel van je werk. En dat is wel hoe steeds meer IT teams ingericht worden. Daar hoort in sommige gevallen nog veel meer bij dan alleen het code onderhoud, denk ook aan beheer van databases en servers, dit is iets dat niet elke ontwikkelaar graag doet, maar waar je met de juiste insteek en drive ook leuke uitdaging uit kunt halen.

Als laatste kun je altijd nog voor jezelf in eigen tijd apps bouwen, of bijdragen aan open source projecten, hier heb je meer vrijheid om met een hoog niveau van netheid en structuur te kunnen werken, zonder dat tijdsdruk en geld de release bepalen.

[Hydra]

spacy schreef op dinsdag 3 januari 2017 @ 10:33:
Ik werk zelf voor een grotere detacheerder

[...]

Aan de andere kant in dit soort nieuwe projecten, is het een illusie te denken dat alles vlekkeloos gaat

Ja daarom zijn kleine gespecialiseerde detacheerders zoals wij zo populair

[Croga]

gold_dust schreef op maandag 2 januari 2017 @ 14:29:
@Hydra

Briljante post, je verwoordt en visualiseert met de product lifecycle precies wat ik bedoel maar niet goed onder woorden kan brengen. Ik zoek inderdaad een functie in de eerste fases, ik snap zelf eigenlijk ook niet waarom daar zo emotioneel op gereageerd wordt. Waarbij ik het onderhouden en bugs fixen van je eigen en enigzins netjes geschreven code van anderen in de latere fases ook geen probleem vindt.

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Ik ben niet de eerste die het zegt, zal ik niet de laatste zijn: Get over yourself! You're not all that!

Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. Het gevolg van dit dogma was dat er continue oorlog tussen deze twee was. Daarom zijn we daar van af gestapt. In moderne software ontwikkeling (en ik weet dat dit nogsteeds maar een klein percentage van de nederlandse bedrijven is maar we doen ons best...) is er één set aan software engineers die verantwoordelijk zijn voor de volledige levenscyclus van een stuk software. Dat is de enige manier om te zorgen dat er een sterke incentive is om kwaliteit te leveren; doe je dat namelijk niet dan mag je je eigen shit opruimen.

Dat betekend dus ook dat JIJ, TS, zult moeten accepteren dat je een stuk software onder je verantwoordelijkheid krijgt waar je zult moeten zorgen dat dit stabiel draait TERWIJL je zorgt dat er nieuwe functionaliteit bij komt.

Van je posts concludeer ik dat je nog niet heel veel ervaring in de branche hebt. Ik zou je sterk adviseren van je veel te hoge paard af te stappen en te accepteren dat je beeld van het werk niet overeen komt met de werkelijkheid en dat het aanpassen van de werkelijkheid in dit geval te hoog gegrepen gaat zijn voor je.

[gold_dust]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Ik ben niet de eerste die het zegt, zal ik niet de laatste zijn: Get over yourself! You're not all that!

Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. ...

Ik creëer om jouw bewoording te gebruiken geen 'shit' die anderen moeten opruimen. Het is niet zo heel moeilijk om iets op te zetten wat onderhoudbaar, schaalbaar, gedocumenteerd, getest, etc is. Ik heb daar ook al voldoende positieve feedback van opdrachtgevers over gehad. Wat ik wel een probleem vindt is om bij een bedrijf te starten waar het duidelijk initieel niet goed is opgezet zodat ik de 'shit' van anderen in de latere fases van de productcyclus kan opruimen. Daarom zoek ik gericht iets waar ik zelf invloed heb op de startup fase van een project.

[Cloud]

@gold_dust
Tja.. dan kan ik je slechts aanraden héél goed gebruik te maken van je proefperiode om op zoek te gaan naar oplossingen/code die voldoet aan jouw omschrijving van 'shit'. Want zelfs al laten ze je even meekijken bij je sollicitatie, dat ga je echt niet zo snel uitvissen hoor. Jammer genoeg kun je niet je proefperiode verlengen buiten het wettelijk gestelde maximum (één maand bij aanstelling van < 2 jaar), want dat was voor jou denk ik wel fijn geweest om uit te onderhandelen.

Heel wat van de zaken die je in de TS noemde zijn prima te bevragen maar of alle code en architectuur 'up to snuff' is volgens jouw standaarden is dat gewoon niet. Daar zul je actief en snel op zoek naar moeten gaan, tijdens je eerste werkdagen.

Ik zou het in elk geval niet vragen, niet op de manier zoals in dit topic. Hooguit of ze vaker from scratch nieuwe projecten doen of vaak verder werken in bestaande code bases.

[ Voor 13% gewijzigd door Cloud op 03-01-2017 11:23 ]

[Harm_H]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]
Je zit gevangen in het oude dogma van "change" en "run". Het dogma wat stelde dat er "ontwikkelaars" zijn die alleen verantwoordelijk zijn voor het maken/veranderen van het systeem en "beheerders" die verantwoordelijk zijn voor het stabiel laten draaien van het systeem. Het gevolg van dit dogma was dat er continue oorlog tussen deze twee was. Daarom zijn we daar van af gestapt. In moderne software ontwikkeling (en ik weet dat dit nogsteeds maar een klein percentage van de nederlandse bedrijven is maar we doen ons best...) is er één set aan software engineers die verantwoordelijk zijn voor de volledige levenscyclus van een stuk software. Dat is de enige manier om te zorgen dat er een sterke incentive is om kwaliteit te leveren; doe je dat namelijk niet dan mag je je eigen shit opruimen.

Dat betekend dus ook dat JIJ, TS, zult moeten accepteren dat je een stuk software onder je verantwoordelijkheid krijgt waar je zult moeten zorgen dat dit stabiel draait TERWIJL je zorgt dat er nieuwe functionaliteit bij komt.

Je hebt gelijk wat betreft oude dogma's. Ik deel de visie om IT te laten ontwikkelen en beheren door dezelfde groep mensen. Ik vermoed ook zeker dat TS een hoop negatieve baggage heeft.

Zijn schrijfstijl en arrogantie neigen eerder naar gebroken passie/vertrouwen. Een angst om kwetsbaar te zijn. Waar dit tegen je gebruikt wordt. Anderzijds geen ruimte krijgt om zijn talenten te benutten.

Desalniettemin is het wel goed van TS om duidelijke standaarden te hebben. Zolang hij bewust is waarom hij deze standaarden ambieert. Daarbij dus niet meer een bedrijf te accepteren dat een verziekte werkcultuur kent met achterhaalde - of zelfs geen - IT standaarden.

[Hydra]

Croga schreef op dinsdag 3 januari 2017 @ 10:40:
[...]

Je zegt dus *letterlijk*

"Ik wil de shit van anderen niet opruimen. Ik wil alleen shit creëeren zodat anderen die kunnen opruimen".

Nee hij zegt dat absoluut niet letterlijk. Zelf niet figuurlijk.

De rest van je betoog over 'dogmas' is je reinste kul. Het is complete onzin dat er geen verschillen in soorten teams zitten. Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.

gold_dust schreef op dinsdag 3 januari 2017 @ 11:06:
Daarom zoek ik gericht iets waar ik zelf invloed heb op de startup fase van een project.

Ik zou het als ik jou was hier gewoon bij laten. Te veel mensen passen je reactie in hun straatje zodat ze er daarna lekker tegenaan kunnen schoppen.

[ Voor 18% gewijzigd door Hydra op 03-01-2017 12:26 ]

[Croga]

Hydra schreef op dinsdag 3 januari 2017 @ 12:24:
De rest van je betoog over 'dogmas' is je reinste kul. Het is complete onzin dat er geen verschillen in soorten teams zitten. Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.

jij noemt het kul, ik noem het de gangbare theorie in IT land die sterk aan het veranderen is en wat ondertussen zo'n 25 jaar mijn vak is. Heeft in het geheel niets met "zelf nooit meegemaakt" te maken, noch met Dunning-Kruger, wel alles met wetenschap en ervaring. Ik zou je dus willen vragen je psychobabble buiten de discussie te houden als het een onderwerp betreft waar je duidelijk geen kaas van gegeten hebt.

[emnich]

Ik snap wel wat TS bedoelt, vrijwel niemand heeft zin om de shit van anderen op te ruimen en als er slecht gewerkt wordt in een bedrijf dan is er gewoon veel shit.

Dit is niet anders bij andere functies. Als je bij HR werkt en de dossierkasten zijn een zooi dan heb je ook geen zin om dat opnieuw in te richten. En als je bouwvakker bent en niemand ruimt z'n troep op zodat je niet lekker kunt werken, zoek je ook snel een nieuwe baan.

Echter je ontkomt er vaak niet aan dat er in het verleden slechte producten gemaakt zijn. Zeker als de code al flink oud is dan voldoet het gewoon niet aan de huidige standaarden. Je enige optie is dan een bedrijf te zoeken wat pas redelijk recent gestart is of die de oude shit al opgeruimd heeft.

Als er bij mij iemand solliciteert die vooraf al aangeeft geen shit te willen op ruimen dan komt ie er niet in. Hoewel het misschien niet terecht is, is het voor mij een slechte werkhouding. In elk bedrijf ontstaat soms iets waar je minder trots op bent en iedereen moet zich dan inzetten om dat weer te verhelpen.

Ik denk vooral dat veel mensen zich er aan storen dat TS een onderscheidt maakt tussen de verschillende ontwikkelaars. Vaak is het moeilijker om bestaande projecten om te bouwen naar de huidige standaarden (zonder dat er dingen kapot gaan) dan vanaf scratch te beginnen met een heel nieuw project. Deze mensen slechts "ontwikkelaars" noemen is dan ook onzin.

[CodeCaster]

Hydra schreef op dinsdag 3 januari 2017 @ 12:24:
Je hebt dat gewoon zelf nooit meegemaakt. Mensen hier stellen een knap staaltje Dunning-Kruger ten toon; dat jij het niet gezien hebt is een beperking in jouw ontwikkeling. Niks meer.
[...]
Ik zou het als ik jou was hier gewoon bij laten. Te veel mensen passen je reactie in hun straatje zodat ze er daarna lekker tegenaan kunnen schoppen.

Wie de schoen past, trekke hem aan. Je weet van jezelf hopelijk dat je regelmatig bijzonder ongenuanceerd reageert door met gestrekt been vol op één begrip of opmerking in te gaan, daarbij het bredere plaatje van de betreffende post uit het oog verliezend, zoals je hierboven demonstreert?

Volgens mij heeft nog niemand hier ontkend dat er bedrijven zijn waarbij er wordt gewerkt met aparte productontwikkelingsteams, die frameworks of basisapplicaties bouwen, implementatieteams die daarop weer features ontwerpen en implementeren en supportteams die onderhoud of klantspecifieke aanpassingen doen, met daarnaast nog eens onderhoudsteams die producten draaiend houden (backporten, patchen, hotfixen, klantsupport) die richting End-of-Life gaan.

Blijkbaar doelt TS met "onderhoud" op de werkzaamheden die laatstgenoemde teams doen, maar dat is niet de gangbare definitie.

In mijn ervaring zijn bedrijven met zo'n scheiding in de verschillende werkzaamheden zeldzaam, of zit er in ieder geval behoorlijke overlap in. Dan kun je mij weer op mijn ervaring gaan aanvallen, maar dat mag je achterwege laten. Koppel daaraan nog eens dat bedrijven waarin het goed toepassen van SCRUM, OTAP, CI/CD, OO, DevOps, documenteren, testen en wat dies meer zij minstens even zeldzaam zijn en voilá: de combinatie daarvan is schijnbaar onvindbaar, en daar hebben we exact het probleem waar TS tegenaan loopt.

Misschien is het ook wel zo dat als iemand moet vrágen naar waar zulke bedrijven zijn, dat ze niet naar diegene op zoek zijn. Anders had het bedrijf wel contact met hen gezocht.

Jij mag je in de handen wrijven met je situatie, en ik denk dat er genoeg mensen hier jaloers mogen zijn op wat jij voor werk doet, maar het gros van de developers die ik ken en spreek werken voor een middelmatig bedrijf, bouwen middelmatige software en zijn wellicht gewoon ... middelmatig. Ze bouwen "Yet Another Java CRUD Application" (of hoe noemde Joel dat?).

Volgens mij is elke developer met een greintje passie in z'n hart op zoek naar zo'n heilige graal als baan of opdracht, maar zowel jij als de TS mogen wat mij betreft een toontje lager zingen tegen mensen die de échte realiteit kennen en dat hier komen melden, getriggerd door de lompe verwoording van zowel jou als de TS.

Je moet je realiseren dat jíj degene bent die in een uitzonderingspositie zit, en dat de softwaremarkt in ieder geval in Nederland over het algemeen gewoon bagger produceert en dat er jaarlijks miljarden en miljarden euro's worden weggesmeten aan het oplappen en draaiend houden van software die nooit uitgebracht had mogen worden. Dus betrek jouw ervaringen niet op het gehele werkveld.

En ja, ik realiseer me dat die laatste opmerkingen beide kanten op werkt.

Dus voor de laatste keer: ik begrijp TS helemaal, maar het denigrerende gedoe dat verschillende personen hier tentoonspreiden is helemaal nergens voor nodig.

[Hydra]

Croga schreef op dinsdag 3 januari 2017 @ 12:46:
jij noemt het kul, ik noem het de gangbare theorie in IT land die sterk aan het veranderen is en wat ondertussen zo'n 25 jaar mijn vak is. Heeft in het geheel niets met "zelf nooit meegemaakt" te maken, noch met Dunning-Kruger, wel alles met wetenschap en ervaring. Ik zou je dus willen vragen je psychobabble buiten de discussie te houden als het een onderwerp betreft waar je duidelijk geen kaas van gegeten hebt.

Na alle stromannen komt je nu met een appel op autoriteit? Ik werk zelf zo'n 14 jaar in het vak en heb hiervan minimaal 10 jaar als consultant (6 jaar voor een tech bedrijf als integratie consultant, tegenwoordig gedetacheerd vanuit een kleine gespecialiseerde club) een hele hoop projecten van binnen gezien. UWV, IND, ING, Philips, Forensisch Instituut, USG en Randstad om maar een paar bekende namen te noemen. Ik heb hier steevast samengewerkt met zowel in-house developers, grote algemene detacherings clubs (Cap, IBM, Logica, Accenture, Ordina) als met kleine gespecialiseerde clubs (Xebia, Luminus, wijzelf) samengewerkt.

Kom dus niet aan met je 25 jaar. Je bent een goed voorbeeld van iemand die in een eigen wereldje zit en niet doorheeft dat daarbuiten een hoop andere dingen te zien zijn.

Het is doodnormaal dat er bij dit soort grote complexe projecten in de initiele start-up fase een ander team aan de slag is dan wat er na een jaar of zo aan de systemen werkt; laat staan het team dat in een tien jaar oud systeem in het eind van de levenscyclus bezig is met maintenance. Dat jij en een hoop mensen het "arrogant" vinden dat de TS (en anderen) de initiele fase veel interessanter vinden dan de 3e of 4e fase ligt compleet aan jezelf. Grote integrators als Cap en Accenture hebben daar echt compleet andere teams voor.

Jij en anderen verwarren "agile" en "devops" met de product lifecycle (zoals ik al eerder aangaf). Dat je agile werkt betekent niet dat je in de initiele fase dezelfde mensen hebt als na een jaar of twee. Het is echt de normaalste zaak van de wereld dat bedrijven juist externen inhuren om te zorgen dat het faciliterende werk (CI/CD, etc.) gedaan is en langzamerhand die (dure gespecialiseerde) externen vervangen voor in-house medewerkers.

Jij stelt dat er in "modern" software ontwikkeling een set ontwikkelaars verantwoordelijk is voor de hele levenscyclus. Complete bullshit. Hoe ga je dat uberhaupt afdwingen? Door mensen die vooral het architectuur deel leuk vinden niet aan te nemen? Geen specialisten aannemen? Een beetje schamper lopen doen over "die dure consultants" en vinden dat je het allemaal zelf wel kan? Je zal de eerste niet zijn. Maar je hebt dan wel een enorme plaat voor je kop. Wat voor jou en een hoop anderen goed overeenkomt door heel defensief te stellend dat de TS "arrogant" is. Nee; het is een software engineer die het architectuur deel het leukste vindt. En iets leuk vinden is over het algemeen een goeie manier om ergens ook erg goed in te worden. Mensen met een passie hiervoor moet je koesteren i.p.v. af te zeiken.

Edit: What the F? Heb je LinkedIn gecheckt en je bent uberhaupt geen developer! Hoe durf je dan in hemelsnaam iemand zo af te pissen?

CodeCaster schreef op dinsdag 3 januari 2017 @ 13:39:
Dus voor de laatste keer: ik begrijp TS helemaal, maar het denigrerende gedoe dat verschillende personen hier tentoonspreiden is helemaal nergens voor nodig.

Misschien moeten mensen dan woorden als "arrogant" en whatever zelfs nadat de TS aangegeven heeft het vooral over de product lifecycle te hebben en een voorkeur te hebben voor de initiele fase te hebben dan achterwege laten?

De reden dat ik hier redelijk pissig reageer (en dat ben ik serieus ook; in het wereldje waar ik zit heeft zo ongeveer verwacht dat je deze drive hebt) is gewoon omdat veel posts hier volgens een vast patroon geplaatst worden. 1. leg de tekst van de OP op zo'n slecht mogelijke manier uit. 2. negeer elke verdere uitleg die niet in dat straatje past. 3. Pas wat stromannen toe. 4. Fakkel de stromannen af.

Sorry, maar dan verlies ik alle respect voor de desbetreffende personen.

Ik vind dat wat je zegt heel treffend is. Mensen zouden jaloers zijn op mijn situatie? Heb je enig idee hoe lastig het is voor ons en de bedrijven waar wij ingehuurd worden om goeie ontwikkelaars te vinden? Die "meewerkers" zijn geen probleem. Software engineers die from scratch een microservice architectuur neer kunnen zetten; daar is niet aan te komen. Nog erger: goeie data engineers! Uurtarieven van 200E per uur zijn geen uitzondering.

Als dan in een topic gedaan wordt of middelmatigheid de norm is en de TS een arrogante zot is om daar uit te willen ontsnappen is om te huilen! We zijn dacht ik hier toch zo trots op ons opleidingsniveau en onze kenniseconomie? Als je na 4 jaar met je papiertje van school af komt begint het leren pas. Als je gezapig op je dikker wordende reet wil blijven zitten, 20 jaar bij hetzelfde bedrijf: prima. Maar ga dan niet iemand compleet af lopen fakkelen (en die mods doen er lekker aan mee) als hij wel meer wil.

[ Voor 24% gewijzigd door Hydra op 03-01-2017 14:08 ]

[BarôZZa]

CodeCaster schreef op dinsdag 3 januari 2017 @ 13:39:
[...]

Je moet je realiseren dat jíj degene bent die in een uitzonderingspositie zit, en dat de softwaremarkt in ieder geval in Nederland over het algemeen gewoon bagger produceert en dat er jaarlijks miljarden en miljarden euro's worden weggesmeten aan het oplappen en draaiend houden van software die nooit uitgebracht had mogen worden.

Dat is inderdaad wel de essentie vaak, dus de vraag van de TS vind ik niet vreemd. Toen ik mijn eerste sollicitaties had verbaasde ik me ook over de kwaliteit van veel toko's. Hoe is het mogelijk dat je als jong onervaren broekie al meteen de brakheid en onkunde kan waarnemen. Het is een krankzinnige situatie, je zou juist moeten leren van de ervaren mensen. Wat hebben die al die jaren gedaan?

Eerste bedrijf waar ik zat ook. Functies met 1000 regels aan if-statements. Pagina inladen kon een minuutje duren. Bij 75 gelijktijdige bezoekers ging de site plat. Beveiliging was ook droevig.

Maar iedereen vond het de meest normale zaak van de wereld. En het geld bleef binnenrollen, want klanten legden de lat ook niet hoog. Je zou verwachten dat het einde verhaal zou moeten zijn, maar in Nederland gaat zoveel geld rond dat dit soort bedrijven eindeloos lang kunnen bestaan. Sterker nog, ze denken dat ze het goed doen en een prachtig product afleveren. Het levert geld op, dus durven ze er niet veel aan te vernieuwen.

Ik denk niet dat TS er vanuit ging dat hij nooit een bug zou moeten oplossen. Maar er zijn behoorlijk veel bedrijven waarbij je weet dat je de komende jaren weinig zal bouwen en meer een eindeloze lijst krijgt met bugs die je niet structureel kan oplossen, maar waarvoor je een mooie hack mag bouwen.

[CMD-Snake]

Hydra schreef op dinsdag 3 januari 2017 @ 08:03:
Ik zie hier vooral een flink aantal mensen zich om een of andere reden bijzonder aangesproken voelen en dat dan vooral maar persoonlijk gaan maken naar de TS toe. Er is niks mis met een voorkeur hebben voor nieuwbouw (er zijn niet voor niets teams en bedrijven die zich daarin specialiseren) en er is niets mis met klaar zijn met pruts bedrijven waar pruts developers vooral technical debt creeeren.

Als je bij een dergelijk bedrijf werkt en je de TS mateloos arrogant vindt moet je toch echt eens bij jezelf gaan kijken of je niet al een paar jaartjes compleet stil staat in je ontwikkeling; zoals een hele grote groep developers in Nederland compleet stil staat.

Het is wel komisch dat je beschuldigingen uit dat we het persoonlijk maken en in de alinea die volgt maak je het persoonlijk.

Het kan mij overigens werkelijk niets schelen, ik geef enkel een advies. Als je zo fixeert op bepaalde zaken maak je jezelf ongelukkig. En dergelijke 'eerlijkheid' kan bij een sollicitatie ook verkeerde gevoelens oproepen. Het feit dat ontwikkelaar gewild zijn betekent niet dat men alles bereid is om te accepteren.

Over 'technical debt' gesproken. Software die vandaag op zijn best is, is dat mogelijk over vijf jaar niet meer. Inzichten veranderen. Code die vandaag wordt geschreven is de technical debt van morgen. Dat geldt voor alles in de IT.

[GoldenSample]

downtime schreef op zaterdag 31 december 2016 @ 12:22:
[...]

Dat dus. Of ga mobile apps ontwikkelen. Die zijn veelal ook nieuw. Maar als web of mobile niet jouw ding is, dan kun je maar beter accepteren dat een groot deel van jouw werkzame leven eruit bestaat dat je voortborduurt op andermans werk, want echte greenfields zijn zeldzaam geworden.

Ik zou het belangrijker vinden dat je zelf wel de ruimte krijgt om zaken te verbeteren. Als die ruimte er ook niet is, omdat management de zin van documentatie/architectuur/versioncontrol/testen niet ziet, dan moet je daar niet gaan werken.

Dit. En ja knap versie beheer etc. Is wel iets dat je moet kunnen verwachten bij een professionele organisatie zulke zaken zou ik ook op afknappen.

Voor de rest is het een keuze: wen er aan of accepteer dat je vaak toch in de wat 'simpelere' systemen blijft/je naar een positie moet gaan toe werken waar je van project naar project hopt overal en nergens. Een complex systeem wordt langer gebruikt -> langer onderhouden -> extra functies toegevoegd/fixes voor een veranderende wereld -> gelijt vanzelf naar meer en meer lagacy code.

En ja het is net wat je wilt. Een groot complex systeem heeft ook weer zijn voordelen en heel andere positief uitdagende kanten.

Oh en Agile Scrum? Ben er opzich in veel situaties wel fan van (ben zelf geen programmeur/Developer maar heb er erg veel mee te maken, team dat voor mij dingen maakt werkt ook met een variant) maar besef je wel dat dat ook als nadeel heeft: documentatie is niet niet belangrijk maar wel minder belangrijk dan functionaliteit.

Overigens heeft Hydra weldegelijk een punt. Denk dat je in zo'n situatie inderdaad niet op de interne ontehoudskant moet gaan zitten nee. Vraag is alleen: ben je er wel goed genoeg/geschikt/ervaren genoeg voor om zoiets te gaan doen. Bij, noem een dwarsstraat, Accenture zit je toch in een iets ander bedrijf dan een MKBer om de hoek (dat zullen we dan maar die 'drive' noemen ) en bij Accenture is het merendeel ook gewoon in de modder aan het worstelen. Maw. wees realistisch en neem een lampje mee om deze sweetspot te zoeken.

Hell binnen een bedrijf kan t zo veel schelen. Zit zelf binnen een enorm bedrijf met hele afdelingen met allemaal legacy shit uit het jaar kruik. Ondertussen draag ik bij aan een platform (waar ook veel legacy meuk in zit) waaraan hard ontwikkeld wordt, veel nieuwe dingen gedaan worden en totaal nieuwe functionaliteit soms vrijwel vanaf Scratch wordt neergezet. Een heel andere wereld dan soms letterlijk een gangpad verder.

[ Voor 30% gewijzigd door GoldenSample op 03-01-2017 20:29 ]

[makato2003]

Als engineer blijf je continue leren, ook van legacy (misschien wel juist van...) code.
Die ervaring pas je toe, stel je bij. Dat is een continue proces.

Scrum zegt niets over prioriteit van documentatie, laat staan het niet maken ervan. Dat is echt complete onzin. Een onderkend probleem is waarborging van architectuur; het systeemontwerp.

Scrum is een tijdmanagement methode. Niet meer. niet minder.

Zoals in ieder vak heb je goede mensen die netjes werken en minder goede mensen die de kantjes eraf lopen. Dit is (helaas) van buitenaf niet te zien. Je zult in de praktijk met beide types te maken hebben, altijd.

[unezra]

Ik zit echt met verbazing dit topic te lezen.
Zelf geen developer maar systeembeheerder, heel andere tak van sport dus. Development heeft me nooit echt getrokken, op het incidentele shellscript na.

Toch zie ik wel overeenkomsten.

- Je hebt OVERAL legacy en ongeveer iedere beheerder begint met het opruimen van de troep van anderen, bewijs jezelf eerst maar voordat je aan een nieuwe implementatie van wat dan ook mag beginnen
- Iedere beheerder maakt fouten en genereert precies dat waarover de volgende generatie beheerders binnen het bedrijf gaat klagen: troep
- Iedere beheerder denkt na een jaar, 2 jaar "waarom in vredesnaam heb ik dat ooit zo gedaan"
- Je leert ongelooflijk veel van puinruimen, de systemen doorgronden, hoe bepaalde dingen in het bedrijf werken, samenwerking tussen platformen, etc, etc, etc.

Wat me ook verrast is dat veel mensen hier aangeven het opruimen van troep niet leuk te vinden (da's de milde variant) en zelfs neer te kijken op mensen die dat wel leuk vinden.

Waarom?

Ik ben dus juist een van die mensen die het geweldig vind om, binnen mijn eigen vak, de zooi van anderen op te ruimen. Daar valt eer te behalen. Het is ook lastig. Je hebt namelijk te maken met bestaande systemen en impact op de organisatie. Mensen zijn gewend op een bepaalde manier te werken en je moet zorgen dat het systeem verbeterd word (of zelfs vervangen) zonder dat daar al te veel gezeur door komt.

Natuurlijk vind ik het ook fijn om met nieuwe dingen bezig te zijn, compleet nieuwe functionaliteit te ontsluiten, maar vaak is "nieuwe functionaliteit" binnen mijn vakgebied ook het vervangen van een bestaand systeem door een nieuw systeem, waarbij de overgang niet al te heftig moet zijn.

Voor sommige projecten die eenmalig zijn huren we externen in, die sturen we dan zelf aan. Die externen doen zo'n implementatie 100x, wij zouden het 1x moeten doen. Voor hen is het standaard werk bij een nieuwe klant. Zij doen dus eigenlijk niets nieuws en wij besteden een klus uit waarbij het netto voordeliger is dan eerst onszelf helemaal op te leiden voor een klus die we maar 1x in ons leven hoeven te gaan doen.

Daar zit dus ook een overeenkomst. Je kunt prima bij een tent gaan werken die voor klanten alleen nieuwe code schrijft, maar volgens mij doe je dan nog steeds 100x hetzelfde ding maar voor verschillende klanten.

Terug naar mijn eigen vak, als hier een nieuwe beheerder binnen komt die alleen met nieuwe projecten bezig wil zijn en geen zin heeft bestaande implementaties te verbeteren is het gesprek snel afgelopen. Die ruimte is er niet. Komt diegene net van school af, is het gesprek *nog* sneller afgelopen omdat ik me in dat geval af zou vragen of zo iemand wel enige redelijkheid bij te brengen is of zelf na 3 maanden bedankt, neus in de lucht, op zoek naar een volgende werkgever.

Mijn 0,02 EUR.

EDIT (nabrander):

spacy schreef op dinsdag 3 januari 2017 @ 10:33:
Als laatste kun je altijd nog voor jezelf in eigen tijd apps bouwen, of bijdragen aan open source projecten, hier heb je meer vrijheid om met een hoog niveau van netheid en structuur te kunnen werken, zonder dat tijdsdruk en geld de release bepalen.

Dat is maar voor een deel van de OSS projecten maar zeker niet voor allemaal. Heel veel grotere OSS projecten worden gerund door commerciële bedrijven en die kennen ook gewoon release cycles en zijn afhankelijk van klantwensen. Dat is niets nieuws. RedHat ontwikkelde al vanaf het prille begin eigen code. Tegenwoordig heb je bedrijven als Canonical (Ubuntu), Suse, Combodo (iTop CMDB), Promox GmbH, Zabbix, etc, etc, etc, die allemaal zelf code schrijven en programma's voor eindgebruikers. De structuren daar zullen niet veel anders zijn.

Dus ja, er zijn OSS projecten waarbij je die vrijheid hebt maar er zijn ook heel veel OSS projecten die net zo werken als eigen projecten van reguliere commerciële organisaties.

[ Voor 18% gewijzigd door unezra op 04-01-2017 09:28 . Reden: OSS misvatting ]

[L0we]

makato2003 schreef op woensdag 4 januari 2017 @ 09:00:
Als engineer blijf je continue leren, ook van legacy (misschien wel juist van...) code.
Die ervaring pas je toe, stel je bij. Dat is een continue proces.

Scrum zegt niets over prioriteit van documentatie, laat staan het niet maken ervan. Dat is echt complete onzin. Een onderkend probleem is waarborging van architectuur; het systeemontwerp.

Scrum is een tijdmanagement methode. Niet meer. niet minder.

Zoals in ieder vak heb je goede mensen die netjes werken en minder goede mensen die de kantjes eraf lopen. Dit is (helaas) van buitenaf niet te zien. Je zult in de praktijk met beide types te maken hebben, altijd.

Scrum kan ook wel degelijk gebruikt worden om een bepaalde procesgang te borgen, het is aan jezelf hoe je dat inricht.

Bij mijn vorige werkgever was het zo dat als er geen documentatie was, je iets niet als 'af' kon beschouwen. Dat was ook onderdeel van de code review, of de documentatie duidelijk & volledig is. Op die manier kan je heel goed borgen dat de kwaliteit hoog blijft (zowel van code als documentatie)

Het fijne van zo'n proces vind ik wel dat iedereen geacht wordt om het te volgen, en aangezien er altijd een code review gebeurt, vallen de mensen die de kantjes er vanaf lopen zo door de mand.