But really the details of this are not that important. What I believe is really, really important is the ability to critically examine your job and projects and examine their worth.
What normally happens is that you get a group of people and tell them to work on project X. They will iterate through features and complete features. And repeat and keep going. And if you don’t stop at some point and critically examine what is going on, it will keep repeating. People will find new features, new enhancements, new areas to add to the project. Just as they have been trained to do so. And the project will keep growing.
That’s a perfectly normal thing for a team to do. It’s harder to call a project done, the features complete and realize that there might be an end.
Timeline
- Juillet-septembre 2013 : contrat pour travailler sur les paiements du Marketplace en Python/Django à plein temps ;
- Début octobre 2013 : participation au Mozilla Summit ;
- Octobre-novembre 2013 : travail sur une implémentation de référence pour les pourvoyeurs de solutions de paiement en NodeJS à mi-temps ;
- Décembre 2013 : mois de « congé » pour accueillir Alexandre ;
- Janvier-décembre 2014 : travail pour le site des add-ons avec Mathieu et Yohan à tiers-temps.
Ce qui s’est bien passé
- la montée en compétence ET en humilité sur Python et JavaScript et la découverte de l’intérêt des revues de code, je n’envisage plus de travailler sans ;
- la flexibilité qui m’a permis de bosser quand je voulais et combien je voulais pour avoir le temps de m’occuper de mon fils souvent au cours de la dernière année (et de payer au moins un salaire) ;
- l’adrénaline liée au fait de travailler sur un site très populaire (~1 milliard de requêtes/jour) et la contrainte de performance associée ;
- l’équipe francophone pour travailler à 3 sur le site des add-ons, parfois en pair-programming distribué, parfois en présence dans des coins sympas.
Ce qui pourrait être amélioré
- le manque de collaboration, c’est vraiment ce qui m’a choqué en arrivant dans une équipe distribuée (attention cela s’applique uniquement aux équipes par lesquelles je suis passé, pas forcément toutes les équipes Mozilla) ;
- la communication/stratégie interne, je ne peux pas dire grand chose publiquement là-dessus à part ce qui fuite mais certains épisodes ont été clairement décevants ;
- l’absence de stratégie claire sur les projets qui nuit grandement à la motivation nécessaire à tout travail ;
- mon anglais, j’aurais pu profiter de cette période pour que ma communication dans cette langue soit plus fluide.
Actions pour la suite
- éviter les projets complexes (un billet est à venir là-dessus) ;
- éviter les projets sans stratégie bien définie ;
- réussir à travailler sur un projet commun avec scopyleft.
Au final c’était vraiment une très bonne expérience car cela m’a permis de réaliser à quel point je n’étais pas fait pour travailler dans une entreprise de cette taille. J’ai pu expérimenter de nouvelles technologies et de nouvelles façons de collaborer. J’ai pu confirmer certains points sur la relation qu’ont les geeks au travail qui feront peut-être l’objet de futurs billets.
PS : je redeviens disponible pour de nouvelles aventures via scopyleft si vous voulez que l’on travaille ensemble, je suis toujours motivé par des projets utiles et citoyens ainsi que la transmission de mes savoirs.
