Risposte:
Jeff Atwood ha The Programmer's Bill of Rights .
Dal post:
- Ogni programmatore deve avere due monitor
- Ogni programmatore deve avere un PC veloce
- Ogni programmatore deve scegliere il mouse e la tastiera
- Ogni programmatore deve avere una sedia comoda
- Ogni programmatore deve disporre di una connessione Internet veloce
- Ogni programmatore deve avere condizioni di lavoro tranquille
Questo sembra avere alcuni elementi che mi piacerebbe vedere nell'elenco di Joel. In particolare nell'area dell'hardware (doppio monitor, PC veloce, mouse / tastiera, sedia comoda, connessione veloce).
L'unica cosa non menzionata è avere una scrivania comoda e regolabile .
Tutto ciò potrebbe essere aggiunto modificando:
Current # 9: Usi i migliori strumenti che il denaro può comprare?
per
Migliorato n. 9: usi gli strumenti e le attrezzature migliori che il denaro possa comprare?
È interessante che il punto 8 ora reciti:
8. Do programmers have quiet working conditions?
quando era solito leggere (qualcosa del genere)
8. Do programmers have their own office?
e l'ultimo paragrafo inizia ancora:
Ora spostiamoli in uffici separati con pareti e porte.
Sono sempre stato sospettoso di questo test in quanto in tutti i posti in cui ho lavorato - sia come dipendente che come visitatore - le uniche persone con i loro uffici sono i direttori e i senior manager.
Scrivere software nel mondo reale è di solito un'attività di gruppo, devi parlare con i tuoi compagni di squadra per far rimbalzare idee ecc. E questo è più difficile da fare con le persone in uffici separati anche con i sistemi di messaggistica istantanea. Essere in grado di disegnare e mostrare codice e diagrammi alle persone aiuta molto. Questo non vuol dire che i team distribuiti non possano funzionare - ovviamente possono e lo fanno, è solo una serie diversa di problemi.
Quello che vorrei dire è che ogni squadra deve essere nel proprio ufficio di 6-8 persone (supponendo che sia la dimensione della squadra). In questo modo possono interagire senza disturbare gli altri team (se ce ne sono) e andare avanti con il loro lavoro senza essere disturbati dal team di vendita o dai visitatori (in un posto in cui ho lavorato sei arrivato direttamente dall'area di sviluppo).
Se stai lavorando con altri sviluppatori, ma ognuno sta lavorando a progetti separati, allora un ufficio condiviso può essere utile - ma solo se sei severo nel prendere riunioni nella sala riunioni e rispettare le scadenze di altre persone ecc.
La maggior parte degli altri sono verità evidenti.
L'unico affare per me è:
8. Do programmers have quiet working conditions?
Interessante è la domanda che molto probabilmente fallirà con le offerte di lavoro di Stack Overflow.
Alcune delle domande sono difficili da fallire, in particolare se c'è più di un programmatore nell'azienda:
1. Do you use source control?
2. Can you make a build in one step?
4. Do you have a bug database?
La maggior parte degli altri non mi interessa davvero. Voglio dire, onestamente:
12. Do you do hallway usability testing?
Ce n'è uno per rilevare i bugiardi:
5. Do you fix bugs before writing new code?
Devo dire che è una buona "base", ma con qualsiasi strumento di misurazione ci sono altri fattori. Ad esempio, non una singola azienda per cui ho lavorato ha realizzato build giornaliere (lo so, lo so), ma alcune sono state molto buone.
Personalmente ho alcuni altri elementi che aggiungerei a un elenco.
Più di ogni altra cosa si tratta di elementi che mi hanno "fatto incazzare" dai precedenti datori di lavoro e che ora sono domande rapide che faccio su ogni singola opportunità.
Sono d'accordo con la maggior parte dei punti di Joel. Non sono così sicuro del "test di usabilità in corridoio". Test di usabilità, certo, ma in realtà afferrare qualcuno dal corridoio e farli testare il tuo programma, anche se non è il loro lavoro? Sembra un ottimo modo per stuzzicare le persone.
Il Joel Test non verifica quanto è brava una squadra. Verifica quanto bene la tua squadra aderisce al Joel Test.
Ecco un test migliore di quanto è brava la tua squadra. Lo chiamo test GrandmasterB. Ha una domanda
1) Il software che scrivi è buono?
Per me è irrilevante se si esegue il "test di corridoio" o meno, o quale controllo del codice sorgente si ha o quale sia il processo di compilazione (se presente, non tutti i linguaggi li hanno). La vera misura di una squadra è la qualità del software che creano.
Fondamentalmente, potresti seguire ogni singolo passaggio del test Joel e finire con codice merda e prodotti che non vengono mai spediti. Ad esempio, il controllo del codice sorgente non rende magicamente uno dei programmatori migliori; semplifica la gestione del codice. E avere l'ultima versione di Visual Studio non significa che la tua applicazione funzionerà meglio che se fosse stata scritta con Visual Studio 2005 .
Anche se penso che abbia un senso in senso generale, ho trovato la lista piuttosto centrata sul tipo specifico di software che Fog Creek Software fa ( termoretraibile ). Non è davvero sorprendente, visto che ne parla anche in un altro post, Five Worlds . E ci sono molti sviluppi al di fuori di quel mondo.
Ci sono alcune condizioni che non hanno molto senso se si sviluppa, ad esempio, un software incorporato per un satellite o un distributore automatico, come build giornaliere (3) o test di usabilità (12).