[traduction] 16 moyens de torturer vos développeurs

billet originel : 16 ways to torture developers par Andrew Oliver, le 4 mars 2013

Je dédicace cette traduction à Alexandre Rodière et à Eric Lemoine qui ont été inspirants dans ma carrière.Si vous reconnaissez certains points comme faisant partie de votre travail, je vous invite à calculer le score de votre entreprise 🙂

By Kristaps B. from Tukums, Latvia (Summer’s boredom) [CC-BY-2.0 (http://creativecommons.org/licenses/by/2.0)%5D, via Wikimedia Commons

Lire la suite

Publicité

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 ?

[Traduction] 10 mythes injustifiés sur PHP

Ce qui suit est une traduction de 10 PHP Myths Dispelled écrit par Jaybill McCarthy paru en janvier 2008 sur Jaybill.com (que vous pouvez aller lire pour profiter des commentaires des visiteurs)

___

Je suis un développeur PHP. Peut-être même la moitié d’un vrai développeur. En tant que tel, je me suis souvent retrouvé mêlé à des conversations sur le développement des applications web en général et sur PHP en particulier. Je suis continuellement frappé par les mythes, les demi-verités et de vrais mensonges que les gens autant techniques que non-techniques propagent sur cet humble langage de programmation.

Je suis loin d’être un fanatique sur quoi que ce soit de logiciel. Je pense que si vous êtes passionné d’un logiciel, vous ratez le coche. C’est comme si un charpentier était passionné de marteaux au lieu de construction de maisons. En ayant dit cela, je sens que je dois vraiment dissiper quelques malentendus avant qu’ils ne prennent plus d’importance : je suis fatigué d’être pris de haut par les développeurs Java qui croient que leur choix de langage est Le Seul Vrai Chemin(TM). Donc voici ma liste.

Mythe n°1 : PHP n’est pas vraiment un langage orienté objet

J’ai entendu cela de beaucoup de développeurs Java. C’est complètement faux. PHP a un excellent bagage OO. Il y a l’héritage, les classes abstraites, les interfaces, les propriétés et les méthodes. D’accord, il n’y a pas de surcharge de méthodes, mais il y a moyen de contourner cela. Seul le binding est encore un peu immature. Je dirais qu’il y a eu de grands progrès dans les mécanismes OO avec PHP5, mais j’ai aussi écrit beaucoup d’applications PHP4 qui étaient complètement OO. Le seul fait que vous pouvez écrire du code complètement procédural en PHP ne signifie pas que PHP ne peut pas faire d’objet. En outre, le fait que PHP vous autorise à mélanger objet et procédural rend les choses comme le bootstrap vraiment simple.

Mythe n°2 : PHP encourage le mauvais code

Egalement faux. Y a-t-il beaucoup de mauvais code PHP ? Absolument. La barrière d’entrée faible de PHP signifie que beaucoup de gens qui ne sont pas des développeurs formés entrent dans la danse.

Le mauvais code qui en résulte est la conséquence d’une formation faible et d’une mauvaise gestion, non du langage lui-même. Dire que PHP encourage le mauvais code, c’est comme dire que les mateaux encouragent les doigts ensanglantés. Evidemment, vous pouvez vous taper sur les doigts avec un marteau, mais est-ce de la faute du marteau ou vous qui ne savez pas comment l’utiliser correctement ?

Mythe n°3 : PHP ne suit pas le modèle MVC

Je sais que cela paraît ridicule, mais je ne sais pas avec combien de Railers j’ai eu cette discussion. Non, PHP ne fournit pas, de lui-même un framework MVC. Pas plus que Ruby, ou aucun autre langage, d’ailleurs. C’est parce que Ruby et PHP sont des langages, et non des framework d’application. MVC est un design pattern, et non une possibilité du langage. Il existe beaucoup d’excellents frameworks MVC écrits pour PHP. J’aime le Zend Framework. Pouvez-vous faire un appel à la base depuis un script qui générerait aussi le HTML ? Bien entendu, vous pouvez. Est-ce que cela veut dire que vous devez ? Non.

Mythe n°4 : PHP est lent parce qu’il est interprété

Celui ci est insidieux parce que cela semble plausible. En fait, cela devrait être vrai. En pratique, cela ne l’est pas. Le Zend Engine qui fait tourner la plupart des implémentations PHP est incroyablement rapide de base. Combinez le avec un accélérateur, (comme eAccelerator, libre) qui pré-compile et cache le code (et qui l’adapte si on change de disque), et c’est l’une des plate-formes d’applications la plus performante actuellement, même comparé à des choses qui sont traditionnellement compilée comme Java et .NET. Même en écrivant votre appli en C ou C++, en le compilant et en l’intégrant à votre serveur web, vous n’aurez pas plus de performances.

Mythe n°5 : PHP n’est pas de bon EDI ou de débogueur

C’est vrai. Il n’y en a pas un. Il y en a plein. Il y a au moins deux débogueurs, et plein de bons EDIs. Vous pouvez avoir toutes les options que vous voulez, comme les points d’arrêt, la surveillance des variables, l’évaluation au passage de la souris, etc. Pouvez-vous utiliser un éditeur texte et un client FTP ? Bien entendu, vous pouvez. Vous n’êtes certainement pas obligés, je pense.

Mythe n°6 : les applis PHP se ressemblent toutes

Je dois le dire, cela m’a pris longtemps pour comprendre ce que les gens qui déclaraient ça voulaient dire. Au départ, j’ai pensé que la personne disant cela était folle. Après tout, PHP est juste un langage, vous pouvez faire que la sortie soit…comme vous la voulez ! De façon surprenante, j’ai beaucoup entendu ça. Par la suite, j’ai compris que la confusion provenait de profils non-techniques qui confondaient PHP et PHP-Nuke, qui est juste une application écrite en PHP. Elle est complètement personnalisable, mais propose des colonnes et des pavés qui ont tous le même genre d’apparence.

Mythe n°7 : PHP n’est pas vraiment pour les « vrais » développeurs

C’est un autre que j’ai entendu des développeurs Java (et encore plus amusant, des développeurs .NET). Comme le n°2, je pense que cela provient de la faible barrière d’entrée pour PHP. Quasiement tout le monde peut apprendre les rudiments de bidouillage de scripts PHP en un après-midi. Est-ce que cela signifie qu’il n’y a pas la place pour des « vrais » développeurs ? Bon, PHP, comme toute plate-forme de développement est un outil. La façon dont est utilisé un outil varie grandement selon les connaissances et l’expérience de la personne qui l’utilise. J’ai écrit plein d’application PHP de grosse taille, robustes et performantes, et je ne suis pas le seul.

Mythe n°8 : PHP n’est bon que pour les applications web

C’était vrai par le passé, mais de nos jours, il est beaucoup plus universel. Vous avez un interpréteur de ligne de commande qui peut tourner de manière complètement indépendante d’un serveur web (pour des scripts) mais peut continuer à utiliser vos bibliothèques existantes de code PHP. Vous pouvez même créer des applications avec une interface graphique, par PHP-GTK.
Evidemment, le but initial de PHP et sa visée étaient les applications web, mais c’est bien loin de tout ce qu’il peut faire.

Mythe n°9 : Le code PHP est un tas d’ « include » et de « require » qui se cassent facilement

En tant que langage de script, PHP est interprété à la volée. Cela signifie que n’importe quel code qui est exécuté doit être pris sur le disque et le script en question a besoin de savoir où il se trouve. La plus simple (mais la moins bonne) manière de faire est de mettre un « include » ou un « require » qui charge le script externe. Si vous faites cela et que vous renommez le fichier, votre code est cassé, à moins que vous ne modifiez l’instruction erronnée. Un tas d’include et de require peut faire de votre code un tas de spaghetti.

Heureusement, en suivant les règles de la programmation OO, des bonnes conventions de nommage et en utilisant __autoload les include et require sont généralement complètement intules. __autoload est une fonction de callback qui accepte en argument le nom d’une classe. Si vous instanciez un objet, et que le moteur ne sait rien de la classe, il appelle votre __autoload avec le nom de la classe en tant que chaîne. En présumant que vous avez une convention de nommage raisonnable (une classe par fichier, le nom de la classe et le nom du fichier correspondent), c’est plutôt simple de charger la classe au moment voulu. Cela a l’avantage de ne charger que les classes nécessaires pour un script particulier, au lieu de les charge toutes avant même le début du code fonctionnel.

Mythe n°10 : Le code PHP est bourré de requêtes SQL

Jetez un oeil aux applications PHP et vous le verrez. Le SQL a été mêlé avec des chaînes et passé à la base (souvent MySQL) avec les fonctions spécifiques. Cela rend votre code fragile, lourd à déboguer et à maintenir et sujet aux attaques par injection SQL. C’est aussi complètement inutile et peut-être facilement évité. Utilisez simplement une couche d’abstraction comme Zend_DB ou ADOdb au lieu de parler directement à la base.

Voilà, c’est fait. Les dix mythes sur PHP sont littéralement…heu…explosés. Cela ne signifie pas que PHP est sans défaut, mais je pense que peu d’autres outils ont cette mauvaise image.
J’espère que j’ai un peu éclairci les choses.

NdT : les commentaires sur les liens sont de l’auteur, juste traduits. Cet article ne reflète pas complètement mon opinion personnelle, mais je l’ai trouvé intéressant.

[Traduction] La documentation vous apprend 12 choses

Ce qui suit est une traduction libre du billet Twelve Lessons From Writing Documentation de Jeff Staddon, paru en novembre 2007.

Nous croyons tous qu’une bonne doc est importante, mais qui la fait réellement ? La documentation typique d’un système informatique d’entreprise consiste habituellement en un regroupements de notes, de quelques documents LISEZMOI abandonnés sur le partage réseau et peut-être de quelques lignes de commentaire dans le code.

Il y a quelques années, j’en ai eu assez du « processus de documentation » standard et j’ai commencé à réellement documenter ce que je faisais.

Voici ce que j’en ai retiré :

  1. Comme toute compétence, pour écrire de la doc, on s’améliore avec la pratique. Au fur et à mesure que l’on s’améliore, cela devient de plus en plus amusant. (Oui, j’ai dit amusant. Cela peut vraiment être amusant).
  2. Quelques uns des documents « classiques » (minimum requis par exemple) semblent avoir un temps de vie vraiment court. Les autres documents – étapes pour lancer un script compliqué – tendent à être très utilisés.
  3. La doc est meilleur en petits fragments. J’utilise un wiki – cela facilite le type de « jet d’idée » rapide, c’est pourquoi les wikis sont très souvent le plus pratique. Ecrire en petits fragments préserve la tâche de l’ennui.
  4. La doc doit être facile à mettre à jour. Autrement, elle sera périmée et perdra sa fiabilité. A nouveau, j’aime beaucoup le wiki pour cela.
  5. On doit pouvoir chercher facilement dans la doc. Quelque chose qui est difficile à référencer — comme le format de document traditionnel utilisé sur le partage — ne doit tout simplement pas être utilisé.
  6. La documentation est pour les développeurs et les utilisateurs, pas pour le management. Laissez la professionnelle (même s’il semble que le document sur le multi-threading est compliqué), mais cool.
  7. Gardez la documentation réduite. Je préfère 1 ou 2 pages imprimées. Si un document est plus long que 3 pages, il couvre trop de sujets et peut être divisé en plus petites parties. C’est plus facile de naviguer dans des documents courts et il est plus facile de faire des recherches dedans (moins de fausses réponses). Appuyez vous sur la puissance des hyperliens !
  8. Réduisez la documentation. Les systèmes sont naturellement hiérarchiques. Les systèmes se divisent en sous-systèmes, qui deviennent des classes, etc. Laissez la doc divisée de la même façon que l’architecture ou l’utilisation de votre système.
  9. C’est pas grave d’avoir la document en dehors du code. La documentation qui est liée à une partie spécifique du code – documentant la classe et ses méthodes, par exemple – devrait être dans le code. Mais la doc sur le système et ses sous-systèmes fonctionneront mieux dans un wiki. La chose importante est que la documentation doit être facilement accessible et universellement reconnue comme le lieu où aller.
  10. Tout la doc n’est pas relative au code. (Par exemple, un lexique des termes business ou acronymes). Il faut un endroit où stocker la documentation ne concernant pas le code.
  11. La doc doit répondre aux questions sur « Quoi ? Où ? » et « Pourquoi ? ». Le code répond déjà à la question « Comment ? ». Pour ceux qui pensent que le code est « auto-documenté », essayé juste d’écrire du code qui explique pourquoi une conception ou une architecture a été choisie plutôt qu’une autre…Les commentaires les plus utiles sont ceux comme « nous essayons de faire…mais cela a semblé être une mauvaise idée parce que… »
  12. La documentation doit être partagée. Plus de paires d’yeux la voient, plus elle devient valable.

Mais pour finir, la plus grande leçon – celui qui utilise le plus ma documentation est : moi. Je suis étonné de la fréquence. Je reviens lire quelque chose que j’ai écrit pour me rafraîchir la mémoire sur un certain système, processus ou autre. Le temps que j’ai passé à écrire a été facilement rentabilisé, juste pour le temps gagné à ne pas re-rechercher.