Réponses:
Jeff Atwood a la Charte des droits du programmeur .
De la poste:
- Chaque programmeur doit avoir deux moniteurs
- Chaque programmeur aura un PC rapide
- Chaque programmeur aura son choix de souris et de clavier
- Chaque programmeur doit avoir une chaise confortable
- Chaque programmeur doit avoir une connexion internet rapide
- Chaque programmeur doit avoir des conditions de travail silencieuses
Cela semble avoir certains éléments que j'aimerais voir sur la liste de Joel. Spécifiquement dans le domaine du matériel (double moniteur, PC rapide, souris / clavier, fauteuil confortable, connexion rapide).
La seule chose qui n’a pas été mentionnée est d’avoir un bureau confortable et réglable .
Tout cela pourrait être ajouté en changeant:
Actuel # 9: Utilisez-vous les meilleurs outils que l’argent peut acheter?
à
Amélioré # 9: Utilisez-vous les meilleurs outils et équipements que l’ argent peut acheter?
Il est intéressant de noter que le point 8 se lit maintenant:
8. Do programmers have quiet working conditions?
quand il lisait (quelque chose comme)
8. Do programmers have their own office?
et le dernier paragraphe commence toujours:
Maintenant, déplaçons-les dans des bureaux séparés avec des murs et des portes.
Je me suis toujours méfié de ce test car, dans tous les endroits où j'ai travaillé - en tant qu'employé et visiteur - les seules personnes ayant leur propre bureau sont les directeurs et les cadres supérieurs.
Écrire un logiciel dans le monde réel est généralement une activité d'équipe. Vous devez parler à vos coéquipiers pour échanger des idées, etc., ce qui est plus difficile à faire avec des personnes se trouvant dans des bureaux distincts, même avec des systèmes de messagerie instantanée. Être capable de dessiner des choses et de montrer aux gens des codes et des diagrammes aide beaucoup. Cela ne veut pas dire que les équipes distribuées ne peuvent pas fonctionner - elles le peuvent et le font, c’est un ensemble de problèmes différent.
Ce que je dirais, c'est que chaque équipe doit être dans son propre bureau de 6 à 8 personnes (en supposant que ce soit la taille de l'équipe). De cette façon, ils peuvent interagir sans déranger les autres équipes (le cas échéant) et poursuivre leur travail sans être dérangés par l'équipe des ventes ou les visiteurs (à un endroit où j'ai travaillé, vous êtes entré directement dans la zone de développement par la porte d'entrée).
Si vous travaillez avec d'autres développeurs, mais que chacun travaille sur des projets distincts, un bureau partagé peut s'avérer utile, mais uniquement si vous êtes strict sur le fait de prendre des réunions dans la salle de réunion et de respecter les délais impartis par d'autres personnes, etc.
La plupart des autres sont des vérités évidentes.
Le seul deal-breaker pour moi est:
8. Do programmers have quiet working conditions?
Intéressant, c’est la question la plus susceptible d’être un échec par l’affichage des offres de débordement de pile.
Certaines des questions sont difficiles à échouer, en particulier s'il y a plus d'un programmeur dans l'entreprise:
1. Do you use source control?
2. Can you make a build in one step?
4. Do you have a bug database?
La plupart des autres ne m'intéressent pas vraiment. Je veux dire, honnêtement:
12. Do you do hallway usability testing?
Il y en a un pour détecter les menteurs:
5. Do you fix bugs before writing new code?
Je dois dire que c'est une bonne "base", mais avec tout outil de mesure, il y a d'autres facteurs. Par exemple, pas une seule société pour laquelle j'ai travaillé n'a fait Daily Builds (je sais, je sais), mais certaines d'entre elles ont été très bonnes.
J'ai personnellement quelques autres éléments à ajouter à une liste.
Plus que tout, ce sont des articles qui m'ont "énervé" des employeurs précédents et, bien, ce sont maintenant des questions rapides que je pose à propos de chaque opportunité.
Je suis d'accord avec la plupart des points de Joel. Je ne suis pas si sûr de "tests d'utilisabilité de couloir". Des tests d’utilisabilité, bien sûr, mais en fait, attrapez une personne dans le couloir pour qu’elle teste votre programme, même si ce n’est pas leur travail? Cela semble être un excellent moyen de cocher les gens.
Le test de Joël ne teste pas la qualité d'une équipe. Il teste à quel point votre équipe adhère au test Joel.
Voici un meilleur test de la qualité de votre équipe. Je l'appelle le test GrandmasterB. Il a une question.
1) Le logiciel que vous écrivez est-il bon?
Peu importe si vous testez un couloir ou non, ou quel contrôle de source vous avez, ou quel est votre processus de construction (s'il en existe un - tous les langues ne les ont pas). La véritable mesure d’une équipe est la qualité du logiciel qu’elle crée.
Fondamentalement, vous pouvez suivre chaque étape du test Joel tout en vous retrouvant avec un code de merde et des produits qui ne sont jamais expédiés. Par exemple, le contrôle de source ne fait pas d'un magicien un meilleur codeur; cela rend le code plus facile à gérer. Et disposer de la dernière version de Visual Studio ne signifie pas que votre application fonctionnera mieux que si elle avait été écrite avec Visual Studio 2005 .
Bien que je pense que cela ait du sens au sens général, j'ai trouvé la liste assez centrée sur le type de logiciel spécifique que Fog Creek Software ( shrinkwrap ) fait. Ce n'est pas vraiment surprenant, car il en parle également dans un autre article, Five Worlds . Et il y a beaucoup de développements en dehors de ce monde.
Certaines conditions n’ont pas vraiment de sens si vous développez, par exemple, un logiciel embarqué pour satellite ou un distributeur automatique, comme des versions quotidiennes (3) ou des tests d’utilisabilité (12).