Mon expérience au Code Retreat

IMG_0040

Le 21 mai dernier, moi et deux autres collègues (Félix-Antoine Bourbonnais et Amélie Turgeon) avons organisé le premier Code Retreat à Québec. Tout cela a commencé en début février lorsque le nouveau conseil d’administration de la communauté Agile de Québec s’est réuni.

Lors d’un tour de table, il a été suggéré de tenter d’organiser cet événement. Je trouvais qu’il n’y avait pas assez d’événements de ce genre pour les programmeurs. En particulier des événements qui ne parlent pas de produit d’un vendeur ni d’une technologie particulière. Juste du code orienté-objet sans égards à un langage particulier.

Comme nous n’avions jamais fait ce genre d’événement, il nous fallait un facilitateur de calibre et qui en avait fait beaucoup auparavant: Corey Haines. Ce dernier habite Chicago  et le faire venir ici comporte certains frais, mais rien de trop astronomique. Donc, on s’est rendu compte que c’était possible de le faire venir. Dans notre planification, l’aide des commanditaires serait aussi importante et permettrait de définir le prix d’entrée, le lieu et la nourriture et les rafraichissements servis aux participants durant la journée.

Donc, au fil des mois tout s’est tranquillement mis en place pour réaliser l’événement qui fut un bon succès selon moi. Une grande majorité des participants ont apprécié. On a aussi pu noter certains aspects qui seront à améliorer la prochaine fois que l’on réalisera cet événement. Car nous avons bien l’attention d’en refaire un. Mais avec l’Agile Tour 2011 qui s’en vient cet automne, c’est bien possible que cela ait lieu qu’en 2012.

Aussi, organiser tout cela nous a permis de tester ou d’approfondir certaines technologies qui pourraient nous être utiles dans le futur :

  • WordPress: Nous avons fait un blogue pour contenir toute l’info de l’événement.
  • Eventbrite: Pour la gestion des inscriptions
  • Google Documents: Pour l’échange de documents entre les organisateurs
  • Survey Monkey: Définition et compilation des sondages d’appréciation de l’événement.

Au niveau du contenu de l’événement, j’ai aussi bien adoré. J’ai été surpris du nombre de personnes qui n’avaient jamais vraiment pratiqué le TDD avant. Mais c’est le but de ce genre d’événement, donner du temps pour pratiquer des techniques et langages qu’on n’a pas l’occasion de pratiquer au travail.  L’apport de Corey Haines a aussi été excellent. Cela nous guidera lors des prochains Code Retreat.  Car ce sera nous de jouer le rôle de facilitateurs la prochaine fois. J’ai bien aimé aussi mes différentes sessions de pairage. J’ai pu me remettre au C# (car je fais du VB.Net habituellement), voir un peu de Ruby à l’œuvre et appris quelques trucs ici et là. J’ai aussi montré l’outil Resharper à quelques-uns et du C# à un gars de Java. Bref, it was a blast !

En résumé, je suis bien content de voir qu’à partir d’une idée, et entouré de bonnes personnes, on peut voir un projet se réaliser. Il ne faut pas toujours avoir peur de commencer des choses, mais il faut plutôt oser le faire. On y découvre alors plein de choses…

Références :

Critique du livre: The Passionate Programmer

 

The Passionate Programmer: Creating a Remarkable Career in Software Development (Pragmatic Life)

Êtes-vous passionnés par votre travail ?

Je me suis intéressé à ce livre un peu par curiosité et je voulais voir ce qu’il pouvait apporter à ma carrière. Autrefois intitulé My job went to India: 52 ways to save your job dans sa première édition, le livre a changé de nom pour sortit un peu du titre controversé et bien refléter son sujet principal: comment avoir une carrière remarquable en tant que programmeur. L’auteur Chad Fowler est développeur connu au niveau international. Il travaille principalement avec le langage Ruby et le Framework Ruby on Rails.

Le livre est composé de 53 conseils de carrière divisés en 5 sections dont voici leurs descriptions:

  • Choisir son marché : L’importance de bien choisir dans quelles technologies et quel domaine d’affaires on veut évoluer. Ne pas se limiter à une seule technologie et bien balancer les risques potentiels.
  • Investir dans son produit : Mise à part la programmation, il est aussi important de bien connaître son domaine d’affaires. Si on ne connait pas trop certaines notions, se trouver un mentor. Si on veut voir si on connaître bien son affaire, essayer de l’enseigner à quelqu’un d’autre. Et ne pas oublier de pratiquer, pratiquer et pratiquer.
  • Exécution : Se rappeler régulièrement pour qui on travaille et s’assurer d’apporter de la valeur à l’entreprise. Noter ses bons coups et savoir comment gérer ses erreurs sont aussi important.
  • Marketing, pas seulement pour les cadres : Les perceptions sont importantes, c’est d’ailleurs le facteur principal dans les évaluations de rendement. Être présent et communicatif. Parler le langage de nos interlocuteurs.
  • Maintenir son expertise : Nous sommes déjà obsolètes ! C’est donc nécessaire de faire son plan de carrière,  de surveiller les tendances et de s’évaluer régulièrement

J’ai particulièrement aimé les sections qui parlaient des notions de Généralistes et de Spécialistes. L’auteur raconte qu’il est important d’être les deux. Je m’explique:

  • Être un généraliste: L’idée est ne pas être seulement un programmeur. Si l’opportunité se présente, ne pas hésiter à faire aussi de l’analyse, de l’architecture, de la charge de projet ou administrateur de base de données. L’idée est d’être utile à l’équipe, peu importe les tâches. C’est un peu la même chose au niveau de la technologie. Il faudrait normalement que nos habiletés transcendent les différentes infrastructures. Si on maîtrise bien une plateforme, ne pas hésiter à approfondir une autre.
  • Être un spécialiste: Bien connaître à fond un type de technologie est important. On ne parle pas ici de tout connaître, mais d’avoir une bonne profondeur pour connaître environ 80 % des situations qui pourraient se présenter au programmeur. Exemple: Si vous êtes un spécialiste .NET, vous n’avez pas d’excuses de ne pas connaître tout sauf du .Net. Il faut aussi savoir comment redémarrer un serveur IIS, faire l’installation d’un gestionnaire de code source ou corriger des problèmes de performance.

En conclusion, j’ai beaucoup aimé ce livre et d’ailleurs cela m’a pris seulement deux semaines à livre. Je le recommande à tous ceux œuvrant dans le domaine de la programmation, de près ou de loin. Les conseils de Chad Fowler, bien que pas nécessairement applicable pour tous, sont intéressants. On voit aussi à travers le livre ce qu’ont vécu l’auteur et les choix de carrière qu’il a du faire et pourquoi il les a faits. Bref, soyez passionné et remarquable !

Point négatif: On parle beaucoup du contexte américain et des emplois volatiles surtout en crise économique. Cela ne s’applique pas trop au Québec où l’on manque d’informaticiens un peu partout.

 

Mes points clefs:

  • Investir dans sa carrière est important. Il ne faut pas attendre que son employeur le fasse.
  • Être un généraliste et un spécialiste en même temps.
  • Bien connaître le domaine d’affaire de son employeur est un atout important.

 

Références :

Small Basic, un bel outil d’apprentissage

En bon papa, je voulais initier ma grande fille à la programmation et aussi lui expliquer un peu ce que je fais dans la vie.

En regardant l’environnement de développement Small Basic de Microsoft, qui est gratuit en passant, j’ai donc décidé de l’utiliser et de regarder un peu ce qu’il peut faire.

Premièrement, l’interface est très « bonbon » avec seulement quelques gros boutons. Beaucoup plus épuré que Visual Studio:

image

Par la suite, je remarque que l’intellisense est aussi très graphique:

image

J’aime bien.  Je trouve que cela rend facile de voir les possibilités du langage. Je regarde aussi dans la documentation pour me trouver quelques exemples intéressants et je tombe sur les commandes suivantes:

image

Eh oui, le langage “Logo” est inclus en partie dans le Small Basic avec la commande “Turtle”. Ce fut un de mes premiers langages de programmation sur mon vieux Commodore 64 il y a de ça de nombreuses années. D’ailleurs, cela ressemblait à ceci à l’époque:

c64-terrapin-logo-vers-a.jpg

Par la suite, je guide ma fille pour l’aider à écrire ses premières lignes de code et on y va avec la compilation:

image

Ce qui donne un petit déplacement de la tortue:

image

On a aussi repris un exemple de la documentation qui fait tourner la tortue pour faire un beau dessin. Voici le code:

image

Et son résultat:

image

Cool, n’est-ce pas  ?

D’ailleurs la documentation est assez bien faite et montre différents exemples. On peut aussi compiler le tout et faire des exécutables.  Avec cela, s’achève cette première leçon, elle préfère jouer sur l’ordinateur que de programmer semble-t-il… On va donc la laisser grandir un peu plus et on essayera une autre fois.

Références: