fplanque: Techno

Ed Yourdon décortique le personnage du superpogrammeur dans un article de 1976 qui n'a pas pris une ride!


Voici quelques uns de mes passages préférés à propos des méthodes de travail des superprogrammeurs:

Isolate yourself from the distractions normally found in an office. It is extremely difficult carrying out superprogrammer activities in a typical commercial "bullpen" office. This may require you to work at night or to work at home -- neither or which will make you popular with your management.

Make sure you are calm and rested and then work straight through until you have finished the project. This implies, of course, that the project is not very large. Nevertheless, I have watched several superprogrammers work 24, 36, and even 54 hours until they have finished coding a program, at which point they drop from exhaustion. After a good night's sleep, they spend another 54 hours getting the program to work -- and then take a week off.

Spread your papers -- especially your coding sheets -- out on a large table so you can see everything you have done as you write the code. Even better, paste the program up on a wall as you write it. This will allow you to see the entire program as your write it, so you can see if you've forgotten anything and so you can see how everything fits together.

Tout cela m'évoque des souvenirs sympathiques d'une époque lointaine... mais ce qui m'intéresserait dans l'immédiat c'est d'avoir l'avis de Cédric. Pour sûr, il ne s'agit pas ici de software engineering dans les règles... mais faut-il pourtant se passer des gains de productivité énormes qu'on peut obtenir en confiant un développement à un superprogrammeur? :

While the phrase superprogrammer is apparently being replaced by the phrase chief programmer, it is still recognized that there are programmers in the industry -- and always will be -- who at least an order of magnitude better than the average programmer.

Encore une petite, juste pour le plaisir:

There is another phenomenon that is enormously important if one is to understand the personality of a superprogrammer: most of them reach a critical age (usually 30, plus or minus a couple of years) when they decide that they should grow up and do something constructive with their lives, rather than just playing games in a computer room. As a result, we have seen a number of brilliant superprogrammers throw it all away by becoming a manager (ugh!), getting married, having a baby, or deciding to become a farmer. Conversely, those superprogrammers who do not make such a radical change at the age of 30 are often those who, because of their personality, are totally unable to do so. Hence, it should not surprise us that many of the established superprogrammers are freaks in some sense of the word: they look funny; they wear funny clothes; they refuse to work regular hours; they don't get along with normal people; and so forth.

L'évolution de l'informatique est une longue histoire ponctuée de tentatives d'abstraction successives destinées à manipuler les éléments de base avec des méthodes de plus en plus haut niveau. Le problème, c'est qu'aucune de ces abstractions, quelle qu'elle soit (TCP, NFS, la mémoire virtuelle, les classes String...) n'a jamais réussi à masquer complètement ce sur quoi elle repose et l'informaticien (développeur, administrateur, architecte...) ne peut toujours pas se passer d'apprendre tout depuis la base... tout depuis 0 et 1!

Joel on Software explique pourquoi dans The Law of Leaky Abstractions.