Pragmatismo e ingegneria basati sul team

Quando si tratta di fare qualsiasi tipo di sviluppo – non mi interessa se è per il web, per dispositivi mobili o per qualche altra piattaforma – ci sono molti libri, corsi online e così via che rendono incredibilmente facile imparare qualunque cosa è che vuoi imparare.

Per essere chiari, non sto nemmeno bussando a nessuno dei modi disponibili per imparare. Dopotutto, impariamo tutti in modi diversi, giusto? E chi sono io per dire qual è il modo migliore di qualsiasi altro, soprattutto visto il fatto che scrivo quotidianamente su argomenti qui e su altri siti?

Ma posso dire definitivamente che per me – qualcuno a cui è piaciuto sia l’apprendimento attraverso l’istruzione formale, i tutorial, i corsi e così via – il modo migliore per acquisire esperienza in questo settore è stato duplice:

• lavorare con altre persone,
• rompere le cose e imparare a risolverle.

Intendo farlo in questo ordine specifico? No. Questo significa che sono un passo avanti rispetto agli altri? È ridicolo.

Ma poiché ho avuto il piacere di lavorare con gli altri su più progetti, parlare con altri tramite Twitter, conferenze e così via e ho sperimentato sia il bene che il male, è qualcosa che penso che tutti dovrebbero avere l’opportunità di fare prima o poi.

Se dovessi riassumerlo, direi che si tratta di trovare un equilibrio tra pragmatismo e ingegneria basati sul team. Perché, tuttavia, se nulla di quanto sopra è nuovo (dato che le società di software esistono da decenni) mi prendo la briga di scriverne ora?

Pragmatismo e ingegneria basati sul team

Probabilmente potrei inventare un elenco di motivi per cui ritengo importante questo particolare argomento, ma ci sono tre cose specifiche che vorrei menzionare in questo post. E, per motivi di lunghezza (leggi: tempo), farò quello che posso fare per mantenerli brevi.

In effetti, il TL;DR di ciò di cui parlerò ha a che fare con il pragmatismo e l’abilità ingegneristica. Inizialmente, avrei incluso anche una prospettiva sul business in generale, ma il post generale è stato un po’ fuori tema.

1 Pragmatismo

Ho già scritto sull’equilibrio tra ingegneria e pragmatismo .  Quindi potrei non avere molto da offrire in termini di qualcosa di nuovo, ma sto iniziando a cambiare un po’ la mia prospettiva.

Cioè, a un certo punto, si trattava esclusivamente di trovare un equilibrio tra la ricerca di una soluzione che funzionasse per l’abitudine, che fosse ben costruita e che risolvesse il loro problema. E lo sottoscrivo ancora.

E, naturalmente, c’è qualcosa da dire su come è organizzato il codice in modo che possa essere mantenuto nel tempo. Questa è la chiave. Ma come viene scritto il codice e viene costruita la soluzione è dove le cose possono diventare un po’ più sfocate rispetto al pragmatismo.

Vale a dire che è facile scrivere codice orientato agli oggetti di base, documentarlo, fare in modo che alcune classi o funzioni si chiamino a vicenda, si colleghino a WordPress e poi chiami un giorno.

2 Abilità ingegneristica

Ma quel livello di equilibrio tra spedizione della soluzione e architettura della soluzione è una linea sottile su cui camminare. Credo, tuttavia, che ci sia un pericolo nel cercare di essere troppo pragmatici: se miri a rimanere il più pragmatico possibile tutto il tempo e a lasciare le tue capacità ingegneristiche a un livello particolare, potresti non riuscire a progredire come sviluppatore.

Anche se preferisco usare la programmazione orientata agli oggetti nel tipo di lavoro che svolgo, non sono tipo da entrare in una guerra religiosa o entrare in quale versione di quale linguaggio, quale tecnologia, o se funzionale, procedurale o orientata agli oggetti la programmazione è migliore.

In poche parole: riguarda il livello generale di abilità che puoi raggiungere durante la tua carriera.

E quando lavoro con sviluppatori che hanno lavorato su progetti con competenze diverse, che sono stati formati in modi diversi e che hanno risolto diversi tipi di problemi, scopro di imparare costantemente cose nuove.

Questo non vuol dire che non ci siano conversazioni su cose che possiamo implementare come team o come partnership, ma significa che può impedire di ostacolare il potenziale di crescita come programmatore.

Potrei continuare su questo, ma in breve è questo: se lavorerai con gli altri, assicurati che abbiano esperienza, divertiti a usare lo stesso tipo di paradigmi che usi, sei aperto a conversazioni ponderate e porta un varietà di esperienza al tavolo.

In definitiva, questo può aiutare a migliorare sia le tue capacità che la qualità di ciò che tu e il tuo team state portando in tavola.

C’è sempre di più

Come ho detto prima nel post, c’è sempre di più. Probabilmente parlerò di più dell’aspetto commerciale di esso nei post futuri.

Per ora, però, lascerò ciò che ho scritto dov’è e andrò da lì in seguito.