Hoe gaan jullie om met veranderingen in de IT?

[HollowGamer]

De IT staat nooit stil, wat je vorig jaar hebt geleerd, kan je over een jaar alweer vergeten.
Tuurlijk is het niet zo zwart/wit, maar als ik kijk hoeveel er per dag bijkomt op GitHub is het erg moeilijk om te volgen wat je nu wel of niet moeten oppikken om te leren en wat useful is/kan zijn in je huidige sector.

Neem als voorbeeld deze link: https://hackernoon.com/5-...orks-in-2017-7a63b3870282
Nog soms binnen een jaar tijd is er alweer iets beters, sneller, en eenvoudiger beschikbaar.
De sterren nemen toe op GitHub, iedereen gebruikt het opeens en als webdeveloper dien je dit z.s.m. toe te voegen aan je skillset. Een 'oude' techniek is niet meer interessant, het is Vue wat je nu moet weten! *om maar een voorbeeld te geven

Opzicht niet erg; ik vind het allemaal erg interessant en als iets beter kan sta ik daar altijd voor open.
Het probleem is vaak dat ik door de bomen het bos niet meer zie, veel tijd bezig ben met research (zie voorbeeld link JS-frameworks), en vaak het gevoel heb dat het 'niet perfect' of goed is (er zijn immers zoveel oplossingen, ideeën en betere technieken die ik niet ken/kan toepassen).

Dat perfect willen doen is ook vaak een doorn in het oog van mijn collega's. Vaak vraag ik om de kleinste details 'de waarom vraag' en kan ik mijzelf verliezen door in de avonduren, weekend, en vakantie, door te werken aan/verbeteren van mijn skills (*in hoeverre mogelijk) en daar helemaal in op te gaan. Afschakelen vind ik moeilijk, want het liefste zou ik geen avond willen missen.
Het is niet dat ik daardoor niet programmeer of werk oplever, in tegendeel zelfs, maar ik gewoon het vervelend vind om iets niet te weten of bang ben dat ik zo weinig weet dat ik niet meer interessant ben voor het bedrijf/de markt.

Hoe gaan jullie hier mee om? Herkennen jullie in mijn verhaal?
Wat zou de sleutel zijn om de rust/overzicht te bewaren?

Alvast bedankt.

[sebasd]

Wat voor mij in mijn vakgebied (testautomatisering) heel goed heeft gewerkt is om juist niet meer alles te willen weten over de nieuwste tools en libraries. Je houdt het toch niet bij. Het is voor mij (en ook voor mijn klanten) veel waardevoller gebleken om ze te kunnen adviseren over wat ze wel en niet moeten doen (het waarom? en het wat?) dan met welke tool ze dat het beste kunnen doen (het hoe?).

Ik vertel er juist vaak meteen bij dat ik niet alles weet. Is ook helemaal niet erg. Google en StackOverflow helpen je wel bij het 'hoe?'. Juist in het kunnen beantwoorden van en adviseren over het waarom? en het wat? ligt voor mij de toegevoegde waarde, en ik zie om mij heen een heleboel ervaren mensen die er zo over denken.

Laat het los, zoals je zegt, morgen is er weer een nieuwe tool. Principes en good practices blijven.

[MagicTempest]

Ik denk dat je voor jezelf moet bepalen waar je heen wil. Zodra je dat duidelijk in beeld hebt kun je bij alle (nieuwe) dingen je af vragen of het bijdraagt aan je eigen doelen. Zo ja, dan er in verdiepen, zo nee, links laten liggen

[unezra]

Ik werk als systeembeheerder / allround ICTer (goh, waar zou dat onderschrift bij mijn foto toch vandaan komen).

De ICT is zo absurd breed dat je nooit alles kunt bijhouden, dus beperk ik me tot hetgeen ik op dat moment in mijn werk nodig heb of waar ik privé interesse in heb. Als ik een project moet doen dat draait om firewalls, verdiep ik me in firewalls. Daarna neem ik die dingen in gebruik en is het voor een paar jaar minder relevant bij te blijven op firewall gebied. (Want die dingen vervang je niet ieder jaar.)

Wat @sebasd ook zegt, je weet niet alles. Ik maak daar zelf ook nooit een geheim van. Als allound ICTer weet ik van heel veel dingen wel iets af maar zodra het ontzettend diep de materie in gaat zoek ik de kennis ook op en huur desnoods de kennis in.

Een van de dingen die ik jaarlijks doe omdat ik ook verantwoordelijk ben voor een stuk inkoop en advisering op ICT gebied is mijn vaste leveranciers uitnodigen en ze vragen "wat zouden jullie doen als jullie mijn baan hebben". Dat is _het_ moment voor een salespitch, dan mogen ze me alle nieuwe technieken en dingen vertellen die ik de komende jaren echt _moet_ gaan gebruiken. Ook dat is bijblijven. Maar ik beperk dat in de regel wel tot wanneer ik met een project van start ga en de "eindejaarsronde" (die ergens in augustus is).

[pirke]

In de C++ en C# wereld gaat het gelukkig niet zo snel, zeker niet in de high tech machinewereld. Ik heb geen zicht op de web technologieën, dat is voor mij niet relevant. Het enige wat wel verandert is wat syntax hier en daar, wellicht andere unit test frameworks en de build omgeving of versie beheer. Allemaal niet zo spannend, uiteindelijk doet het allemaal hetzelfde. En vaak is een ander framework of andere tool niet eens beter, maar gewoon anders. Kwestie van smaak, en elk voordeel heb z'n nadeel zullen we maar zeggen. Oftewel ik lig er niet wakker van

Op architectuur niveau is er van nature weinig beweging, en bij projectmanagement is alles agile... ook al is het vaak toch een verkapte vorm van waterval waar een agile sticker op geplakt wordt

Dan heb je nog de cloud en virtualisatie, tja, ook geen nieuwe concepten. Een remote server(park) was er vroeger ook al, net als virtuele machines.

Heel veel andere IT gebieden kom ik niet tegen. In de afgelopen 10 jaar heb ik eigenlijk geen noemenswaardige veranderingen gezien.

[Verwijderd]

Als ik kijk naar mijn laatste 15 jaar als IT'er kan ik het volgende wel stellen..
- Op architectuur niveau zijn de veranderingen laatste 5-6 jaar niet zo heel groot meer, het zit hem juist in de kleinere dingen, zoals betere aansluiting op andere systemen, automatiion, versimpeling van beheer.
- De huidige systemen op de markt zoals programmeertalen, cloud etc zijn niets anders dan tools om je werk te kunnen doen..

Waar het om gaat is dat jij en elke andere IT'er de kennis en de kunde hebt om een dienst te beheersen.

Ik vergelijk het altijd maar even met een timmerman, ik als IT'er weet hoe ik een spijker in een stuk hout moet slaan.. Dus ik heb de kennis om een hamer te gebruiken..
Maar om er iets moois van te maken heb je visie, kunde en ervaring nodig..
Dit is niet iets wat je met een cursus kunt leren, een cursus leert je alleen een hamer vasthouden en een spijker erin rammen. Jou persoonlijkheid, de toepasbaarheid van jou kennis en de ervaring die je opdoet in de loop van de tijd maakt jou een goede werknemer!!

Voor mij persoonlijk richt ik me gewoon op mijn eigen systemen en tools, 1-2x per jaar naar een seminar om nieuwe ontwikkelingen te zien waarmee ik op me werk verder ga en ik ben weer helemaal bij.

Tools worden elke paar jaar vervangen, het toepassen van opgedane kennis en ervaring daar draait het om, dat moet je op pijl houden en dan red je het wel.

[Sissors]

Je moet niet altijd het nieuwste van het nieuwste willen gebruiken, maar liever hetgeen wat voor jou / jouw afdeling / jouw bedrijf het effectiefste is. En tuurlijk, je wil op de hoogte blijven van de ontwikkelingen, maar je hoeft niet alles tot in detail te kennen.

Het is leuk hoor dat er een nieuw framework is wat iets wat effectiever kan doen. Maar als het jou 2x zoveel tijd kost vanwege alle tijd die je nodig hebt het uit te zoeken, je erin te verdiepen, etc, dan had je simpelweg beter je oude framework kunnen gebruiken. Misschien in een ideale wereld wat minder effectief, maar voor jou wel veel handiger.

"Ik heb er ervaring mee", is een enorm pluspunt voor een tool/framework/taal/whatever.

[Mugwump]

Verwijderd schreef op dinsdag 30 mei 2017 @ 08:22:
Als ik kijk naar mijn laatste 15 jaar als IT'er kan ik het volgende wel stellen..
- Op architectuur niveau zijn de veranderingen laatste 5-6 jaar niet zo heel groot meer, het zit hem juist in de kleinere dingen, zoals betere aansluiting op andere systemen, automatiion, versimpeling van beheer.
- De huidige systemen op de markt zoals programmeertalen, cloud etc zijn niets anders dan tools om je werk te kunnen doen..

Ik zou zelfs nog wel veel verder willen gaan. Het gros van de 'revoluties' in de IT van de afgelopen 20 jaar is niet veel meer dan oude wijn in nieuwe zakken.
Het is in mijn ogen dan ook erg belangrijk om de fundamenten goed te snappen, dan kun je je specifieke implementaties wel snel eigen maken. Dat vereist wel een bepaald abstractieniveau.
Als je kijkt naar programmeerwerk, dan is het vooral zaak om de basis van object georiënteerd en functioneel programmeren goed te snappen, te weten hoe design patterns werken en wanneer je ze moet toepassen, enzovoort.
Ik doe zelf niet heel veel web front-end werk meer, maar elke keer als ik weer eens wat moet doen met de JS framework hype van het moment, dan gaat dat vrij eenvoudig.

Frameworks zijn toch vooral bedoeld als productiviteitshulpmiddelen. Er is geen reden om elke keer weer het wiel opnieuw te gaan uitvinden dus de basis wordt gestandaardiseerd zodat de ontwikkelaar zich kan richten op de specifieke klant- / projectimplementatie. Het is zeker nuttig om wat ervaring op te doen met een breed scala aan tools, maar het is in mijn ogen verspilde moeite om bij elk van dergelijke frameworks alle details te willen weten.

Ik schat de verwachte levensduur van veel van die frameworks ook niet bijzonder hoog in.

De manier waarop ik zelf een beetje bijblijf is vooral conferenties en trainingen op een wat abstracter niveau, veel lezen en wanneer je bij een project kans ziet om een specifieke interessante technologie toe te passen deze kans aangrijpen. Dat laatste kan wel lastig zijn als je bij een bedrijf zit dat aan de lopende band webapplicaties of apps uitspuugt op basis van een gestandaardiseerde straat, dus dan kun je er wellicht beter in je vrije tijd of in de loze uurtjes wat mee experimenteren.

[Strykeforce]

De opkomst van de javascript frameworks heeft veel te maken met het feit dat javascript wat meer volwassen is geworden en dat de clients/telefoons/computers ook simpelweg veel meer rekenkracht over de jaren heen hebben gekregen waardoor je een hoop client-side kan doen tegenwoordig. Zodoende zijn er een hoop frameworks als paddestoelen uit de grond geschoten zonder dat er over alles goed is nagedacht (wat moet het eigenlijk allemaal kunnen?), het is hard gegaan maar ik heb zo het idee dat afgelopen jaar rustig is verlopen eigenlijk.

Ik probeer het ook bij te houden en wanneer er weer iets nieuws voorbij komt kijk ik er even naar, maar uiteindelijk is de keuze voor welk framework/techniek afhankelijk naar wat logisch is voor het project waar je mee bezig bent en wat binnen de cultuur van het team valt. Uiteindelijk is het ook maar net wat je zelf leuk vind en van waarde lijkt te zijn.

Ik denk ook dat naast alle frameworks de laatste tijd een hoop nieuwe dingen komen die het leven van een developer vermakkelijken. Ik kan me nog heel goed herinneren hoe klote het was om deployments van software in de avonden met pizza te moeten doen, ook al was die pizza wel lekker doe ik toch liever andere dingen in de avond. Nu kan je met een hoop handige zaken makkelijk je deployment automatiseren. Ook nu ik dik een jaar met Typescript bezig ben geweest wil ik nooit meer een regel javascript code schrijven bijvoorbeeld.