Recruiters & HR - Ervaringen, belevingen, verhalen.

[unezra]

GG85 schreef op maandag 26 september 2022 @ 17:10:
Mijn frustratie moment: berichtje gehad van interne recruiter van een internationaal bedrijf.
Eerste gesprekje gehad en daarbij aangegeven dat ik 4x9 werk omdat ik een dochterje heb en daar een dag in de week voor wil zorgen.
Allemaal prima, leuk gesprek en hij zou mijn profiel voorleggen aan de toekomstige manager. Bericht terug dat ze positief waren en dat ze met een voorstel zouden komen voor een 2e gesprek.
Krijg ik vervolgens een mailtje met de strekking "we zoeken toch iemand die hier fulltime zit dus we gaan voor een andere kandidaat"....

Wtf? Het is 2022 en mensen nemen pappadagen op waar je recht op hebt. Daarnaast geeft de CAO waar ze onder vallen ook nog eens expliciet het recht om 4 dagen te werken dus wat is het probleem?

Gereageerd dat ik beter niet eerlijk had kunnen zijn en na het tekenen van het contract (2 maanden proef, dan vast adverteerden ze mee) 4x9 aan had moeten vragen wat ze niet hadden kunnen weigeren.

Ik begrijp ze ergens wel maar het is nu eenmaal een fact dat mensen kinderen krijgen en dan andere prioriteiten. Precies hierom mag je een vrouw niet vragen of ze ooit zwanger wil worden en bij een "ja" de baan niet geven.

Rant: kan me voorstellen dat er zo een zure lul van een toekomstige manager zit met een mislukt huwelijk die er nooit voor zijn eigen kinderen was en nu dus maar iedereen z'n papadag misgunt.

Maar goed, beter dat ik het nu weet dan later wat voor toko het is.

Sowieso raar. Bij veel bedrijven *is* 36 uur fulltime.

[GG85]

In de Metalektro niet maar dan nog. Vlgns mij gevalletje semi-boomer manager die niet snapt dat t er in 2022 anders aan toe gaat

[jongetje]

@GG85 Mooi toch dat je er nu al achter komt hoe je nieuwe manager denkt.

[Mandera]

GG85 schreef op maandag 26 september 2022 @ 17:10:

Gereageerd dat ik beter niet eerlijk had kunnen zijn en na het tekenen van het contract (2 maanden proef, dan vast adverteerden ze mee) 4x9 aan had moeten vragen wat ze niet hadden kunnen weigeren.

Ik snap je redenering hoor maar deze reactie is wel erg onprofessioneel. Je laat je ontzettend kennen. Pas ermee op in de toekomst. Het is vaak beter om politiek correct te blijven en gewoon "jammer maar helaas" te antwoorden. Just my 2 cents.

[Orangelights23]

@GG85
Nederland js koploper deeltijd werken. In veel andere landen is minder dan 40 uur al part time. Dus logisch dat het een dealbreaker is. Niet logisch natuurlijk is dat veel andere landen en daarmee bedrijven verwachten dat 40 uur nog de norm is, maar men is verwend in Nederland met dit systeem en veel mensen weten dit niet.

Pssst, pappadag is iets van 2007. Zoals je zegt, het is 2022, vader en moeder zijn beiden gewoon betrokken

[GG85]

Mandera schreef op dinsdag 27 september 2022 @ 07:02:
[...]

Ik snap je redenering hoor maar deze reactie is wel erg onprofessioneel. Je laat je ontzettend kennen. Pas ermee op in de toekomst. Het is vaak beter om politiek correct te blijven en gewoon "jammer maar helaas" te antwoorden. Just my 2 cents.

Ben ik niet met je eens, mijn reactie was keurig en genuanceerd maar aangegeven dat ik me benadeeld voel door netjes open kaart te spelen want daar komt t op neer.
Plus, het stoort me dat een hiring manager blijkbaar niet weet wat de rechten van werknemers zijn anno 2022 en iemand afrekent die netjes van tevoren aan geeft dat hij verlof gaat opnemen voor zijn kind.

Daarnaast, ik heb niets meer van ze nodig en door niets te zeggen houdt je dit in stand.

Mijn reactie hier op het forum was uiteraard de ongefilterde, betekend niet dat mijn reactie naar het bedrijf dat ook was maar de strekking was zeker hetzelfde.
Onrecht mag je m.i. prima aan de kaart stellen en als ze daar niet tegen kunnen hoef ik sowieso al niets van ze in de toekomst. Het is niet dat ik werkeloos ben en zit te smachten op wat nieuws, ze benaderen mij tenslotte dus kijk dan niet raar op als toekomstige werknemers (zeker in deze tijd) een (m.i. heel redelijk) wensenijstje neerleggen.

Ben gewoon wat gefrustreerd omdat het verder een heel mooi bedrijf leek met hele mooie (maatschapelijk nuttige) producten.

[ Voor 14% gewijzigd door GG85 op 27-09-2022 10:50 ]

[CVTTPD2DQ]

GG85 schreef op dinsdag 27 september 2022 @ 10:43:
Plus, het stoort me dat een hiring manager blijkbaar niet weet wat de rechten van werknemers zijn anno 2022 en iemand afrekent die netjes van tevoren aan geeft dat hij verlof gaat opnemen voor zijn kind.

Als het een echt internationaal bedrijf is met remote posities kunnen ze natuurlijk rondshoppen in landen die de meest gunstige voorwaarden voor werkgevers hebben.

[GG85]

Denk eerder het tegenovergestelde. Ze zijn internationaal maar vermoed dat de afdelingsmanager hier een oude stempel type is die alles wat niet 5x8=40 werkt maar lastig en moeilijk vindt.
Qua thuiswerken liet de reqruiter al doorschemeren dat ze een company brede thuiswerk policy hebben maar de invulling afh is van de manager.

Dus ik gok een manager die het allemaal maar lastig vind en dus de cv's kiest van mensen die niet "moeilijk" doen.

[jongetje]

GG85 schreef op dinsdag 27 september 2022 @ 12:41:
Dus ik gok een manager die het allemaal maar lastig vind en dus de cv's kiest van mensen die niet "moeilijk" doen.

Als hij de luxe heeft van een stapel geschikte CV's op zijn bureau is dat zijn goed recht.

[Verwijderd]

Verwijderd

[ Voor 98% gewijzigd door Verwijderd op 28-10-2023 08:18 ]

[Lisadr]

Verwijderd schreef op maandag 26 september 2022 @ 14:45:
[...]

Dat is inderdaad zo.

Ik besef mij dat dit niet hetzelfde is maar het platform heeft ook de mogelijkheid aan te geven dat je niet actief op zoek bent en eventueel alleen openstaat voor hele specifieke zaken.
[Afbeelding]

Welke platform is dit? Op LinkedIn heb ik geen open veld optie.

GG85 schreef op maandag 26 september 2022 @ 17:10:
Mijn frustratie moment: berichtje gehad van interne recruiter van een internationaal bedrijf.
Eerste gesprekje gehad en daarbij aangegeven dat ik 4x9 werk omdat ik een dochterje heb en daar een dag in de week voor wil zorgen....

Voor mij een red flag! Wees blij dat je daar niet bent gaan werken. Bedrijven die geen aandacht hebben voor de persoonlijke situatie van hun medewerkers zijn geen gezonde plekken om te werken.

[Wild Chocolate]

Lisadr schreef op dinsdag 27 september 2022 @ 23:21:
[...]


Welke platform is dit? Op LinkedIn heb ik geen open veld optie.
(...)

Wilde gok:
https://www.werkenmet.net/

@Verwijderd loopt daar stage geloof ik

[Lisadr]

Wild Chocolate schreef op woensdag 28 september 2022 @ 00:30:
[...]


Wilde gok:
https://www.werkenmet.net/

@Verwijderd loopt daar stage geloof ik

https://www.werkenmet.net/

"Ben jij echt een dev? Ho even. Eerst eens kijken of jij wel echt een developer bent en geen vervelende recruiter."

Ik ga stuk!

[unezra]

GG85 schreef op maandag 26 september 2022 @ 19:53:
In de Metalektro niet maar dan nog. Vlgns mij gevalletje semi-boomer manager die niet snapt dat t er in 2022 anders aan toe gaat

Hoe dan ook idd niet meer van deze tijd, iig niet in Nederland.

Ik hang wat rond in een internationale FB groep voor- en door managers, zitten veel Amerikanen. Echt. Wat je dáár af en toe leest (ook als advies hoe om te gaan met personeel), hebben we het NL best goed voor elkaar.

Werk- privébalans is een groot goed.

Al hoor je in NL ook vaak genoeg dat contracturen niet meer dan een vage richtlijn zijn, of zelfs dat niet. Keer cursus gedaan met wat andere managers uit alle lagen van diverse organisaties. "Ja, het is belangrijk dat mensen niet meer dan 32, 36 of 40 uur te werken. Dat stimuleren we ook binnen het team." "Hoe veel werken jullie eigenlijk?" "Nou, 45, 50, 60 uur per week. Want..."

Practice what you preach...

(Binnen bepaalde sectoren is het volgens mij nog veel erger.)

[Verwijderd]

Verwijderd

[ Voor 99% gewijzigd door Verwijderd op 28-10-2023 08:18 ]

[Tylen]

[FreezeXJ]

Verwijderd schreef op woensdag 28 september 2022 @ 09:43:
Leuk om te horen
Maar de reacties hierover lopen behoorlijk uiteen. Van "geniaal" tot boze reacties in de trend van "wat een onzin; ik ontwikkel al 20 jaar en deze test zegt dat ik geen developer ben". En dan blijkt meestal dat ze de vraag niet goed gelezen hebben

Aan de ene kant is het bedoeld als statement en leuke gimmick, maar aan de andere kant zit er ook wel een serieuze gedachte achter. Door deze simpele test willen we het bureau-recruiters niet te makkelijk maken om bedrijven vervolgens lastig te vallen die een account hebben aangemaakt. Ik heb geen illusies dat het 100% van de bureau-recruiters stopt, maar zelfs wanneer het 50% ontmoedigt dan is dat al 50% minder overlast.

Ik noem het een top-actie, binnen een paar klikken heb je een hoop slecht-lezenden en niet-ITers eruit gefilterd, en ja, die zullen zuur zijn. Ik denk dat je er niet veel aan gaat missen Als java dev kom ik er ook net zo makkelijk door, dus tja... Ik mis alleen de java-baantjes natuurlijk maar he, dat was te verwachten.


Verder vind ik het vaak wel zo nuttig om gewoon even koffie te drinken bij een bedrijf, even kijken of de cultuur me ligt, en dan pols je natuurlijk wel hoe er over overwerken of nette oplossingen (die tijd kosten!) gedacht wordt... Meeste devs zijn daar bij een bak koffie eerlijker over dan HR / de manager (plus dat het de slootwaterautomaatbedrijven (3x woordwaarde) eruit filtert natuurlijk)

[Hydra]

Lisadr schreef op woensdag 28 september 2022 @ 00:57:
"Ben jij echt een dev? Ho even. Eerst eens kijken of jij wel echt een developer bent en geen vervelende recruiter."

Ik ben gezakt omdat ik Cobol de beste taal vond

[Verwijderd]

Verwijderd

[ Voor 94% gewijzigd door Verwijderd op 28-10-2023 08:18 ]

[Verwijderd]

Verwijderd

[ Voor 99% gewijzigd door Verwijderd op 27-10-2023 20:51 ]

[unezra]

FreezeXJ schreef op woensdag 28 september 2022 @ 15:54:
[...]
Verder vind ik het vaak wel zo nuttig om gewoon even koffie te drinken bij een bedrijf, even kijken of de cultuur me ligt, en dan pols je natuurlijk wel hoe er over overwerken of nette oplossingen (die tijd kosten!) gedacht wordt... Meeste devs zijn daar bij een bak koffie eerlijker over dan HR / de manager (plus dat het de slootwaterautomaatbedrijven (3x woordwaarde) eruit filtert natuurlijk)

Neem al jaren mijn eigen theebeker, en als ze enkel Pickwick achtige meuk hebben, ook mijn eigen thee mee. Vanaf dag 1 ook echt. "Wil je koffie?" "Nee dank je. Heb je heet water voor me? Dan vul ik mijn emmer." Emmer gaat 's avonds in mijn tas.

Uiteraard niet naar een sollicitatiegesprek.

Heb volgens mij nog nooit écht lekkere koffie bij een bedrijf gedronken. Zelfs niet als ze eoa hip duur apparaat van een half jaarsalaris hadden. Koffie uit onze moka pot is bijna altijd beter.

[Get!em]

Bij ons hadden ze deze zomer gewoon zo’n tuktuk met espresso apparaat en barista naar binnen gereden.
Prima koffie
Hele Italiaanse spectrum kon je laten maken.

[unezra]

Get!em schreef op woensdag 28 september 2022 @ 20:03:
Bij ons hadden ze deze zomer gewoon zo’n tuktuk met espresso apparaat en barista naar binnen gereden.
Prima koffie
Hele Italiaanse spectrum kon je laten maken.

Realiseer me dat ik op één plek wel goede koffie had: Grote verzekeraar.
Daar was én een inpandige Starbucks automaat én een café waar je ook als niet-medewerker koffie kon drinken. (In fact, de hele kantine én het á-la-carte restaurant was openbaar.)

Die koffie was zowaar goed te drinken.

Maar verder...

Dus ik ben d'r overdag mee gestopt. Enkel kruidenmelange. (Ook goede test, als ze dat raar vinden, zit ik daar niet op mijn plek.)

[Hydra]

Verwijderd schreef op woensdag 28 september 2022 @ 19:52:
Toen we het platform begonnen heb ik gelijk werkenmetjava.nl gekocht van iemand anders. Dus wie weet, misschien ooit in de toekomst.

Als daar het antwoord op die vraag "Java" gaat zijn, ga ik je slaan

Overigens; de Java ZZP markt wordt ook goed verziekt door recruiters dus ik zou er zeker geld voor over hebben.

[ Voor 14% gewijzigd door Hydra op 28-09-2022 20:54 ]

[Verwijderd]

Verwijderd

[ Voor 108% gewijzigd door Verwijderd op 27-10-2023 20:46 ]

[Hydra]

@Verwijderd als ik dan een keer via jouw platform een Java klus vind krijg je een mooie fles wijn van me dan

[CodeCaster]

Verwijderd schreef op woensdag 28 september 2022 @ 21:12:
[...]

Een paar gratis opmerkingen voor je site

• Loop de teksten even na op spatiefouten.
• Testvragen: de bool False bestaat niet in C# (false wel), ToInt32 ook niet (Convert.ToInt32() wel).
• Er vraagt minstens één bedrijf om 3 jaar ervaring met .NET 5+, wat in november 2020 is uitgekomen.
• Na .NET Core 3 kwam .NET 5, en dat is inmiddels alweer end of life, de upgrade naar 6 is een no-brainer. Als iemand .NET 5 als technologie in z'n vacature heeft staan, of nog erger, het ".NET Core 5" noemt, zou de site een waarschuwing moeten geven. Of aan de invoerder, of aan de bezoeker.
• Als een nieuwe pagina aan vacatures wordt geladen, laden de logo's erg traag, dus blijven die van de vorige pagina staan.
• De interimlijst is erg leeg.

Ik blijf het een mooi initiatief vinden, al blijf ik hopen nooit meer recruiters of sites nodig te hebben.

[Verwijderd]

Verwijderd

[ Voor 99% gewijzigd door Verwijderd op 27-10-2023 20:46 ]

[Verwijderd]

Verwijderd

[ Voor 101% gewijzigd door Verwijderd op 27-10-2023 20:46 ]

[RagingPenguin]

CodeCaster schreef op donderdag 29 september 2022 @ 00:51:
Na .NET Core 3 kwam .NET 5, en dat is inmiddels alweer end of life, de upgrade naar 6 is een no-brainer.

Dit kan natuurlijk ook voorkomen als de vacature tekst wat ouder is, sommige vacatures staan lang open en men schrijft niet altijd een hele nieuwe tekst als er een positie open komt.

[Verwijderd]

Verwijderd

[ Voor 98% gewijzigd door Verwijderd op 27-10-2023 20:46 ]

[CodeCaster]

Verwijderd schreef op donderdag 29 september 2022 @ 10:03:
[...]


Klopt inderdaad.

Daarbij was onze gedachte achter .NET 5+ het volgende:

Om bedrijven en vacatures te kunnen filteren hebben we een lijst gemaakt van een hoop standaard technieken waar mensen uit kunnen kiezen. (uiteraard bestaat de mogelijkheid om ook zelf technieken toe te voegen maar daar kan dan nog niet op gefilterd worden)

Om te voorkomen dat we een lange reeks krijgen van .NET 5, 6, 7 etc. kwam een van de developers met het idee om er gewoon .NET 5+ van te maken. Dus alles vanaf .NET 5 valt hier hieronder.

Het bedrijf heeft in het onderdeel "Hoe wordt jullie stack toegepast" altijd de vrijheid om te omschrijven wat voor technieken ze precies gebruiken en hoe. Maar .NET 5+ is slechts een manier om die bedrijven en vacatures te filteren die met .NET 5 of hoger werken.

Het is slechts mijn mening, dus doe er vooral mee wat je wil.

In mijn ervaring hebben dotnetters als geen ander een hekel aan het moeten onderhouden van andermans legacy.

Als ik ".NET Core 3.1" lees (end of support: 2022-12-13, over tweeënhalve maand), lees ik: "legacy". Hetzelfde met .NET 5: support daarvoor is in mei 2022 (op dit moment vier maanden geleden) opgehouden. Dus wederom: als dat ergens staat = legacy = wegwezen.

De even .NET-versies (nu: 6) worden 3 jaar lang ondersteund (LTS). .NET 6 blijft ondersteund en onderhouden tot november 2024, dus nu nog 2 jaar. De oneven versies (nu: 7) de helft daarvan, zodat men daarop nieuwe features kan introduceren en stabiliseren, die dan weer worden meegenomen naar versie 8.

Dus het is niet alsof er elke paar maanden een nieuwe .NET-versie uitkomt. Aandacht hiervoor geeft voor mij aan dat versioning, onderhoud en support in ieder geval op dat vlak serieus worden genomen.

Vandaar dat ik zou voorstellen om er in dat geval ".NET 6+" van te maken, en 3.1/5 daar los van te trekken. Dan hoef je eerstgenoemde over een jaar of anderhalf pas weer te updaten.

RagingPenguin schreef op donderdag 29 september 2022 @ 09:55:
[...]


Dit kan natuurlijk ook voorkomen als de vacature tekst wat ouder is, sommige vacatures staan lang open en men schrijft niet altijd een hele nieuwe tekst als er een positie open komt.

Aan de ene kant begrijp ik dat. Aan de andere kant geeft het je sollicitanten gewoon een bepaald beeld. Als een vacature/opdracht nu bijvoorbeeld trots zou vermelden dat er "met de nieuwste technieken (.NET 5)!" wordt gewerkt, dan zou die voor mij alvast een paar mentale minpuntjes krijgen.

Hoeveel moeite is het om, na de upgrade van je softwareprojecten, een getalletje in een vacature op te hogen? Je gaat in de looptijd van het contract van je kandidaat tien-, zo niet honderdduizenden euro's aan hen spenderen, kan dat beetje moeite er niet meer van af om ze te lokken?

[Verwijderd]

Verwijderd

[ Voor 116% gewijzigd door Verwijderd op 27-10-2023 20:50 ]

[Mugwump]

CodeCaster schreef op donderdag 29 september 2022 @ 14:53:
[...]

Het is slechts mijn mening, dus doe er vooral mee wat je wil.

In mijn ervaring hebben dotnetters als geen ander een hekel aan het moeten onderhouden van andermans legacy.

Dat is niet voorbehouden aan dotnetters hoor.

[Verwijderd]

Verwijderd

[ Voor 107% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[CodeCaster]

Verwijderd schreef op donderdag 29 september 2022 @ 15:47:
[...]


Ik ben eigenlijk wel benieuwd hoe groot het aandeel is die géén probleem hebben met het onderhouden van legacy code. Bij veel bedrijven is dit namemlijk wel een gegeven. Misschien volgende maand eens een poll over houden op Linkedin.

Ik zou zeggen, zoals ik altijd en overal al zeg: het hangt ervan af.

Met name van de kennis en kunde van degenen die het systeem hebben opgezet. Zijn er tests, is er documentatie, zijn best practices en patterns gevolgd en is niet gepoogd om zelf alle wielen opnieuw in het vierkant uit te vinden?

Of is het van een self-taught rockstar die al tien jaar geen andere code heeft gezien of aangeraakt, die NuGet-packages van anderen niet vertrouwt, en die zelf koste wat kost een framework wilde opzetten zonder er zelf ooit een gebruikt te hebben? Zonder één enkele comment (uitgecommente code daargelaten), zonder foutafhandeling of developer-vriendelijke exceptions op de juiste plaatsen (NullRefs vijftien stack frames diep in cryptisch genaamde utility-methods die je moet gebruiken om jouw code in het framework te krijgen), code die zo custom is en die zó hard probeert om generics te gebruiken en async te vermijden dat soms zelfs de compiler, de runtime of heel Visual Studio er gewoon mee stoppen?

U hoort het, ik heb in het geheel geen trauma's opgelopen in het verleden. Daarentegen heb ik aan uit de .NET Framework 1-tijd stammende code gewerkt die zó goed in elkaar zat en met het framework en de taal was meegeëvolueerd, en nog steeds voldeed aan de eisen van de systemen die erop gebouwd waren, dat het heerlijk was om in te werken. Ook al was alles custom (op de Enterprise Library na), en was er uiteraard nergens op het hele internet hulp te vinden voor de fouten die het soms gooide.

Dit soort subtiliteit past niet in een polletje. Tegelijkertijd is "als ze genoeg betalen" mogelijk wel een valide antwoord, maar dan is "genoeg" weer voor iedere persoon en situatie anders.

Elk systeem is legacy zodra het leeft. Het ene legacy-systeem blijft enkel langer in gebruik dan het ander. Soms heb je de luxe om from scratch iets te kunnen opzetten; meestal heeft een bedrijf bagage of gewoontes.

Maar dit heeft verder erg weinig meer met recruiters te maken.

[Verwijderd]

Verwijderd

[ Voor 156% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[RagingPenguin]

Verwijderd schreef op donderdag 29 september 2022 @ 15:47:
[...]


Ik ben eigenlijk wel benieuwd hoe groot het aandeel is die géén probleem hebben met het onderhouden van legacy code. Bij veel bedrijven is dit namemlijk wel een gegeven. Misschien volgende maand eens een poll over houden op Linkedin.

Zoals je hem hier omschrijft heb je wel twee interpretaties:
- developers die nu een probleem hebben met legacy software in hun huidige rol
- developers die een probleem hebben met het accepteren van een baan waar legacy onderhouden onderdeel is van de omschrijving

Zoals @CodeCaster al omschrijft, niet alle legacy is problematisch, maar als het heel nadrukkelijk 'legacy' genoemd wordt dan schept dat wel die verwachting. Hier bij een groot product bedrijf is het enige project jaren oud, maar het is wel cutting edge (zeg maar rechterbovenhoek Gartner Magic Quadrant innovatief) met alle best practices en een serieus budget om dat zo te houden (denk aan bv 100+ FTE aan enkel specops gerelateerde zaken).

Bij mijn vorige baan was bijna alles greenfield, maar dan zonder budget voor testen, QA, goede architectuur en alles draaide om zo snel mogelijk features verschepen. Onder de streep was die code veel slechter en deden we veel meer aan typisch legacy gezeur (vage bugs, hacks om verkeerd datamodel etc), ook was die code veel nieuwer en vaak nog niet eens live.

Vanuit een developers perspectief draait legacy imho niet eens zo zeer om hoe oud software is, maar of men heeft opgegeven om het goed te doen. En sommige bedrijven doen daar niet eens een poging toe (en is alles vanaf uur 0 legacy) terwijl andere bedrijven decennia oude software hebben die nog in perfecte staat is.

[Transportman]

Verwijderd schreef op donderdag 29 september 2022 @ 15:47:
[...]


Ik ben eigenlijk wel benieuwd hoe groot het aandeel is die géén probleem hebben met het onderhouden van legacy code. Bij veel bedrijven is dit namemlijk wel een gegeven. Misschien volgende maand eens een poll over houden op Linkedin.

Ik heb niet zo zeer een probleem met legacy onderhouden, het hoort er bij, je kan niet constant aan nieuwe spannende projecten werken, maar er moet wel een balans in zijn. En zoals anderen al aangeven, het hangt er vanaf. Legacy die goed in elkaar zit, goed gedocumenteerd is, is prima om te onderhouden en zullen de meeste geen probleem mee hebben als onderdeel van hun werkzaamheden, maar meestal voldoet legacy daar niet aan. Dan is de legacy slecht of niet gedocumenteerd, zit het structureel niet goed in elkaar, weet niemand hoe het werkt en is er al jaren geen of onvoldoende onderhoud aan gepleegd omdat "het werkt" en er geen budget voor is.

Wat dat betreft, als legacy al in de vacature staat of tijdens gesprekken naar voren komt, ga ik er al vanuit dat het vooral problematische legacy is. En ik heb er wel eens sollicitaties op afgebroken, omdat het echt om problematische legacy ging of de processen zodanig ingericht waren dat de kans op problemen gewoon 100% was.

[Mugwump]

Verwijderd schreef op donderdag 29 september 2022 @ 15:47:
[...]


Ik ben eigenlijk wel benieuwd hoe groot het aandeel is die géén probleem hebben met het onderhouden van legacy code. Bij veel bedrijven is dit namemlijk wel een gegeven. Misschien volgende maand eens een poll over houden op Linkedin.

Ik ken er wel een paar. Lang niet alle developers vinden het maar leuk om met allerlei nieuwe, hen onbekende zaken te werken. Er zijn er ook wel die wat behoudender zijn en liever werken in een vertrouwde omgeving waarin ze zich comfortabel voelen, zowel qua techniek, als qua werkwijze en domein.

Ik zit zelf alweer een aardige tijd op een enorm migratietraject om een stuk legacy software te herbouwen. Die legacy software wordt ook nog gewoon onderhouden / minimaal doorontwikkeld door nog twee man. Dat zijn precies het soort types dat het prima vind om aan dat soort software te werken. Ze doen dat bovendien al meer dan 10 jaar. Oude meuk, testen gebeurt met de hand met een verslagje wat via mail of sharepoint wordt opgeleverd, uitrollen is allemaal handwerk en ga zo maar door. De technologie an sich is nog niet eens zozeer het probleem vaak.

[mannowlahn]

Hydra schreef op woensdag 28 september 2022 @ 20:52:
[...]


Als daar het antwoord op die vraag "Java" gaat zijn, ga ik je slaan

Overigens; de Java ZZP markt wordt ook goed verziekt door recruiters dus ik zou er zeker geld voor over hebben.

Ze worden wanhopig, gisteren belde een recruiter. Ik dacht daar gaan we weer. Die vroeg of ik wist of mensen met mijn profiel nog gezocht worden bij mijn opdrachtgever want hij had nog iemand. Heb gezegd dat ik zo hard werk dat ze niemand meer nodig hebben (gelogen hoor, ik doe geen flikker )

Ik vind trouwens de opzet van freelancedev.nl echt top. Geen recruiters er tussen, over het algemeen staat tarief er ook bij. Dit is echt een win win voor beide partijen. Als ik straks weer op zoek ga hoop ik via dit platform wat te vinden. Je ziet ook meteen dat je tarief met 20 euro omhoog gaat omdat er geen marge meer is. Zo stond gemeente Amsterdam er op die 120 euro overhadden voor azure cloud engineer. Dat is natuurlijk afwachten of je dat er uit haalt maar wel een behoorlijk verschil tov wat ik nu als tarief krijg.

[ Voor 30% gewijzigd door mannowlahn op 30-09-2022 08:02 ]

[mannowlahn]

Verwijderd schreef op donderdag 29 september 2022 @ 15:47:
[...]


Ik ben eigenlijk wel benieuwd hoe groot het aandeel is die géén probleem hebben met het onderhouden van legacy code. Bij veel bedrijven is dit namemlijk wel een gegeven. Misschien volgende maand eens een poll over houden op Linkedin.

Ik ben benieuwd naar de uitslag, met name degene die antwoorden. Ik heb jarenlang(bijna twintig jaar) meegelopen als c# developer, maar het is niet c# specifiek, zie het nu ook met infra mensen die niet naar de cloud willen. Ik zag vooral vaak dezelfde soort types die geen problemen met legacy hebben. Ze waren de reden van legacy. Het is een een vrij ironische it’er. IT is vooruitgang, doorpakken. Maar dit zijn vaak one trick ponies en enorm stug in overtuigen, de uren/dagen die verspild zijn in vergaderingen. Voor geen goud zou ik ooit nog legacy projecten willen doen. Trekken aan een dood paard is nog rooskleurig. Deze paarden zijn jarenlang begraven onder een laag mest, die moet je laten liggen. Ik kan mij met mijn pet niet bij dat iemand die werkzaam is in de IT en dan hetgeen wat het zo leuk maakt, oude methodes verbeteren, dan niet oppakt. Maar degen die wel overwillen en ze begeleiden is dan wel weer een leuk traject wat voldoening geeft. Vaak waren dat de wat minder vocale mensen die onder gesneeuwd werden door de stugge collega’s.

Dan zou je nog kunnen stellen, ja maar als freelancer kan je behoorlijk verdienen met legacy. Dat klopt maar je hebt dan een houdbaarheid. Elk jaar minder projecten te vinden want de boel droogt op. Dus wellicht interessant om vanaf je 50e te doen?

[Verwijderd]

Verwijderd

[ Voor 98% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[Verwijderd]

Verwijderd

[ Voor 99% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[Verwijderd]

Verwijderd

[ Voor 97% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[Verwijderd]

Verwijderd

[ Voor 100% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[Mugwump]

Verwijderd schreef op vrijdag 30 september 2022 @ 09:20:
[...]


Dit inderdaad. Zoals zojuist aangaf heb ik ze ook gesproken. Zoveel mensen, zoveel wensen.

Ergens kan ik het mij ook wel voorstellen. Wanneer je op een gegeven met je eigen systeem/omgeving gecreëerd hebt dan is dat je comfort zone.

En dat niet alleen. Je krijgt ook vaak veel waardering. Jij bent immers degene die precies weet waarom dingen zo zijn (veelal omdat je die spaghetticode zelf in elkaar hebt gedraaid). Jij bent degene die steeds weer alle problemen oplost (die je veelal zelf eigenlijk veroorzaakt, direct of indirect).
Het laatste wat ik persoonlijk wil in m'n werk is onmisbaar zijn omdat ik een systeem in elkaar heb gebrouwen waar niemand anders z'n weg in kan vinden, maar er zijn mensen die daar om de een of andere reden heel veel trots en voldoening uithalen.
Ik heb zelf wel eens gehad dat er grote paniek was in een organisatie en er moest iets gebeuren met een softwaretooltje dat geschreven was door persoon X, maar die was op vakantie. Of ik er even naar wilde kijken. Bleek een stuk lineaire PHP scripting te zijn met daarin myVariable1 t/m 526 en myTemporaryArray1 t/m 298. Nou, succes ermee.

[CVTTPD2DQ]

Verwijderd schreef op vrijdag 30 september 2022 @ 09:34:
Wanneer een huis eenmaal gebouwd is en het dient zijn doel (mensen zijn tevreden), dan kan het gerust jaren zo blijven staan zonder veel wijzigingen (ook al is het fundament misschien niet heel goed). Het is pas wanneer het niet meer in zijn doel voorziet (gezinsuitbreiding, duurzaamheid, instortingsgevaar door dat slechte fundament etc), ga je kijken of je het wilt aanpassen.

Veranderen voor het veranderen heeft natuurlijk weinig zin behalve dat het voor sommige IT'ers misschien een leuke speeltuin creëert.

Leuke metafoor. En in die metafoor zijn veel IT-projecten natuurlijk een mooi jaren '30 huis, waar ergens in de jaren '70 een zitkuil is ingeklust, die in de jaren '90 weer is opgevuld met piepschuim platen (want isolatie, weetjewel). De achtermuur is in de jaren '80 uitgebroken om een grote sèrre te maken, waar vorig jaar weer een overkapping met een buitenkeuken aan vast gemaakt is. De ramen roesten onderhand uit de dakkapel, maar het dak ligt helemaal vol met zonnepanelen, dus we zijn compleet bij de tijd, toch?

Mensen werken het liefst aan makkelijke klussen met een grote zichtbaarheid, die direct iets opleveren. Als je echt de fundamenten van een "huis" wil verstevigen heb je mensen met gezag en kennis nodig die daar belang aan hechten.

Om het heel bot te zeggen, ik denk dat voor veel developers het extreem belangrijk is aan wat voor "huis" ze mogen gaan werken. Maar dat is iets waar een organisatie zelf vaak weinig inzicht in heeft.

[Transportman]

Verwijderd schreef op vrijdag 30 september 2022 @ 09:17:
[...]


Ik vermoed ook dat de meeste developers er zo over denken.

Een van onze vacature vragen is "Wat is (ongeveer) de verdeling tussen bug fixing, nieuwbouw/nieuwe features, wegwerken technical debt?" Deze informatie helpt denk ik wel om een eerste indruk te krijgen. Ik heb namelijk ook wel eens developers gesproken die perse alleen greenfield wilde doen, maar ook die juist graag brownfield wilde doen. Naast deze vraag kun je vacatures ook nog filteren op specifiek nieuwbouw of bestaande (uit)bouw.)

Uiteraard is al deze informatie slechts bedoeld als eerste filter en uiteindelijk ga je dan solliciteren. Want op basis van deze informatie alleen kun je meestal niet achterhalen of legacy slecht gedocumenteerd is of structureel niet goed in elkaar zit etc. Daarom adviseer ik mensen ook altijd om in ieder geval een halve of hele dag mee te draaien. Dit geeft je toch het beste idee van de code en de cultuur binnen een bedrijf (nog steeds geen garantie, maar die zijn er nooit).

Ik heb inderdaad ooit een keer een halve dag ergens meegedraaid, en kwam er toen achter dat met hoe de processen in elkaar zaten, dat dat gewoon niet paste bij mij als persoon. Maar een halve of hele dag meedraaien moet ook maar net in de agenda's passen, en ook met het vele thuiswerken tegenwoordig is dat nog lastiger om passend te krijgen.

Verwijderd schreef op vrijdag 30 september 2022 @ 09:34:
[...]


Zoals ik zojuist al aangaf, zoveel mensen, zoveel wensen. De perceptie die we hebben van IT is vooruitgang maar IT is ook niet meer dan een middel voor een doel. Zoals stenen het doel zijn van een huis.

Wanneer een huis eenmaal gebouwd is en het dient zijn doel (mensen zijn tevreden), dan kan het gerust jaren zo blijven staan zonder veel wijzigingen (ook al is het fundament misschien niet heel goed). Het is pas wanneer het niet meer in zijn doel voorziet (gezinsuitbreiding, duurzaamheid, instortingsgevaar door dat slechte fundament etc), ga je kijken of je het wilt aanpassen.

Veranderen voor het veranderen heeft natuurlijk weinig zin behalve dat het voor sommige IT'ers misschien een leuke speeltuin creëert.

Aan de andere kant kan ik mij goed voorstellen dat mensen die gewoonweg niet willen veranderen (vanuit angst, ongemak, onzekerheid) terwijl het wel nodig is, een grote bron van ergernis zijn voor de mensen om hun heen.

Maar ook een huis moet onderhouden worden. Een goed gebouwd nieuwbouwhuis nu zal de komende jaren minder onderhoud nodig hebben, maar op een gegeven moment gaat dat wel nodig zijn. In de IT is dat onderhoud alleen veel sneller nodig omdat op allerlei niveaus nieuwe patches en versies uitgebracht worden, en vervolgens is de keuze, zorg je dat je IT bij blijft en voer je met iedere versie ook de nodige verbeteringen door (om in de huizen te blijven: vervang je de kozijnen gelijk als je de ramen vervangt door dubbelglas), doe je het minimale om bij te blijven (vervang je alleen de ramen), of doe je helemaal niets en sta je dan opeens voor een gigantische uitdaging (je moet niet alleen de ramen nog vervangen, maar eigenlijk kan je beter een compleet nieuwe woning neerzetten).

[Verwijderd]

Verwijderd

[ Voor 100% gewijzigd door Verwijderd op 27-10-2023 20:45 ]

[Verwijderd]

Verwijderd

[ Voor 98% gewijzigd door Verwijderd op 27-10-2023 20:44 ]

[CVTTPD2DQ]

Verwijderd schreef op vrijdag 30 september 2022 @ 10:18:
Aan de andere kant van het spectrum heb je developers die willen veranderen voor het veranderen. Een modern huis, die alle voorzieningen heeft wat je van een huis anno 2022 mag verwachten, maar "hé wacht even. Ik las laatst dat artikel over een lift in je huis. Dan klinkt makkelijk en leuk. Laten we dat ook doen!" Terwijl gewoon iedereen goed ter been is en prima de trap kan gebruiken.

En als je dan het management meekrijgt (zeker als het zichtbaar en goed te verkopen is), dan komt die lift er.

De andere kant is het verstevigen van de funderingen. Dan komen een paar serieus kijkende mannen met grijze haren vragen om een fors bedrag. De rotte balken moeten worden vervangen, maar de wekelijkse house-parties mogen niet gestoord worden. Het gaat een halfjaar aan werk kosten, en op korte termijn geen cent opleveren. Je kunt er geen ZZP'er of junior voor inhuren, want die willen het werk niet doen, en weten sowieso niet waar de problemen zitten.

Achteraf snapt niemand wat het probleem nou was.

[CodeCaster]

Ik ben wel benieuwd (hey, een link naar recruitment ) hoe er gezocht wordt naar mensen voor nieuwbouw/greenfield.

Als een bedrijf besluit dat een stuk software nodig is, ofwel geheel nieuw, dan wel vervanging, dan moet dat toch eerst op enige wijze gespect worden. Welk probleem is er, en waaraan moet het systeem dat dat gaat oplossen voldoen?

Dan kijk je toch eerst naar binnen, naar de al aanwezige developers met domeinkennis, want externen moeten eerst 1-3 maanden inkomen in de business.

[Verwijderd]

Verwijderd

[ Voor 94% gewijzigd door Verwijderd op 27-10-2023 20:44 ]

[Mugwump]

Verwijderd schreef op vrijdag 30 september 2022 @ 10:22:
Ben ik het ook mee eens. Het ging mij er meer om dat sommige IT'ers veranderen om het veranderen, terwijl het niet direct het doel van de organisatie dient. Maar tussen dit en tevreden zijn met hele slechte IT en niets hieraan doen, zit natuurlijk nog een heel spectrum.

Sterker nog, ik ben als IT'er juist vaak aan het terugduwen. Ik zit nu weer bij zo'n prachtige corporate waar ze zogenaamd agile werken oftewel: centraal megalomane ideeën bedenken, laten uitwerken door de afdeling blokjes en pijltjes (enterprise architecture) en dan werk bij teams naar binnen schuiven voor een kwartaal waarbij je dan als team volledig de vrijheid hebt om met 15 andere teams af te gaan stemmen hoe je onderling brokjes werk gaat opleveren zodat er gezamenlijk iets kan worden bereikt wat natuurlijk aan het eind van het kwartaal weer leidt tot verbazing en teleurstelling als er feitelijk weer niets van waarde is opgeleverd.

Vaak kunnen dat soort megalomane ideeën veel efficiënter in MVP vorm worden opgeleverd in een paar weken, waarbij je ook de feedback van je klanten / gebruikers kunt meten. Goed, dan heb je niet de fantastische doelarchitectuur zoals die bedacht was door een paar figuren in een ivoren toren die al 20 jaar niet meer met hun voeten in de klei staan of dat überhaupt nooit hebben gestaan.

Daarnaast proberen we tussen al die zaken door nog een complexe migratie af te ronden. En waar we een paar van die jonge honden in ons team hebben die niets liever willen doen dan gelijk weer nieuwe technologieën uit de kast trekken en bakken code produceren om zaken uit het oude systeem te herbouwen, begin ik eerst met de vraag 'is dit nog relevant'. Bij het migreren van legacy kom je vaak bakken functionaliteit tegen waarvan helemaal niemand je nog kan uitleggen wat de waarde voor het bedrijf is of waarvan zelfs blijkt dat het bedoeld was voor bijvoorbeeld een dienst of product dat helemaal niet meer bestaat. Zo hebben we denk ik al 20-30% van de functionaliteit (en bijbehorende code) met pensioen gestuurd. Geen enkele migratiestrategie uit de 6 R-en van AWS is zo efficiënt als 'retire'.

Uiteindelijk denk ik dat je als je als developer wil groeien je toch echt veel meer bezig moet zijn met de businesskant van het verhaal als je echt waarde aan een organisatie wilt toevoegen. Ik zie nog te veel developers die denken dat het enkel hun werk is om koffie in code te veranderen, maar als dat je enige toegevoegde waarde is, dan is je werk ook prima te outsourcen naar lagelonenlanden.
Natuurlijk, er zijn ook wel voornamelijk technische projecten en organisaties waarbij de nadruk ligt op het implementeren van complexe algoritmen, maar heel bot gezegd werkt het gros van de developers toch vooral aan technisch vrij triviale zaken om in het bedrijfsleven processen te automatiseren of faciliteren.

[Verwijderd]

[Verwijderd

[ Voor 97% gewijzigd door Verwijderd op 27-10-2023 12:16 ]

[Verwijderd]

Verwijderd

[ Voor 100% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[0xDEADBEEF]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

offtopic:
brownfield

[CodeCaster]

Mugwump schreef op vrijdag 30 september 2022 @ 11:35:
[...]
zo'n prachtige corporate waar ze zogenaamd agile werken oftewel: centraal megalomane ideeën bedenken, laten uitwerken door de afdeling blokjes en pijltjes (enterprise architecture) [...] een paar figuren in een ivoren toren die al 20 jaar niet meer met hun voeten in de klei staan of dat überhaupt nooit hebben gestaan.

Ach ja. Zij die denken "als één blokje 1000 klanten bedient, zeggen we dat we er van dat blokje 10 nodig hebben", of "als we dit pijltje tekenen, dan kunnen die bokjes informatie uitwisselen".

[Hydra]

@Mugwump ik vind je weergave van 'enterprise development' zo treffend dat spontaan weer jeuk krijg.

[Hydra]

Verwijderd schreef op vrijdag 30 september 2022 @ 11:47:
Zou ik zo iemand in dienst hebben dan is mij dat veel waard.

Ja maar jij hebt geen enterprise architect in dienst die dan 2 weken na dat de feature opgeleverd is stennis gaat schoppen bij de manager van de developer dat hij niet de 'doelarchitectuur' volgt.

[mannowlahn]

Verwijderd schreef op vrijdag 30 september 2022 @ 09:34:
[...]


Zoals ik zojuist al aangaf, zoveel mensen, zoveel wensen. De perceptie die we hebben van IT is vooruitgang maar IT is ook niet meer dan een middel voor een doel. Zoals stenen het doel zijn van een huis.

Wanneer een huis eenmaal gebouwd is en het dient zijn doel (mensen zijn tevreden), dan kan het gerust jaren zo blijven staan zonder veel wijzigingen (ook al is het fundament misschien niet heel goed). Het is pas wanneer het niet meer in zijn doel voorziet (gezinsuitbreiding, duurzaamheid, instortingsgevaar door dat slechte fundament etc), ga je kijken of je het wilt aanpassen.

Veranderen voor het veranderen heeft natuurlijk weinig zin behalve dat het voor sommige IT'ers misschien een leuke speeltuin creëert.

Aan de andere kant kan ik mij goed voorstellen dat mensen die gewoonweg niet willen veranderen (vanuit angst, ongemak, onzekerheid) terwijl het wel nodig is, een grote bron van ergernis zijn voor de mensen om hun heen.

Ik ben met je eens dat het een middel is en geen doel. Echter als je niet meegaat dan werk je op een gegeven moment met meuk wat niet meer gesupport wordt, veiligheid komt in gevaar, je wordt gegijzeld door een aar ouwe lullen en als je eenmaal besluit dat het toch anders moet ben je vaak te laat. Dat veranderen heeft wel een doel, dat je zorgt dat je meer mensen uit de markt kan aantrekken, dat je je geen zorgen hoeft te maken over veiligheidslekken, dat je een grotere markt kan bedienen omdat mensen nou eenmaal niet meer op een desktop werken maar graag een web app willen.

Om jou metafoor door te trekken, als jij een huis bouwt met materialen die na verloop van tijd niet meer beschikbaar zijn en je moet repareren en je wil andere materialen gebruiken die niet aansluiten, dan is je huis gedoemd tot instorten. Incrementeel zaken aanpakken heeft bewezen een betere tactiek te zijn.

[Verwijderd]

Verwijderd

[ Voor 95% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[Verwijderd]

Verwijderd

[ Voor 102% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[CodeCaster]

mannowlahn schreef op vrijdag 30 september 2022 @ 15:38:
[...]

dat je een grotere markt kan bedienen omdat mensen nou eenmaal niet meer op een desktop werken maar graag een web app willen.

Bwoahhhhh... Voor inhouse werk waarbij interactie met de desktop, randapparatuur en/of het netwerk belangrijk is, is nog steeds een markt voor desktopapplicaties hoor.

Of je maakt er een PWA van die je in Electron hangt waarbij je dan een subset van API's krijgt, maar dan heb je ineens tien nieuwe problemen.

[mannowlahn]

CodeCaster schreef op vrijdag 30 september 2022 @ 16:17:
[...]

Bwoahhhhh... Voor inhouse werk waarbij interactie met de desktop, randapparatuur en/of het netwerk belangrijk is, is nog steeds een markt voor desktopapplicaties hoor.

Of je maakt er een PWA van die je in Electron hangt waarbij je dan een subset van API's krijgt, maar dan heb je ineens tien nieuwe problemen.

Tuurlijk er zijn vast wat marginale interne projecten te verzinnen waarbij je met frameworks aan de gang kan gaan zoals electron of andere meuk.

Ik doelde meer op het gros van de markt.

[RagingPenguin]

Verwijderd schreef op vrijdag 30 september 2022 @ 15:52:
[...]


Ben ik ook met je eens. In dat geval dient veranderen ook echt een doel. Ik zou zelfs durven stellen dat wanner je genoeg geld verdient en developers dusdanig belangrijk zijn voor je organisatie, het een doel heeft om deze mensen play-time te geven binnen je organisatie. Dit met als enige doel developers de vrijheid te geven te doen wat ze graag willen doen om daarmee extra mensen aan te trekken.

Het grappige aan play-time/garage days/crafting days vind ik altijd dat het vaak de meest productieve dagen zijn. De meeste mensen doen niet niks als je ze zelf laat bepalen wat ze doen, maar ze automatiseren kleine taken, voegen gimmicky features toe, fixen kleine problemen, zetten ergens de puntjes op de i, of leren iets nieuws. Allemaal dingen die zich direct of indirect terug betalen.

[Verwijderd]

Verwijderd

[ Voor 102% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[Arloid]

Ah ja, IKEA. 1 keer neerzetten en nooit meer verplaatsen. Snap wel dat code door een ander ook zo gezien wordt door IT'ers.

Persoonlijk zit ik dan toch meer in de houtbewerking, wat minder relevante werkervaring, of gekwalificeert in de software kant dan ik eigenlijk wil. Maar goed, een eigen werkplaats en ervaring met het ondersteunen van studenten met CAD en CAM vragen met betrekking tot Co2 lasersnijders en fdm printers is hopelijk ook wat waard.

Maar goed, ik vroeg mij af wat een goede manier is om arbeidsbeperkingen aan te geven. Ik denk zelf dat het wellicht beter is om elke beperking apart bij te lichten en te beginnen met de positieve punten, gevold met waar ik tegenaan loop met daarbij een oplossing.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[unezra]

Arloid schreef op zaterdag 1 oktober 2022 @ 10:10:
Maar goed, ik vroeg mij af wat een goede manier is om arbeidsbeperkingen aan te geven. Ik denk zelf dat het wellicht beter is om elke beperking apart bij te lichten en te beginnen met de positieve punten, gevold met waar ik tegenaan loop met daarbij een oplossing.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

Ik zou hier in een motivatiebrief kort en open over zijn, maar ook aangeven dat je dit in een persoonlijk gesprek nader toe kunt lichten. Kortom, 2 zinnen aan wijden zodat het geen verrassing is, maar meteen in die zinnen aangeven dat het minimale impact heeft op je functioneren en als de verwachting is dat het verbetert, dát ook meteen aangeven.

Je loopt het risico dat er een aantal deuren gesloten blijven, da's met alles en iedereen die niet in het perfecte plaatje past, maar tegelijkertijd zijn de deuren die gesloten blijven omdat je er meteen eerlijk over bent, denk ik ook de deuren waarvan je sowieso niet moet willen dat ze open gaan. Beter aan de voordeur afgewezen dan op de werkvloer er achter komen dat de omgeving toch niet past.

[Arloid]

unezra schreef op zaterdag 1 oktober 2022 @ 10:22:
[...]


Ik zou hier in een motivatiebrief kort en open over zijn, maar ook aangeven dat je dit in een persoonlijk gesprek nader toe kunt lichten. Kortom, 2 zinnen aan wijden zodat het geen verrassing is, maar meteen in die zinnen aangeven dat het minimale impact heeft op je functioneren en als de verwachting is dat het verbetert, dát ook meteen aangeven.

Je loopt het risico dat er een aantal deuren gesloten blijven, da's met alles en iedereen die niet in het perfecte plaatje past, maar tegelijkertijd zijn de deuren die gesloten blijven omdat je er meteen eerlijk over bent, denk ik ook de deuren waarvan je sowieso niet moet willen dat ze open gaan. Beter aan de voordeur afgewezen dan op de werkvloer er achter komen dat de omgeving toch niet past.

Dat is wellicht ook wat praktischer dan om het geheel mondeling toe te lichten. Ik deel ook je mening wat dichte deuren betreft.

Ik verwacht inderdaad dat m'n klachten ook wel milder worden, of beter gezegd dat ik ermee leer leven. Zal nog wel even duren voordat ik weer op m'n oude niveau zit, maar beter parttime aan de slag dan op de bank.

[Frieda]

Arloid schreef op zaterdag 1 oktober 2022 @ 10:10:
Ah ja, IKEA. 1 keer neerzetten en nooit meer verplaatsen. Snap wel dat code door een ander ook zo gezien wordt door IT'ers.

Persoonlijk zit ik dan toch meer in de houtbewerking, wat minder relevante werkervaring, of gekwalificeert in de software kant dan ik eigenlijk wil. Maar goed, een eigen werkplaats en ervaring met het ondersteunen van studenten met CAD en CAM vragen met betrekking tot Co2 lasersnijders en fdm printers is hopelijk ook wat waard.

Maar goed, ik vroeg mij af wat een goede manier is om arbeidsbeperkingen aan te geven. Ik denk zelf dat het wellicht beter is om elke beperking apart bij te lichten en te beginnen met de positieve punten, gevold met waar ik tegenaan loop met daarbij een oplossing.


***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Arloid]

Frieda schreef op zondag 2 oktober 2022 @ 15:04:
[...]


***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Frieda]

Arloid schreef op zondag 2 oktober 2022 @ 19:09:
[...]


***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[defiant]

Verwijderd schreef op vrijdag 30 september 2022 @ 15:52:
Het probleem ligt volgens mij bij developers/ IT'ers die alleen de nieuwste technieken willen implementeren omdat het de nieuwste technieken zijn. Dus veranderen voor het veranderen.

Dat klopt vaak maar deels, men wil de nieuwste technieken omdat de uitdagende en goedbetaalde banen vaak de nieuwste technieken als nice of must have hebben in de vacature. Mis je de boot met het bijzijn met nieuwe technieken en ga je achterlopen, dan is het vaak moeilijk om relevante werkervaring op te doen met nieuwe technieken, waardoor je carrièreperspectief daalt.

Men wijst vaak naar developers als oorzaak van dit probleem, maar een groot gedeelte ligt toch echt aan werkgevers die zelf de dynamiek creëren waarin het noodzakelijk is voor carrière ontwikkeling om die nieuwe technieken te beheersen.

Hier heb ik bij mijn vorige werkgever in house recruitment ook wel eens op gewezen, men zei dat men mensen met oude technieken op de CV niet eens uitnodigden. Ik wees er toen op dat we de mensen die we afwijzen gewoon ook zelf in in al in dienst hebben op de legacy projecten die er in dat bedrijf waren.

[Motrax]

defiant schreef op zondag 2 oktober 2022 @ 23:58:
[...]

Dat klopt vaak maar deels, men wil de nieuwste technieken omdat de uitdagende en goedbetaalde banen vaak de nieuwste technieken als nice of must have hebben in de vacature. Mis je de boot met het bijzijn met nieuwe technieken en ga je achterlopen, dan is het vaak moeilijk om relevante werkervaring op te doen met nieuwe technieken, waardoor je carrièreperspectief daalt.

Men wijst vaak naar developers als oorzaak van dit probleem, maar een groot gedeelte ligt toch echt aan werkgevers die zelf de dynamiek creëren waarin het noodzakelijk is voor carrière ontwikkeling om die nieuwe technieken te beheersen.

Hier heb ik bij mijn vorige werkgever in house recruitment ook wel eens op gewezen, men zei dat men mensen met oude technieken op de CV niet eens uitnodigden. Ik wees er toen op dat we de mensen die we afwijzen gewoon ook zelf in in al in dienst hebben op de legacy projecten die er in dat bedrijf waren.

Ja dat is een heel lastige balans. We nodigen iedereen uit die reageert en een redelijke aansluiting met het cv heeft.

In mijn vakgebied is cloud enorm aan het toenemen. Wij proberen ook bewust nieuwe dingen op te pakken (binnen redelijke grenzen) om vakinhoudelijk een interessante werkgever te blijven. En met cloud is dat sowieso makkelijker, even een service aanzetten, testen, voor/nadelen afwegen en soms op de plank laten liggen tot er een goede use case langs komt.

Ontwikkelaars in oude tooling kunnen heel goed zijn, we hebben goede ervaringen gehad, maar ook een aantal heel slechte. Vaak zijn dat wat oudere mensen en tot nu is de flexibiliteit om over te stappen naar de nieuwe stack... tegengevallen... oude denkpatronen, kunnen de complexiteit en hoeveelheid keuzes van cloud niet overzien. Vaak geen interesse om meer bij te blijven. Sterker nog: git/versie beheer is vaak al een probleem

Dus relevante cloud ervaring heeft bij ons zeer sterk de voorkeur.

Tegelijkertijd nu 2 junioren in ons team en het tempo waar die de oude en nieuwe stack oppakken is simpelweg eng. Overigens waren de junioren een bewuste keuze. We hadden genoeg seniors in het team, we moesten uitbreiden en ik denk dat we onze junioren een goede leeromgeving kunnen bieden.

[ Voor 5% gewijzigd door Motrax op 03-10-2022 05:11 ]

[Verwijderd]

Verwijderd

[ Voor 100% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[Mugwump]

Motrax schreef op maandag 3 oktober 2022 @ 05:09:
[...]
Ja dat is een heel lastige balans. We nodigen iedereen uit die reageert en een redelijke aansluiting met het cv heeft.

In mijn vakgebied is cloud enorm aan het toenemen. Wij proberen ook bewust nieuwe dingen op te pakken (binnen redelijke grenzen) om vakinhoudelijk een interessante werkgever te blijven. En met cloud is dat sowieso makkelijker, even een service aanzetten, testen, voor/nadelen afwegen en soms op de plank laten liggen tot er een goede use case langs komt.

Ontwikkelaars in oude tooling kunnen heel goed zijn, we hebben goede ervaringen gehad, maar ook een aantal heel slechte. Vaak zijn dat wat oudere mensen en tot nu is de flexibiliteit om over te stappen naar de nieuwe stack... tegengevallen... oude denkpatronen, kunnen de complexiteit en hoeveelheid keuzes van cloud niet overzien. Vaak geen interesse om meer bij te blijven. Sterker nog: git/versie beheer is vaak al een probleem

Dus relevante cloud ervaring heeft bij ons zeer sterk de voorkeur.

Tegelijkertijd nu 2 junioren in ons team en het tempo waar die de oude en nieuwe stack oppakken is simpelweg eng. Overigens waren de junioren een bewuste keuze. We hadden genoeg seniors in het team, we moesten uitbreiden en ik denk dat we onze junioren een goede leeromgeving kunnen bieden.

Het type 'git is al moeilijk' ken ik ook maar al te goed, maar aan de andere kant heb ik ook genoeg slechte ervaringen met wat ik maar even de 'Tiktokgeneratie van developers' zal noemen. Recent nog twee vrij jonge developers uit ons team weggesaneerd omdat ze gewoon niet in staat waren die verdiepingsslag te maken die nodig is als je echt verder wilt komen en elke keer 'wat nieuws wilden oppakken' zonder dat ze dat oude nou eigenlijk echt in de vingers hadden. Als je vooral bezig bent met heel oppervlakkig wat met technologieën werken dan kan je in mijn ogen nog niets. De WO'er in mij vindt al die flitsende nieuwe technologieën ook niet zo spannend. Echt grote fundamentele doorbraken zijn er al decennia niet. Het meeste is gewoon oude wijn in nieuwe zakken. Fundamenteel begrip maakt je veel flexibeler, dan enkel met zo veel mogelijk verschillende technologieën 'gewerkt' te hebben. Ik ben nooit onder de indruk van een nieuw taaltje hier, een nieuw frameworkje daar, wat clouddiensten en ga zo maar door.

[Hydra]

Hoe dan ook is de markt op dit moment zo in onbalans tussen vraag en aanbod dat je als bedrijf grote problemen gaat krijgen als je achter loopt kwa technologie. Ik zie dat bij mijn huidige klant ook; die krijgt het niet voor elkaar uberhaupt developers op interview te krijgen.

Natuurlijk moet je developers niet maar hun gang laten gaan en er een grote puinhoop van laten maken. Maar als bedrijf te veel weerstand bieden leidt er alleen maar toe dat juist de goeie mensen allemaal vertrekken. Technisch leiderschap wordt enorm onderschat in Nederland. Je ziet vaak dat 'architecten' die al 10+ jaar niet meer up to date zijn bepalen wat een developer wel en niet mag gebruiken.

[Hydra]

Mugwump schreef op maandag 3 oktober 2022 @ 11:15:
Ik ben nooit onder de indruk van een nieuw taaltje hier, een nieuw frameworkje daar, wat clouddiensten en ga zo maar door.

Ik ook niet perse. Maar het is wel aan mij om met die developers samen te gaan zitten om te kijken wat voor voor- en nadelen van dit soort technologiekeuzes zijn. Er zit maar een hele dunne lijn tussen je bedrijf willen behoeden voor risico's en zelf een bedrijfsrisico zijn als software architect.

[Verwijderd]

Verwijderd

[ Voor 96% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[Hydra]

Verwijderd schreef op maandag 3 oktober 2022 @ 12:01:
Het lijkt mij ook moeilijk voor veel organisaties om te weten wat een goede technische leider is?

Absoluut. Het is niet veel anders dan dat organisaties gewoon al moeite hebben om inn te schatten of iemand z'n tech skills goed zijn, of dat het een goede leider is. Die twee samen is helemaal problematisch

De spoeling is zo dun en de kenniskloof tussen niet-IT en wel-IT groot, dat de meeste een "slecht" referentiekader hebben om dit soort beslissingen te nemen.

Ik denk dat het belangrijk is wel te kijken naar mensen die die kloof kunnen dichten. Als je niet empatisch genoeg bent om moeilijke zaken simpel uit te kunnen leggen, mis je zowel technische als leiderschap skills in mijn ogen.

[Verwijderd]

Verwijderd

[ Voor 98% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[CVTTPD2DQ]

mannowlahn schreef op vrijdag 30 september 2022 @ 15:38:
Echter als je niet meegaat dan werk je op een gegeven moment met meuk wat niet meer gesupport wordt, veiligheid komt in gevaar, je wordt gegijzeld door een aar ouwe lullen en als je eenmaal besluit dat het toch anders moet ben je vaak te laat.

Dat "niet meer gesupport" valt meestal erg mee. Om maar wat voorbeelden te geven van omgevingen waar je geen developers zonder grijs haar voor vindt: Adobe Coldfusion: 2021. Perl 5: mei 2022. Delphi september 2022. Voor Fortran zijn verschillende implementaties die actief ontwikkeld worden, en een nieuwe versie van de standaard in 2023.

Dus word je gegijzeld door een paar ouwe lullen, of word je gedwongen door nieuwe medewerkers die niet aan "oude" software willen werken?

Die dat niet willen omdat "de markt" om skills in modieuze tools vraagt?

Waarbij "de markt" dat doet omdat bedrijven denken dat ze zo (jonge) developers kunnen aantrekken?

Het aannamebeleid van softwarebedrijven speelt een heel interessante rol in de vernieuwingscyclus van software.

[mannowlahn]

CVTTPD2DQ schreef op maandag 3 oktober 2022 @ 17:25:
[...]


Dat "niet meer gesupport" valt meestal erg mee. Om maar wat voorbeelden te geven van omgevingen waar je geen developers zonder grijs haar voor vindt: Adobe Coldfusion: 2021. Perl 5: mei 2022. Delphi september 2022. Voor Fortran zijn verschillende implementaties die actief ontwikkeld worden, en een nieuwe versie van de standaard in 2023.

Dus word je gegijzeld door een paar ouwe lullen, of word je gedwongen door nieuwe medewerkers die niet aan "oude" software willen werken?

Die dat niet willen omdat "de markt" om skills in modieuze tools vraagt?

Waarbij "de markt" dat doet omdat bedrijven denken dat ze zo (jonge) developers kunnen aantrekken?

Het aannamebeleid van softwarebedrijven speelt een heel interessante rol in de vernieuwingscyclus van software.

Wow cold fusion bestaat nog steeds en Delphi iOS developer, wat een wereld.

Geen idee of het ouwe lullen zijn die daar nog in werken maar laten we ff heel eerlijk zijn. Hoe groot acht jij de kans dat een jong en vitaal iemand de keuze maakt om nog met die talen te werken? Je wilt toch optimale carrière mogelijkheden hebben als je in de IT begint, dan kies niet voor cold fushion of delphi? Ik had gehoopt op foto’s bij die links maar ik heb wel echt een vermoeden hoe die demografie er uit ziet.

Gedwongen door nieuwe medewerkers? De markt zegt toch wel iets anders als we even de gemiddelde vacature paginas open slaan. Dat is niet alleen door hippe startups maar ook door grote enterprises.

Ieder zijn ding hoor en als iemand zich prettig voelt om decennia in een taal te blijven, moet je doen niemand die je dwing. Er is overigens niks mis met steeds een nieuwe taal of framework onder de knie te krijgen, dat wordt steeds makkelijker als je het trucje door hebt.

Overigens heb ik ook een lange periode door slechter keuze qua werkgevers een achterstand opgelopen. Stond zelfs op het punt om iets anders te gaan doen omdat ik het gevoel dat dat de achterstand al te groot was tov de qualify acties in de markt. Twee keer achter elkaar een werkgever die nog met winforms bezig was en allerlei belofte had voor .net core en dan wil je op een gegeven moment verder wil maar dan merk je dat je nooit wat met unit testen,ddd,bdd, service bus, devops, cloud etc gedaan heb. Ga je er maar aanstaan dan om ergens binnen te komen, een paar jaar geleden werd je gewoon (terecht) bijna uitgelachen als je op gesprek kwam. Nu? Als je niet minimaal een cicd pipeline kan aanleggen dan heb je wel echt liggen slapen vind ik.

[ Voor 14% gewijzigd door mannowlahn op 03-10-2022 21:57 ]

[CVTTPD2DQ]

mannowlahn schreef op maandag 3 oktober 2022 @ 21:43:
Geen idee of het ouwe lullen zijn die daar nog in werken maar laten we ff heel eerlijk zijn. Hoe groot acht jij de kans dat een jong en vitaal iemand de keuze maakt om nog met die talen te werken? Je wilt toch optimale carrière mogelijkheden hebben als je in de IT begint, dan kies niet voor cold fushion of delphi?

Precies mijn punt. Jonge "vitale" mensen kiezen voor nieuwe hippe programmeertalen omdat bedrijven ernaar vragen.

Waarom vragen bedrijven er naar als ze zeker ook behoefte hebben aan mensen die in staat zijn de bestaande software te onderhouden?

Één verklaring is dat de nieuwe platformen radicaal productiever zijn; dat strookt eigenlijk niet met mijn ervaringen

Een tweede verklaring is dat grote spelers keuzes forceren: als je wil ontwikkelen voor iOS ben je aangewezen op objective C/Swift (en blijkbaar Delphi). Android duwt je in de richting van Java/Kotlin, Windows heeft een enorme push naar .NET gehad, en webontwikkeling maakt javascript (of naar javascript transpilende talen) bijna noodzakelijk.

Een derde verklaring is dat de bedrijven hun vraag afstemmen op het aanbod.

En een vierde verklaring is dat bedrijven bij voorkeur "jonge vitale mensen" (lees: die 40u werken voor minder dan 3k) willen aannemen, en daar hun vraag op afstemmen.

Ik vind het een interessante discussie, omdat het recruitmentproces bijzonder invloedrijk is op de architecturele keuzes die binnen een organisatie gemaakt worden.

[Hydra]

Er zit kwa programmeertalen helemaal niet zo veel snelle verschuiving in de industrie. Er is een constante langzame beweging in ons werk (een evolutie en geen revolutie) waarin vooral verbeteringen in de tooling zitten. Het grootste deel van de bedrijven beweegt hier gewoon op mee. Sommige zijn early adopters en lopen voorop. Een aantal hobbelen er wat meer achteraan en zijn wat afwachtender.

Als developer wil je vaak liever bij de bedrijven zitten die (tenminste) in de middenmoot zitten. Anders is het op een gegeven moment 2022 en hoor je voor het eerst over Docker (zie ik bij mijn huidige klant). En dat zie je dan ook terug in dat deze bedrijven vaak moeite hebben mensen aan te trekken. Ook zie ik wel een sterke correlatie tussen salaris en hoe ver bedrijven achterlopen; bedrijven die goed betalen doen vaak meer hun best developers tevreden te houden.

Tenslotte heb je ook de bedrijven die eigenlijk volledig buiten de innovatiecycle vallen. Voorbeeld is een web dev bedrijf dat ik ken dat nog in Coldfusion werkt. Daar werken eigenlijk alleen maar hele jonge onervaren mensen onder leiderschap dat het internet al behoorlijk nieuwerwets vindt.

[Verwijderd]

Verwijderd

[ Voor 96% gewijzigd door Verwijderd op 27-10-2023 12:15 ]

[Verwijderd]

Verwijderd

[ Voor 96% gewijzigd door Verwijderd op 27-10-2023 12:14 ]

[Arloid]

Als consument zonder IT achtergrond (elektronica interesse doorgelaten) is veiligheid wel een drijfveer om nieuwere technologie en daarmee kennis meer vertrouwen te geven.

Een bedrijf zal wel mee moeten bewegen om op de nieuwste consumenten platforms te concureren. Zelfde geld ook voor bedrijven, als je niet meebeweegt heb je ook geen aansluiting op de nieuwste technieken. Dat zie ik onder anderen binnen de houtbewerking, daar komt steeds meer de nadruk op cnc techniek te liggen tot ook de 3 axis machines moeten wijken voor 4-6 axis machines.

[Mugwump]

Hydra schreef op dinsdag 4 oktober 2022 @ 09:29:
Er zit kwa programmeertalen helemaal niet zo veel snelle verschuiving in de industrie. Er is een constante langzame beweging in ons werk (een evolutie en geen revolutie) waarin vooral verbeteringen in de tooling zitten. Het grootste deel van de bedrijven beweegt hier gewoon op mee. Sommige zijn early adopters en lopen voorop. Een aantal hobbelen er wat meer achteraan en zijn wat afwachtender.

Als developer wil je vaak liever bij de bedrijven zitten die (tenminste) in de middenmoot zitten. Anders is het op een gegeven moment 2022 en hoor je voor het eerst over Docker (zie ik bij mijn huidige klant). En dat zie je dan ook terug in dat deze bedrijven vaak moeite hebben mensen aan te trekken. Ook zie ik wel een sterke correlatie tussen salaris en hoe ver bedrijven achterlopen; bedrijven die goed betalen doen vaak meer hun best developers tevreden te houden.

Tenslotte heb je ook de bedrijven die eigenlijk volledig buiten de innovatiecycle vallen. Voorbeeld is een web dev bedrijf dat ik ken dat nog in Coldfusion werkt. Daar werken eigenlijk alleen maar hele jonge onervaren mensen onder leiderschap dat het internet al behoorlijk nieuwerwets vindt.

Ik viel laatst wel even van m'n stoel toen ik van de klant te horen kreeg of we in ons team niet beter Kotlin dan Java konden gaan gebruiken, want ze merkten toch wel dat veel sollicitanten afknapten op Java en toch liever iets hips als Kotlin wilden (we doen geen Android App development).

Nou is Kotlin best mooi, maar 'even overstappen' op Kotlin is niet zo maar gedaan. En waar ik niet zo veel moeite zal hebben om de switch te maken heb ik toch ook developers in m'n team die een flinke leercurve zullen ervaren waardoor je development flink vertraagt (en het project staat al enorm onder druk).
Belangrijker nog is dat een dergelijke keuze in mijn ogen echt niet beïnvloed moet worden door 'We krijgen sollicitanten die liever hippe taaltjes willen doen'. Dat moet een weloverwogen keuze zijn waarbij je de voor- en nadelen afweegt. Uiteindelijk is marktaanbod qua developers wel degelijk een overweging bij technologiekeuze. Als jij een groot project uit de grond wil stampen en je maakt obscure technologiekeuzes waar je geen developers voor kunt vinden komt je project simpelweg niet van de grond. Ik snap ook dat developers niet zitten te wachten op technologie die op sterven na dood is. Maar ik vind Java toch bij lange na niet op sterven na dood. Daarbij is eigenlijk wat om het taaltje heen zit minstens net zo belangrijk en in theorie verschilt dat tussen Kotlin en Java niet zoveel, aangezien Kotlin gewoon een andere JVM taal is die net zo goed compileert naar Java byte code (of native binaries met Graal VM).

[Hydra]

Mugwump schreef op dinsdag 4 oktober 2022 @ 10:26:
Nou is Kotlin best mooi, maar 'even overstappen' op Kotlin is niet zo maar gedaan.

Nou dat is dus niet zo. Toevallig ben ik zelf een Kotlin 'advocate' en heb het bij verschillende bedrijven geintroduceerd. Het is niet te vergelijken met een overstap van (bijvoorbeeld) Java naar C# of zelfs Java naar Scala. Het is meer Java 2.0.

Ik zal hier verder niet te diep op in gaan maar ik kan je zeer aanraden om het serieus te overwegen omdat er ook bij wat 'langzamere' bedrijven (NS, ING) echt een shift is naar Kotlin op de back-end. Die deur hard gesloten houden, gaat je problemen opleveren over een poosje.

Mocht jullie technisch leiderschap hier mee strugglen en hier meer over willen weten, dan vertel ik daar graag eens over trouwens. De leercurve is er nauwelijks (mijn ervaring is dat een Java dev in een week productief is) en het heeft absoluut voordelen in productiviteit en motivatie.

[Verwijderd]

Verwijderd

[ Voor 99% gewijzigd door Verwijderd op 27-10-2023 12:14 ]

[Wild Chocolate]

Verwijderd schreef op dinsdag 4 oktober 2022 @ 10:55:
[...]


Kan ik nog wel steeds werkenmetjava.nl aanhouden straks?

Alvast werkenmetkotl.in registreren...

[Verwijderd]

Verwijderd

[ Voor 94% gewijzigd door Verwijderd op 27-10-2023 11:58 ]

[mannowlahn]

Verwijderd schreef op dinsdag 4 oktober 2022 @ 10:06:
[...]


Zojuist even gekeken en wanneer ik filter op Winforms dan wordt dit nog in 63 van de 350 vacatures genoemd. Dat is behoorlijk veel.

Dat is idd veel, hoewel winforms laatst nog wel een nieuwe update heeft gekregen. Ik praat over mijn periode van 2015 tm 2017z dat was een tijd waar de markt al veel meer stappen gemaakt had en ik met moeite ergens aan de bak kon wegen gebrek aan up to date .net kennis. Daar heb ik toen veel van geleerd en nu zorg ik veel actiever om up to date te blijven. Mede ook omdat ik freelancer ben. Twee jaar geleden kwam er nog wel een project lang voor drie maanden voor onderhoud aan .net 4.6 en heb toen vriendelijk geweigerd, ondanks een zeer hoog uur tarief.

Los van dat alles, ik kan ook echt niet meer met winforms aan de gang omdat ik dan heel vaak denk, de tering, dit kan allemaal zoveel sneller en makkelijker tegenwoordig. Die ouwe meuk begint dan echt op mijn humeur te werken. Als ik weet dat het beter kan en met name een fijnere developer ervaring heeft dan ga ik niet meer aankloten met oude meuk. Maar het is wel zo, als je dus niet je kennis op peil houdt, dan weet je niet beter. Dus er valt wat voor te zeggen om in en bepaalde versie te blijven hangen.

[Mugwump]

Hydra schreef op dinsdag 4 oktober 2022 @ 10:37:
[...]


Nou dat is dus niet zo. Toevallig ben ik zelf een Kotlin 'advocate' en heb het bij verschillende bedrijven geintroduceerd. Het is niet te vergelijken met een overstap van (bijvoorbeeld) Java naar C# of zelfs Java naar Scala. Het is meer Java 2.0.

Ik zal hier verder niet te diep op in gaan maar ik kan je zeer aanraden om het serieus te overwegen omdat er ook bij wat 'langzamere' bedrijven (NS, ING) echt een shift is naar Kotlin op de back-end. Die deur hard gesloten houden, gaat je problemen opleveren over een poosje.

Mocht jullie technisch leiderschap hier mee strugglen en hier meer over willen weten, dan vertel ik daar graag eens over trouwens. De leercurve is er nauwelijks (mijn ervaring is dat een Java dev in een week productief is) en het heeft absoluut voordelen in productiviteit en motivatie.

Nee ik weet dat vanwege het feit dat je in hetzelfde ecosysteem zit de overstap lang niet zo groot is als wanneer je overstapt naar C# (en dus het .Net ecosysteem). Scala is ook een stuk complexer en ontstaan vanuit een academische achtergrond, terwijl Jetbrains heel goed snapt hoe ze developers moeten ontlasten en dat zie je ook doorwerken in Kotlin.

Als ik zeg dat 'even overstappen' niet zo gedaan is dan bedoel ik ook niet sec dat de taal leren enorm lastig is, al weet ik wel dat er wat mensen in ons team moeite mee gaan hebben. Het gaat er vooral om dat er een hele forse codebase staat die al in Java geschreven is. Die omzetten naar Java is ook niet in een dag gedaan. Ja, dat kan b.v. IntelliJ grotendeels voor je doen, maar dan nog ben je wel even bezig met alles omzetten en zijn er ook altijd wel wat minder triviale zaken qua omzetting.

Ik zeg ook nergens dat ik de deur hard wil dicht gooien hoor. Ik zeg dat enkel 'hey ik krijg nu een paar developers die liever Kotlin doen, kunnen we dat even gaan doen?' een slechte reden is.

Aangezien dit het recruitment topic is probeer ik hier de wisselwerking tussen arbeidsmarkt en technologiekeuzes weer te geven. Ja de markt duwt technologiekeuzes uiteindelijk wel in een bepaalde richting, maar ik wil er ook voor waken om continuiteit gelijk maar weer overboord te gooien omdat je wat jonge gasten krijgt die techniek X niet meer hip vinden.

[RagingPenguin]

Verwijderd schreef op dinsdag 4 oktober 2022 @ 10:55:
[...]


Kan ik nog wel steeds werkenmetjava.nl aanhouden straks?

Maak werkenmetkotlin.nl en werkenmetscala.nl een alias

CVTTPD2DQ schreef op maandag 3 oktober 2022 @ 17:25:
[...]


Dat "niet meer gesupport" valt meestal erg mee. Om maar wat voorbeelden te geven van omgevingen waar je geen developers zonder grijs haar voor vindt: Adobe Coldfusion: 2021. Perl 5: mei 2022. Delphi september 2022. Voor Fortran zijn verschillende implementaties die actief ontwikkeld worden, en een nieuwe versie van de standaard in 2023.

Maar dan heb je het ook wel echt over talen die in de jaren '90 gesneuveld zijn onder de java apocalypse. Dat daar nu nog wel wat aan word gedaan is gewoon too little, too late. Ik denk ook niet dat er nog heel veel high-level software uit de jaren 90 is wat nog mee komt op moderne standaarden mbt UX, security, horizontale schaalbaarheid etc. En als een rewrite doet dan is ook direct een goed moment om iets nieuws te kiezen, al is het maar om het risico dat wat je nu gebruikt over 10 jaar EOL is te verkleinen (hangt natuurlijk sterk van de omstandigheden af).

En is nu ook echt niet zo dat alles en iedereen met super nieuwe technologie werkt. Het JVM ecosysteem stamt uit 1995, dotnet uit 2002 en Python uit 1991 om maar een paar grote namen te noemen die al decenia meegaan.

[ Voor 6% gewijzigd door RagingPenguin op 04-10-2022 11:08 ]

[Hydra]

Verwijderd schreef op dinsdag 4 oktober 2022 @ 10:55:
Kan ik nog wel steeds werkenmetjava.nl aanhouden straks? 200 Euro voor betaald

Ja hoor! Het is nog steeds het 'Java ecosysteem'

[Hydra]

Mugwump schreef op dinsdag 4 oktober 2022 @ 11:03:
Als ik zeg dat 'even overstappen' niet zo gedaan is dan bedoel ik ook niet sec dat de taal leren enorm lastig is, al weet ik wel dat er wat mensen in ons team moeite mee gaan hebben. Het gaat er vooral om dat er een hele forse codebase staat die al in Java geschreven is. Die omzetten naar Java is ook niet in een dag gedaan. Ja, dat kan b.v. IntelliJ grotendeels voor je doen, maar dan nog ben je wel even bezig met alles omzetten en zijn er ook altijd wel wat minder triviale zaken qua omzetting.

Ik zou bestaande projecten ook niet gaan omschrijven. Nergens voor nodig. Je kunt Kotlin wel binnen een Java project gebruiken, maar dan zou ik dat alsnog alleen doen in aparte modules/libraries. Anders krijg je een schizofrene codebase.

Ik zeg ook nergens dat ik de deur hard wil dicht gooien hoor. Ik zeg dat enkel 'hey ik krijg nu een paar developers die liever Kotlin doen, kunnen we dat even gaan doen?' een slechte reden is.

Aangezien dit het recruitment topic is probeer ik hier de wisselwerking tussen arbeidsmarkt en technologiekeuzes weer te geven.

Ja snap ik, alleen vind ik toevallig A) Kotlin hier geen goed voorbeeld (is niet te vergelijken van met Java naar bijv Go gaan, dat is enorm risicovol) en is het iets waar ik zelf veel mee te maken heb en graag over vertel. Ik vind dat een 'Java' bedrijf dit heel serieus moet nemen want je begint nu wel echt achter in de curve te belanden.