En général la journée commence entre 8h et 9h selon les développeurs (nous faisons du télétravail 3 jours par semaine). Notre premier point de la journée est à 9h15, où nous faisons un Daily Scrum Meeting, point de synchronisation entre tous les développeurs de l'équipe. Ensuite nous développons la journée, et nous avons des réunions régulièrement dans la semaine en fonction d'où on en est dans notre sprint Scrum. Nous utilisons la méthodologie Agile Scrum pour travailler, nous avons donc 5 meetings toutes les 2 semaines : la planification de Sprint, 2h toutes les 2 semaines où nous préparons (estimations, découpages, ...) et validons la liste des tâches à effectuer sur les 2 prochaines semaines. Le daily scrum meeting, tous les jours 15 minutes pour se synchroniser entre développeurs et suivre notre avancée commune. Les backlog refinements, 1h par semaine où on valide en équipe la faisabilité des futurs tickets à venir. La sprint review, 2h toutes les 2 semaines est le moment où on présente aux clients ce qu'on a développé et où on valide les futurs développements. La sprint retrospective, 1h30 toutes les 2 semaines est le moment où on fait un tour de ce qui a bien marché et mal marché pour en tirer des actions. Sinon nous travaillons en général chacun sur un ticket, nous utilisons Git comme contrôleur de sources, parfois nous faisons du peer développement (2 derrière un écran) si le sujet est important ou complexe. Nous faisons également des points de synchronisation quand c'est important, des meetings spontanés, nous discutons beaucoup de la technique et/ou de ce qui est le mieux pour le client ou l'utilisateur. Nous avons une checklist pour valider chaque développement : le PO doit avoir validé le rendu, un autre développeur doit avoir relu et validé le code, les tests doivent avoir été codés (nous avons des tests unitaires et d'interface E2E), la pipeline (process automatisé qui valide la qualité du code) doit être verte, etc. Notre stack technique est : Angular ,Ionic, Typescript, NestJS. Chaque développeur peut travailler sur n'importe quelle stack ou application.
On développe à 80% du front end, et à 20% du backend, car nous développons en parallèle des app mobiles et web une application backend. Cette dernière nous permet l'interfaçage avec toutes les API partenaire (achat de billet, réservations de bus, itinéraires, départs, etc.). Elle est en NestJS. Mais 80% du temps nous développons des applications Angular et Ionic, donc en HTML/CSS/Typescript.
Je suis développeur depuis 2008, je suis passé leader technique en 2014, puis en 2018 j'ai quitté ma région pour devenir développeur et Scrum Master dans ma société actuelle (actuellement je ne fais plus le Scrum Mastering, uniquement du développement et de l'animation technique).
J'ai travaillé tout d'abord en alternance dans une société à côté de Dijon, Géosphère, où je faisais du développement PHP et C# d'applications de cartographie pour les communes. Ensuite j'ai rejoint Paris où j'ai travaillé sur les sites web de Vente-privée, le site de vente de produits en ligne à bas prix. (C# ASP.Net) J'ai ensuite rejoint Sarenza, où je travaillais sur leur site web de vente de chaussures (C# ASP.Net) J'ai ensuite fait 4 ans chez Talentsoft où j'étais Leader Technique, société chez qui je travaillais sur l'application Hello Talent, une application de recrutement et de sourcing de candidats, application SPA en C# ASP.Net et KnockoutJS. Finalement j'ai rejoint OpenIT où je suis. Je n'ai jamais été indépendant car même si l'aspect financier peut être très intéressant, c'est beaucoup de stress en plus (devoir gérer l'administratif, les finances, le temps, les clients) et beaucoup de tâches qui ne sont pas liées au développement et ce que j'aime, c'est développer !
Plus ou moins, je suis développeur Senior donc on me pose beaucoup plus de questions d'architecture qu'avant, avant c'était surtout moi qui les posait. On voit quand même énormément de changements dans le monde du développement, les technologies évoluent vite, et si vous m'aviez dit en 2008 que Javascript était le langage du futur, je ne vous aurait pas cru ! Je sais que lorsque j'étais jeune, en tant que développeur, je ne jurais que par la technologie, avoir les dernières technologies pour développer le plus vite possible, je participais à des conférences (techdays microsoft par exemple) régulièrement. Aujourd'hui je suis un adepte du fait de développer du code simple et clair, que n'importe quel développeur peut reprendre. J'ai beaucoup amélioré mes compétences en documentation, en tests, en pertinence du code, je vois plus facilement les erreurs qu'avant, je débug mieux, je me pose de meilleures questions, et je sais être plus pragmatique et juste dans mes analyses.
Développer ! Je sais que c'est quelque chose qui parait pourtant évident, mais ce que je veux dire c'est : développez pour vous, développez pour votre quotidien, simplifiez-vous la vie. Vous aimeriez bien avoir une application pour vos courses ? Développez-la. Vous aimeriez avoir une application pour lire vos mangas préférés ? Développez-la. Vous aimeriez faire une app web pour stocker et retrouver vos sites utiles et préférés ? Développez-le. Je suis devenu, je pense, un bon développeur, car j'ai développé, au fil des années, des dizaines d'applications. J'ai développé mon propre moteur de blog. J'ai développé une application pour lire mon manhwa préféré (Solo Leveling). J'ai développé une application pour suivre le sommeil de mon bébé. J'ai développé des jeux vidéos sur mon temps libre, dont un qui a même gagné une Game Jam. J'ai développé des apps de jeux pour mes soirées entre amis. Enfin, lorsqu'on fait passer un entretien d'embauche à un développeur, on voit immédiatement quelqu'un qui développe régulièrement, et quelqu'un qui développe juste pendant ses cours de développement. Mon second conseil serait Faites des recherches. Quelle est la bonne façon de faire ça ? Pourquoi utiliser cette techno plus qu'une autre? Comment rendre mon code plus rapide ? Se concentrer sur l'idée de progresser, d'apprendre des choses, et de développer régulièrement, fera de vous un super développeur.
Du plus important au moins important : Etre pragmatique, du code parfait qui ne se lance pas ou qui ne répond pas au besoin du client, ne sert à rien. Le mieux est l'ennemi du bien. (dans le sens où vouloir faire le code parfait conduit souvent à du code inutile, du code). Savoir se remettre en question, accepter la critique, admettre quand on ne sait pas, faire des recherches, douter de soi, faire des tests, éprouver les limites de ses connaissances, mettre de côté son égo (mais pas trop) quand on travaille avec des gens plus compétents, ... Etre efficace, régler son IDE, apprendre à développer vite, apprendre à débugguer vite, utiliser les raccourcis clavier, prendre des notes, documenter ce qu'on fait, ses procédures, son code, bookmarker les articles intéressants, ... L'à-côté du code est aussi important que le code lui-même, savoir tester, savoir documenter, savoir poser un meeting quand nécessaire, savoir poser des questions quand on ne comprend pas, savoir dire non, savoir faire de l'architecture, ... Ecrire du code de qualité, oui c'est important, mais moins que les points précédents à mes yeux Faire de la veille, se tenir à jour de ce qui se passe sur ses technos.
Pas forcément. Il y a beaucoup de développeurs pour qui ce travail est alimentaire, et c'est quelque chose de normal, on a tous des goûts et appétences différents. Mais il y a aussi beaucoup de développeurs pour qui ce travail est une passion. Ce qu'il est important de comprendre c'est que le développement c'est très intéressant, c'est à la fois de l'art et du travail pratique. Quelque chose de pratique, de simple, et d'un peu magique. Mais selon son poste, les tâches en cours, les projets en cours, ... parfois ça peut être difficile au quotidien. C'est un travail qui peut aussi parfois être incroyablement frustrant. Passer des jours et des jours pour corriger un bug peut parfois rendre un peu fou. Egalement, on subit beaucoup en tant que développeur. On subit les mauvais choix des clients, les mauvais choix de la direction, les mauvais choix des autres développeurs. On passe 80% de notre temps à relire du code (comprendre pour débugguer ou évoluer), et seulement 20% de notre temps à coder. Ce qui est parfois usant.
1. Son côté humain. Je préfère travailler avec des développeurs
moyennement compétents techniquement, mais très compétents humainement
(personnes de confiance, gentilles, à l'écoute, présentes en cas de
crise, ...) qu'avec une équipe très compétente techniquement, mais
incompétent humainement (méchants, cassants, hautains, mauvais en
communication, ...).
2. Sa capacité à faire tout ce qui est satellite au développement.
En effet, tous les développeurs du marché savent développer. Mais seule
une poignée saura bien tester son code. Saura demander de l'aide. Saura
documenter ce qu'il a fait. Saura poser les bonnes questions. Saura
proposer un meeting quand nécessaire. Saura se remettre en question.
Saura proposer des améliorations produit ou d'architecture. Saura
améliorer les process et scripts auxquels il touche. Saura se rendre
disponible quand c'est nécessaire.
Galerie d'un travail personnel de Tommy Roughol