#ExpériencePro : Bilan des 2 mois dans mon nouveau Job

Table des matières

#ExpériencePro : Bilan des 2 mois dans mon nouveau Job

Dans mon précédent article, je vous annonçais que je changeais de job et je vous expliquais comment j’allais me préparer pour mon arrivée dans l’entreprise, chose sur laquelle vous pourriez vous inspirer si vous êtes dans ce cas là.

Pour rappel, j’ai quitté la boîte où j’ai travaillé pendant près de 8 ans en commençant comme « Web Developer » et en finissant « Chef de Projet ». Mes raisons : l’esprit d’entreprise et l’évolution envisagée par les dirigeants n’étaient plus en phase avec mes valeurs et mes principes dans ce métier. La structure que j’ai intégrée au mois de septembre 2018 est une startup qui a plus de 5 ans d’existence avec un management très souple et un esprit d’entreprise « Work Hard, Play Hard ».

Je vais donc vous partager le bilan de ces 2 mois que je découperais volontairement en 3 parties.

Les 15 premiers jours de septembre : « Je n’y connais rien, je suis un noob ! »

Le titre résume assez bien la situation dans laquelle j’étais et je vais bien entendu rentrer un peu plus dans les détails. Ayant un profil « senior », j’ai dû m’adapter très vite et apprendre très rapidement à plusieurs niveaux. J’ai commencé par la reprise d’un projet historique.

Les langages de programmation

Il y a tout d’abord les langages de programmation. Plusieurs langages de programmation sont utilisés au sein de l’entreprise. Pour les applications historiques (plus de 2 ans d’existences), les technologies utilisées sont du AngularJS pour le frontend et du PHP pour le backend.

Les nouvelles applications utilisent des technologies plus récentes. Pour le frontend, on est toujours sur de l’angular mais sur des versions plus avancées (à partir de Angular 4), mais par contre pour le backend c’est plutôt du Node.js. Ce qui est commun c’est le moteur de base de données qui est le NoSQL et la technologie choisie est le MongoDB.

Ayant fait du PHP pendant plus de 10 ans, cela ne m’a pas posé de problème. Pareil pour AngularJS que j’ai surtout utilisé avec Ionic 1 (d’ailleurs il y a quelques applications mobiles qui tournent sur Ionic 1). Ce qui m’a donné un peu du fil à retordre c’est MongoDB dont je connaissais de manière théorique. Et j’ai réellement découvert en analysant et en manipulant l’architecture complexe des données de l’application qui est en place depuis 5 ans.

Architecture applicative

J’ai dû également découvrir une toute nouvelle architecture applicative. Ici pas de MVC ! L’application web est constituée de 2 applications : une application de type API et une application de type front. L’application front fait des appels à l’API pour récupérer, insérer, modifier et supprimer des données. Le gros avantage de cette architecture c’est que le backend n’est créé qu’une seule fois et donc qu’il est ainsi possible de créer autant de front que l’on veut. Voici un petit schéma montrant les possibilités :

L’architecture je l’ai bien comprise, mais l’orchestration entre le moteur et les règles définissant l’API, le routing côté front ainsi que la définition des appels à l’API n’a pas été une mince affaire dès le début. À côté de cela, j’ai dû appréhender un tout nouvel environnement de travail.

L’environnement de travail

Mon ancien job était des adeptes de l’environnement Windows tant au niveau réseau qu’au niveau programmation. On programmait, on testait et l’on déployait sur Windows, pas sur Linux. C’était tout nouveau pour moi sur le plan professionnel, mais fort heureusement le monde de Linux et de MacOS m’était très familier. On développe sur des MacBook Pro et on déploie sur un environnement Linux basé sur CentOS.

Pour le code, il est hébergé de façon privée sur GitHub et il est structuré par le workflow Git Flow. Un système d’automatisation a été créé autour de GitHub pour faciliter les tests tant pour le développeur que pour les clients. J’ai donc dû apprendre Heroku 🔗, la solution choisit par l’entreprise pour l’automatisation de déploiement d’environnement de test. On peut bien entendu aller plus loin en déployant des environnements de production sur l’hébergement d’Heroku 🔗 (ce qui n’est pas le cas chez nous). En clair pour chaque correction de bug, nouvelle fonctionnalité ou nouvelle version de notre application Heroku 🔗 nous déploie une version dédiée dont le lien est directement accessible depuis GitHub. C’est un gain de temps énorme et cela permet une aisance pour soumettre ce que l’on a fait au client.

Pour valoriser notre temps de développement par projet, nous utilisons l’outil Toggl 🔗. Cet outil est très simple d’utilisation : un simple clic pour déclencher le timer puis on choisit le projet sur lequel on travaille et l’on décrit brièvement sur quoi on travaille. Une extension existe pour Google Chrome permettant de déclencher des timers sur certaines URL encore plus rapidement sans renseigner le descriptif de la tâche. C’est une habitude à prendre d’utiliser cet outil lorsque l’on travaille sur quelque chose (peu importe si c’est de la programmation ou non).

Par exemple, sur GitHub nous nous positionnons sur une issue et à partir de celle-ci on déclenche le timer. Toggle renseigne ainsi l’information que l’on travaille sur une issue en particulier automatiquement. Il est capable de détecter que votre timer n’est pas activé et vous suggère par des notifications sur le bureau de l’activer. Il est capable aussi de détecter les inactivités sur votre poste et vous le notifier pour savoir si vous souhaitez tout même comptabiliser ce temps d’inactivité dans votre tâche ou non.

Immersion dans le métier

Je pense que c’était la partie la plus compliquée à assimiler en si peu de temps. J’ai assimilé le métier de mon client, mais aussi son mode de fonctionnement, son jargon, son histoire, ses logiques. Mais aussi comprendre les mécanismes mis en place dans l’application suivant la volonté du client. Ce n’était pas si simple, car le client a un jargon très technique (c’est un fabricant de matériel médical). Je suis même partie une journée chez le client pour visiter leur infrastructure et m’immerger plus profondément dans son monde.

Cumulons le tout !

Pour résumer en moins de 15 jours, j’ai dû apprendre :

• les spécificités et le fonctionnement de MongoDB sur une application en production depuis 5 ans
• une nouvelle architecture applicative
• un tout nouvel environnement de travail
• m’immerger dans le métier de mon client

Et tout cela de manière cumulée. J’avais tellement de choses à apprendre et par moment j’avais l’impression d’être un débutant et d’être passé à côté de pas mal de choses. Une très grande frustration m’a gagné et c’était une grosse remise en question.

Avec le recul, cela faisait beaucoup à assimiler et pour tenir la cadence je ne me suis pas ménagé. J’étais fatigué moralement après seulement quelques jours, mais j’aimais ça. J’étais tellement pris dans le mouvement que je continuais de travailler sur mon temps personnel pour assimiler et combler certaines de mes lacunes. C’était vraiment très intense !

Les 15 derniers jours de septembre : « diversification de ma fonction ! »

J’ai été engagé comme Lead Developer et le moins que l’on puisse dire c’est qu’au départ, j’ai surtout joué le rôle de développeur en mode apprentissage. Il était donc temps naturellement de commencer à explorer d’autres projets et connaître plus précisément le travail des autres développeurs.

J’ai commencé à reprendre un autre projet tant sur l’aspect technique que l’aspect gestion de projets. Même si ce n’est que du support dans un premier temps, le but est de pouvoir proposer une évolution à la solution existante mise en place. J’ai également commencé à travailler pour un grand groupe international dans la réflexion du changement de leur SI suivant leurs problématiques métiers, leurs attentes et leur budget. Le but est de leur proposer plusieurs solutions qui leur correspondent tout en les challengeant.

Je suis également un autre projet, d’un peu plus loin pour le moment, pour un autre grand groupe.

Je discute également beaucoup avec les autres développeurs pour connaître les problématiques du moment, les choix effectués au niveau de tout de ce qui est mis place au sein de l’entreprise. Mais surtout, je m’intéresse à leurs projets ainsi qu’à leur travail.

Pour cette deuxième quinzaine, j’ai continué à prendre mes marques et j’ai commencé à observer tout en apprenant d’eux.

Le mois d’octobre : « Place à l’action ! »

Le mois de septembre fut très intense où j’ai appris énormément de choses en peu de temps. M’habituant peu à peu à mon environnement, je commence à prendre de l’aisance et de l’assurance dans ce que je fais. J’organise mon travail autour des tâches qui me sont confiées en interne et les retours de mes clients. Et je commence sérieusement à cogiter sur ce que j’observe et ce que je découvre chaque jour.

Naturellement, j’ai commencé à faire jouer mon expérience et à suggérer des améliorations sur la gestion de projets ainsi que sur la programmation de manière générale.

Par exemple dans la gestion de projets, j’ai commencé à suggérer qu’il serait intéressant impliquer le développeur au moment de deviser un projet ou une fonctionnalité (à condition de connaître qui travaillera dessus à l’avance). J’ai remarqué en effet qu’il était souvent frustrant et stressant pour un développeur de découvrir un projet au moment même où celui-ci commence. Le choix, les délais de réalisation, les technologies ainsi que la façon de faire lui est directement imposée. Je fonctionne donc sur le principe de me projeter avec le ou les développeurs qui pourront être amenés à travailler sur le projet, car au final c’est eux qui accompliront le travail. Et il y a 2 avantages de faire cela :

• Le premier avantage est que l’on obtient bien avant le projet le ressentie du développeur. En effet suivant ses capacités et sa façon de faire, il pourra nous indiquer de manière informelle si l’estimation et si les préconisations choisies sont en adéquation avec le projet. Mieux, il pourra challenger ce qui a été pensé pour le projet et lui apporter une autre vision. * Le deuxième avantage est qu’en l’impliquant pendant l’élaboration du projet il pourra ainsi cogiter dessus inconsciemment et lorsque qu’il sera en charge de travailler sur le projet, la réflexion en amont lui aura donné une vision d’ensemble dès le départ qui lui donnera plus de faciliter ainsi que d’aisance dans sa réalisation

Un autre exemple plus sur le plan technique de la programmation. Comme je l’ai dit plus haut, MongoDB m’a donné un peu du fil à retordre surtout ayant travaillé avec du langage SQL uniquement pendant plus de 10 ans. Au-delà de ça, j’ai vu et compris les possibilités de MongoDB, mais surtout la façon dont il était utilisé par mes collègues. J’ai ainsi mis à profit mon expérience provenant des bases de données relationnelles. Chez MongoDB, il est possible de définir des schémas (l’équivalent des structures des tables en SQL) en validant les données depuis son langage de programmation, mais aussi directement sur une collection. Il est également tout à fait possible de cumuler les 2.

Par facilité et rapidité de mise en place au niveau de programmation, mais également lors des déploiements, la validation des données par schéma se fait uniquement par le code hors j’ai remarqué 2 véritables inconvénients dans cette pratique.

• Le premier c’est la cohérence des données dans MongoDB en supposant que tous les développeurs amenés à travailler sur un même projet soient des ultras disciplinés et assidus. En effet, la validation des données par un schéma dans le code n’est pas obligatoire en soi. Il est donc tout à fait possible de ne pas les utiliser volontairement ou involontairement par oubli par exemple. De même, qu’il est tout à fait possible de valider les données entrant dans une collection par des schémas différents * Le deuxième c’est l’ambiguïté de la structure des données. Comme la validation des données se fait au niveau du code et peut être ignorée, rien ne certifie à 100% que le schéma défini dans le code est forcément le bon. À ce titre, on peut dire qu’il n’y a pas une base commune sur laquelle chaque développeur peut se baser

J’ai donc suggéré pour tous les nouveaux projets de se forcer tous ensemble à instaurer dès le départ un schéma sur chaque collection que l’on sera amené à créer tout en gardant la simplicité de déploiement en production.

Pour résumer et pour conclure

Je pourrais donc résumer mes 2 derniers mois en 3 actions : j’apprends, j’observe et j’agis. Même si j’avais une solide expérience et une aisance dans ce que je faisais, le changement de l’environnement et des technologies m’a quelque peu déstabilisé au départ et surtout remis en question pour finalement surmonter le challenge que je m’étais imposé en intégrant l’équipe.

Je voulais très sincèrement partager mon expérience professionnelle pour vous mettre en confiance que peu importe si c’est votre premier job ou non il y a toujours un temps d’adaptation et il est impossible de pouvoir tout connaître.

Si vous souhaitez avoir quelques précisions sur certaines parties ou si vous souhaitez que je vous partage un peu plus souvent ce genre d’expérience soit sous forme d’articles ou même d’un podcast par exemple, n’hésitez pas à me le faire savoir en commentaires.