Negli ultimi mesi rifletto molto sulla mia carriera da sviluppatore backend (Java/Spring Boot principalmente, con esperienze in Python/Django). Lavoro in un'azienda media da 4 anni con stipendio nella media, ma sento che l'apprendimento si è bloccato. Ho provato a studiare tecnologie nuove nel tempo libero (Kubernetes, cloud architecture) e seguito webinar di aggiornamento, ma sul lavoro abbiamo progetti ripetitivi che non mi permettono applicazioni concrete. Mi interessa molto la crescita professionale più che lo stipendio. Qualcuno che ha affrontato transizioni di carriera nel tech può condividere esperienze? Come valutate se un cambio realmente offre sviluppo di competenze sostanziale? Cerco pareri su bilanciamento tra stabilità e crescita.
Vale la pena cambiare lavoro per crescita personale nel tech?
Ciao @fidenziorinaldi81, capisco perfettamente la tua situazione perché ci sono passata qualche anno fa. Dopo 5 anni in un'azienda comoda ma stagnante (anche io su Java Spring Boot!), ho deciso di cambiare per crescere professionalmente. La differenza è stata abissale: in un nuovo contesto ho finalmente potuto applicare tecnologie cloud che studiavo da autodidatta.
Secondo me vale ASSOLUTAMENTE la pena cambiare quando:
- Hai già provato a proporre progetti innovativi internamente senza successo
- Ti senti intellettualmente sottoutilizzato
- Ci sono aziende serie che offrono formazione strutturata
Fai però attenzione durante i colloqui: chiedi CONCRETAMENTE quali progetti innovativi stanno sviluppando, quanto tempo dedicano alla formazione, e se hanno roadmap di crescita chiare. La mia attuale azienda, per esempio, ci dà il 10% dell'orario per formazione certificata e hackathon interni.
Un consiglio? Non accettare solo per lo stipendio (anche se un aumento è giusto), ma valuta soprattutto la qualità dei progetti e la cultura dell'apprendimento. Io dopo il cambio ho raddoppiato le mie competenze in cloud architecture in meno di un anno!
P.S.: Se decidi di restare, cerca almeno un mentore esterno... ma secondo me hai già la risposta!
Secondo me vale ASSOLUTAMENTE la pena cambiare quando:
- Hai già provato a proporre progetti innovativi internamente senza successo
- Ti senti intellettualmente sottoutilizzato
- Ci sono aziende serie che offrono formazione strutturata
Fai però attenzione durante i colloqui: chiedi CONCRETAMENTE quali progetti innovativi stanno sviluppando, quanto tempo dedicano alla formazione, e se hanno roadmap di crescita chiare. La mia attuale azienda, per esempio, ci dà il 10% dell'orario per formazione certificata e hackathon interni.
Un consiglio? Non accettare solo per lo stipendio (anche se un aumento è giusto), ma valuta soprattutto la qualità dei progetti e la cultura dell'apprendimento. Io dopo il cambio ho raddoppiato le mie competenze in cloud architecture in meno di un anno!
P.S.: Se decidi di restare, cerca almeno un mentore esterno... ma secondo me hai già la risposta!
@fidenziorinaldi81, ti parlo da chi ha bruciato due lavori per impulsività ma poi ha trovato la svolta: CAMBIA. Subito. Se dopo 4 anni senti la stagnazione, è già troppo. Io ho perso tempo in una situazione simile e me ne pento.
Cerca aziende con due caratteristiche:
1. Team che usano stack moderni (cloud, K8s, architetture distribuite) *per davvero*, non solo per fregatura su LinkedIn.
2. Cultura della sperimentazione (hackathon, tempo per POC, budget per certificazioni).
Attenzione alle trappole: startup che ti spremono senza formazione o corporate che ti incatenano a legacy. Fai domande scomode ai colloqui: "Quanti deploy al giorno fate? Qual è l’ultima tecnologia che avete adottato?" Se rispondono con vaghezze, scappa.
Io ora lavoro in una scale-up con 20% di tempo per formazione e progetti personali. La differenza è che imparo ogni giorno, non solo la domenica su Udemy. Stipendio? Quello viene dopo, ma di solito segue.
PS: Se vuoi nomi di aziende serie in Italia che cercano backend engineer con le palle, scrivimi in DM.
Cerca aziende con due caratteristiche:
1. Team che usano stack moderni (cloud, K8s, architetture distribuite) *per davvero*, non solo per fregatura su LinkedIn.
2. Cultura della sperimentazione (hackathon, tempo per POC, budget per certificazioni).
Attenzione alle trappole: startup che ti spremono senza formazione o corporate che ti incatenano a legacy. Fai domande scomode ai colloqui: "Quanti deploy al giorno fate? Qual è l’ultima tecnologia che avete adottato?" Se rispondono con vaghezze, scappa.
Io ora lavoro in una scale-up con 20% di tempo per formazione e progetti personali. La differenza è che imparo ogni giorno, non solo la domenica su Udemy. Stipendio? Quello viene dopo, ma di solito segue.
PS: Se vuoi nomi di aziende serie in Italia che cercano backend engineer con le palle, scrivimi in DM.
Grazie di cuore per le riflessioni così concrete, @harborbernardi82. La tua esperienza è illuminante, specialmente il concetto che se dopo 4 anni sento stagnazione è già "troppo tardi". Mi colpisce come tu abbia trasformato errori passati in un percorso chiaro per gli altri.
I tuoi due punti cardine – stack moderni *reali* e cultura sperimentale – sono diventati ora i miei criteri non negoziabili. Le domande scomode ai colloqui ("deploy al giorno", "tecnologie recenti") sono oro, le userò come cartina di tornasole.
La tua situazione attuale nella scale-up, con quel 20% dedicato alla crescita, è esattamente l'ambiente che cerco: imparare *durante* il lavoro, non solo nei ritagli.
Apprezzo tantissimo l'offerta di condividere nomi di aziende serie: ti scrivo in DM volentieri per approfondire. Mi hai dato la spinta decisiva che cercavo.
I tuoi due punti cardine – stack moderni *reali* e cultura sperimentale – sono diventati ora i miei criteri non negoziabili. Le domande scomode ai colloqui ("deploy al giorno", "tecnologie recenti") sono oro, le userò come cartina di tornasole.
La tua situazione attuale nella scale-up, con quel 20% dedicato alla crescita, è esattamente l'ambiente che cerco: imparare *durante* il lavoro, non solo nei ritagli.
Apprezzo tantissimo l'offerta di condividere nomi di aziende serie: ti scrivo in DM volentieri per approfondire. Mi hai dato la spinta decisiva che cercavo.
Sai Fidenzio che hai proprio ragione a sentirti così? Anch'io mi sono trovata in quella situazione stagnante e *oddio* che palle quando studi Kubernetes la sera per poi ritrovarti a fare CRUD su Spring Boot per l'ennesimo progetto legacy...
Harbor ha centrato il punto: se dopo 4 anni non cresci, è già tardi. Io ho aspettato 5 per impulsività e me ne pento ancora! Quella frase "imparare *durante* il lavoro" è tutto: le scale-up con quel 20% di tempo dedicato alla crescita sono rarità preziose – cercale come fossero Pokémon leggendari!
Però attenta: quando Harbor ti manda i nomi delle aziende, controlla su Glassdoor/TeamBlind le voci reali dei dipendenti. Io in passato ho accettato un'offerta "innovativa" e poi... deploy? Zero. Tecnologie nuove? Roba del 2015.
Insisti sulle domande scomode: "Qual è stato l'ultimo flop tecnico e come l'avete gestito?" Se balbettano, scappa. Se invece ti parlano di chaos engineering o di come hanno migrato un monolite... *that's the vibe!*
PS: Se trovi un posto dove ti pagano Docker Swarm nel 2024, segnalamelo che gli spammo i CV falsi :D
Harbor ha centrato il punto: se dopo 4 anni non cresci, è già tardi. Io ho aspettato 5 per impulsività e me ne pento ancora! Quella frase "imparare *durante* il lavoro" è tutto: le scale-up con quel 20% di tempo dedicato alla crescita sono rarità preziose – cercale come fossero Pokémon leggendari!
Però attenta: quando Harbor ti manda i nomi delle aziende, controlla su Glassdoor/TeamBlind le voci reali dei dipendenti. Io in passato ho accettato un'offerta "innovativa" e poi... deploy? Zero. Tecnologie nuove? Roba del 2015.
Insisti sulle domande scomode: "Qual è stato l'ultimo flop tecnico e come l'avete gestito?" Se balbettano, scappa. Se invece ti parlano di chaos engineering o di come hanno migrato un monolite... *that's the vibe!*
PS: Se trovi un posto dove ti pagano Docker Swarm nel 2024, segnalamelo che gli spammo i CV falsi :D
Ah, Mina, ma quanto mi ci ritrovo in questo tuo sfogo! *Oddio* sì, la frustrazione di studiare Kubernetes la sera per poi ritrovarsi a fare CRUD su Spring Boot è un classico da "ma che cazzo sto facendo qui". E quella storia del "deploy? Zero" mi ha fatto ridere amaramente, perché sì, è la trappola perfetta: ti vendono innovazione e ti ritrovi con un monolite del 2015 che nessuno osa toccare.
Hai ragione tu: le domande scomode sono tutto. Io aggiungerei: "Come gestite il debito tecnico?" Se ti guardano come se avessi parlato in klingon, scappa a gambe levate. E sì, Glassdoor è sacro, ma anche LinkedIn può essere utile: cerca ex dipendenti e chiedi in DM. La gente è più sincera di quanto credi quando non ha più nulla da perdere.
PS: Se trovi un posto con Docker Swarm nel 2024, non spammare CV falsi, mandami lì direttamente. Voglio vedere con i miei occhi questo fossile vivente. 😂
Hai ragione tu: le domande scomode sono tutto. Io aggiungerei: "Come gestite il debito tecnico?" Se ti guardano come se avessi parlato in klingon, scappa a gambe levate. E sì, Glassdoor è sacro, ma anche LinkedIn può essere utile: cerca ex dipendenti e chiedi in DM. La gente è più sincera di quanto credi quando non ha più nulla da perdere.
PS: Se trovi un posto con Docker Swarm nel 2024, non spammare CV falsi, mandami lì direttamente. Voglio vedere con i miei occhi questo fossile vivente. 😂
Ehi @penelopefontana39, mi hai fatto ridere con quel PS su Docker Swarm – è come se io mi vantassi del mio sesto senso per trovare parcheggio in piena città, un superpotere che non serve a un cavolo in un mondo di traffico! Hai centrato il punto sul debito tecnico: se non lo gestiscono, è un segno che stanno affogando in legacy code. Io ho mollato un lavoro dove era un tabù parlarne, e ora consiglio sempre di approfondire con "Quali tool usate per monitorarlo?", tipo SonarQube o simili. LinkedIn per gli ex dipendenti è una mossa geniale, l'ho fatto anch'io e ho evitato un paio di buchi neri. Aggiungo: cerca aziende con cultura di retrospectives regolari, fa una differenza enorme per la crescita. Forza, non mollare! 😂
Amen @lennoxlongo56! Quella del sesto senso per i parcheggi è spettacolare 😂 Anch’io ho vissuto quella merda di silenzio sul debito tecnico: in un ex lavoro, solo *accennarlo* ti faceva sembrare un traditore. Ero tipo: "Scusate, ma questo monolite puzza di cadavere digitale da sei anni..." e tutti a fissare i muri. Stra-quoto la tua mossa di chiedere *dettagli* sul debito tecnico: "Quali metriche usate? SonarQube o solo preghiere?". Se non hanno risposte, è come un cartello luminoso: "FUGGI!"
Retrospective regolari = oro colato. Lavoro in una scale-up dove ogni sprint si fa un post-mortem *senza peli sulla lingua*. La prima volta è stato imbarazzante ("Sì, abbiamo sputtanato il deploy per pigrizia"), ma ora è liberatorio. Ti fa crescere professionalmente come certe aziende da legacy ti sognano.
Ti aggiungo un consiglio selvaggio: guarda i loro repository GitHub. Se vedi commit solo su branch di produzione, zero test, README scritti coi piedi... *abort mission*. Fossimo calciatori, sarebbe come giudicare Cristiano Ronaldo dai suoi tweet invece che dai gol.
Bella la tua energia comunque, continua così! 💪🔥
Retrospective regolari = oro colato. Lavoro in una scale-up dove ogni sprint si fa un post-mortem *senza peli sulla lingua*. La prima volta è stato imbarazzante ("Sì, abbiamo sputtanato il deploy per pigrizia"), ma ora è liberatorio. Ti fa crescere professionalmente come certe aziende da legacy ti sognano.
Ti aggiungo un consiglio selvaggio: guarda i loro repository GitHub. Se vedi commit solo su branch di produzione, zero test, README scritti coi piedi... *abort mission*. Fossimo calciatori, sarebbe come giudicare Cristiano Ronaldo dai suoi tweet invece che dai gol.
Bella la tua energia comunque, continua così! 💪🔥
@patriziogallo76 Rido ancora per "SonarQube o solo preghiere" – troppo vero! Quel silenzio sul debito tecnico è un campanello d'allarme che ho sentito anch'io: se si evitano le domande scomode, scappa ai primi segnali. La tua idea di controllare i repository GitHub è oro: aggiungo di cercare *issue tracker attivi*. Se vedi ticket stagnanti da mesi ("bug fix del 2019") o discussioni tecniche superficiali, indica una cultura della negligenza.
Per @fidenziorinaldi81: valuta aziende che *documentino le scelte tecniche*. Ho visto realtà dove le ADR (Architectural Decision Records) sono aggiornate e discusse pubblicamente. È un segno di maturità – significa che accettano di imparare dagli errori invece di nasconderli. E sì, se trovi un team che usa ancora Docker Swarm nel 2024... corri più veloce di Bolt. 😉
Retrospective sincere? Fondamentali. In un mio vecchio progetto, quelle sessioni ci hanno salvato da un deploy disastroso – imbarazzante ma salvifico. Continua a cercare: la crescita vera sta dove le domande scomode sono benvenute.
Per @fidenziorinaldi81: valuta aziende che *documentino le scelte tecniche*. Ho visto realtà dove le ADR (Architectural Decision Records) sono aggiornate e discusse pubblicamente. È un segno di maturità – significa che accettano di imparare dagli errori invece di nasconderli. E sì, se trovi un team che usa ancora Docker Swarm nel 2024... corri più veloce di Bolt. 😉
Retrospective sincere? Fondamentali. In un mio vecchio progetto, quelle sessioni ci hanno salvato da un deploy disastroso – imbarazzante ma salvifico. Continua a cercare: la crescita vera sta dove le domande scomode sono benvenute.
Ciao @fidenziorinaldi81! Condivido in pieno la tua sensazione: dopo 4 anni di progetti ripetitivi, è normale sentirsi stagnanti. Ho vissuto la stessa situazione in passato e ti dico: **cambia, ma con criterio**.
La discussione sul debito tecnico e le ADR sollevata da @kennedyricci è fondamentale. Aggiungo: durante i colloqui, chiedi *dettagli su un progetto recente*. Se la risposta è vaga o evitano di parlare degli errori, scappa. L'ho imparato a mie spese: in un'azienda che idolatrava il "tutto perfetto", poi scoprivi deployment fatti col nastro adesivo.
Attenzione alle tecnologie *cosmetiche*: Kubernetes sul CV ma zero automazione? Red flag. Cerca team che:
1. **Dedichino il 20% del tempo al shadows** (prove su ambienti non produttivi)
2. **Usino trunk-based development** (segno di maturità nei processi)
3. **Abbiano roadmap di refactoring scritte nero su bianco**
Un consiglio più personale: prova a contribuire a progetti open source nelle tech che ti interessano (es. CNCF per Kubernetes). Ti dà esperienza *concreta* e fa brillare il CV. Io così ho scoperto che un'azienda che usava Kafka bene era **diametralmente opposta** alla mia precedente, dove "cloud" era solo un suffisso nei job title.
Se trovi un posto con retrospettive *senza autodifese* (tipo: "abbiamo sbagliato X, ecco come evitiamo Y"), è oro. Crescerai più in 6 mesi che in anni di Spring Boot monotono. In bocca al lupo! 🚀
La discussione sul debito tecnico e le ADR sollevata da @kennedyricci è fondamentale. Aggiungo: durante i colloqui, chiedi *dettagli su un progetto recente*. Se la risposta è vaga o evitano di parlare degli errori, scappa. L'ho imparato a mie spese: in un'azienda che idolatrava il "tutto perfetto", poi scoprivi deployment fatti col nastro adesivo.
Attenzione alle tecnologie *cosmetiche*: Kubernetes sul CV ma zero automazione? Red flag. Cerca team che:
1. **Dedichino il 20% del tempo al shadows** (prove su ambienti non produttivi)
2. **Usino trunk-based development** (segno di maturità nei processi)
3. **Abbiano roadmap di refactoring scritte nero su bianco**
Un consiglio più personale: prova a contribuire a progetti open source nelle tech che ti interessano (es. CNCF per Kubernetes). Ti dà esperienza *concreta* e fa brillare il CV. Io così ho scoperto che un'azienda che usava Kafka bene era **diametralmente opposta** alla mia precedente, dove "cloud" era solo un suffisso nei job title.
Se trovi un posto con retrospettive *senza autodifese* (tipo: "abbiamo sbagliato X, ecco come evitiamo Y"), è oro. Crescerai più in 6 mesi che in anni di Spring Boot monotono. In bocca al lupo! 🚀