Récemment, j’ai lu des articles sur l’évolution de carrière des ingénieurs développeurs de logiciels. Cela m’a donné le sentiment qu’il n’y a qu’un seul type d’ingénieur et que ce métier n’est pas compris dans les entreprises. Dans le modèle, on trouve généralement une approche linéaire de l’évolution : Ingénieur Niveau 1, …. Ingénieur niveau 3, ingénieurs seniors. Certains modèles proposent un modèle d’évolution intéressant après le niveau senior. Il suggère que vous pouvez aller dans plusieurs directions : business, commercial, produit, management, processus….. C’est intéressant, mais cela suggère qu’après avoir été un ingénieur senior, il y a peu d’évolution dans le monde technique.
Aujourd’hui, mon sentiment est qu’il n’y a pas qu’un seul type d’ingénieur, et que vous pouvez avoir cette évolution plus tôt dans votre carrière.
Prenons un exemple : vous commencez comme développeur frontal, en apprenant VueJs (ou le langage de votre choix). Après un certain temps, vous devenez un bon praticien de ce langage. À ce stade, au début de votre carrière, vous avez déjà beaucoup de choix :
devenir un chef d’équipe, en essayant d’encourager et de faire progresser une équipe vers l’acquisition
de meilleures pratiques
devenir un leader technique, en tirant les pratiques de l’équipe dans une seule direction
devenir un expert VueJs, en développant vos compétences VueJs
devenez un expert front-end en développant votre expertise angulaire et VueJs
devenir un ingénieur full stack en apprenant les pratiques et le langage du back-end
devenir un développeur avec des sensibilités : Ux, produit, agile, XP, …..
Et bien sûr, vous pouvez changer au cours de votre carrière.
Ainsi, je pense que l’évolution n’est pas linéaire, vous pouvez expérimenter de nombreux chemins, vous pouvez changer votre domaine principal (Front to back, data, devops, …. ).
Peu de développeurs de logiciels évoluent, en fait certains tombent des rails et abandonnent leurs rêves, non pas parce qu’ils ne sont pas assez intelligents et certainement pas parce qu’ils ne sont pas assez qualifiés et expérimentés, mais surtout parce qu’ils n’ont pas réussi à embrasser et survivre les différentes étapes qu’un développeur de logiciels subit pour évoluer, quel que soit le langage de programmation qu’il choisit d’apprendre et de devenir un expert.
Les différentes étapes d’un ingénieur logiciel ne sont pas différentes des étapes de la maturité humaine ni de celle de la maturité dans n’importe quelle carrière. Certains pourraient dire : leurs carrières sont plus difficiles et plus compliquées, mais c’est en fait chacun pour soi parce qu’en fin de compte, les étapes varient, mais la douleur, les tests d’endurance et la persévérance sont similaires à tout être humain essayant d’avancer dans sa carrière ou son métier.
Étape fondamentale :
La première étape est ce que j’appelle l’étape fondamentale : où vous commencez à apprendre quelque chose de nouveau en étudiant les concepts fondamentaux de la technologie, sur laquelle plus vous commencez à comprendre les fondamentaux, vous devenez capable d’appliquer les connaissances pratiques pour construire de petites applications et devenir un novice. Mais on ne peut jamais vraiment passer cette étape sans montrer une certaine forme d’intérêt dans le langage de programmation qu’ils veulent apprendre. Car sans intérêt, il est pratiquement impossible de même commencer à apprendre quelque chose de nouveau.
Novice :
La deuxième étape n’intervient que si vous avez persévéré dans les bases, appris l’art de l’étude, de la recherche et de la pratique de ce que vous apprenez, et compris pleinement les concepts de base. à ce stade, vous commencez à approfondir vos connaissances au-delà des fondamentaux de base et des applications en plongeant plus profondément dans peut-être dans ce cas, dans le cas d’une petite application, en appliquant des approches plus avancées à votre petite application, en ne se contentant pas d’écrire de grandes classes avec un million de lignes de code, mais en écrivant des classes dédiées avec des fonctionnalités dédiées et en appliquant une certaine forme d’héritage de vos super classes à vos sous-classes. Et si votre programme peut compiler avec succès et accomplir la tâche pour laquelle vous l’avez développé, sans rencontrer les ennuyeux bugs d’exécution et peut-être un ou deux repo git pour les pousser…, et que vous avez définitivement maîtrisé les bases de la programmation orientée objet aux étapes fondamentales et les avez appliquées assez bien dans vos petites applications, alors, eh bien, bienvenue au stade de novice.
À ce stade, un novice peut être employé comme développeur de logiciels et construire une application conviviale parfaitement fonctionnelle. C’est à ce stade que vous vous retrouvez propriétaire d’un incroyable compte GitHub rempli de superbes interfaces utilisateur avec des fonctions backend sympas et des applications fonctionnelles que tout étudiant en informatique ou en génie logiciel est prêt à mettre la main dessus pour terminer ses travaux pratiques sur la calculatrice ou le robot martien.
Évolution :
La troisième étape est ce que j’appelle « l’évolution » – et cette étape exige un état d’esprit persistant, par lequel vous continuez à construire des choses et à apprendre et à appliquer ce que vous avez appris à ce que vous construisez. À ce stade, plus vous faites, plus vous évoluez et l’évolution stipule que « plus vous faites quelque chose, plus vous vous améliorez », oui, en fait, plus vous vous améliorez, plus vous devenez compétent pour construire ce que vous construisez. À ce stade, on est plus près de devenir un professionnel, un spécialiste et un soi-disant expert. Mais on ne peut jamais vraiment arriver au stade de professionnel, de spécialiste et d’expert si on ne s’accroche pas assez longtemps pour développer une passion profonde pour le sujet, l’artisanat, la technologie ou l’art. Car c’est la passion qui nous conduira au stade de la créativité, où l’être humain commence à explorer son subconscient créatif et à développer des idées novatrices en appliquant les compétences acquises au cours des étapes précédentes.
à ce stade, les connaissances de base acquises lors de l’étape fondamentale deviennent un trait naturel (comme un bonjour qui roule facilement sur la langue), l’étape du novice évolue en une combinaison de connaissances et de compétences de novice à « je veux continuer à faire ça », « j’aime ça », ce qui donne naissance à une immense passion : d’où l’étape de la passion. Malheureusement, l’intérêt seul à ce stade n’est pas suffisant pour réussir en tant qu’ingénieur logiciel ou développeur de logiciels. C’est la passion qui vous conduira et la passion qui vous permettra de continuer.
A ce stade, on devient plus ou moins obsédé par ce que l’on fait, à un point tel que rien d’autre ne compte dans ce monde, rien d’autre que sa passion et on ne semble pas pouvoir passer un jour sans le faire. On a même posé un lapin à son rendez-vous pour résoudre un bug dans son code. On a oublié de manger son déjeuner et les heures passent comme si la planète avait soudainement accéléré sa rotation. On embrasse le « Flow ». On vit dans un monde branché où rien d’autre n’existe que ce que l’on a sous les yeux, et une profonde capacité à se concentrer pendant de longues heures prend forme. On devient un zombie.
Combattre ou fuir :
vous avez développé une immense passion (votre Github compte même 20 dépôts avec des applications sympas), et vous avez maintenant tant d’idées géniales pour diverses applications logicielles, vous avez même mis un point d’honneur à lire autant d’ebooks, d’articles et de blogs sur le développement de logiciels que possible, c’est devenu un processus naturel pour vous, quelque chose d’aussi naturel que de vérifier votre courrier chaque matin. Maintenant, vous avez développé l’œil qui voit tout pour identifier les problèmes de votre communauté et trouver des idées créatives pour les résoudre en appliquant vos compétences technologiques. Concevoir un site Web est comme dessiner un bonhomme de bois pour vous, construire une API est comme faire un gâteau pour grand-mère et écrire quelques requêtes SQL est devenu un défi amusant. C’est cette étape.
C’est le stade où vous voulez même aller jusqu’à créer un logiciel qui active un petit réveil qui vous rappelle que vous devez nourrir votre chat dans 2 minutes, sinon il va venir dans votre zone de travail et miauler si fort que vous perdrez votre concentration sur ce que vous êtes en train de faire (perdre votre flux).
Vous saisissez les cornes d’un problème, dessinez quelques croquis (Lo fi wireframes), puis vous décidez de les rendre plus réalistes en concevant des wireframes hi-fi et des interfaces utilisateur dans sketchapp et peut-être même en allant jusqu’à la conception UI/UX dans AdobeXd. L’idée a pris vie, vous avez un prototype brillant, sur lequel n’importe quelle entreprise milliardaire se jettera pour vous l’acheter et vous êtes excité à l’idée de commencer à écrire du code pour ce projet.
Vous avez appris à mener des recherches, vous avez appris de nouvelles choses très rapidement et vous les avez appliquées aux stades fondamental, évolutif et novice, et vous êtes prêt à conquérir et à conceptualiser votre idée brillante et c’est parti…coder comme un fou homme, débogage, recherche, codage, débogage, recherche, codage, stackoverflow est même devenu votre meilleur ami…. est un défi et vous l’appréciez en regardant votre application logicielle prendre vie chaque jour qui passe.
Vous alternez entre le stade de novice et le stade d’évolution pour mener des recherches approfondies et découvrir des bibliothèques sympas pour rendre votre application plus belle, plus animée et plus fluide. Un an passe et vous êtes toujours en train de vous acharner sur cette chose alors que vous avez rencontré de multiples bugs d’exécution et cela vous a placé au bord du monde des frustrations et vous voulez juste réparer cette chose et la faire fonctionner. Vous refusez d’abandonner. Vous continuez à apprendre de nouvelles façons de conquérir votre bête, de nouvelles façons d’appliquer votre code pour faire fonctionner votre application et peu importe qu’il pleuve, qu’il neige, qu’il fasse froid, qu’il fasse chaud ou que vous ayez des douleurs musculaires dans les jambes et les bras à cause de votre position assise de 12 heures, vous vous poussez au-delà de vos limites, vous lancez votre application et vous vous tenez enfin debout comme un homo sapiens et vous devenez un développeur de logiciels expérimenté.
Expérience :
Maintenant que vous êtes arrivé au stade expérimenté… vous vous sentez ainsi parce que vous avez finalement déployé une application sur playstore ou appstore et que les gens l’aiment.
Vous avez même décroché quelques emplois en tant que freelance et tout cela parce que vous avez conquis la bête au stade de la lutte ou de la fuite. Vous êtes extrêmement confiant dans vos capacités et vous refusez même les emplois mal payés, vous avez même la possibilité de le faire. C’est génial !!! Vous êtes sur un nuage au moment où nous parlons et vous vous amusez énormément.
Vous passez l’entretien téléphonique avec brio et l’entretien en face à face avec votre connaissance du sujet. On vous donne ensuite un test technique pour développer une simple application de liste qui affiche une liste d’articles à partir d’un serveur en analysant le json d’une URL hébergée sur Amazon Web Services que la société vous a envoyé. Vous vous lancez dans l’aventure avec confiance et glamour. Vous construisez une belle interface utilisateur pour augmenter vos chances de battre les autres candidats et de devenir le champion. Puis vous vous asseyez et reprenez votre routine de travail habituelle, à savoir la maintenance des applications que vous avez lancées, en attendant le feedback de l’employeur potentiel.
Vous commencez à regarder votre liste de contrôle pour l’entretien pratique :
Développer une application de liste : Vérifier
Analyser les éléments de la liste à partir de cette url en tant que json : vérifié.
et en plus, vous avez conçu une belle interface utilisateur pour cette application : Check
L’application a été poussée sur github : Check
Vous avez même créé une API personnalisée responsable des opérations CRUD en tant que middleware pour les données et votre application: Check Check Check
soumettre le repo url de l’application sur github en une semaine par email à l’équipe technique :
Eh bien, vous avez terminé en 3 jours et soumis: Check – Check Bonus Check
Mais qu’est-ce que j’ai fait de mal, pourquoi m’ont-ils rejeté !!!!!!
Vos cheveux commencent à tomber et vous vous demandez où vous vous êtes trompé, qu’est-ce qu’ils veulent dire par manque d’architecture et de tests, j’ai exécuté cette fichue chose et elle fonctionne. Vous tombez dans un gouffre de dépression et une crise de colère, et toute personne qui croise votre chemin avec un sourire chaleureux est votre ennemi numéro un.
Mais finalement, vous vous calmez, vous décidez de lancer des insultes télépathiques à l’entreprise qui vous a rejeté et vous commencez à postuler pour d’autres emplois.
Vous continuez à atteindre les étapes pratiques, mais vous n’arrivez pas à décrocher un emploi : qu’est-ce que je fais de travers, vous demandez-vous.
Vous faites alors des recherches sur l’architecture :
Modèle en couches
Modèle client-serveur
Modèle maître-esclave
Modèle tuyau-filtre
Modèle de courtier
Modèle peer-to-peer
Modèle de bus d’événements
Modèle de contrôleur de vue-modèle
Modèle de tableau noir
Modèle d’interpréteur
et les appliquer à chaque entretien pratique que vous passez. Mais vous êtes toujours rejeté 100 fois.
Et puis un jour, vous êtes enfin embauché. Et on vous a donné un poste de junior pour une raison quelconque et ça vous énerve, mais vous prenez le travail quand même dans l’espoir de devenir le meilleur et d’éliminer les seniors dans la société et un jour prendre leurs emplois en tant qu’ingénieur logiciel senior.
Semaine 1 :
au travail : Vous êtes confronté à des réunions debout que vous trouvez ennuyeuses mais auxquelles vous devez participer malgré tout, car il s’agit d’une nouvelle application sur laquelle vous et votre équipe allez travailler.
Semaine 2 :
Vos coéquipiers vous reprochent de ne pas utiliser de packages, d’interfaces et de ne pas appliquer l’approche de la programmation réactive, et ils vont même jusqu’à vous demander de réduire la taille de votre code en utilisant plus d’héritage dans vos classes. 6 Vous avez appris à automatiser les processus logiciels, à écrire des tests unitaires et automatisés et vous avez même une maîtrise professionnelle de l’application de l’architecture à vos applications et vous en réalisez l’importance. Vous avez même Jira, Confluence et Gitflow comme vos trois petits patrons pour vous assurer que votre code n’est pas un dépotoir de classes multiples partout qui sont fonctionnelles mais difficiles et coûteuses à maintenir et boguées.
Année 1 :
Vous vous rendez compte que vous auriez pu décrocher un emploi bien rémunéré il y a un an, si seulement vous aviez été assez patient pour maîtriser les approches de l’industrie et leurs outils de développement de logiciels. Mais ce n’est qu’un passé oublié, et vous vous accrochez fermement à votre emploi et profitez de chaque jour où vous apprenez une nouvelle chose. Vous réalisez même le pouvoir de la réutilisation et la puissance de la création de bibliothèques pour vos applications. Votre compte github personnel est même devenu célèbre, et fleurit de petites bibliothèques que d’autres développeurs utilisent avec votre nom dessus. Vous souriez au nombre de pull requests et de problèmes soumis que vous recevez, et vous travaillez même pendant votre temps libre pour améliorer ces bibliothèques. Vous vous sentez comme un génie, un scientifique fou dans un laboratoire d’expériences sans fin. Vous êtes inarrêtable maintenant. Vous êtes devenu une super star. Le monde connaît votre nom maintenant.
Année 2 :
Avec chaque année qui passe, vous devenez un pro dans ce que vous faites et votre employeur et vos coéquipiers vous font confiance maintenant.
Et puis un jour :
la charge de travail dans l’entreprise augmente soudainement et on vous a confié un grand projet à développer seul. La mission solo que vous attendiez depuis si longtemps : enfin ! !!
L’équipe a été démantelée pour que chaque individu travaille sur un projet dédié et on attend de vous que vous vous appropriiez votre travail. Oui ! !!
Vous commencez à appliquer tout ce que vous avez appris et vous réalisez soudain, au fil des semaines, que vous êtes toujours en train d’apprendre. Plus vous vous enfoncez dans votre langage de programmation dédié, plus vous découvrez de nouvelles choses que vous devez recommencer à apprendre, depuis le stade fondamental. Et puis, soudain, certaines méthodes et certains objets de la bibliothèque du langage deviennent redondants. Et vous êtes obligé de remanier votre code et vous commencez à avoir l’impression que votre monde s’est écroulé à nouveau, vous êtes de retour à la case départ. Vous êtes de nouveau confronté à l’étape fondamentale, novice, évolution, combat ou fuite et passion :
Et vous savez que si vous ne recherchez pas et ne comprenez pas ces nouvelles choses (étape fondamentale, étape Novice), vous ne serez pas en mesure de développer ces classes (Evolution), et si vous ne réussissez pas à développer ces classes, vous ne serez pas en mesure de construire les autres classes qui font fonctionner cette application, mais vous devez essayer de ne pas abandonner, vous devez creuser dans votre esprit et appliquer toutes les connaissances que vous savez afin de corriger ces bugs et faire fonctionner cette chose (Fight or Flight), mais vous devez aussi rester calme et maîtriser votre esprit et croire en vous. Et vous savez parfaitement que si vous perdez la passion, vous ne pouvez pas continuer (étape de la passion).Vous vous êtes donné beaucoup de mal et l’application a finalement été approuvée par l’équipe d’assurance qualité (QA).Cela après qu’ils vous aient fait vivre un enfer avec des corrections dans les deux sens, des ajouts dans les deux sens à la fonctionnalité de votre application et vous aient emmené dans un manège à travers un labyrinthe sans fin de torture sur quelque chose dont vous étiez sûr à 100% qu’il était parfait et prêt à être déployé. Mais finalement, vous l’avez fait.
Vous êtes officiellement expérimenté. Vous avez maintenant la capacité d’évoluer avec le langage de programmation et toutes les nouvelles technologies qui se présentent à vous. Vous pouvez apprendre et maîtriser de nouvelles choses rapidement et les appliquer. Et vous êtes capable d’écrire un code propre et testable. Vous êtes officiellement expérimenté, on vous a même confié la responsabilité de maintenir le projet et pourtant, quelle que soit votre expérience, vous avez toujours l’impression d’apprendre les bases à chaque défi qui vous est présenté. Puis un jour, le PDG présente une idée brillante/plus un problème qu’une idée, et vous êtes obligé de matérialiser cette idée et de résoudre le problème.
Résolution du problème :
vous vous retrouvez avec vos coéquipiers pour essayer de résoudre les algorithmes et d’appliquer les approches les plus possibles pour développer cette idée en une application. L’équipe UX/UI a déjà soumis le prototype à votre équipe, mais vous devez trouver l’architecture logicielle à appliquer pour commencer à écrire cette application. Finalement, le projet démarre, après des mois passés sur le tableau blanc à planifier la meilleure approche de l’idée.
On attend de vous que vous résolviez des algorithmes très complexes en code, afin de faire fonctionner tout ce qui se trouve dans le module qui vous a été assigné, et vous êtes bloqué et ne savez pas par où commencer. Vous avez des tableaux, des listes, et vous êtes frappé en plein visage par la complexité des algorithmes, la complexité de l’espace, la complexité du temps et vous vous retrouvez à étudier les bases encore une fois. Vous vous poussez à fond, creusez dans chaque cellule du cerveau que vous pouvez mettre la main sur et résoudre le problème. Vous vous attendiez à ce qu’un groupe de vos coéquipiers se tienne derrière vous pour vous encourager à chaque clic, clac et frappe agressive de votre clavier, mais vous regardez le module en cours d’exécution et parfaitement achevé qu’on vous a demandé de développer et vous réalisez que personne ne vous regarde alors que vous tendez les bras en signe de célébration comme un crapaud nouveau-né embrassant son premier saut terrestre sur le sable après avoir survécu aux crocodiles dans la rivière.
La réunion du lundi approche, vous avez passé le week-end à célébrer votre réussite et, pour la première fois en deux ans, vous avez passé votre dimanche à vous détendre et à regarder Baby Boss sur Netflix. Vous êtes prêt à présenter votre code le lundi, et c’est à ce moment-là que vous réalisez que chacun de vos coéquipiers a résolu des problèmes similaires, que certains ont même été plus durement touchés que vous, mais que tout le monde est à jour le lundi et que l’équipe est prête à se réunir et à commencer à mettre en place le projet dans son intégralité.
Au fil des années, vous allez même jusqu’à passer 2 à 3 fois par jour à résoudre de multiples algorithmes afin d’améliorer vos compétences en matière de résolution de problèmes. Et vous vous rendez compte qu’à mesure que vous mûrissez en tant que développeur de logiciels, il vous faudra de nombreuses années avant de devenir un expert/professionnel. Vous êtes tellement confiant dans toutes vos connaissances, mais vous vous retrouvez à obtenir des points inférieurs à la moyenne dans la plupart de vos tests pratiques de codilité en ligne, au point de ressentir le redoutable syndrome de l’imposteur qui se glisse comme un fantôme dans la nuit.
Le stade d’expert : Aussi longtemps que les logiciels évolueront et que les langages de programmation se développeront, ce stade sera toujours déterminé par la quantité de travail que vous ferez pour apprendre, le temps que vous pourrez tenir (combat ou fuite) et la passion que vous aurez pour continuer. Vous aurez toujours l’impression d’être un novice en apprenant les bases, le syndrome de l’imposteur vous frappera un million de fois à chaque nouveau défi, mais vous saisirez toutes les occasions de célébrer une application déployée, d’apprécier les réactions des utilisateurs (bonnes ou mauvaises) et de travailler à l’amélioration de vos applications afin d’obtenir des réactions positives de la communauté et des utilisateurs, sans oublier les avantages et les faveurs de vos patrons qui ne durent qu’une semaine avant que vous ne soyez jeté dans l’océan rempli de requins pour résoudre un autre problème complexe. Et si vous continuez à vous améliorer chaque jour, un jour viendra où le monde vous percevra et vous glorifiera comme un expert.
Le cycle se répétera encore et encore tout au long de chaque étape et vous fêterez et serez fêté jusqu’au jour où un hacker de 12 ans s’introduira dans votre application logicielle et vous vous retrouverez une fois de plus à vous battre pour résoudre le problème « What went wrong problem » et une fois de plus à l’étape « Fight or Flight ».
En conclusion, il n’y a qu’une seule règle qui régit le monde du logiciel : EVOLUER OU RISQUER DE DEVENIR REDONDANT..
