Êtes-vous le pirate informatique ou êtes-vous l'académique?

Au cours de mes 18 années de carrière en tant que programmeur, j'ai travaillé sur des dizaines de projets différents, allant de la robotique à la finance en passant par la santé et les télécommunications. Et j’ai eu l’occasion de travailler avec des centaines de programmeurs de tous les horizons, chacun ayant ses propres habitudes et attitudes.

J'ai appris que peu importe d'où ils viennent ou ce qu'ils font, tous les programmeurs se situent quelque part dans ce spectre:

L'académique

À une extrémité du spectre se trouvent les programmeurs qui sont férus de théorie. Ils aiment apprendre, lire, explorer et innover. Pour eux, chaque ligne de code est une contribution au monde, un héritage pour l'avenir même. S'il y a une faille dans le code, c'est parce qu'ils ne le savent pas encore.

Dans leur monde, le code doit être parfait, sans bug et conformément aux meilleures pratiques. Ils apprécient les façons intelligentes de faire les choses et aiment se tenir au courant des dernières technologies.

Malheureusement, les universitaires s’ennuieront lorsque l’apprentissage cessera et rechercheront d’autres projets - voire changeront de travail:

L'inconvénient de cette façon de travailler est que les projets avancent lentement. Lorsque vous apprenez quelque chose, vous avez aussi tendance à tomber sur quelque chose que vous aimeriez apprendre. Et ce cycle de descente dans les trous de lapin peut durer un bon bout de temps avant que des fonctionnalités significatives ne soient livrées:

Mais tout n’est pas mauvais. Lorsque le produit doit respecter des normes élevées, le monde académique est en fait le bon type de programmeur.

Par exemple, pour les logiciels de santé, la sécurité des patients est extrêmement importante. Vous voulez que vos programmeurs prennent leur temps et découvrent leurs bases avant d’insérer du code dans «l’environnement de production» qu'est la vie des gens.

Même un petit bug peut être fatal.

Un autre exemple est le secteur financier, où une simple erreur peut coûter cher. C'est également le cas de la plupart des logiciels de sécurité ou exigeants en matière de sécurité, où la réputation de l'entreprise est souvent en jeu.

Le pirate

Le pirate informatique se trouve à l'autre extrémité du spectre. Il est le «travailleur du savoir» idéal selon Deep Work de Cal Newport. Les pirates informatiques apprennent vite et (idéalement) fournissent des résultats à un rythme constant. Ils disent rarement «non» à une demande de fonctionnalité et l'inséreront d'une manière ou d'une autre dans le code.

Mais après un certain temps, le code devient incomplet. Le processus est encrassé au point que l'ajout de nouvelles fonctionnalités peut endommager un autre code qui devrait normalement fonctionner:

La dette technique s'accumule et l'entreprise en pâtit à long terme.

Ces programmeurs sont les candidats parfaits pour des emplois de consultant, dans lesquels le projet est mis en œuvre à la vitesse de la tâche. Ils peuvent même être payés pour réparer les défauts qu'ils ont mis dans le code! Bon pour le cabinet de conseil, mauvais pour votre entreprise. Sauf si, bien sûr, vous vous trouvez dans la phase de prototypage ou de validation du concept du développement du produit, une grande partie du code risque d'être réécrite.

Le pirate informatique est idéal pour les startups qui se trouvent au début du stade de développement du produit minimum viable. Le pirate informatique peut rapidement générer des résultats. Ils apportent le meilleur rapport qualité-prix (en argent et en temps). Dans ces situations, l’universitaire paralyserait le développement.

Conclusion

Il y a une blague qui va comme ceci:

Mais en réalité, il y a deux types de faiseurs:

Le pirate

Le pirate informatique peut faire le travail rapidement et à moindre coût, sans se soucier de la qualité. Ce ne sera pas bon marché à long terme, compte tenu de tous les coûts de maintenance.

L’universitaire met l’accent sur la qualité, mais les choses évolueront très lentement et il en coûtera certainement plus pour obtenir des résultats tangibles. De plus, quand ils s'ennuient, ils peuvent imposer encore plus de coûts au projet en partant - ou pire en restant - ne se sentant pas passionnés par leur travail.

L'académique

Le hacker et l’universitaire sont deux extrêmes du spectre et, en réalité, la plupart des programmeurs se situent quelque part entre les deux. Il est important de sélectionner les bons développeurs pour votre projet et le type de logiciel spécifique que vous construisez.

Dans l’idéal, vous pouvez commencer un projet avec le pirate, tandis que l’universitaire peut s’asseoir sur la banquette arrière, affûtant ses sabres lorsque le produit devient un hit et nécessite une refactorisation importante.

De plus, les gens ne sont pas fabriqués dans des usines. Ils peuvent changer. Certains des développeurs les plus intelligents que j'ai rencontrés peuvent basculer entre pirate informatique et universitaire en fonction du stade du projet. C’est une compétence en or que de nombreux développeurs cultivent au fil des ans.

Si vous lisez ce que vous lisez, partagez-le et suivez-moi pour rester au courant des derniers essais. Consultez également mes deux autres essais populaires:

  • Quelle est l'écriture de code terrible?
  • La programmation est le meilleur travail de tous les temps

Déni de responsabilité: tous les avis sont les miens, je ne représente aucune société ou entreprise.

Mise à jour: après avoir partagé cet article, j'ai reçu quelques bons commentaires qui méritent d'être partagés:

Les «universitaires» apprendront des choses une fois [mais] les appliqueront plusieurs fois. Le "pirate informatique" n'apprendra jamais. Ainsi, le graphique des «fonctionnalités livrées» ne s'applique que lorsqu'il est confronté à une plate-forme / pile / framework. La deuxième fois, l '"universitaire" laissera le "pirate informatique" dans la poussière.
Je suis tout à fait d’accord avec votre séparation entre les universitaires qui sont plus axés sur la «correction» et les pirates informatiques qui se concentrent sur «faire avancer les choses» J'appartiens plus près de ce dernier groupe et j'ai eu une collaboration extrêmement fructueuse avec un collègue plus orienté vers le monde universitaire. Moi seul peux faire beaucoup de merde, mais ça ne veut pas dire que c'est du code sympa. De son côté, il peut encore faire beaucoup de choses, mais passera réellement le temps à bien faire les choses. Je vois également une différence dans la façon dont les problèmes sont abordés. Il lisait les solutions connexes avant de concevoir la solution, où je voudrais au lieu de lire, expérimenter différentes solutions. Mon chemin donne des résultats plus rapides, tandis que ses résultats donnent de meilleures solutions. La combinaison de ces éléments crée une journée de travail très productive et intéressante.

Vous avez aimé ce que vous avez lu? Suivez-moi pour être averti lorsque j'écris quelque chose de nouveau.