Quale cappello non dovrebbe indossare un programmatore? [chiuso]

Nella mia esperienza, gli sviluppatori di software tendono a indossare più cappelli e ricoprono più ruoli con responsabilità diverse. Dalla codifica non solo, ma a volte anche alla scrittura di SQL, dalla progettazione dell'interfaccia utente, dalla progettazione del database, dalla manipolazione grafica, fino ai test di controllo qualità.

Se il ruolo principale è scrivere software / codice, quali ruoli lo sviluppatore non dovrebbe assumere? Ci sono?

L'intenzione di questa domanda non è perché uno sviluppatore non è in grado di ricoprire un altro ruolo, ma avere il ruolo aggiuntivo funziona effettivamente contro il ruolo principale , o dovrebbe davvero essere un ruolo dedicato di qualcuno che non programma principalmente.

Sysadmin. Lo sviluppo di software e la gestione dell'infrastruttura IT sono due diversi skillset simili a quelli di un estraneo. (Sta solo sbattendo sui computer, giusto?) Per una piccola azienda, la tentazione sarà molto forte per rendere The Computer Guy responsabile di tutte le macchine dell'ufficio.

Se hai le abilità per indossare effettivamente entrambi i cappelli, fantastico; ma è una di quelle cose che possono essere una perdita di tempo molto più grande di quanto la gente capisca, e se stai insegnando da solo mentre procedi, è probabile che non lo stai facendo molto bene.

Indossi qualunque cappello ti chieda il tuo datore di lavoro. Questo è ciò che ti rende un giocatore di squadra. Questo è ciò che ti rende un risolutore di problemi .

Le persone sono troppo prese dall'idea di essere uno "sviluppatore" o un "architetto" o un "analista". Fanculo. Dovresti essere un risolutore di problemi. Il codice è solo uno strumento nella tua cintura.

La risoluzione dei problemi non passa mai di moda.

Se il mio datore di lavoro vuole che io faccia supporto tecnico o costruisca computer, così sia. Pensa che stiano sprecando i loro soldi, considerando un salario degli sviluppatori, ma sono affari loro. Sono qui per risolvere i problemi. Comunque posso farlo, lo farò. E se ho la sensazione che, dopo un certo periodo di tempo, i miei talenti vengono sprecati o la mia soddisfazione sul lavoro non è dove voglio che sia, allora ho solo il diritto di passare a un altro lavoro.

Ma alla domanda di base - non c'è un cappello che non indossi. Diamine, se vogliono che tu vada a prendere il caffè, fallo. Risolvi i loro problemi; sappi solo che hai il diritto di trovare un altro lavoro se desideri un cambiamento.

Tester!

Vi preghiamo di inviarci tester direttamente dalla scuola di prova, se necessario!

Senza tester le persone si aspettano che tutto funzioni alla grande perché il programmatore è il tester e sono molto intelligenti, quindi dovrebbe funzionare.

Non sto dicendo che il cibo per cani non sia una buona idea. Penso solo che i tester siano molto importanti ora che sono un programmatore.

Dovresti stare attento a diventare il ragazzo di riferimento per i problemi hardware dell'ufficio . Ciò può includere la risoluzione dei problemi del PC, l'amministratore del server, i backup e persino il funzionamento del sistema telefonico. Ho commesso l'errore di menzionare la mia precedente esperienza hardware e, alla fine, i miei compiti di hardware / risoluzione dei problemi sono stati gravemente in conflitto con i miei compiti di programmazione.

Un programmatore non dovrebbe essere l'unico tester per il proprio codice .

Gli sviluppatori scrivono codice con una serie di presupposti. Se i tester hanno lo stesso insieme di ipotesi, non eserciteranno la funzionalità imprevista al di fuori di tali limiti e molti problemi rimarranno inosservati.

Inoltre, al fine di andare avanti, gli sviluppatori non sono fortemente motivati ​​a provare a rompere le cose, mentre i tester lo sono (forse a livello subconscio).

Ciò non implica che il test di sviluppo sia inutile. Al contrario, un buon test di sviluppo consente ai tester di concentrarsi sulla ricerca di problemi più profondi. Tuttavia, il test di sviluppo non sostituisce un tester dedicato.

Due a cui riesco a pensare subito.

1. Supporto tecnico. Non sono qui per aiutare i clienti a lavorare sul nuovo sito o insegnare loro come utilizzare le funzionalità.
2. Sebbene possa essere necessario interfacciarsi con i clienti in vari punti del processo, a meno che tu non sia un programmatore di gestione, in realtà non dovresti comunicare direttamente con loro su funzionalità e implementazioni di progettazione.

Si potrebbe dire che lo sviluppo di CSS / UI sarebbe al di fuori del "regno" della programmazione, ma nella mia esperienza è oggi un'abilità necessaria. Non puoi semplicemente cavartela con le tabelle e dipendere da qualcun altro per implementarla correttamente. Potrebbe non piacermi l'implementazione del design o l'alterazione del codice per gestire un nuovo design, ma questo fa parte del lavoro.

Scrivere query va bene, il test Q / A va bene (e IMO dovrebbe essere il lavoro del programmatore, fare trovare un dipartimento esterno, ma prima dovresti testarlo). L'amministrazione del server è un po 'una zona grigia. A seconda delle dimensioni del progetto o se si dispone di un amministratore del server dedicato, potrebbe essere necessario o meno.

In generale, è stata la mia esperienza che la maggior parte dei programmatori non dovrebbe sviluppare l'aspetto dell'interfaccia utente - anche se sono certamente in grado di sviluppare un'interfaccia utente (e spesso crearne uno durante la costruzione di un prototipo o una prova di concetto), questo è meglio lasciare a una persona di fattori umani (che nella nostra piccola azienda è un artista grafico che fa anche i layout dello schermo e crea la maggior parte dei manuali e delle brochure).

Inoltre, gli sviluppatori non dovrebbero eseguire test di controllo qualità: questo è il compito del dipartimento di controllo qualità (la società in cui lavoro produce dispositivi medici incorporati, quindi è necessario che i test vengano eseguiti da un reparto separato).

D'altra parte, non vedo alcun motivo per cui gli sviluppatori non possano progettare database e scrivere SQL, se hanno lo sfondo per farlo - l'ho fatto tante volte.

Supporto tecnico

Gran parte della mia giornata è sprecata prendendo le chiamate di supporto tecnico ...

Alcuni popolari sono:

• "Il mio account è bloccato" o "Ho dimenticato la mia password"
• "Il mio [telefono | tastiera | mouse | computer] non funziona"
• "Il mio computer è lento, puoi verificarlo per qualcosa di insolito?"
• "Perché X accade quando faccio clic su questo pulsante? Dovrebbe essere Y"
• "Continuo a ricevere questi popup ...." o "Penso di avere un virus"
• "Questa persona non è più qui, puoi disabilitare tutte le loro cose?"
• "Abbiamo un nuovo dipendente, puoi configurarlo con login, carta di sicurezza, telefono, email, ecc.?"

Qualsiasi ruolo che lo faccia gestire da solo. Nei piccoli team, c'è spesso la tendenza a rendere uno degli sviluppatori senior il project manager, ma anche a mantenerlo nel team come programmatore. Questo porta a tutti i tipi di problemi, dal momento che questo ragazzo, come programmatore, è sostanzialmente non gestito. Invece di delegare tutti i compiti agli altri membri del team, sarà spesso tentato di assegnarne molti a se stesso, in particolare i compiti più difficili. Quindi i compiti più difficili, quelli che hanno maggiori probabilità di causare problemi, sono assegnati a una persona che è disponibile solo come 50% come programmatore e come tale non riferisce a nessuno. Quando gli altri membri del team non sono in grado di consegnare, invece di prenderli a calci in culo, proverà a svolgere i loro compiti, perché, in quanto project manager, è responsabile del successo e il modo più sicuro per farlo è farlo da solo no?

Supporto tecnico per qualcosa che non hai avuto mano nello sviluppo, nella distribuzione o nella manutenzione e per il quale non hai ricevuto alcuna formazione e non sei aggiornato su importanti cambiamenti. Parte del mio lavoro è diventata rispondere al telefono per i clienti che chiamavano perché la loro Internet non funziona. Non mi occupo di quella metà del business, quindi non posso dire loro nulla di utile.

Non è necessario fare supporto tecnico, con cui non ci sono problemi. Sta facendo il segretario / ragazzo del supporto tecnico mentre cerca di sviluppare le cose.

È abbastanza faticoso dover ascoltare le persone che si lamentano tutto il giorno e non essere in grado di dire loro nulla. Consiglierei di evitarlo a tutti i costi.

Vendite .

Qualche poveraccio deve farlo, ma sicuramente non dovrebbero essere gli sviluppatori.

Man mano che sono cresciuto, mi sono reso conto che è meglio se gli sviluppatori non eseguono le proprie implementazioni (ho combattuto con un dente e unghia). Non dovrebbero avere alcun diritto sul database di produzione tranne i diritti selezionati. Il nostro codice è diventato molto meno difettoso (e la stessa cosa non è cresciuta più volte perché la modifica è stata apportata solo in prod e una successiva distribuzione di sviluppatori l'ha sovrascritta di nuovo quindi riparata solo su prod in fretta, risciacquo e ripetizione) quando abbiamo ha dovuto iniziare a distribuirlo ad altre persone e non essere autorizzato a apportare modifiche rapide alla produzione perché la distribuzione non era corretta. Inoltre abbiamo smesso di avere quegli "aggiornamenti accidentali senza la clausola where evidenziata che ha modificato tutti i record nella tabella".

Artista e designer dell'interfaccia utente .

La maggior parte dei programmatori è molto povera di opere d'arte, ma le aziende non si preoccupano di pagare per un artista di disegnare immagini e icone per i loro prodotti e usano semplicemente "arte del programmatore" - con risultati orribili. (Fino a Windows Vista, questo era il fattore di differenziazione più immediatamente evidente tra Mac e PC: i Mac sembravano belli e amichevoli, i PC erano un pugno nell'occhio)

Allo stesso modo, molti programmatori non sono molto interessati all'interfaccia utente: si preoccupano principalmente del loro codice. Esse semplicemente espongono il contenuto delle variabili dei loro membri direttamente in alcuni campi modificabili, spesso non importa dove inseriscono pulsanti e campi nei loro moduli, e presumono che ciò sia sufficiente, risultando in un software inutilizzabile. (L'intero settore della telefonia mobile è stato molto colpevole fino a quando l'iPhone è arrivato per mostrare loro che potevi effettivamente creare un'interfaccia utente del telefono che fosse piacevole da usare)

Lotus Notes è un brillante esempio di quanto entrambe queste cose possano essere brutte se non si ottiene un designer professionista per aiutare i programmatori.

Stesura di test generali e piani di test. Seriamente, ragazzi, posso scrivere i miei piani di test, ma ciò significa inserire nel prodotto qualunque apprensione, falsa ipotesi ed errore cognitivo che ho fatto mentre scrivevo le cose. Era l'unica cosa che odiavo di un'azienda in cui lavoravo; dove sono ora, abbiamo almeno recensioni di codice che probabilmente cattureranno queste cose.

Non indossare mai più "cappelli" di quelli che puoi ragionevolmente gestire e con cui ti senti a tuo agio, provando a fare il piccione agli sviluppatori dicendo che non dovrebbero fare A o B significa che un grande designer dell'interfaccia utente potrebbe passare inosservato perché qualcuno pensa che i programmatori dovrebbero stare lontano da l'interfaccia utente.

Alla fine della giornata tutti avranno diversi punti di forza e di debolezza e un buon manager / supervisore / team leader dovrebbe conoscere il modo migliore per indirizzare le persone che lavorano per loro per garantire che i talenti vengano utilizzati in modo appropriato. Allo stesso modo, se non hai dimestichezza con la progettazione di interfacce utente o con gli utenti finali, informa il tuo team in modo da ridurre al minimo il tuo ruolo in quella zona. Tuttavia, dovresti essere pronto a raccogliere qualche lavoro aggiuntivo in un'altra area.

Inoltre, se indossi troppi cappelli (ad es. Programmatore, designer dell'interfaccia utente, tester, analista aziendale, ecc.), O farai male ad alcuni di essi o ti esaurirai. Assicurati di sapere quanti cappelli puoi gestire e cerca di mantenere il carico di lavoro attorno a quel livello.

Oltre a ciò, non ci sono davvero "cappelli" che uno sviluppatore non dovrebbe indossare se ha le capacità per eccellere in quel ruolo.

Tendo a prendere qualsiasi lavoro che mi viene lanciato se e solo se:

• Avviso in anticipo del mio livello di abilità e delle possibili implicazioni e il mio capo decide che è accettabile
• C'è una persona di livello guru che può (e probabilmente ad un certo punto) mi aiuterà ad affrontare qualcosa di inaspettato
• Leggi alcuni documenti, domande online, ecc.

In questo modo sono per lo più assicurato contro il mio capo e se qualcuno va storto è almeno riparabile.

Gli sviluppatori sono parti interessate alla situazione (come clienti, proprietari, ecc.), Quindi hanno il diritto di aspettarsi un lavoro significativo. Secondo me, ciò significa l'opportunità di lavorare con i tuoi punti di forza .

Quindi, uno sviluppatore non dovrebbe indossare un cappello che non si ecciti, non contribuisca alla crescita personale e porti a massime prestazioni - e ruba tempo ai "cappelli" che fanno queste cose per loro.

Oltre a non essere l'unico a testare il proprio codice, penso che qualsiasi "cappello" sia ok se è un lavoro significativo per lo sviluppatore che indossa il cappello.

Il "designer" o il "ragazzo creativo". Passerai dal mettere insieme innocentemente un mockup dell'interfaccia di un'applicazione alla scrittura di testo di marketing per la prossima campagna pubblicitaria online o discussioni infinite sulla sfumatura "giusta" di blu prima di conoscerla x_x.

quel cappello con le lattine di birra sul lato con una cannuccia. cattiva idea se vieni catturato.

modificare:

Ecco il cappello che odio ma che ha una grande ricompensa - è un grande segno per me che dice che se questa cosa si rompe è tutta colpa tua ... ah, ma se è buono, allora tu figlio mio sei il bravo ragazzo che tutti ti conosciamo sono - ora torna nel seminterrato ... bravo ragazzo ... tutto qui.

Il cappello della colpa.