Memorie di ingegneria del software

Jan 26 2023
Quattro anni come ingegnere del software in una startup ad alta crescita, ho imparato alcune lezioni molto preziose su cui rifletto qui. Questa è una lista in continua crescita e continuerò ad aggiungerla.

Quattro anni come ingegnere del software in una startup ad alta crescita, ho imparato alcune lezioni molto preziose su cui rifletto qui. Questa è una lista in continua crescita e continuerò ad aggiungerla.

  • Il lavoro è in continua evoluzione . Soprattutto quando l'azienda è piccola. Quando ho iniziato in OpenGov come 180esimo dipendente, non potevo dire se avrei svolto lo stesso lavoro che stavo facendo in quel momento, un mese dopo. Le cose stanno cambiando rapidamente, l'azienda sta cercando di trovare il suo posto nel mercato e ciò comporta requisiti in continua evoluzione.
  • Tu sei la cultura . Quando un'azienda è piccola, ogni nuova cosa o processo o miglioramento tecnico introdotto da te potrebbe essere adottato dall'intera organizzazione di ingegneria. (o in alcuni casi, l'intera azienda) e potrebbe diventare parte della cultura man mano che l'azienda cresce. Questo, secondo me, è molto appagante e non tutti hanno questa opportunità. Fai sempre attenzione alle cose che puoi migliorare e cerca di avviare una discussione. Non devi fare tutto il lavoro pesante da solo; identificare ciò che potrebbe essere migliorato e fare quel primo passo fa molto.
  • Toccare ogni parte della pila . In una startup che lavora come ingegnere, i ruoli raramente hanno un confine chiaro delle "cose" su cui ti può essere chiesto di lavorare soprattutto come ingegnere junior. Puoi aspettarti di lavorare su frontend, backend, infrastruttura, database e molto altro. Dalla preparazione di un backlog JIRA per una funzionalità alla distribuzione del relativo codice, tutto fa parte del lavoro.
  • Le cose si rompono. Distribuisci un pezzo di codice che interrompe il sistema o non si comporta come in un ambiente pre-produzione. A volte l'infrastruttura si rompe e non puoi distribuire nulla! Queste sono tutte opportunità per imparare e migliorare. In opengov, anche se avevamo un team devops dedicato per gestire problemi come questi, noi come ingegneri eravamo anche esposti al lato operativo dell'ingegneria del software.
  • La documentazione è importante. Dato che siamo impegnati a scrivere e spedire il codice, la documentazione tende a passare in secondo piano. Vale la pena prendersi del tempo, con cadenza regolare, per creare nuova documentazione e mantenere aggiornata quella esistente. Una buona documentazione, a mio avviso, è il segno di una squadra ad alte prestazioni. Man mano che le persone vanno e vengono, particolarmente vero per le startup, la documentazione è ciò che aiuta a inserire nuove persone e diffondere la conoscenza di vari sistemi e domini all'interno dei membri del team esistenti.
  • La comunicazione è difficile . Per ottenere un consenso da diverse parti interessate per un progetto tecnico, è necessario spiegare in che modo apporta valore al cliente. Vuoi dedicare i prossimi due sprint al refactoring della gestione dello stato della tua app? Bene, preparati a spiegarlo al prodotto o al tuo EM (che a sua volta dovrà spiegarlo ai superiori) perché è importante. A volte c'è un vantaggio diretto per l'utente finale, come tempi di caricamento più rapidi dell'app, migliore UX, ecc. Altre volte il vantaggio sarebbe una migliore esperienza dello sviluppatore che accelererebbe lo sviluppo delle funzionalità in futuro. Qualunque cosa sia, formare correttamente quella narrazione può essere complicato e anche se non sei tu quello coinvolto in queste negoziazioni, ti suggerisco di ridurre sempre lo zoom e guardare il tuo lavoro da un obiettivo utente.
  • Trovare il mentore giusto. Come in altre discipline, il tutoraggio può cambiare le regole del gioco per un giovane ingegnere. Un mentore non deve tenerti per mano per insegnarti qualcosa, ma piuttosto spingerti nella giusta direzione. Hanno una vasta esperienza nel settore, sono professionisti esperti e sono disposti a condividere le loro conoscenze con te. Contatta le persone del tuo team/azienda che ammiri e discuti di un problema che stai risolvendo, di un documento di progettazione tecnica che stai scrivendo o di qualsiasi cosa su cui hai bisogno di una guida.