Steeds meer collega's vertrekken, wat mag er verlangt worden

[GrooV]

MarcoC schreef op vrijdag 1 oktober 2021 @ 12:49:
[...]
Mijns inziens zit je er volledig naast. Het enige wat telt is de waarde die gecreëerd wordt voor de klant, en daar zijn platforms, compute en onderhoud net zo essentieel voor als development werk. Hoe kan je nou zeggen dat je je hierdoor niet moet laten "afleiden"? Wat is de waarde van jouw product als de database platligt? Wat heb je eraan als de klant boos opbelt omdat de integratietests niet hebben afgevangen dat een essentiële feature niet meer werkt? Of als elke ochtend om 9u de app traag is omdat er een blijkbaar een cronjob draait? Neem ownership. Neem verantwoordelijkheid. Dat wil niet zeggen dat je zelf alle problemen moet oplossen, maar wel dat je je over de hele keten druk moet maken. Een CEO is eindverantwoordelijk voor het hele bedrijf maar logt ook niet in op de databaseserver om te kijken waarom de boel platligt. Maar hij is wel verantwoordelijk. Als je vindt dat operationele zaken "afleiden" toon je m.i. weinig verantwoordelijkheid.

Niemand hier zegt ook niet dat het systeembeheer werk niet belangrijk is

Je kan toch zeggen dat je een redundant database nodig hebt met X uptime en onderhoud. Dan hoeft een developer zich niet zorgen te maken over de onderliggende infra, updates, licenties en dergelijke. Ja wij doen ons eigen beheer kwa performance meting en error's maar als er een database plat gaat dan gaat ons Devops team dat niet zelf oplossen, dan wordt dat gemeld bij de teams die dat in onderhoud hebben. What's next, dat iedere developer zelf naar het DC rijdt om een server te rebooten?

En een eindklant die developers rechtstreeks belt dat er integratietests iets niet hebben afgevangen? Daar zou ik ook wel heel hard bij wegrennen

[Falcon]

Misschien tijd voor een eigen topic over dit onderwerp? @MarcoC @GrooV

[bwerg]

MarcoC schreef op vrijdag 1 oktober 2021 @ 12:49:
Het enige wat telt is de waarde die gecreëerd wordt voor de klant, en daar zijn platforms, compute en onderhoud net zo essentieel voor als development werk.

Ja, en het contract, support en een bloemetje erbij ook. Bekent dat dat dat een software engineer contracten moet gaan schrijven, de telefoon bij de helpdesk moet opnemen en bloemetjes moet gaan plukken?

TS heeft al lang aangegeven om welke taken het concreet gaat, dat dat totaal niet is waar hij mee bezig wil zijn noch met wat jij als systeembeheer ziet en dat hij binnenkort pleite is, dus ik weet niet welk punt je wil maken met je definities van systeembeheer en dev-ops en waarde-voor-de-klant.

[ Voor 5% gewijzigd door bwerg op 01-10-2021 13:48 ]

[Xqlusive]

MarcoC schreef op vrijdag 1 oktober 2021 @ 12:49:
[...]
Mijns inziens zit je er volledig naast. Het enige wat telt is de waarde die gecreëerd wordt voor de klant, en daar zijn platforms, compute en onderhoud net zo essentieel voor als development werk. Hoe kan je nou zeggen dat je je hierdoor niet moet laten "afleiden"?

Lezen is ook een vak blijkbaar.....

Nergens hoor je mij zeggen dat die onderdelen niet belangrijk zijn. Wat ik zeg is dat die onderdelen niet de verantwoordelijkheid/expertise zijn van een developer. En dit hoort ook zo, een developer moet kunnen vertrouwen op de expertise van andere collega's in de keten.

Wat is de waarde van jouw product als de database platligt? Wat heb je eraan als de klant boos opbelt omdat de integratietests niet hebben afgevangen dat een essentiële feature niet meer werkt? Of als elke ochtend om 9u de app traag is omdat er een blijkbaar een cronjob draait? Neem ownership.

Precies, ownership ja...Maar dan wel over het onderdeel van de keten waar jij over gaat en daadwerkelijk kennis van hebt.

Neem verantwoordelijkheid. Dat wil niet zeggen dat je zelf alle problemen moet oplossen, maar wel dat je je over de hele keten druk moet maken.

Nee, dat moet je niet. Mensen die zich druk (moeten) maken over de gehele keten zijn ofwel 'architecten', 'product owners' etc. Die kijken naar de keten op een hoger abstractieniveau en vertrouwen op de experts binnen de keten voor de specifieke details. Tuurlijk moet je dingen afstemmen met andere teams, en is het goed om de keten te overzien, maar de details van andere onderdelen binnen de keten heb je weinig mee te maken als developer.

Een CEO is eindverantwoordelijk voor het hele bedrijf maar logt ook niet in op de databaseserver om te kijken waarom de boel platligt. Maar hij is wel verantwoordelijk. Als je vindt dat operationele zaken "afleiden" toon je m.i. weinig verantwoordelijkheid.

Het is simpelweg ook niet de verantwoordelijkheid van een developer. Daar heb je mensen voor die er er veel meer van af weten.

[ Voor 5% gewijzigd door Xqlusive op 01-10-2021 14:18 ]

[Xqlusive]

MarcoC schreef op vrijdag 1 oktober 2021 @ 12:43:
[...]

Ik werk juist bij een organisatie met meer dan 2.000 werknemers. Specialisatie is waardevol, maar uiteindelijk wil je multidisciplinaire teams die verantwoordelijkheid dragen voor de waarde die het product of de dienst creëert. Dat betekent dat dev en ops vaak in 1 team zitten. Gedeelde verantwoordelijkheid voor dev en ops is heel achterhaald. Dat wil natuurlijk niet zeggen dat er geen specialisaties bestaan, maar het wil zeggen dat 1 team verantwoordelijk is en developers niet hun werk over de schutting gooien naar "ops".

Nu heb je het over dev en ops. Die 2 liggen inderdaad redelijk dicht bij elkaar, en worden steeds meer verweven. Maar dat is heel iets anders dan dev en systeembeheer.

En voor de duidelijkheid, ik heb het over IT projecten waar meer dan een enkel dev en ops team bij betrokken is. Projecten binnen multinationals waar >100 man aan werken verdeeld over >10 teams.

voorbeeld keten:
- Model ontwikkeling (team 1)
- API development (team 2)
- API hosting (team 3)
- Upstream data provider (team 4)
- Streaming kafka bus (team 5)
- Frontend Elastics db (team 6)
- App backend (team 7)
- App frontend (team 8 )

en dan heb ik het nog niet eens over de ondersteunende teams:
- data science platform (platform engineers, data engineers, etc)
- Infrastructure architects
- Business stakeholders
- UX/UI
- CLR
- etc.

[ Voor 28% gewijzigd door Xqlusive op 01-10-2021 14:02 ]

[bytewhisperer]

1) Frame het op je CV als 'devops ervaring'.
2) Zsm wegwezen

[D33F]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[acemoo]

D33F schreef op vrijdag 1 oktober 2021 @ 14:22:
***members only***

Ik zou m'n bek open trekken. Zoals vaak genoemd in dit topic, als developer krijg je wel een nieuwe baan in no-time. Het ergste dat kan gebeuren als je je bek open trekt is dat je ontslag krijgt. In welk geval je een leuke bonus mee kunt krijgen.

Eventueel meld je ziek wat vrije dagen opnemen en stort jezelf wat meer op het vinden van een nieuwe baan.
Als je je bek niet open trekt en over jezelf heen laat walsen dan ben je over een jaar niet gelukkig.

[powerboat]

MarcoC schreef op donderdag 30 september 2021 @ 23:34:
[...]

99% van de tijd zijn systeembeheerders niet bezig complexe storingen op te lossen. Denk je echt dat ze in Silicon Valley "system administrators" en "developers" aannemen? Iedereen is daar gewoon software engineer. Logisch. Ongetwijfeld met verschillende expertises en niet iedereen kan elkaar 1-op-1 vervangen, maar dat hoeft ook niet.

Prima als je zenuwachtig wordt van systeembeheertaken, maar dan ook niet over 5 jaar klagen dat de rek uit je carrière is. Je moet begrijpen dat het onderscheid tussen "systeembeheer" en "ontwikkelaars" iets is wat "we" zelf bedacht hebben in de IT. Niemand heeft daar wat aan behalve wijzelf zodat we een schutting hebben om dingen overheen te gooien en lekker te klagen.

Het verbaast me dat "DevOps" in dit topic blijkbaar iets is waar mensen zenuwachtig van worden. Dan loop je echt achter de feiten aan.

Ik denk dat je een beetje neerkijkt op een systeembeheerder. Vind het erg denegrerend klinken.

Overigens stuur het maar door richting de TD want er zit ook een stekker aan

[ Voor 4% gewijzigd door powerboat op 01-10-2021 21:22 . Reden: i ]

[Pizza_Boom]

D33F schreef op vrijdag 1 oktober 2021 @ 14:22:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[Lethalis]

D33F schreef op vrijdag 1 oktober 2021 @ 14:22:
***members only***

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[D33F]

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[ Voor 7% gewijzigd door D33F op 18-11-2021 21:34 ]

[sypie]

Goede keuze. Ik hoop dat je collega hetzelfde gaat doen voordat er een nieuwe developer is aangetrokken. Laat de bom maar barsten. Dat is kennelijk de enige manier die je werkgever wil voelen of geloven. Zodra het pijn begint te doen aan de portemonnee zal de werkgever misschien eens van gedachten veranderen, of niet. Zulke bedrijven moeten niet te lang bestaan, is niet goed voor het volk wat er werkt.

In ieder geval gefeliciteerd met je nieuwe aanstelling. Hopelijk klopt je vooronderzoek en ga je er qua werkgever op vooruit.

[Invisible_man]

Bedankt voor de update en mooi dat je voor jezelf gekozen hebt!

Je schuldig voelen ken ik wel (ik weet ook wat voor gat ik ga achterlaten als ik bij mijn huidige werkgever weg zou gaan), maar zoals hier al eerder aangehaald gaat een werkgever echt niet zomaar veranderen, anders had die dat al lang gedaan. Ik hoop voor jouw collega dat jouw vertrek voor hem ook een eye opener is, maar realiteit is dat voor veel mensen het switchen van werkgever best wel een hoge drempel is, vooral naarmate men ouder wordt.

[Panzer_V]

Top dat je een update geeft. Heel veel succes in je nieuwe baan!

[RagingPenguin]

MarcoC schreef op vrijdag 1 oktober 2021 @ 12:43:
[...]

Ik werk juist bij een organisatie met meer dan 2.000 werknemers. Specialisatie is waardevol, maar uiteindelijk wil je multidisciplinaire teams die verantwoordelijkheid dragen voor de waarde die het product of de dienst creëert. Dat betekent dat dev en ops vaak in 1 team zitten. Gedeelde verantwoordelijkheid voor dev en ops is heel achterhaald. Dat wil natuurlijk niet zeggen dat er geen specialisaties bestaan, maar het wil zeggen dat 1 team verantwoordelijk is en developers niet hun werk over de schutting gooien naar "ops".

Maar nu heb je het opeens weer over teams en niet over personen. In een multidisciplinaire team zijn de individuen nog gewoon specialisten. Figuren die van alles een beetje kunnen en denken dat ze op all die verschillende vakgebeiden een expert zijn leiden over het algemeen aan het donor-kruning effect. Bestaande tooltjes aan elkaar kunnen knopen is echt heel iets anders dan daadwerkelijk begrijpen waar het over gaat. Echt goed worden in een technische specialisatie kost jaren, dat doe je niet zo maar eventjes omdat je nu een probleem hebt. Als je nu een probleem hebt dan praat je met de persoon die nu de expert is. "jack of all trades master of none" is mooi gezegde hier.

Als je geen specialisten hebt binnen een bedrijf dan ben je heel erg gelimiteerd in je maximale kwaliteit. Iets wat je binnen je bedrijf niet snel zal door hebben, als er geen expert is om inhoudelijke feedback te geven dan hou je de donor-kruning in stand.

[ Voor 12% gewijzigd door RagingPenguin op 19-11-2021 13:38 ]

[Pizza_Boom]

Omdenken: Misschien heeft je collega het wel nodig een keer volledig te verzuipen in het werk. Misschien heeft hij het wel nodig om wakker te worden en assertiever te worden.