[Traduction] Chanceux d’être un développeur

L’article qui suit est une traduction d’un article intitulé : « Lucky to be a Programmer » publié par Gustavo Duartes sur son blog, le 14 juillet 2008. Les liens sont ceux d’origine et proposent donc un contenu en anglais, les mises en valeur (gras et italique) sont les miennes.

J’ai aimé l’enthousiasme de Gustavo et sa vision de la programmation.

Merci à Cécile Villemant de la Faculty of Life Sciences de Manchester, et à ses collègues pour l’aide sur les parties concernant la Biologie et les histoires de gènes.
Vous aussi, vous aimez le zen of coding ? L’état de sérénité qu’on atteint quand on développe  ?
Vous aussi pensez que coder, c’est créatif et rigoureux, scientifique et artistique ?

Durant les semaines passées, j’ai travaillé avec un collègue développeur sur un projet qui nécessitait une grosse dose de programmation. C’est maintenant terminé, et nous sommes repartis sur notre emploi du temps habituel mais quand les gens apprennent nos horaires dingues, ils ont souvent pitié de nous. Ils ne devraient pas. Je ne ferais pas cela tous les jours, ou sur des longues périodes, ou sans aucune compensation, si je le fais pour un employeur, mais en réalité, ces séances intensives de programmation sont mes périodes préférées dans la vie. Avec les conditions idéales, écrire des logiciel procure un plaisir si intense, que cela devrait être illégal.

Beaucoup de développeurs connaissent cet état, mais les autres reculent quand ils entendent ça. Je pense que c’est parce que beaucoup d’institutions excellent à retirer le plaisir de toute chose. C’est flagrant, par exemple, comme les écoles peuvent se saisir des sujets les plus passionnants et les rendre sous une forme académique et ennuyeuse. Même la programmation. Beaucoup d’enseignements transforment une expérience enrichissante en quelque chose que les gens acceptent de ne faire que s’ils sont payés.

C’est trop bête. Peu de choses sont  plus agréables que de passer du temps sur son nuage créatif, assailli par des idées, en regardant votre travail prendre forme, aller se coucher tendu et se réveiller rapidement, et essayer de nouvelles idées. Je ne suggère pas que les heures excessives sont nécessaires ou encore conseillées ; un emploi du temps sain est le mieux, sauf pour des excès occasionnels. Le fait est que programmer est un plaisir créatif intense, un mélange parfait entre le casse-tête, l’écriture et le bricolage.

Programmer offre des défis de haut niveau et laisse beaucoup de place pour l’invention. Quelques problèmes sont  de la recherche et de la déduction : « pourquoi le code tourne aussi lentement ? Qu’est-ce qui peut diable causer ce bug ? » Les autres sont constructifs, comme modéliser des algorithmes et architectures. Tous sont un délice si vous aimez l’analyse, être immergé dans un monde plein de monstres, comme les malwares, les routeurs, le cache, les protocoles, les bases de données, les graphes et les nombres.

Ce côté analytique est celui que la plupart des gens associent à la programmation. Cela la rend intéressante, comme un jeu de stratégie complexe. Mais dans la plupart des logiciels, le premier défi est la communication : avec les pairs par le code et avec les utilisateurs par les interfaces. En gros, écrire du code est plutôt un essai qu’un problème de maths. C’est donner forme à vos idées et concepts en un tout cohérent ; cela demande de la clarté, de la simplicité et de la concision. Coder et créer des interfaces sont liés à la joie de la création.

Une autre source de plaisir est que, sous certaines conditions, la beauté émerge de la programmation. Cela peut ressembler à des conneries, mais c’est réel, c’est ce qui rend votre journée meilleure. Prenez par exemple la démonstration de 2 lignes d’Euclide prouvant que les nombres premiers sont infinis. Je pense que beaucoup trouveront cela merveilleux – un résultat si court et si fascinant. C’est la beauté des maths, froides et austères, et cela fonctionne aussi pour le développement. Ce sont les algorithmes astucieux comme quicksort, dans les sources des noyaux et compilateur, ce sont les exploits élégants et les trucs que nous utilisons pour résoudre les problèmes de tous les jours. Quand vous voyez ces solutions, que ce soit un algorithme connu ou une astuce exclusive, vous souriez et vous pensez « comme c’est classe » et vous vous sentez bien. How noble in reason!

Une beauté non-mathématique existe également dans le code, qui rejoint l’éloquence dans le discours. C’est présent dans les logiciels bien écrits qui font beaucoup avec peu de code, dans des fonctions courtes et concises, avec des architectures bien pensées. Quelques langages rendent cela difficile, et les développeurs ne codent pas ainsi, mais c’est une joie de lire et travailler sur un tel code. Si vous travaillez avec un langage expressif avec des collègues qui codent d’une manière agréable, cela arrive assez souvent pour vous rendre heureux.

Maintenant, parlons du bricolage. Dans un sens, le développement est abstrait – où le programme existe-t-il à part dans nos esprits ? Cependant nous appelons cela « fabriquer des logiciels » pour une raison. Les logiciels sont créés fonctionnalité après fonctionnalité, les architectures démarrent  et grandissent, les interfaces utilisateur s’y ajoutent, les bugs sont réparés et les points durs sont optimisés pour rendre les choses plus rapide. Le développement procure un sentiment profondément satisfaisant de travail manuel. Nous construisons des choses depuis des idées et ensuite nous les regardons travailler à résoudre des problèmes réels et à rendre la vie des gens meilleure. Ou loin de cela, selon le cas.

Prenez la biologie. Malgré environ 400 années de révolution scientifique, la biologie a été incapable de livrer la solution à des problèmes cruciaux comme les infections virales ou le cancer. Certains de nos meilleurs progrès, comme les antibiotiques, ont été trouvés par hasard et par des expériences empiriques. Vous démarrez un essai clinique pour le traitement de l’hypertension quand soudain – waouh – tous vos sujets ont des érections ! Le Viagra est né. Il est certain que le hasard jour un rôle dans toutes les découvertes, mais la physique et la chimie ont une théorie systématique des améliorations, alors que la biologie a été grandement confinée à de la bidouille. Vous voulez traiter le cancer ? Ok, bombardez le patient avec des radiations et du poison et espérons que le cancer meure le premier. Ce sont des bidouilles géniales, et je suis heureux de les avoir, mais c’est loin de la précision qu’on peut rencontrer ailleurs.

Le développement modifie cela. Il y a seulement 50 ans, la structure de l’ADN était découverte, mais maintenant n’importe qui peut parcourir et télécharger des centaines de séquences génomiques complètes. Ou regarder des milliers de gènes (DLEC1 est un exemple au hasard), complets avec la séquence nucléotidique, la séquence en acides aminés pour les protéines exprimées, la littérature mentionnant le gène, et bien d’autres choses ! Ou vous pouvez chercher dans de vastes bases de données génétiques et protéiques des séquences nucléotidiques ou d’acides amines, peut-être après avoir séquencé quelque chose dans des appareils toujours moins chers, et obtenir un rapport complet sur le profil correspondant. Il n’est pas important que la correspondance soit exacte, car l’algorithme de BLAST, l’outil standard de recherche de séquence, donne des correspondances partielles parmi différentes bases de données et espèces, en indiquant le taux de correspondance. Ces avancéess vont permettre des découvertes majeures en médecine. La biologie entre dans une nouvelle ère, comme la physique au 18ème siècle, propulsée par le développement logiciel.

Oui, bien entendu, les biologistes ont un rôle mineur, mais l’informatique augmente la possibilité de développements majeurs dans la science, la culture et le business. Quand un enfant du Tiers Monde lit un article Wikipédia, c’est notre boulot aussi ! Nous écrivons des RFCs et les piles réseaux, le navigateur et MediaWiki, les OS et les serveurs HTTP. Sans parler des articles de Wikipedia, mais puisque quelques uns sont sur leur temps de travail je laisse cela de côté.  L’influence des technologistes va au delà des octets et du numérique : c’était un développeur qui a inventé les wikis et notre communauté qui a démarré les blogs. Henry Mencken souligne avec justesse que « la liberté de la presse est limité à celle de ceux qui la possèdent ». C’est dommage qu’il ne soit pas là pour voir nos créations briser la conformité  et la douce soumission du journalisme professionnel. Moins glamour, mais grand avantage, nos applications ont livré des gains de productivité significatifs pour les entreprises de l’économie. Ce ne sont que quelques exemples d’une longue liste.

Il y a deux ans, quand j’ai terminé mon premier cycle (après avoir été un développeur durant des années), j’étais sur le point d’entrer en école de médecine. A ce moment, quelques expériences négatives m’avaient refroidi du travail sur ordinateur. Je suis content de m’être accroché. Je suis toujours intéressé par la recherche biomédicale, mais si j’avais voulu en être, j’aurais mieux fait d’attaquer par l’angle informatique, parce que, franchement, c’est trop de plaisir. Ma mère pense que je suis un dactylo, mais bon.

Si vous vous trouvez coincez dans un endroit qui tue votre passion inné de la technologie, par tous les moyens, barrez vous ! Ne restez pas en place tandis que votre enthousiasme s’épuise lentement. C’est difficile de trouver des gens motivés à embaucher donc vous avez déjà un atout majeur ; il y a plein d’employeurs – et d’entreprises à créer – qui iront mieux pour vous. Pour les gens qui pensent qu’ils pourraient aimer programmer, votre déplacement peut varier, mais je le recommande vraiment en tant que métier. Non seulement les perspectives optimistes sur le front de l’emploi, mais aussi le rôle du logiciel qui croît dans la société fait que nous verrons de plus en plus de d’excitation et de changement bénéfiques induits par la technologie. Je suis ravi d’être dans la course avec mon art et bricolage que je tente de maîtriser.

Je rappelle que je partage ces opinions en grande partie, mais que ce ne sont pas mes écrits.

Publicité

YAP : créez vos applications Yahoo!

Mercredi soir, j’ai assisté à une présentation de YAP : Yahoo! Application Platform.

Pour résumer, vous connaissez les applications Facebook ? Ou les Widgets d’Opera ?
C’est le même principe, vous créez des applications pour les utilisateurs Yahoo!

Yahoo App Platform logo

Ce que vous ferez, utilitaire, inutilitaire, jeu ou portage d’une application n’est pas le propos, pour le moment, il s’agit de la plate-forme qui vous permet de réaliser une application.

Voici une présentation succinte de ce que j’ai compris hier soir, je n’ai pas encore eu l’occasion de tester en créant mon application, soyez indulgents avec les coquilles potentielles.

Quel est le principe ?

Pour le moment, il n’y a pas encore de Gallery ou de catalogue des Y!Apps, cela reste donc un peu confidentiel (bien que Yahoo! communique dessus depuis octobre 2008 comme en témoigne ce billet chez Fred Cavazza).
Les utilisateurs de Yahoo! (e-mail, groupes, news, etc.) pourront ajouter à leur page leurs applications – on reste sur le même modèle que Facebook pour le coup. Cela comprend aussi ceux qui bénéficient de la Yahoo! Toolbar dans leur navigateur.

Les applications sont cachés sur les serveurs de Yahoo! pour éviter d’impacter sur votre charge serveur, mais surtout pour ne pas dépendre de vos performances.
De plus, les applications passent par Caja[1], qui ne laisse pas les mauvaises pratiques passer (HTML, CSS et Javascript) pour augmenter la qualité des applications et surtout la sécurité pour les utilisateurs.

Quelles technos ?

Vous pouvez très bien utiliser la stack LAMP + du Javascript pour votre application, vous pouvez aussi utiliser le YML (Yahoo! Markup Language) pour coder votre application.
Les SDK habituels sont également utilisables.

Quelles contraintes ?

Les applications sont dans une iframe, vous ne pourrez donc pas accéder au ou au de l’application.

Comment faire son application ?

En gros, vous créez votre application, soit en PHP chez vous, soit uniquement via le YML, vous la testez sur la plate-forme, et vous la soumettez à l’assurance qualité qui la validera.
Voilà pour le workflow !

Un très bon exemple de conception d’application est présenté…sur le blog de Yahoo! Developer Network : si vous voulez suivre cela de plus près, consultez le portage de Whaddyathink de MySpace à YAP.

Pour les spécs détaillées, la documentation est riche, donc je vous invite à la consulter (ou RTFM). Voici les quelques informations supplémentaires que j’ai glané hier soir.

Référencer son application

Même si le catalogue n’est pas encore en activité, pour que votre application soit trouvable, il vaut mieux remplir tous les champs de description.
Notamment le champ langue, par exemple.

YML ou application PHP ?

Le PHP vous permettra d’être plus fin sur le traitement de ressources externes, mais le YML vous permettra, malgré ses limites pour une application complète, de gérer les inclusions d’Ajax.

Charge sur les images

Christian Hellman nous conseille de positionner les images sur Flickr pour bénéficier de la performance de ce service.

Bref, je vais explorer un peu plus avant cette techno et ses possibilités pour vous faire un compte-rendu.

[1] : Je prépare aussi un article sur Caja

Ce que j’aimerais faire avec WordPress

Si quelqu’un se sent de traduire en anglais cet article (pour Ma.tt), qu’il se sente libre de le faire.
J’aimerais beaucoup avec WordPress pouvoir poster un billet par SMS. Pas avec l’iPhone que je n’ai pas, non, avec un simple téléphone.
Je sais qu’actuellement les SMS sont payants en France, mais surtout il n’y a pas de surcoût pour les envoyer à l’étranger.
Pourquoi j’aimerais le faire « avec WordPress » ?
J’ai confiance dans cette plate-forme, et je ne souhaite pas utiliser un plugin, qui dépendrait de son auteur pour les mises à jour et l’évolutivité.

PHPFrance relooke son forum

Depuis quelques années, je fréquente le forum de PHPFrance. Les discussions techniques ont pris peu à peu un tour convivial, et je fais partie maintenant de l’équipe de modération du forum.
Les cordonniers sont les plus mal chaussés, paraît-il, mais nous avions envie de moderniser notre espace de discussion, qui accueille chaque jour des développeurs débutants, et des développeurs plus avancés en PHP qui ont besoin d’aide.

Après quelques années de fonctionnement comme sur des roulettes, l’envie de changer la déco nous titillait, et c’est @rthur qui a oeuvré pour refaire le logo et changer la maquette du forum. Merci @rthur !

nouveau look PHPFrance

Nous avons voulu mettre en avant des parties, qui sont dans le forum mais qui font la force du site PHPFrance :

Comme je l’ai déjà dit de visu à ceux que j’ai croisé, le gros atout du forum PHPFrance est sa réactivité : des membres sont connectés en permanence et vous permettent d’avoir rapidement une réponse. Allez donc y faire un tour !

edit : à la demande de J0k sur Twitter, voici un aperçu de la version précédente (un simple PHPBB au niveau du design, mais complètement modifié au niveau fonctionnalités).

vieux design PHPFrance

Les 5 qualités d’un développpeur très efficace : passion (5/5)

Voici la troisième partie de la publication en 5 parties de la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.

Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :

  1. Humilité
  2. Aimer apprendre (2e partie)
  3. Amour du détail (3e partie)
  4. Adaptabilité (4e partie)
  5. Passion (5e partie)

–‬

Passion

Je pense que la passion est avec l’humilité la chose la plus importante. C’est si fondamental que sans, le reste ne compte pas.

Chacun peut le faire en amateur, mais un seul d’entre vous a pris l’engagement, votre sang doit avoir une particularité en lui, que c’est si difficile pour les gens de vous arrêter. – Bill Cosby.

C’est aussi le point difficile à développer. Je ne suis pas certain de ce qui en fait partie ou non. Dans mon propre cas, je pense que ma passion s’est développé à un très jeune âge. Elle est là depuis aussi longtemps que je me souvienne, même s’il y a eu des périodes avec peu de choses réaliseés.

J’ai reçu en entretien des centaines de développeurs potentiels, et c’est la seule chose qui manque de façon récurrente. Tant d’entre eux sont là juste pour un emploi en plus sur le CV. Si c’est tout ce qui vous intéresse, un boulot qui paye vos factures, prenez un emploi alimentaire. (Bien entendu, je me demande, en ce cas, pourquoi vous lisez cet article ?)

Une personne passionnée est meilleure que quarante personne juste intéressées. – E. M .Forster

Il y a une différence énorme entre quelqu’un qui programme juste et quelqu’un qui aime programmer. Celui qui programme seulement ne sera probablement pas au courant des derniers outils, des dernières pratiques, techniques ou technologies, qui débarquent tous les jours. Ils ne penseront pas à programmer en dehors de leurs heures de travail. Durant les week-end, ils feront de leur mieux pour oublier leur ordinateur. Ils n’ont pas de projets personnels, pas de technologies préférées, pas de blogs qu’ils aiment lire, et rien ne les pousse à exceller.Ils ont du mal à apprendre de nouvelles choses et peuvent être un fardeau pour une équipe de développement.

Ok, c’est peut-être un peu exagéré, mais en listant les opposés, c’est facile de voir les symptômes de quelqu’un qui est passioné :

  • Pense et respire technologie
  • Lit des blogs sur le développement
  • Lit des livres sur le développement
  • Tient un blog sur le développement
  • A des projets personnels
  • Ces projets personnels sont plus importants que les choses ennuyeuses du boulot
  • Reste à jour des dernières technologies par intérêt
  • Pousse à l’implémentation des dernières technologies (pas aveuglément, bien sûr)
  • Va en profondeur dans les problèmes techniques
  • Ne se contente pas de coder les spécifs
  • A besoin d’un exutoire créatif, que ce soit professionnel (création de logiciels) ou personnel (musique, maquettisme, LEGO, art, etc.)
  • Pense le monde en termes Star Trek

Je plaisante pour le dernier…
…(peut-être)

Conclusion

C’est ma liste. Cela m’a pris quelques mois pour l’écrire, et j’espère qu’elle sera utile à quelqu’un, particulièrement les jeunes ingénieurs informaticiens qui commencent. C’est un secteur difficile, mais cela doit être également amusant. Apprendre à posséder ces qualités, modifier votre état d’esprit, et consciemment décider de devenir l’ingénieur et le développeur que vous voulez être sont les premiers pas. Et également une partie des étapes suivantes.

Personne n’est né avec ces qualités, et on peut les développer, pratiquer et aiguiser jusqu’à la perfection durant toute une vie. Il n’y a pas de meilleur moment pour commencer que maintenant.

Bon cela m’a pris quelques mois pour la traduire aussi, car cette série est riche et réfléchie.

[Traduction] 8 façons de décourager vos employés

Entre deux chapitres de la longue traduction en 5 volumes des qualités d’un développeur, voici un article plus court paru sur le site geekstuffdaily.com, le 12 mars 2009, sous le titre «8 rules to discourage your employees».
Il a obtenu 52 commentaires sur son site, il mérite donc d’être mentionné ici, et au moins traduit.


Si vous voulez emmerder vos employés, mais que vous ne trouvez pas de bonne manière de le faire, suivez ces quelques règles et vous y arriverez.

  1. Encouragez la pro-activité

    Le management aime ce mot. Cela signifie que les employés n’ont pas à réagir, mais doivent agir en avance. Cela se traduit par un management beaucoup plus facile. Pas de documentation, de specs ou aucune sorte d’information n’est fournie aux employés puisqu’ils doivent proactivement chercher ces informations.
    Découragez la pro-activité excessive : si quelques employés veulent encore faire des choses par eux-même, essayez de documenter les choses pour abaisser la courbe d’apprentissage de vos (futurs) recrutements, développez un outil maison pour (vous) économiser du temps ou de l’argent ou pour faire des choses comme ré-usiner le code ou implémenter des méthodes agiles, simplement claquez ces enthousiastes en traitant ses efforts avec indifférence, règles d’entreprises, manque de retour du management et autres outils dont vous disposez.
    Déjouez simplement les suggestions ou améliorations ; dites même non directement, ou dites oui, oui, oui et laissez mourir à petit feu. Toutes les méthodes fonctionnent bien.

  2. Ne laissez pas vos employés s’impliquer

    Ne promouvez jamais aucun ancien de l’équipe, qui serait apte à cette tâche à une position de chef de projet.
    Les choses pourraient être trop douces, puisque la personne ne peut pas seulement diriger correctement l’équipe mais elle aura aussi une compréhension profonde du sujet à traiter.
    Embauchez simplement quelqu’un de l’extérieur qui ne connaît que le management (trimballer un agenda en cuir et/ou un iPhone, oragniser des réunions, parler sur des sujets sans avoir aucune connaissance, sans dire des choses cohérente ou qui paraissent sérieuses, etc.) Le moins le chef de projet en sait sur l’équipe, le mieux c’est. Après tout, ce sont les soldats qui doivent recevoir des balles.

  3. Distribuez des récompenses

    Avant que vous ne pensiez que cela ne puisse remonter le moral de quelqu’un, pensez aux autres membres de l’équipe (et aux autres équipes) qui n’en auront pas. C’est tout bête : un moral remonté, les autres plongent.
    Récompensez les gens qui le méritent le moins : ceux qui passent leur temps à parler de leur super boulot au lieu de vraiment faire quelque chose. Cela énervera définitivement tous les autres.

  4. Restreignez leurs outils

    Si vos employés ont besoin d’outils, comme un ordinateur, un OS, une base de données, et quelques outils pour mieux travailler, la meilleure chose à faire est de les en priver ; pas tous à la fois, mais un par un, pour rallonger leur agonie. S’ils ont besoin d’outils payants, déclarez les hors-budget. S’ils ont besoin d’outils open-source, dites que ce n’est pas compatible avec la règle interne X et que cela requiert des autorisations spéciales (qu’ils n’auront jamais, bien entendu).
    Faites leur remplir des formulaires sans fin et inutiles, et rédiger des e-mails. Ne renouvelez pas leurs licences. Faites les travailler en ligne sur un serveur placé sur un autre continent avec plus de 10 secondes de latence. Interdisez l’utilisation de putty comme console de travail. Faites tout cela étape par étape, tout en demandant des résultats constants.

  5. Gâchez leur concentration

    Soyez certains qu’ils sont inscrits sur toutes les mailing-listes sans rapport possible. Vous leur ferez perdre des heures à lire leurs messages et à faire du filtrage manuel. Retirez toute couche d’abstraction qui permettrait de leur épargner un problème qui ne les concerneraient pas. Votre meilleure arme ici est l’open space (comme un étage entier) où plus de 100 personnes travaillent, sans murs au milieu.
    Encouragez les sonneries de téléphone très fortes des portables abandonnés sur les bureaux et les discussions de machine à café pour distraire les autres. Organisez des réunions inutiles et des conférences-call qui se concentrent sur des sujets qui ne les concernent pas.

  6. Abattez leurs intérêts avec des formations

    Donnez leur des formations obligatoires sur des sujets qui ne les intéressent pas et qui n’ont pas de connexion inter-disciplinaire avec leur métier.

  7. Virussez les !

    Soyez sûrs que toutes les imperfections sont soigneusement classées en priorité haute. Si quelqu’un casse le code (particulièrement si quelqu’un le casse de façon répétée), ne le laissez pas réparer. Demandez à quelqu’un d’autre à la place (de préférence s’il n’a pas de passif avec le sujet) de le réparer dans un laps de temps très court.
    Laissez tout le monde assigner des bugs à n’importe qui, sans savoir le temps restant dont disposent les développeurs. Plutôt avec un système qui ne laisse pas la possibilité de savoir qui vous a assigné un ticket.

Avant de penser que cela ne fonctionne pas, sachez que c’est basé sur une histoire vraie (cela m’est arrivé).

Edit : Comme l’ont fait remarquer de nombreuses personnes (et elles ont raison) tous les développeurs expérimentés ne font pas des bons chefs de projet (la plupart n’ont pas les compétences). Pour rectifier cela, j’ai mis à jour la règle 3. Merci de ces retours !

Les 5 qualités d’un développpeur très efficace : adaptabilité (4/5)

Voici la troisième partie de la publication en 5 parties de la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.

Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :

  1. Humilité
  2. Aimer apprendre (2e partie)
  3. Amour du détail (3e partie)
  4. Adaptabilité  (4e partie)
  5. Passion (5e partie)

–‬

Adaptabilité

« Profiter du succès requiert une capacité d’adaptation. C’est seulement être ouvert au changement qui fera que vous aurez une vraie opportunité d’obtenir le meilleur de votre talent. » Nolan Ryan

Des modifications arrivent. Soyez préparés à cela. Ce qui est difficile pour moi, à dire vrai. J’ai vraiment réellement un plan, que je suis et je l’adapte à mes besoins, non pas à celui des autres.
Les faits sont que dans le développement, le projet que vous venez de finir d’écrire ne sera pas celui que vous démarrerez. Ce changement peut être frustrant si vous ne savez pas comment le gérer.

Pour devenir adaptable, il faut d’abord opérer un changement d’esprit. Cet esprit est de penser que le changement est inévitable, ce n’est pas grave, et vous êtes prêts pour cela. Comment vous êtes devenu prêt ? C’est une autre histoire, et j’y consacrerais probablement un autre article.

En plus de votre esprit, commencez à utiliser des techniques et technologies qui vous laissent faire des changements facilement. Les choses comme les tests unitaires, la couverture de code, le réusinage (ndt :refactoring) permettent des modificiations plus faciles du code.

A la guerre comme dans la vie, c’est souvent nécessaire quand un plan prévu a échoué de prendre la meilleur alternative, et en ce cas, c’est de la folie de ne pas faire tout ce que vous pouvez.
Winston Churchill

Pour moi, la première étape, pour changer mon esprit est de ne pas être frustré chaque fois que les choses changent. (« Mais vous aviez dit que nous n’allions pas implémenter la fonctionnalité de cette manière! ».)

Là, je crois que tous ceux qui travaillent sur du développement web ont acquis de gré ou de force cette qualité.

Les 5 qualités d’un développpeur très efficace : l’amour du détail (3/5)

Voici la troisième partie de la publication en 5 parties de la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.

Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :

  1. Humilité
  2. Aimer apprendre (2e partie)
  3. Amour du détail  (3e partie)
  4. Adaptabilité  (4e partie)
  5. Passion (5e partie)

Amour du détail

Développez des logiciels avec les technologies d’aujourd’hui est une affaire de détails. Peut-être que dans 100 ans, le logiciel va arriver à un point où il pourra s’écrire lui-même, être complètement découpé en composants interopérables, auto-documenté, auto-testé et ensuite…il n’y aura plus de développeurs. Mais avant que cela n’arrive (si jamais cela arrive), prenez l’habitude d’être attentif à tous les détails.

Pour illustrer : prenez une fonctionnalité de n’importe quel logiciel, et essayer de penser à tout le travail qui a dû être effectué pour la modifier de quelque manière. Pour n’importe quoi de pas primordial, vous pourriez probablement arriver à une liste d’une centaine d’opération mineures : modifier l’interface graphique (ce qui inclut les images, le texte, la localisation, les événements, la customisation, etc.), les tests unitaires, les algos, l’interaction avec les composants en relation, et tout cela de nouveau divisé en étapes mineures.

J’ai toujours trouvé que les plans étaient inutiles, mais la planification est indispensable. – Dwight Eisenhower
Voici un problème cependant : quelques humains peuvent garder chacune des tâches dans leur tête, durant un certain temps. Heureusement, le souci du détail ne signifie pas nécessairement être capable de suivre mentalement chacun des détails. Cela signifie que vous développez une approche mentale pour les gérer. Par exemple, les étapes pour modifier une partie d’un logiciel pourraient être :

  1. Comprendre globalement ce que le code fait et pourquoi
  2. Examiner toutes les dépendances et interactions en relation avec ce code
  3. Avoir une bonne représentation mentale de comment tout cela s’assemble
  4. Evaluer les conséquences des modifications de la fonctionnalité
  5. Mettre à jour le code qui le nécessite (et répéter ce cycle pour chacun des composants)
  6. Mettre à jour les éléments auxiliaires qui peuvent dépendre de ce code (builds système, installeurs, tests, documentation, etc.)
  7. Tester et recommencer

Un exemple : J’étais en train de travailler sur une portion de code. J’ai réalisé qu’il y avait plusieurs tâches à effectuer immédiatement après avoir fini ce que j’étais en train de faire. Si je ne les faisais pas, je détruisais le logiciel. Si j’essayais de me souvenir de toutes, j’en aurais sûrement oublié une en route. J’avais donc plusieurs choix :
1.Reporter à plus tard, en essayant de me rappeler de toutes
2.Les effectuer immédiatement
3.Reporter à plus tard, après les avoir écrites.
Chaque possibilité est utile selon les circonstances. Bon, peut-être pas la première. Je pense que c’est idiot d’échouer dès le départ et de prendre de mauvaises habitudes. Si les tâches secondaires sont courtes, facile et bien comprises faites les immédiatement et revenez à votre tâche initiale.

Quoi qu’il en soit, si vous savez qu’elles nécessitent beaucoup de travail, mettez les par écrit. Je préfère un bloc-notes tout simple dans tous les cas, mais des fichiers textes, les tâches Outlook, les notes, OneNote, un système de bug tracker et les autres méthodes peuvent aussi travailler à rendre cela possible.

Plus vous avez d’expérience, plus vous serez capable de capter tous les détails dont vous avez à vous soucier. Vous les analyserez plus vite, mais vous aurez toujours besoin, d’une manière ou d’une autre de garder la trace de ce que vous ferez après. Il y a tout simplement trop de détails. Une organisation efficace est une capacité clef pour d’un bon ingénieur logiciel.

Un autre aspect auquel prêter attention est la pensée critique (ndt : critical thinking). La pensée critique implique un scepticisme de bon aloi sur tout ce que vous faites. C’est particulièrement important quand vous examinez les détails de votre implémentation, de vos designs ou plans. C’est la capacité de sortir de tous ces détails ce qui est important, ce qui est correct, ou au contraire, ce qui est nul et doit être abandonné.Cela vous guide également quand vous devez utiliser une méthode de développement connue, et quand vous devez venir avec une nouvelle solution à une problème délicat.

Les 5 qualités d’un développpeur très efficace : aimer apprendre (2/5)

Voici la deuxième partie de la publication en 5 parties de la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.

Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :

  1. Humilité
  2. Aimer apprendre (2e partie)
  3. Amour du détail  (3e partie)
  4. Adaptabilité  (4e partie)
  5. Passion (5e partie)

Passion de l’apprentissage

Si vous êtes nouveau dans tout ce truc de développement, je déteste ce que je vais faire : l’apprentissage vient juste de commencer. Quoi que vous pensiez de votre diplôme d’ingénieur en Sciences Informatique pour lequel vous avez bossé si dur, c’était juste le début. Cela vous prendra un emploi ou deux, mais c’est comme ça. Si vous ne pouvez pas apprendre en avançant, de maintenant à la retraite, vous êtes un poids mort. Bien entendu, vous serez capable de trouver un emploi quelque part avec votre langage préféré pour le reste de votre vie, COBOL et FORTRAN sont encore là, après tout, mais si vous voulez réellement progresser vous allez devoir apprendre.

Apprendre n’est pas compulser. Pas plus que survivre. – W. Edwards Deming

Cela signifie lire. Beaucoup. Si vous n’aimez pas lire, je vous recommande de vous plonger dans Harry Potter, la fantasy, la SF, la fiction historique, qu’importe. Quelque chose. Lisez simplement. Ensuite procurez vous quelques livres techniques. Commencez avec ma liste des livres essentiels pour les développeurs. Ils ne sont pas aussi excitant que Harry Potter, mais ils ne sont pas mal non plus.

Beaucoup de matériau est en ligne, mais pour une très bonne qualité, du contenu qui fait autorité sur des sujets fondamentaux, les livres battent tout le reste.

Lire n’est pas assez, bien sûr. Vous devez pratiquer. Vous devez écrire vos propres projets de test. Vous devez vous forcer à repousser les limites. Vous pouvez commencer en tapant les exemples de code, mais vous devez les changer d’une manière unique et personnelle. Vous devez avoir des projets personnels et loisirs qui développent vos compétences. Ecrivez vos propres outils, ou des programmes « marrants ». Ecrivez un jeu. Faites ce qu’il faut pour apprendre de nouvelles choses !
Le type de programme que vous écrivez a une grande influence sur la manière dont vous apprendrez de nouvelles choses. Cela doit être quelque chose qui vous intéresse, ou vous lâcherez le morceau. Dans mon cas, je développe des programmes relatifs à ma passion des LEGO. Dans le passé, j’ai écrit des outils pour des jeux de mots, des utilitaires systèmes, des plug-in multimédia, et bien plus encore. Tous ont débuté par un besoin que j’avais, ou un désir d’apprendre quelque chose de nouveau et d’utile pour moi.

Un autre aspect de cette passion de l’apprentissage est relative au déboggage d’application. Un développeur efficace n’est pas satisfait d’un problème jusqu’à ce qu’il comprenne comment cela fonctionne, pourquoi cela arrive et les détails sur comment le réparer. Les détails comptent – comprendre pourquoi un bug se produit est aussi important que de savoir comment le résoudre.

Apprenez des erreurs. J’ai vu des développeurs qui font des erreurs, ont la bonne solution mise sous leur nez , et disent « Oh, je me demande pourquoi cela ne marchait pas pour moi », et continuent sur leur chemin merveilleux de l’ignorance. Une fois que le code fonctionne « de la façon correcte » ils ont terminé. Ils ne se soucient pas de savoir pourquoi cela ne fonctionne pas. Ce n’est pas assez ! Comprendre les erreurs, ce qui les répare et pourquoi.

Les jugements justes viennent de l’expérience et l’expérience vient des erreurs de jugement. – Fred Brooks

Evidemment, il faut modérer un peu. Vous ne pouvez pas apprendre tout–c’est simplement impossible. Notre métier devient de plus en plus spécialisé parce qu’il y a tout simplement trop de savoir. Je pense aussi que, dans une certaine mesure, vous devez aimez apprendre juste pour apprendre des choses.

Je suis complètement d’accord avec ce chapitre. Et je le vois régulièrement au cours des sessions de formation que j’anime : les développeurs aiment apprendre, et même, aiment comprendre. Ils sont friands de nouvelles connaissances.

Les 5 qualités d’un développpeur très efficace : humilité (1/5)

Voici en cinq parties, la traduction d’un article de Ben Watson publié le 20 janvier 2008 sur son blog : Top 5 Attributes of Highly Effective Programmers. Ma traduction est amateur, mais vous permettra de profiter des idées de Ben Watson dans votre langue maternelle.

Il propose, et développe 5 qualités essentielles qui distinguent le bon développeur du mauvais :

  1. Humilité
  2. Aimer apprendre (2e partie)
  3. Amour du détail  (3e partie)
  4. Adaptabilité  (4e partie)
  5. Passion (5e partie)

—-

Quelles qualités peuvent contribuer à différencier un développeur très efficace d’un banal développeur ordinaire ?

Je ne crois pas que les qualités listées ici soient une finalité, pas plus que je ne crois que vous devez être né avec. Presque tout dans la vie peut s’apprendre, et ces qualités ne font pas exception.

Humilité

L’humilité est la première parce que cela implique les autres qualités, ou au moins, les rend possible. Il y a beaucoup de malentendus sur ce qu’est l’humilité et parfois c’est plus facile d’expliquer ce que cela n’est pas :

  • l’humilité ce n’est pas laisser les autres vous marcher dessus
  • l’humilité ce n’est pas supprimer vos opinions
  • l’humilité ce n’est pas penser que vous êtes un mauvais développeur

C.S. Lewis l’a le mieux décrite, sous l’apparence littéraire d’un diable essayant de subvertir l’humanité :

Laissez le penser à [l’humilité] pas comme un effacement de soi, mais comme une certaine sorte d’opinion (à savoir, une petite opinion) de ses propres talents et caractéristiques…Réparer dans son esprit l’idée que l’humilité consiste à essayer de croire que ces talents sont moins importants que ce qu’il croit qu’ils sont… Avec cette méthode des milliers d’humains ont été amenés à penser que l’humilité signifiait des jolies femmes essayant de croire qu’elles étaient laides et des hommes malins essayant de croire qu’ils étaient idiots.

(The Screwtape Letters, C.S. Lewis)

Ok, donc nous réalisons que l’humilité n’est pas de prétendre être pire que ce que l’on est et ce n’est pas la timidité. Alors, qu’est-ce que c’est ?

Simplement l’humilité est comprendre que le monde ne commence ni ne finit avec vous. C’est accepter que vous ne sachiez pas tout ce qu’il y a à savoir sur WPF, ou Perl ou Linux. C’est une reconnaissance du fait que, même si vous êtes un expert dans un domaine particulier, il y a encore beaucoup à apprendre. En fait, il y a largement plus à apprendre que vous ne pouvez le faire durant une vie entière, et c’est pas grave.

Une fois que vous commencez à penser que vous êtes un expert, à être présomptueux et que vous avez le mot de la fin sur quelque chose, vous cessez de grandir, vous cessez d’apprendre, et vous cessez de progresser. La fierté peut vous rendre obsolète plus vite que vous ne pouvez dire « Java ».

Le fait est que même si vous êtes humble, vous êtes probablement intelligent. Si vous travaillez dans une petite entreprise avec quelques développeurs (ou dans n’importe quelle entreprise avec quelques bons développeurs), il est probable que vous êtes plus intelligent que la majorité d’eux quand on en vient à l’informatique. (Si vous êtes plus intelligent qu’eux à propos de tout, alors vous échouez au test de l’humilité ou vous avez besoin de partir rapidement de cette entreprise). Depuis que vous avez appris à en savoir plus sur les ordinateurs, et sur comment les logiciels fonctionnent, que la plupart des gens, et, depuis que la vie de tout le monde tourne de plus en plus autour de l’utilisation d’un ordinateur, cela vous donne l’illusion que vous êtes plus intelligent que les autres sur tout. C’est habituellement une erreur.

Prenez le Service Marketing/Ventes par exemple. J’ai environ 50 strips de Dilbert accrochés dans mon bureau. Je devine que la moitié se moquent du Service Marketing/Ventes d’une certaine façon. C’est facile, c’est drôle et souvent amplement mérité !

Mais s’ils ne vendent pas votre logiciel, vous ne serez pas payés. Vous avez besoin d’eux autant qu’ils ont besoin de vous. Si quelqu’un vous demande de vendre votre logiciel, comment ferez vous ? Aimez-vous au moins parler aux gens ? Aussi nuls soient-ils sur les réalités du développement logiciel, ils ont des compétences que vous n’avez pas.

Il existe quelques industries où les egos démesurés vous donnent votre place. Je ne crois pas que ce soit le cas le plus courant dans le logiciel, du moins dans les entreprises dirigées par des gens qui comprennent le logiciel. L’ego ne compte pas pour les résultats. Si vous avez un gros égo, vous feriez mieux d’être capable de le retenir. Malheureusement, le problème avec les egos est qu’ils grandissent-par la suite vous ne serez plus capable de le contrôler et les gens le verront.

Le développeur compétent est complètement conscient de l’étendue limitée de ses propres compétences ; c’est pourquoi il considère les tâches de programmation en toute humilité, et par dessus tout il évite les trucs intellos comme la peste. – Dijkstra

Sans l’humilité, vous allez faire des erreurs. En fait, même avec l’humilité vous allez faire des erreurs, mais vous le réaliserez plus tôt. En considérant que vous savez comment résoudre un problème immédiatement, vous pouvez prendre des raccourcis dans le processus de développement. Vous pouvez penser que vous comprenez le logiciel si bien que vous pouvez facilement réparer un bogue avec quelques astuces…mais, vous ne vous rendez pas compte que cette autre fonction là bas est maintenant inopérante. Un développeur humble dira d’abord « Je ne connais pas la manière propre de réparer le problème » et prendra du temps pour l’analyser.

Au final, il est plus agréable de travailler avec des gens humbles. Ils ne font pas de leur supériorité un but. Ils n’ont pas tout le temps la « bonne réponse » (signifiant que tout les autres ont tort, bien entendu).

Laissez votre égo de côté quand vous développez.

Ce n’est pas si important d’avoir tout bon la première fois. C’est extrêmement important d’avoir tout bon au final. – Andrew Hunt and David Thomas

Peut-être que le plus important est qu’un développeur humble peut se former lui-même.

Etes-vous humble, alors ? Avez-vous remarqué cette qualité chez vos collègues ?

Aujourd’hui c’est le Thank A Dev Day !

Qu’est-ce que c’est ?

il s’agit d’une journée pour exprimer sa gratitude à un développeur OpenSource pour un logiciel qu’il a créé.

Comment ça marche ?

C’est simple, choisissez l’appli OpenSource que vous préférez, trouvez les coordonnées du développeur et envoyez lui un mail avec le tag [TADD] dans lequel vous lui expliquez pourquoi vous appréciez son logiciel.

En savoir plus : http://thankadev.wordpress.com

Le MAOW, j’y étais

Je vous prépare un compte-rendu des conférences auxquelles j’ai assisté. (D’ailleurs, je me demande si je dois mettre le résumé de la conférence, mes notes, ou juste donner mon avis sur la conférence. Qu’en pensez-vous ?)

En attendant, le Mozilla Add-On Workshop co-organisé par XULfr.org et Mozilla à Paris, c’était:

  • Pas beaucoup de filles mais des stars de Mozilla
  • Un tee-shirt super joli et même à ma taille
  • Un très bon accueil et un très bon café
  • Un petit regret : ne pas avoir un pack visiteur, comme à certaines conférences plutôt que des goodies jetées ça et là, qui étaient au premier arrivé, premier servi.
    En même temps, cela m’a aussi permis d’avoir 2 badges, et Mozilla n’est pas avare de goodies.

Voilà pour l’ambiance générale.