En bref : Joel Spolsky livre un guide sans détour pour attirer et identifier les meilleurs développeurs. Sa thèse centrale tient en une phrase : les talents exceptionnels ne sont pas légèrement meilleurs que la moyenne, ils sont dix fois plus productifs. Le livre propose des critères concrets pour les repérer et, surtout, pour créer l’environnement qui les fera venir à vous.
Du code Excel au blog le plus lu des développeurs
Joel Spolsky a commencé sa carrière chez Microsoft au début des années 1990. Son terrain de jeu : l’équipe Excel, où il a notamment conçu la stratégie VBA et travaillé sur les spécifications du produit. Cette expérience lui a donné une vision de l’intérieur sur ce qui distingue les équipes de développement performantes des autres.
En 2000, il quitte le confort de Microsoft pour fonder Fog Creek Software à New York. Une petite structure, volontairement. L’objectif n’est pas de devenir le prochain géant du logiciel, mais de créer un environnement de travail idéal pour les développeurs. Le genre d’endroit où lui-même aurait voulu travailler.
Parallèlement, Spolsky lance son blog Joel on Software. Le ton est direct, parfois provocateur. Il parle de code, de management, de recrutement, des absurdités qu’il observe dans l’industrie. Le blog devient une référence. Des millions de développeurs le lisent. Certains articles sont traduits dans plus de trente langues.
De Fog Creek naîtront deux produits qui marqueront l’industrie : Trello, l’outil de gestion de projet que tout le monde connaît aujourd’hui, et Stack Overflow, le site de questions-réponses devenu incontournable pour les développeurs du monde entier. Stack Overflow compte aujourd’hui plus de 100 millions de visiteurs mensuels.
Smart and Gets Things Done, publié en 2007, synthétise ce que Spolsky a appris en recrutant pour Fog Creek. Le livre est court, environ 180 pages. Pas de théorie RH abstraite. Des constats tirés de l’expérience, des erreurs commises, des leçons retenues.
Le mythe du développeur interchangeable
La plupart des entreprises traitent les développeurs comme des ressources interchangeables. Un poste se libère, on publie une annonce, on reçoit des CV, on fait passer des entretiens standardisés, on embauche celui qui coche le plus de cases. Le processus ressemble à celui qu’on utiliserait pour recruter un comptable ou un commercial.
Spolsky affirme que cette approche est fondamentalement erronée. Et il avance un chiffre qui dérange : les meilleurs développeurs ne sont pas 10% ou 20% plus productifs que la moyenne. Ils sont dix fois plus productifs. Parfois plus.
Ce ratio n’est pas une invention. Des études menées depuis les années 1960, notamment par Sackman, Erikson et Grant, ont mesuré des écarts de productivité de 1 à 10 entre développeurs travaillant sur les mêmes tâches. Plus récemment, des recherches chez Microsoft ont confirmé ces ordres de grandeur.
Les implications sont vertigineuses. Si un excellent développeur produit autant que dix développeurs moyens, le coût du mauvais recrutement explose. Vous ne perdez pas simplement un salaire. Vous perdez l’équivalent de neuf salaires en productivité non réalisée.
Pourquoi les entreprises continuent-elles à recruter de façon standard ? Parce que les processus RH ont été conçus pour des postes où les écarts de performance sont linéaires. Parce que les managers non techniques ne savent pas évaluer un développeur. Parce que les annonces d’emploi listent des technologies au lieu de décrire des problèmes à résoudre.
Smart and Gets Things Done : les deux critères qui comptent
Le titre du livre résume la méthode de sélection de Spolsky. Deux critères, pas quinze. Deux questions à se poser après chaque entretien : cette personne est-elle intelligente ? Cette personne livre-t-elle ?
« Smart » ne signifie pas « diplômé d’une grande école » ou « capable de réciter des algorithmes ». Spolsky parle d’une intelligence pratique, la capacité à comprendre rapidement un problème nouveau et à trouver des solutions. Quelqu’un de smart pose les bonnes questions. Il fait des connexions inattendues. Il apprend vite.
« Gets Things Done » est le contrepoids nécessaire. L’industrie ne manque pas de gens brillants qui ne livrent jamais rien. Des perfectionnistes paralysés par la recherche de la solution idéale. Des architectes qui dessinent des systèmes magnifiques sur tableau blanc mais ne produisent pas de code qui fonctionne. Des passionnés de nouvelles technologies qui passent leur temps à expérimenter au lieu de résoudre les problèmes du client.
Spolsky insiste : il faut les deux. Un développeur smart qui ne livre pas est un gouffre à discussions. Un développeur qui livre mais n’est pas smart produira du code médiocre qui coûtera cher à maintenir. Peter Thiel, dans Zero to One, fait une observation similaire sur les startups : la vélocité d’exécution compte autant que la qualité de l’idée.
Comment évaluer ces deux dimensions en entretien ? Spolsky recommande de faire coder les candidats sur des problèmes ouverts, pas des quiz techniques. Observer comment ils réfléchissent, pas seulement ce qu’ils produisent. Leur demander de parler de projets qu’ils ont menés à terme, en creusant les détails pour distinguer les vrais contributeurs des passagers.
Créer un environnement qui attire les talents
Recruter les meilleurs ne suffit pas. Encore faut-il qu’ils aient envie de venir chez vous. Et là, Spolsky est catégorique : les bons développeurs ont le choix. Ils ne viendront pas dans un environnement médiocre, quel que soit le salaire proposé.
C’est dans cet esprit qu’il a créé le « Joel Test », une liste de douze questions pour évaluer la qualité d’une équipe de développement. Utilisez-vous un système de contrôle de version ? Pouvez-vous faire un build en une seule étape ? Avez-vous des testeurs dédiés ? Les candidats écrivent-ils du code pendant l’entretien ? Travaillez-vous dans un environnement calme ?
Chaque « oui » vaut un point. Un score de 12 indique une équipe mature. En dessous de 10, des problèmes sérieux existent. Spolsky affirme que la plupart des équipes qu’il a observées plafonnent entre 2 et 3.
Le test paraît basique aujourd’hui. En 2000, quand Spolsky l’a publié pour la première fois, beaucoup d’équipes ne faisaient pas de builds automatisés, ne corrigeaient pas les bugs avant d’ajouter des fonctionnalités, n’avaient pas de spécifications écrites.
L’idée centrale reste pertinente : les bons développeurs veulent travailler avec de bons outils, dans un environnement qui respecte leur concentration, avec des processus qui ne les ralentissent pas. Jason Fried et David Heinemeier Hansson développent une philosophie similaire dans Rework : la qualité de l’environnement de travail n’est pas un luxe, c’est un avantage compétitif.
Spolsky va plus loin. Chez Fog Creek, il a installé des bureaux privés pour chaque développeur. Pas des open spaces bruyants, des vrais bureaux avec des portes. Son argument : une interruption coûte en moyenne quinze minutes de productivité. Multipliez par le nombre d’interruptions quotidiennes dans un open space, et le calcul devient effrayant.
Les limites de l’approche
Le livre date de 2007. Certains conseils ont mal vieilli.
Le marché du recrutement tech a changé. La compétition pour les talents s’est intensifiée. Les développeurs ont encore plus de pouvoir de négociation qu’à l’époque. Les entreprises ont dû affiner leurs pratiques bien au-delà de ce que Spolsky décrivait.
Le livre parle peu de diversité. Les exemples sont presque exclusivement masculins. Les critères « smart » et « gets things done », présentés comme objectifs, peuvent être influencés par des biais inconscients. Un candidat introverti ou issu d’un parcours non traditionnel peut être mal évalué par des entretiens conçus pour des profils similaires à ceux qui recrutent.
L’approche suppose un lecteur technique ou au moins familier avec le monde du développement. Un dirigeant sans background technique aura du mal à appliquer les conseils directement. Il comprendra les principes, mais ne saura pas forcément quoi observer dans un entretien technique.
Le contexte américain, et plus précisément celui de la Silicon Valley, imprègne tout le livre. Les salaires mentionnés, les pratiques décrites, les attentes des candidats correspondent à un marché spécifique. L’adaptation à d’autres contextes demande un effort de traduction.
Enfin, le livre se concentre sur le recrutement et dit peu du management au quotidien. Comment retenir les talents une fois recrutés ? Comment gérer les conflits dans une équipe de fortes personnalités ? Ces questions restent largement ouvertes.
Ces réserves n’enlèvent rien à l’essentiel. Les principes fondamentaux de Spolsky restent solides : comprendre que les écarts de productivité sont exponentiels, recruter sur l’intelligence et la capacité à livrer, créer un environnement qui attire les meilleurs.
FAQ
CE LIVRE EST-IL ENCORE PERTINENT AUJOURD’HUI ?
Les principes fondamentaux restent valides. Les écarts de productivité entre développeurs n’ont pas disparu. L’importance de l’environnement de travail non plus. Certains exemples et certains conseils pratiques ont vieilli, mais la philosophie générale tient toujours.
FAUT-IL ÊTRE TECHNIQUE POUR APPLIQUER CES CONSEILS ?
Pas nécessairement, mais cela aide. Un dirigeant non technique peut comprendre les principes et déléguer leur application à un CTO ou un lead developer de confiance. Les chapitres sur l’environnement de travail et la culture d’entreprise sont accessibles à tous.
QU’EST-CE QUE LE « JOEL TEST » EXACTEMENT ?
Une liste de douze questions binaires (oui/non) pour évaluer la maturité d’une équipe de développement. Contrôle de version, builds automatisés, environnement calme, correction des bugs avant ajout de fonctionnalités, etc. Le score maximum est 12. La plupart des équipes obtiennent entre 2 et 3.
LE LIVRE TRAITE-T-IL DU MANAGEMENT D’ÉQUIPE ?
Marginalement. Le focus est sur le recrutement et l’attraction des talents. Le management quotidien, la rétention, la gestion des conflits ne sont pas couverts en profondeur. Pour ces sujets, d’autres ressources seront nécessaires.
JOEL SPOLSKY A-T-IL ÉCRIT D’AUTRES LIVRES ?
Oui. Joel on Software (2004) compile les meilleurs articles de son blog. More Joel on Software (2008) poursuit la compilation. User Interface Design for Programmers (2001) traite de l’ergonomie logicielle. Tous sont tirés de son expérience pratique chez Microsoft puis Fog Creek.
LE LIVRE EXISTE-T-IL EN FRANÇAIS ?
Non. Smart and Gets Things Done n’a pas été traduit en français. Il est disponible uniquement en anglais. Le niveau de langue reste accessible pour un lecteur intermédiaire, le style de Spolsky étant direct et peu jargonnant.
