Investeren in een nieuwe programmeertaal.

[Uhmmie]

Het begin van mijn carrière heb ik voornamelijk gewerkt met PHP en in mijn vrije tijd heb ik ervaring opgedaan in Java en C#.

Uit eindelijk vond ik C#/Dotnet het fijnste werken en ben dan ook gewisseld van baan. Ondertussen is dat alweer bijna een jaar terug en op zich bevalt het me nog steeds goed. (Generics en delegates zijn een verademing).

Daarnaast ben ik weer begonnen om aan wat eigen projectjes te werken, waarbij ik gebruik ben gaan maken van language-ext (aan de hand van wat YouTube tutorials). Omdat ik soms nog wat moeite had om bepaalde logica te volgen (op papier snapte ik het “prima”, maar zodra ik het zelf toeging passen liep ik toch regelmatig vast). Ben ik opzoek gegaan naar wat meer uitleg over bepaalde onderdelen van language-ext (voornamelijk het optimaal gebruik van Option/Some/None en Result).

Vervolgens zag ik hoe Rust dit oploste met hun unieke enums en pattern matching en was eigenlijk direct verkocht. Ergens kriebelt het nu weer om een nieuwe taal te gaan leren, maar gelijkertijd zie ik maar een beperkte mogelijkheid qua nieuwe baan (zijn er echt veel minder) en daarnaast blijf je op die manier junior, omdat je steeds switched van taal (zeker gezien rust toch wel een stuk complexer voelt).

Ik ben benieuwd hoe andere hiermee omgaan?

[Furion2000]

Mijn aanpak is een beetje pareto, elke keer beginnen aan iets waar je 80% wel weet waar je aan begint en 20% nieuwe dingen leren. Daarmee tackle je imo dat probleem van altijd junior blijven.

Moet er wel bij zeggen dat de core (java/kotlin) basis blijft in die 80% tot nu toe en ik niet zo snel van die core af zal stappen in de nabije toekomst. Enige wat ik mogelijk als toevoeging zie is Python.

In de praktijk is dat dus niet ik ben .netter en ik switch van baan naar java, maar eerder ik ben javaan en in de volgende opdracht doen ze java + een deel python. Je beweegt dan wat natuurlijker naar je nieuwe interesses of gebieden die je steeds relevanter ziet worden en daarmee jezelf relevant houdt.

Merk daarnaast steeds meer dat de uitdaging niet de taal is, de hamer van de timmerman, maar het project waar ja aan werkt hetgeen is wat het leuk maakt. Dus voor de timmerman die bijv. altijd kasten heeft gemaakt, nu beweegt naar het maken van banken. Voor beiden gebruikt hij die hamer, maar toch wel met een hele andere gedachtegang.

[ Voor 19% gewijzigd door Furion2000 op 06-10-2022 12:09 ]

[Uhmmie]

@Furion2000 dat de opdracht belangrijker is dan de taal ben ik het ook helemaal mee eens. Daarom vind ik het ook juist leuk om met andere talen bezig te zijn. Helaas is de keerzijde dat als ik een leuke andere functie zie, er bijna altijd iets bij staat als minimaal 5 jaar ervaring in X.

Soms kom je daar dan nog wel voorbij in een gesprek, maar vaak heeft het dan wel invloed op het salaris.

[ Voor 15% gewijzigd door Uhmmie op 06-10-2022 12:54 ]

[Furion2000]

Uhmmie schreef op donderdag 6 oktober 2022 @ 12:54:
@Furion2000 dat de opdracht belangrijker is dan de taal ben ik het ook helemaal mee eens. Daarom vind ik het ook juist leuk om met andere talen bezig te zijn. Helaas is de keerzijde dat als ik een leuke andere functie zie, er bijna altijd iets bij staat als minimaal 5 jaar ervaring in X.

Soms kom je daar dan nog wel voorbij in een gesprek, maar vaak heeft het dan wel invloed op het salaris.

Dat is toch ook niet gek dat ze dat verwachten van een medior+ ontwikkelaar? Niet meenement dat sommigen echt goed zijn en zich veel sneller ontwikkelen, heeft menig toch wel 5 jaar nodig om naar een echte medior uit te groeien. Als de complexiteit van je werk meegroeit en je niet alleen maar simpele crud applicaties eruit moet kloppen dan ga je vanzelf merken dat je nog flink te groeien hebt en je nog wel prima zit in je gekozen core taal. Zowel in de frontend, de backend als op de db.

Het stukje 'daarom vind ik het ook juist leuk om met andere talen bezig te zijn' kan ik niet echt naar mijzelf relateren. Ik zie meer dan genoeg uitdaging in mijn full-stack omgeving op het werk en prive. Wat wil je maken wat je met je .net stack niet (goed) kunt doen? Moet ik er wel bij zeggen dat ik niet naar een andere taal zou gaan kijken als ik op zoek ben naar een nieuwe lib (language-ext)

Bij andere bedrijven solliciteren met 5+ jaar ervaring in je core business, in jou geval .net, zou toch geen probleem hoeven zijn? Dan zit je daarmee al op het 'normale' salaris in de range en kun je dat nog omhoog krikken door de rest van de stack ook te beheersen.

Is je valkuil niet dat je te snel rondom je heen gaat kijken qua talen/frameworks/carriere switches? Vooral youtube tutorials maken je soms helemaal gek wat betreft opties in je hoofd (click bait uitspraken zoals RUST IS WAY BETTER haha). Kijk maar naar projecten die tjokvol met libs zitten, altijd de beste lib toevoegen maakt het niet altijd beter. Jou tjokvol talen gooien maakt jou misschien niet beter

[perform93]

Het is ook vaak dat van een taal naar taal niet zo heel fundamenteel anders is. Paradigma van objectgeörienteerd programmeren is nagenoeg gelijk. Hetgeen waar het in verschilt is het hele ecosysteem wat is gebaseerd op een taal en je daarin wegwijs proberen te maken. Denk hierbij ook aan frameworks, library, tools wat toch weer net allemaal anders kan zijn dan dat je gewend bent.

[Lethalis]

Uhmmie schreef op donderdag 6 oktober 2022 @ 10:32:
Ik ben benieuwd hoe andere hiermee omgaan?

F# iets voor jou?

[Uhmmie]

Furion2000 schreef op donderdag 6 oktober 2022 @ 14:42:
[...]


Dat is toch ook niet gek dat ze dat verwachten van een medior+ ontwikkelaar? Niet meenement dat sommigen echt goed zijn en zich veel sneller ontwikkelen, heeft menig toch wel 5 jaar nodig om naar een echte medior uit te groeien. Als de complexiteit van je werk meegroeit en je niet alleen maar simpele crud applicaties eruit moet kloppen dan ga je vanzelf merken dat je nog flink te groeien hebt en je nog wel prima zit in je gekozen core taal. Zowel in de frontend, de backend als op de db.

Het stukje 'daarom vind ik het ook juist leuk om met andere talen bezig te zijn' kan ik niet echt naar mijzelf relateren. Ik zie meer dan genoeg uitdaging in mijn full-stack omgeving op het werk en prive. Wat wil je maken wat je met je .net stack niet (goed) kunt doen? Moet ik er wel bij zeggen dat ik niet naar een andere taal zou gaan kijken als ik op zoek ben naar een nieuwe lib (language-ext)

Bij andere bedrijven solliciteren met 5+ jaar ervaring in je core business, in jou geval .net, zou toch geen probleem hoeven zijn? Dan zit je daarmee al op het 'normale' salaris in de range en kun je dat nog omhoog krikken door de rest van de stack ook te beheersen.

Is je valkuil niet dat je te snel rondom je heen gaat kijken qua talen/frameworks/carriere switches? Vooral youtube tutorials maken je soms helemaal gek wat betreft opties in je hoofd (click bait uitspraken zoals RUST IS WAY BETTER haha). Kijk maar naar projecten die tjokvol met libs zitten, altijd de beste lib toevoegen maakt het niet altijd beter. Jou tjokvol talen gooien maakt jou misschien niet beter

Het is ook niet dat je bepaalde dingen niet in een taal zou kunnen. Het gaat erom dat sommige talen bepaalde features hebben die gewoon heel erg fijn zijn (en dat verschilt weer per developer, want niet iedereen heeft dezelfde voorkeuren).. Persoonlijk vond ik bijvoorbeeld generics en delegates echt een verademing toen ik van PHP naar C# overstapte.. Gelijkertijd ken ik ook genoeg mensen die daar helemaal geen meer waarde in zien.. Dus het is ook zeker een kwestie van smaak. Daarnaast leer ik ook regelmatig nieuwe dingen door naar andere talen te kijken.

Werk gerelateerd heb ik nu rond de 17 jaar met PHP gewerkt en 1 jaar met C# (prive tijd heb ik wel met veel talen lopen rommelen). Dus het is niet dat ik elke keer weer naar een andere taal ga, maar gelijkertijd voel ik me momenteel ook nog niet echt tot C# gebonden (alhoewel ook zeker geen behoefte heb om naar PHP terug te gaan).

De voordelen die ik nu in rust zie, komen echt niet door de clickbate titels van youtubers, maar puur door te lezen hoe bepaalde zaken in rust aangevlogen worden..

perform93 schreef op donderdag 6 oktober 2022 @ 16:01:
Het is ook vaak dat van een taal naar taal niet zo heel fundamenteel anders is. Paradigma van objectgeörienteerd programmeren is nagenoeg gelijk. Hetgeen waar het in verschilt is het hele ecosysteem wat is gebaseerd op een taal en je daarin wegwijs proberen te maken. Denk hierbij ook aan frameworks, library, tools wat toch weer net allemaal anders kan zijn dan dat je gewend bent.

Een andere taal leren is idd de tijd niet.. Weer helemaal thuis raken in het eco systeem/frameworks etc kost idd veel meer tijd.

Lethalis schreef op donderdag 6 oktober 2022 @ 19:05:
[...]

F# iets voor jou?

Ooit wel eens wat mee gedaan en ik vond het er toen (misschien wel alweer 10 jaar terug) best goed uitzien, helaas is de taal nooit echt van de grond gekomen (ik lees er eigenlijk ook nooit meer iets over). Dit is ook wel een beetje het nadeel van Rust, de hoeveelheid beschikbare banen is zeer beperkt en ik ben ivm mijn gezin best regio gebonden (en fulltime thuis werken is niks voor mij).

[Lethalis]

@Uhmmie Ik ben al bijna 20 jaar .NET developer en ik heb in mijn vrije tijd met een hoop dingen gespeeld, van Python, F#, Java, Scala, Kotlin tot en met Golang. Ik heb ook een achtergrond in C/C++.

Elke keer leerde ik wel iets wat ik ook in mijn werk als .NET developer kon gebruiken. Maar het gaat dan met name over de concepten en niet de letterlijke features van een taal.

Het ene sluit het andere niet uit.

Sowieso is werk vaak gebaseerd op een bestaande situatie. Java en C# zul je nou eenmaal veel vaker tegenkomen dan Rust, Golang, Erlang whatever.

Soms heb je geluk en kun je nieuwe dingen in een bestaande situatie gebruiken. Veel Java devs zullen inmiddels Kotlin gebruiken bijvoorbeeld. En C# staat niet stil. Al moet je ook niet proberen teveel een functioneel paradigma op een taal als C# te drukken, alleen maar omdat je dat mooier / leuker vindt.

[Lethalis]

Uhmmie schreef op donderdag 6 oktober 2022 @ 10:32:
Daarnaast blijf je op die manier junior, omdat je steeds switched van taal (zeker gezien rust toch wel een stuk complexer voelt).

Junior / medior / senior heeft met veel meer te maken dan alleen de kennis van een bepaalde taal of ecosysteem, dus ik begrijp deze opmerking niet zo goed

Meer leren over het analyseren van requirements, of bijvoorbeeld het bepalen van de kritieke succesfactoren van een project of functionaliteit, zodat je een project ook tot een goed einde voor iedereen kan brengen speelt daarbij misschien nog wel een grotere rol.

Het programmeren is maar 1 stap in het hele proces. En de taal eigenlijk niet meer dan een implementatie detail.

En tsja, communicatie. Bijvoorbeeld dat je uit jezelf contact zoekt met klanten of mensen die vaak bij de klanten zijn om te controleren of je op de goede weg bent. Dus stel ik moet X bouwen voor klant Y en ik weet dat Jantje dit besproken heeft met de klant, ook al kwam de opdracht van Pietje, dan ga ik toch naar Jantje om het hele verhaal te krijgen.

Want soms is dat toch nét ff anders

Maar goed, terug naar Rust... talen hebben elk hun eigen aandachtsgebied. Rust concurreert toch veel meer met C++? Hoe general purpose is het t.o v. Java en C#?

Het is nogal een verschil of je een driver voor een stuk hardware moet schrijven (waarbij je zelf controle wil over het memory management) of een web api (waarbij je vooral een goed framework wil dat jou zoveel mogelijk werk uit handen neemt).

Dus wát wil jij precies maken met Rust? Of beter gezegd: waar heb jij Rust voor nodig? Of de werkgever die jij zoekt die graag wil dat jij Rust kan?

PS
Een snelle scan van vacatures levert mij het beeld op van performance kritieke software die zo efficiënt mogelijk moet draaien. Dat lijkt mij een andere tak van sport dan bijvoorbeeld web development (in algemene zin).

[ Voor 5% gewijzigd door Lethalis op 06-10-2022 22:27 ]

[CVTTPD2DQ]

Uhmmie schreef op donderdag 6 oktober 2022 @ 10:32:
daarnaast blijf je op die manier junior,

Onzin, zoals andere mensen al opmerken.

Uhmmie schreef op donderdag 6 oktober 2022 @ 10:32:
Ik ben benieuwd hoe andere hiermee omgaan?

Reken eens voor de grap uit hoeveel jaar je nog moet werken tot je pensioen. Stel dat je bijvoorbeeld vijftig bent (ik vermoed dat je nog lang geen vijftig bent) dan moet je nog zo'n 20 jaar.

Hoe zag de banenmarkt er twintig jaar geleden uit?

Java was de nieuwe hype in onderwijs, maar voor applicatieontwikkeling wist eigenlijk niemand wat ze er mee moesten. C# bestond nog niet, Microsoft probeerde iets te pushen dat Visual J++ heette. Veel werk was te vinden in Visual Basic, Delphi, of C++ (met allerlei verschillende compilers). JavaScript was vooral leuk als je de muiscursor op je homepage in een stuiterbal wilde veranderen. En dan negeren we zijstraten als Frontpage en Macromedia Flash.

In de tussentijd zijn talen als PHP, Ruby en Scala razend populair geworden, en eigenlijk alweer over hun hoogtepunt heen geraakt.

Ik heb geen idee hoe de banenmarkt er over twintig jaar uit gaat zien, maar de kans dat je nooit in je carrière zult moeten switchen acht ik uiterst klein. En ja, dan helpt het als je regelmatig aan iets anders ruikt.

[Lethalis]

CVTTPD2DQ schreef op donderdag 6 oktober 2022 @ 22:48:
[...]
Hoe zag de banenmarkt er twintig jaar geleden uit?

C# bestond nog niet, Microsoft probeerde iets te pushen dat Visual J++ heette.

C# is al 22 jaar oud (eerste release in het jaar 2000). In 2003 (okee, 19 jaar geleden) had ik mijn eerste fulltime C# baan. Op dat moment was het al behoorlijk populair.

Maar voor de rest heb je gelijk. Tijden veranderen

Van 1998 tot en met 2003 gebruikte ik vooral Borland C++ Builder. Daarvoor nog Visual Basic en producten als Microsoft Access. En ik begon ooit met Power BASIC op een 286

Eigenlijk ben ik best oud. Bijna 42 alweer

@Uhmmie
Ik heb de laatste jaren bijvoorbeeld geïnvesteerd in Angular en ook in .NET Core wat nu .NET 6 is. Je moet toch bijblijven. Maar mijn insteek is anders dan de jouwe. Ik kijk naar wat er gevraagd wordt en dat leer ik

[ Voor 14% gewijzigd door Lethalis op 06-10-2022 23:46 ]

[boxlessness]

Uhmmie schreef op donderdag 6 oktober 2022 @ 10:32:
Het begin van mijn carrière heb ik voornamelijk gewerkt met PHP en in mijn vrije tijd heb ik ervaring opgedaan in Java en C#.

Uit eindelijk vond ik C#/Dotnet het fijnste werken en ben dan ook gewisseld van baan. Ondertussen is dat alweer bijna een jaar terug en op zich bevalt het me nog steeds goed. (Generics en delegates zijn een verademing).

Daarnaast ben ik weer begonnen om aan wat eigen projectjes te werken, waarbij ik gebruik ben gaan maken van language-ext (aan de hand van wat YouTube tutorials). Omdat ik soms nog wat moeite had om bepaalde logica te volgen (op papier snapte ik het “prima”, maar zodra ik het zelf toeging passen liep ik toch regelmatig vast). Ben ik opzoek gegaan naar wat meer uitleg over bepaalde onderdelen van language-ext (voornamelijk het optimaal gebruik van Option/Some/None en Result).

Vervolgens zag ik hoe Rust dit oploste met hun unieke enums en pattern matching en was eigenlijk direct verkocht. Ergens kriebelt het nu weer om een nieuwe taal te gaan leren, maar gelijkertijd zie ik maar een beperkte mogelijkheid qua nieuwe baan (zijn er echt veel minder) en daarnaast blijf je op die manier junior, omdat je steeds switched van taal (zeker gezien rust toch wel een stuk complexer voelt).

Ik ben benieuwd hoe andere hiermee omgaan?

Ik heb nu 15+ jaar in allerlei research/prototype projecten gewerkt, en in een lange periode daarvan had ik ieder half jaar 1 of meerdere andere programmeertaal/technologie op een project. Je kwam niet op een project als C#/C++/Java/whatever-typmiep, maar om het project naar een hoger plan te tillen en problemen op te lossen. De focus lag veel meer op software best-practices, zowel op het vlak van het maken van de software als ook de project/process aspecten. Zeker in het begin was er veel laaghangend fruit op dat vlak... dingen als clean-code, SOLID, DI, MVVM waren destijds relatief nieuw en hip. Agile en Scrum waren nog "eng" voor projectleiders. Kanban had nog geen ziel van gehoord...

Ik ben nu sinds een anderhalf jaar met full-stack web development bezig met C#/dotnet core, Angular en typescript en python. Wat mij meteen op valt wanneer ik wat nieuws van de plank trek is de overlap met andere concepten die ik gebruikt heb. Zo zie ik Angular components als views in WPF en zet ik het in middels een MVVM patroon... althans... mostly. Ik kies er ook voor om niet de Angular commandline tooling te gebruiken om "components" aan te maken, omdat deze niet overeenkomt met mijn mentale model van namespaces. Ik maak ook een veel diepere directorystructuur dan andere frontend developers in onze organisatie... geen idee of dat goed of slecht is. Ik vermijd @injectable omdat ik het een anti-pattern vind om overal Angular-specifieke code doorheen te sprinkelen, en in plaats daar van initialiseer ik de DI-container bij het starten van de app.

Mijn punt is dat wanneer je de high-level concepten kent, en maar vaak genoeg tegen de muur bent gelopen in andere projecten, je leert wat werkt en wat je tegen gaat werken. Dan kun je ook met een educated guess afwijken van wat de tutorials je aanbieden.

En wanneer je wat nieuws tegen komt moet je ook een deep-dive doen naar de concepten en best-practices achter de tech/tool die je gebruikt.
Wat ook helpt is dat ik al veel technologieen die ik gebruik, ook van binnen ken. Zo heb ik in een stageopdracht een TCP+HTTP-stack geschreven voor een embedded platform. Of zelf smart-pointers gemaakt voordat Boost bestond... en dat was nog voordat het in C++ zelf opgenomen werd. Deze kennis helpt dan weer als ik een "memory-leak" in C# tegen zou komen.
Dat is het voordeel van een "dinosaurus" zijn, maar ook het verschil tussen technologie gebruiken, en de technologie begrijpen.

En niet bang zijn om fouten te maken. Ik heb best wel wat keren echt fundamentele fouten gemaakt omdat ik de technologie niet goed genoeg kende. E.g. Entity Framework (EF) objecten gebruiken als business objecten door de hele applicatie heen... because we can... want "partial classes"... niet realiserend dat hun lifetime/threading/updating geregeld wordt door EF.
Wanneer ik weer eens gegenereerde POCO's tegen kom dat ben ik op mijn hoede.

Anyways, dat was een beetje off-topic, maar senioriteit/junioriteit is geen kwestie van hoe snel je if's en else's kunt typen in een bepaalde programmeertaal. Het gaat er om hoe goed je in staat bent om problemen op te lossen en dingen werkend kunt krijigen.

Moderne "software engineering" jobs/processen nemen (als je niet uit kijkt) een deel van dat groeitraject weg: dat wil zeggen, wanneer je alleen maar userstories mag kloppen en alleen maar op je eigen postzegel mag werken, dan ga je niet de overkoepelende concepten herkennen en weten hoe fundamentele keuzes gemaakt worden door de designer/architect. We leren door fouten te maken, en wanneer we in een silo werken dan dan maken we die fouten niet... Sommige van die fouten kunnen best dure fouten zijn, maar ze zijn nodig om te groeien.
Een interessante blogpost hier gaat over de neveneffecten van Agile/Scrum en hoe dat iemand vast kan zetten in junioriteit. Ik ben een voorstanden van Agile om risico's en voortschrijdend inzicht te managen, en een gedeelde verantwoordelijkheid te creeeren (voornamelijk om de projectleider mee te laten delen, ipv alles maar af te dwingen middels "commitment"). Maar met mijn lekenkennis van psychologie en groepsdynamica zie ik steeds meer negatieve effecten op o.a. groei en kwaliteit. En Scaled Agile is al helemaal the root of all evil.

[Hydra]

boxlessness schreef op vrijdag 7 oktober 2022 @ 09:39:
Een interessante blogpost hier gaat over de neveneffecten van Agile/Scrum en hoe dat iemand vast kan zetten in junioriteit.

FYI: Michael O Church is grote debiel die het niet voor elkaar krijgt waar dan ook een baan te houden. Het is iemand die genoeg bekendheid heeft, in de negatieve zin, om heel vindbaar te zijn in een Google search.

Je moet natuurlijk zelf weten wat je met z'n blogposts doet en ik zeg niet dat je ze niet mag lezen. Maar je moet je wel realiseren dat linken naar zijn rants je niet bepaald geloofwaardig maken. De blog post is complete onzin. Hij gebruikt alleen zoveel tekst dat mensen maar aannemen dat 'ie weet waar hij over praat.

Nogmaals; dit is iemand die het niet voor elkaar krijgt meer dan een paar maanden bij het gemiddelde bedrijf te blijven werken. Hij heeft nooit een succesfol agile project gezien omdat hij er continue uitgekickt wordt.

Als je graag mensen wil 'volgen' die agile wel snappen, volg dan Alan Holub bijvoorbeeld op twitter. Die is ook kritisch op scrum, maar weet wel waar 'ie het over heeft.

En Scaled Agile is al helemaal the root of all evil.

SAFe heeft ook niks met agile te maken. Het is een hoop marketing BS. Dus daar ben ik het helemaal mee eens.

[ Voor 6% gewijzigd door Hydra op 07-10-2022 10:25 ]

[boxlessness]

Hydra schreef op vrijdag 7 oktober 2022 @ 10:24:
[...]


FYI: Michael O Church is grote debiel die het niet voor elkaar krijgt waar dan ook een baan te houden. Het is iemand die genoeg bekendheid heeft, in de negatieve zin, om heel vindbaar te zijn in een Google search.

Je moet natuurlijk zelf weten wat je met z'n blogposts doet en ik zeg niet dat je ze niet mag lezen. Maar je moet je wel realiseren dat linken naar zijn rants je niet bepaald geloofwaardig maken. De blog post is complete onzin. Hij gebruikt alleen zoveel tekst dat mensen maar aannemen dat 'ie weet waar hij over praat.

Nogmaals; dit is iemand die het niet voor elkaar krijgt meer dan een paar maanden bij het gemiddelde bedrijf te blijven werken. Hij heeft nooit een succesfol agile project gezien omdat hij er continue uitgekickt wordt.

Als je graag mensen wil 'volgen' die agile wel snappen, volg dan Alan Holub bijvoorbeeld op twitter. Die is ook kritisch op scrum, maar weet wel waar 'ie het over heeft.

Ik volg Michael ook niet, kwam het gewoon eens tegen. Zal Alan Holub eens opduikelen en kijken wat hij schrijft.

[Dido]

Hydra schreef op vrijdag 7 oktober 2022 @ 10:24:
FYI: Michael O Church is grote debiel die het niet voor elkaar krijgt waar dan ook een baan te houden. Het is iemand die genoeg bekendheid heeft, in de negatieve zin, om heel vindbaar te zijn in een Google search.

De gelinkte blogpost vult wel heel snel mijn "jij hebt niets van Scrum begrepen"-bingokaart Alsof ik de gemiddelde "manager" hoor over scrum

Hydra schreef op vrijdag 7 oktober 2022 @ 10:41:
Hij is echt een bekendheid op Reddit en HackersNews enzo. Op Wikipedia, Quora en HN is 'ie gebanned, 'T is nogal een karakter

De naam zei me niets, maar hij heeft zo te zien een heleboel bruikbaar materiaal geschreven voor mensen die willen leren wat scrum niet is. Aan de andere kant, dergelijk materiaal kan de gemiddelde manager je ook af lib wel verstrekken

[ Voor 33% gewijzigd door Dido op 07-10-2022 10:51 ]

[Hydra]

Dido schreef op vrijdag 7 oktober 2022 @ 10:38:
De gelinkte blogpost vult wel heel snel mijn "jij hebt niets van Scrum begrepen"-bingokaart Alsof ik de gemiddelde "manager" hoor over scrum

Hij is echt een bekendheid op Reddit en HackersNews enzo. Op Wikipedia, Quora en HN is 'ie gebanned, 'T is nogal een karakter

Je vindt op Quora bijvoorbeeld posts over 'em waar de recente duidelijk aangeven wat voor'n type het is. Er zijn ook oudere posts rond 2015 die allemaal beschrijven hoe slim 'ie wel niet is en hoe iedere keer keer het de schuld van de werkgever was. Die zijn allemaal door Michael zelf geschreven.

[Lethalis]

boxlessness schreef op vrijdag 7 oktober 2022 @ 09:39:
[...]
Ik kies er ook voor om niet de Angular commandline tooling te gebruiken om "components" aan te maken, omdat deze niet overeenkomt met mijn mentale model van namespaces. Ik maak ook een veel diepere directorystructuur dan andere frontend developers in onze organisatie... geen idee of dat goed of slecht is.

De grap is dat ik het omgekeerde doe... ik gebruik in mijn Angular schematics de flat optie, zodat mijn directory structuur juist eenvoudiger is.

Ook zet ik het genereren van scss bestanden per component uit, zodat ik wat minder bestanden per component heb.

Alles om het wat simpeler / overzichtelijker te maken.

Verder is de CLI juist handig. Geen zin om componenten met de hand aan te maken en te registreren in de app module etc. Met schematics kun je zo ongeveer alles customizen, dus waarom zou je de cli niet gebruiken?

Bij Blazor WebAssembly doe ik wel het omgekeerde... ik vind 1 Razor bestand met alles er in niet netjes en maak al gauw een dedicated component class aan los van de razor opmaak. Daar knapt de IDE ook van op qua intellisense. Bij Razor is Visual Studio soms een beetje hit and miss.

Ook snap ik niet waarom de Blazor componenten default in een Pages directory staan. Eerste wat ik doe, is er een Components directory van maken

[ Voor 5% gewijzigd door Lethalis op 07-10-2022 23:43 ]

[Lethalis]

boxlessness schreef op vrijdag 7 oktober 2022 @ 09:39:
[...]
En niet bang zijn om fouten te maken. Ik heb best wel wat keren echt fundamentele fouten gemaakt omdat ik de technologie niet goed genoeg kende. E.g. Entity Framework (EF) objecten gebruiken als business objecten door de hele applicatie heen... because we can... want "partial classes"... niet realiserend dat hun lifetime/threading/updating geregeld wordt door EF.
Wanneer ik weer eens gegenereerde POCO's tegen kom dat ben ik op mijn hoede.

Dat riekt naar een anemic domain model (1 op 1 mapping tussen business domain en het data model met weinig extra functionaliteit).

Niet dat ik er een held in ben, maar Martin Fowler ziet het als een serieus anti-pattern:

Wikipedia: Anemic domain model

Het kan wel makkelijk zijn uiteraard. Maar Automapper ertussen naar wat business classes zorgt iig voor een scheiding en voorkomt dat je proxies misbruikt voor zaken waar ze niet voor bedoeld zijn.

Al neig ik al gauw naar losse request en response classes die sowieso los staan van het datamodel. Dat voelt logischer voor mij en die kan ik functionaliteit geven die erbij hoort (OrderRequest.Validate() bijvoorbeeld, en die OrderRequest class wordt dan later gemapt naar een OrderModel voor de datalaag als ik hem wil toevoegen etc).

[Immutable]

Rust is een prachtige taal om te leren. En zal zeker populairder worden. Als je al kan programmeren heeft het een andere leercurve als andere talen. Het is een dijk waar je even doorheen moet betreft het geheugen model. Eenmaal dat onder de knie kun je er behoorlijk productief mee zijn. Rust is een taal die potentieel met zijn macro's zijn zo krachtig dat als je bepaalde web frameworks gebruikt in Rust het net voelt alsof je simpel in python aan het programmeren bent. Je moet goed kijken wat je ermee wilt en wat de sterke punten er van zijn. Ik zelf denk dat Rust een taal is dat 1 van de meest breed toepasbare taal is die er is. Je kunt het inzetten van ARM microcontrollers, tot aan supercomputers, multi-platform, en tevens is het heel dicht verbonden aan web-assembly. Je kan het ook gebruiken voor je back-end, front-end enzovoort. Dus dat is best een kracht, tevens is het qua gebruik en de compiler die zeer modern is. En veel best practises worden toegepast in de taal. Geen null, muttable standaard uit enzovoort.

Rust heeft een grote concurrentie bereik. Het kan concurreren tegen alle binary & byte code talen en ook soms zelfs hier en daar tegen script talen. Een GC heeft soms voordelen bij bepaalde algoritmes maar meestal niet dus waar het wel zo is kun je in Rust weer arena's gebruiken om de voordelen die een GC biedt te gebruiken om zo best of both worlds te krijgen qua performance. Daarnaast is over het algemeen de software kwaliteit van Rust projecten ook aardig hoog omdat je veel meer beschermt wordt tegen "easy but bad roads". In C++ kies je al gauw voor iets makkelijks en dat werkt. Maar de weg met de minste weerstand is vaak niet de beste en dat is ook met C. Het is vaak hit and miss. Veel tutorials met de slechte wegen.

Qua werk dus: Rust kan breed inzetbaar zijn. Heeft sowieso de toekomst. Maar nu een baan vinden is best lastig. En waar veel mensen over klagen in de Rust community is dat veel banen met Cryptocurrencies te maken hebben. Maar zoals mensen zeggen, je moet een taal kiezen op basis van je requirements. En Rust heeft een paar sterke punten waarom Rust gekozen wordt voor nieuwe projecten. Oude legacy systemen worden vaak meer onderhouden en uitgebreid en dus gaan bedrijven ook niet zomaar over op een andere taal.