Il fait beau, voici revenu le temps des apéros !

Datz, de l’AFUP me suggère de vous rappeler qu’il existe un superbe site web : Apero PHP, qui, même s’il date un peu niveau graphisme, est toujours opérationnel. Vous y trouverez les dates des prochains ApérosPHP, et la possibilité d’organiser vous-même un apéro.

Comment faire ?

Si vous avez peur de ne connaître personne, commencez par participer.
Justement, Datz organise un apéro le 18 juin prochain. Venez au prochain apéro organisé par Datz (Mister PHP) au Belushi’s  : 68 quai de la Seine – 75019 Paris

Si vous êtes plutôt jovial et n’avez pas froid aux yeux, organisez donc un apéro. C’est plutôt simple, vous choisissez un bar sympa près de chez vous, et accessible à tous (quelle que soit la ville), et vous lancez le rendez-vous. Quand le nombre d’inscrit à votre apéro augmente, prévoyez de prévenir le tenancier, voire de réserver une table dans le café !
Mon conseil ? Donnez un nom au patron du bar que vous indiquerez aux membres de l’apéro, et allez vous identifier en arrivant, pour que les débutants tout perdus puissent demander aux serveurs où est le groupe PHP

Pourquoi faire ?

Parce que c’est convivial de rencontrer IRL les gens avec qui vous échangez sur les forums. C’est le meilleur endroit pour se tuyauter sur la source des peluches d’éléphants ou les derniers scripts à la mode.

Parfois certains organisent l’apéro avec un thème sur PHP, ici Datz aimerait parler de l’actualité de PHP, et de la sortie de PHP5.3. Pour ma part, tous les apéros PHP auxquels j’ai participé regroupaient des gens concentrés sur le sujet, et des gens prêts à se détendre après le boulot autour d’une mousse fraîche.

Même si vous pensez ne pas avoir envie de refaire du PHP après le boulot, venez rencontrer vos pairs autour d’une bière !

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 ?

Ce mois-ci, je suis en kiosque, deux fois

Ma fierté n’a pas de limites à savoir que je suis lisible par le plus grand nombre puisque j’apparais à la fois dans Programmez! et PHPSolutions (Hors-Série) ce mois-ci. A chaque fois, c’est pour expliquer les bases du langage PHP à des débutants qui voudraient s’y mettre.

Dans ces mêmes magazines, voici les articles qui ont attiré mon attention :

Programez! #118

• Choisir son framework AJAX : trop court mais une bonne base pour comprendre les critères à vérifier
• Métier : développeur Open Source : des interviews de développeurs bossant dans l’Open Source

PHP Solutions 2/2009

• Jeu en PHP : explications pour concevoir un jeu très pertinentes, sur la réflexion de l’univers, des règles
  
• Développement d’application pour Facebook : explication rapide et efficace pour faire votre première application PHP pour la plate-forme Facebook. A la limite, cet article peut être transposé pour n’importe quel autre langage serveur (Ruby, Python, etc.) puisqu’il pose les bases.
  
• Sécurité et PHP : notions de base, simple à comprendre et une bonne piqûre de rappel pour ceux qui savent déjà tout.

Bonne lecture !

9 mai 2009, Paris : PHPCamp #2

L’AFUP vous propose de profiter du long week-end du 8 mai pour participer à un PhpCamp. C’est un évènement gratuit, participatif et ouvert à tous qui vous permettra de rencontrer d’autres développeurs, d’améliorer PHP : et c’est sur inscription.

Si vous souhaitez savoir ce qu’est au juste un PHPCamp (BarCamp orienté sur PHP), vous trouverez des précisions sur le site BarCamp.org ou le (non-)programme des réjouissances est aussi sur site de l’AFUP.

• Date : 09/05/200
• Horaire : 10h -20h
• Capacité : 80 places
• Lieu : La Cantine
  151 rue Montmartre, 12 passage Montmartre
  Galerie des Panoramas, 75002 Paris

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