Beta : version d'essai à expérimenter avec sa clientèle qui deviendra un work in progress en fonction de la réponse reçue.

Dans le développement de logiciels, c'est devenu une norme acceptable de lancer un produit beta et de l'améliorer par la suite. Surtout lorsqu'on est à l'écoute des besoins de nos clients. Il est impossible de créer un produit parfait du premier coup. Il vaut mieux prioriser l'innovation plutôt que la perfection immédiate. Les corrections ne diminuent pas la crédibilité, ça la renforce. Se lever et admettre nos erreurs nous rend plus crédible.

Marissa Mayer disait à propos d'Apple et Madonna : ils étaient cool en 1983 et le sont toujours en 2006 (23 ans plus tard). Comment est-ce qu'ils gèrent ça ? Ils ne le font pas en étant parfait à chaque fois. Il y a beaucoup de faux pas dans le parcours. Apple avait Newton, Madonna a son sex book. Lorsque vous faites une erreur, vous devez trouver le moyen de vous en sortir ou bien vous réinventer. 

À une employée de Google qui présentait ses excuses face à une erreur technique importante qui a engendré des pertes se chiffrant à plusieurs millions de dollars, Larry Page répondit : Je suis si heureux que tu aies fait cette erreur parce que je préfère diriger une entreprise où l'on va trop vite et qui réalise plein de choses plutôt que d'être trop prudent et en faire trop peu. Si nous n'avions aucune de ces erreurs, c'est que nous ne prenons tout simplement pas assez de risques.

Eric Schmidt résuma le tout : S'il vous plaît, échouez rapidement, de sorte que vous pourrez essayer à nouveau.

En relisant ce que j'ai écrit, je n'ai d'autre choix que de faire le parallèle avec la progression d'une vie professionnelle (et personnelle). Notre vie est un prototype en constante évolution. On commence sans expérience, on se lance dans le vide, on gaffe, on écoute les reproches et on s'ajuste, on apprend de nos erreurs, on se réinvente pour être constamment à l'affût des nouvelles technologies et des réalités du marché. À tout moment, on prend des risques pour voir dans quelle direction ça peut nous mener. Tout ça pour dire qu'il faut oser pour progresser.

La chose la plus précieuse que vous pouvez faire est une erreur. Vous ne pouvez pas apprendre quoi que ce soit d'être parfait.

Il y a quelques jours, j'ai envoyé mon CV à une entreprise pour la première fois en plus de 10 ans. C'est maintenant le moment où je dois patienter pour voir si je vais décrocher une entrevue. On a beau se préparer du mieux possible à une éventuelle rencontre, il y aura toujours des surprises quant aux questions qui nous seront posées, aussi curieuses et embêtantes soient-elles. Comme la classique : "quel est ton pire défaut ?". C'est vrai, qu'est-ce que je répondrais à une question aussi traître ?

Le timing était bon car durant la même semaine, un ami partageait sur Twitter un billet intitulé : How to answer 'What is your greatest weakness?'. Comme il connaît ma démarche, c'est à croire que ça m'était adressé. Dans ce billet, l'auteur suggère de recadrer la question de façon à mettre une qualité sous les projecteurs. Selon lui, les forces et les faiblesses sont des vues différentes d'une même caractéristique, d'où la nécessité de répondre habilement à son avantage. Prétendre qu'on est trop perfectionniste ou workaholic sont sans doute les réponses les plus prévisibles et par conséquent, les pires. Rayons-les immédiatement de la liste.

Comment révéler une qualité à travers une faiblesse tout en étant original ? Sa formule : identifiez quelle force vous souhaitez mettre en évidence et déterminez la façon dont elle vous rend faible.

Voici une réponse possible que j'ai imaginé (je me réserve un droit d'auteur jusqu'à son utilisation) :

Mon plus gros défaut est que malgré tous mes efforts pour perfectionner mon savoir-faire, je connais à peine 1% de tout ce qui se fait en programmation. Au rythme où les nouvelles technologies se multiplient, ce pourcentage de connaissances acquises diminue lentement chaque année, ce qui a pour effet de me donner l'impression d'en connaître de moins en moins chaque fois que je me relève les manches pour apprendre quelque chose de nouveau.

La formulation est encore à paufiner mais croyez-vous que cette réplique est valable ? C'est inspiré à la fois du paradoxe de Socrate qui disait "Je ne sais qu’une chose, c’est que je ne sais rien" alors qu'il reconnaît connaître au moins l'ignorance, et de Galilée qui affirmait "Plus j’apprends, plus je m’aperçois que je ne sais pas". L'idée est de démontrer qu'on est conscient que notre savoir est limité tout en démontant un appétit pour l'acquisition de nouvelles connaissances.

À votre tour de faire l'exercice, quelle serait votre réponse ?

Nous avons cessé de compter le nombre de fois que nous sommes allés manger à ce restaurant. Pour certains, c'est plus de 200 fois. Pourquoi ? Simplement parce que semaine après semaine, depuis des années, c'est le seul resto qui a su rassembler la majorité de l'équipe de production pour un lunch hebdomadaire, à l'extérieur des 4 murs du bureau.

Mais mon intention n'est pas de parler de bouffe. J'avoue que celui-là fait plus dans la restauration rapide que dans la haute gastronomie, seulement ça goûte bon et nos discussions contribuent à renforcer les liens d'équipe. En même temps, ce n'est peut-être pas si exceptionnel à l'intérieur d'une petite entreprise, ça devient notre 2ème famille. Toujours est-il que pour aller au restaurant, le seul inconvénient est qu'on ne peut s'y rendre à pied. Pour faciliter les choses, nous essayons de minimiser le nombre de voitures : généralement 2 autos avec 4 ou 5 personnes à l'intérieur de chacune. C'est pratique et un peu plus écologique.

Mais mon intention n'est pas de faire l'éloge du covoiturage même si je l'encourage. D'ailleurs, l'idée déplaît en partie à certains dans la direction de l'entreprise. La grosse crainte ? Le bus factor. Advenant un accident grave, voire mortel, comme se faire percuter par un camion lourd ou un autobus, le risque de perdre des membres de l'équipe ou d'un département, en partie ou en totalité, peut mettre en péril les projets ou la survie de la compagnie. Tellement qu'on s'est déjà fait demander que les programmeurs ne devraient pas être à bord du même véhicule. Le raisonnement est légitime, on a récemment vu une équipe de hockey de la KHL être rayée de la carte lorsque l'avion du Lokomotiv s'est écrasé. Où va-t-on sans équipe ?

Ce qui me dérange, c'est le facteur humain. Dans un tout autre contexte, ce serait comme imposer à une même famille de se diviser pour se déplacer dans des véhicules différents afin de répartir et minimiser le risque en cas d'accident. Perdre sa famille en partie ou en totalité sont des scénarios aussi mauvais l'un que l'autre.

La survie de l'entreprise semble parfois plus importante que les éléments qui la compose. Que ce soit par une démission, une mise à pied ou un malheur, tout employé est remplaçable, dit-on. Mais à quel prix ? Dans un monde utopique, tous les employés seraient polyvalents, la documentation serait parfaitement écrite et les situations seraient prévisibles. Dans la réalité, ça peut signifier de devoir reconstruire à neuf, accepter la perte du savoir-faire, oublier la possibilité du transfert de connaissances, reculer pour mieux avancer. Chaque employé est un élément-clé parce qu'il le devient. Chaque membre de l'équipe est important car il est complémentaire aux autres.

C'est un cadeau de faire parti d'une équipe solidaire. C'est notre force : on travaille, voyage et mange ensemble, on surmonte les obstacles les plus difficiles pour avancer dans la même direction, coûte que coûte.

Les résolutions du nouvel an sont faites pour ne pas être tenues. Comme les écrits restent, peut-être que je me sentirai un peu plus obligé de respecter mes objectifs.

Professionnel

• Apprendre :
• un nouveau langage de programmation ou technologie
• un autre framework PHP MVC
• un CMS (Drupal, Joomla, autre ?)
• Relever des nouveaux défis et sortir de ma zone de confort. Ça fait quelques temps que certains m'incitent à faire le saut, j'ai donc refait mon Curriculum Vitae et je me sens plus prêt que jamais à écouter les opportunités qui me permettront d'atteindre le prochain niveau.
• Donner une chance à Windows 8. J'y vais à reculons mais je vais lui donner une semaine pour qu'il me prouve qu'il ne devrait pas être mal-aimé.

Lecture

Mes étagères sont pleines. J'aimerais rattraper le retard dans ma liste de lecture et si possible, terminer un livre par mois (ce sera difficile) :

1. What Would Google Do? de Jeff Jarvis (pour enfin le remettre à son propriétaire qui me l'a prêté)
2. Team Geek de Brian W. Fitzpatrick et Ben Collins-Sussman
3. Malavita de Tonino Benacquista
4. The Efficient Guitarist, volume 1 & 2 de Marc Schonbrun
5. La vie, mode d'emploi de Georges Perec
6. The Pillars of the Earth de Ken Follett (ou tricher et regarder au minimum la mini-série)
7. Code: The Hidden Language of Computer Hardware and Software de Charles Petzold (commencé mais jamais terminé)
8. Clean Code de Robert C. Martin
9. 97 Things Every Programmer Should Know de Kevlin Henney
10. Society of Mind de Marvin Minsky (il date de 25 ans mais il m'intéresse encore)
11. The World In Six Songs: How the Musical Brain Created Human Nature de Daniel Levitin (j'avais apprécié This is your Brain on Music, je devrais aimer celui-là)
12. Beneath the Neon: Life and Death in the Tunnels of Las Vegas de Matthew O'Brien

Amitié

• J'ai négligé mes amis durant la dernière année en raison des rénovations et d'une bonne dose de temps supplémentaire qu'exigeait mon travail. Il ne devrait pas y avoir d'obstacles pour que la situation revienne à la normale en 2013. Encore cette année, j'organiserai le classique BBQ annuel.
• J'ai rencontré quelques personnes par l'entremise de mon blogue et ce fût fort intéressant. Il y en aura d'autres.

Maison

• Rénovation : les terminer une fois pour toutes et avoir plus de temps libre pour tout le reste.
• Faire de la bière artisanale. J'en ai fait dans le passé et j'aimerais répéter l'expérience maintenant que je suis mieux installé. Mes choix : Hefeweizen, bière blanche, de blé (wheat beer), cream ale ou Irish Stout.

Musique

• Poursuivre les cours de guitare avec Truefire. Parce que j'ai été assidu cette année, j'ai progressé plus rapidement que par le passé. Pour 2013, j'ai l'intention d'atteindre la vitesse grand V.
• Produire des échantillions avec GarageBand sur iPad mini ou M-Audio FastTrack/ProTools.

Voyage

• Visiter un autre pays avec une culture complètement différente. Si la situation le permet, l'Égypte pourrait être une option intéressante.

Si j'accomplis seulement la moitié de tout ça, je serai satisfait. J'espère que vous aurez autant de beaux projets que j'en aurai pour 2013.

À tous, je vous souhaite une bonne et heureuse année.

Trois programmeurs qui se rencontrent pour un souper ont nécessairement des discussions geeks. Avec un peu d'imagination, nous avons énuméré quelques caractéristiques à considérer si vous devez engager un programmeur gremlin dans votre équipe.

Clonage

Au contact de l'eau, le programmeur gremlin se multiplie. Choisissez-en un particulièrement compétent et faites-en bénéficier votre entreprise.

Verdict : avantage

Lumière

Le programmeur gremlin a peur de la lumière, ça peut le tuer. C'est pourquoi il ne doit jamais remplacer les ampoules brûlées et qu'il préfère travailler dans le noir. De toute façon, ce n'est pas dans sa description de tâches, c'est un problème de matériel.

Verdict : neutre

Nourriture

En situation de late night coding, le programmeur gremlin ne doit en aucun cas se nourrir après minuit sans quoi il se transformera en monstre de la programmation.

Pour contourner ce désagrément, vous pouvez tenter de le changer de fuseau horaire avant de lui offrir à manger. Mais considérez la tentative comme risquée puisqu'on dit qu'il est toujours minuit quelque part dans le monde.

Verdict : inconvénient

Une étape importante vient d'être franchie ce matin pour le projet Code 18 : c'est la première fois que le blogue dépasse le cap des 200 000 visiteurs à l'intérieur d'une année. Depuis son ouverture en 2008, c'est plus d'un demi-million de visiteurs uniques de toute la francophonie qui sont venus fouiner par ici.

Quelques statistiques à l'occasion de cette revue de fin d'année :

• créé en octobre 2008
• près de 1200 billets publiés
• 516 000 visiteurs uniques depuis sa création
• moyenne de 550 visiteurs par jour pour 2012
• 343 followers sur mon compte Twitter
• 305 fans sur la page Facebook
• 3 soupers de geeks à Montréal
• environ 100$ de revenus publicitaires en 2012 (pour tout cet effort, 200$ au total)

C'est quand même respectable pour un blogue que j'ai lancé pour le plaisir sans savoir où ça allait mener. Au fil du temps, j'ai diversifié les sujets traités selon mes intérêts, ce qui rend ce blogue encore plus personnel plutôt que de s'orienter vers le webzine.

J'ai souvent vu des créateurs (artistes, auteurs, musiciens) lancer des projets qui étaient principalement consommés par leurs collègues de travail, famille et amis, pour les supporter et les encourager dans leurs démarches. Parce que j'ai lancé mon projet anonymement, même auprès de mes proches, j'ai une petite fierté de dire que ce n'est pas mon cas et qu'il connait un certain succès que je n'aurais pas pu soupçonner. En vérité, moins de 10 personnes de mon entourage connaissent son existence, soit parce que je leur ai dit ou qu'ils ont eu des indices leur permettant de le déduire. Qu'est-ce que ça serait si les autres le savaient ? C'est peut-être la prochaine étape logique dans cette expérience, question de voir jusqu'où ça peut aller.

Justement, je dois me pencher sur les objectifs futurs du blogue pour l'année à venir. Et en profiter pour me fixer des buts personnels et résolutions pour 2013... que j'essaierai tant bien que mal de tenir avant de les abandonner lâchement!