Un ingegnere del software generalmente pensa che un buon software sia il risultato dell'implementazione di modelli collaudati, rimanendo all'interno di regole, usando la disciplina e seguendo processi formali e best practices.
Un programmatore sa che tutta quella roba è una stronzata.
Scrivere codice è più simile a comporre musica, o scrivere libri, produrre film e sicuramente arti grafiche che a costruire ponti. In effetti, è più difficile perché deve fare più che sembrare o suonare bene. Tutti sanno che la buona musica, la letteratura e l'arte non riguardano il modo in cui sono state seguite le regole, ma piuttosto le regole che vengono infrante e le nuove idee che vengono esplorate. Qualcuno pensa che gli articoli più popolari nelle classifiche musicali e nelle liste dei bestseller siano posizionati lì in base alla loro conformità a qualsiasi standard o regola? Quell'elenco sarebbe molto diverso e non molto popolare perché la società si muove in avanti verso cose nuove o vecchie con una nuova svolta, ma non si stabilizzerà mai.
I migliori programmi sono semplici, fanno naturalmente ciò che si vuole, funzionano in modo affidabile, e possono essere usati in modo abbastanza intuitivo da non essere fastidiosi. Ciò che viene lasciato fuori è generalmente più importante di ciò che viene aggiunto - non vogliamo che sia configurabile, vogliamo che si configuri da solo o che non abbia bisogno di configurazione. Probabilmente non ci rendiamo nemmeno conto della maggior parte dei migliori programmi in uso ovunque intorno a noi oggi, perché semplicemente funzionano e non dobbiamo pensare o preoccuparci di loro. Quando il software ci infastidisce, non ci interessa quanto bene gli 'ingegneri del software' abbiano seguito le loro regole e processi, siamo solo infastiditi e il software fa schifo perché si tratta di persone e di risolvere un problema, non di strumenti e tecnologia - prendi lo strumento appropriato una volta che hai capito il problema - e prova strumenti diversi man mano che lo capisci di più - non il contrario. Quando il software ci stupisce, non ci importa ancora delle regole e dei processi, solo che siamo stupiti e ispirati a fare cose simili. Così sembra che solo gli ingegneri si preoccupino delle regole e dei processi.
Trovo che le persone che propendono per una mentalità ingegneristica tendono a concentrarsi sulla tecnologia e sul codice e se il processo è stato seguito correttamente (TDD? MVC?) e quanto bene si adatta a regole per lo più arbitrarie per la struttura e lo stile senza molto riguardo per il problema reale che viene risolto o per ciò che l'utente ha realmente bisogno. Il miglior software viene da un'attenzione equilibrata sull'utente, il problema e la tecnologia - e in quest'ordine di priorità. I migliori risultati di solito vengono da piccoli e semplici cambiamenti in tutti e tre, ma se ci concentriamo solo sull'"ingegneria" vediamo solo un aspetto della situazione.
Il problema è che la creatività viene soffocata quando siamo costretti a seguire delle regole o a rispettare un processo dettagliato. Alcune linee guida e processi generali vanno bene per far sì che il management sia felice di ottenere il valore che vuole, ma questa industria si muove molto velocemente e le vere innovazioni del futuro non verranno fuori dalle 'best practices'. Gli ingegneri tendono verso queste 'best practices' mentre i programmatori cercano di innovare e trovare un modo per fare di più con meno lavoro e potrebbe non seguire il processo o arrivare secondo il programma ma funzionerà.
Per esempio: Forse 200 linee di codice Node.js risolverebbero questo problema più facilmente e meglio di 10.000 linee di codice Java EE? Forse un piccolo cambiamento nel modo in cui l'utente percepisce il problema potrebbe ridurre la complessità della soluzione?
Al punto in cui l'utente, il problema e la tecnologia (programmatore) convergono, emergono una realtà interessante e opportunità che solo un programmatore può vedere. Trovo che gli ingegneri tendano a non vederle perché hanno già deciso come il problema sarà risolto prima di capire il problema. Il controllo dei cambiamenti sarà invocato man mano che il problema si rivela nel loro mondo.
Sono stato un programmatore da quando avevo 14 anni (autodidatta poi al college) e ho seguito tutto il percorso di carriera fino a designer, architetto e mi sono reso conto che ormai stavo solo disegnando diagrammi, scrivendo documenti ed era una perdita di tempo e non molto soddisfacente. Ora ho 48 anni e codifico di nuovo e mi piace perché posso far accadere le cose più velocemente e meglio di quanto abbia mai potuto prima e farle funzionare bene per l'utente, non solo parlarne con descrizioni e astrazioni di alto livello.
Mentre alcune persone ritengono che il termine ingegnere abbia una certa credibilità rispetto a un umile "programmatore", io preferisco il termine programmatore o sviluppatore di software perché l'ingegneria è una disciplina per natura e mentre una trave d'acciaio e il calcestruzzo obbediscono alle regole se seguiamo il processo per installarli, le persone, i computer e il software non funzionano in questo modo - immaginate l'acciaio e il calcestruzzo con caratteristiche comportamentali e proprietà che possono essere cambiate al volo.
Ho scoperto che la programmazione e lo sviluppo del software per me è più un'arte o un talento da praticare e mentre ci vuole un po' di disciplina, si tratta molto di più di creare qualcosa di nuovo - e si spera davvero grande - che intrattiene o fornisce un valore reale per qualcuno.