5 raisons pour lesquelles être Full Stack était mon meilleur choix de carrière | de Syed Mohsin | décembre 2022

Basé sur mon expérience de travail dans plusieurs startups

En tant qu’ingénieur full-stack, une journée typique consiste à regarder plusieurs éditeurs de code remplis de React, Ruby on Rails et de nombreux codes hérités comme AngularJS écrits il y a dix ans. De la conception d’une nouvelle API et d’un nouveau modèle de données à la création d’interfaces utilisateur riches, j’ai appris tous les ingrédients nécessaires pour créer des fonctionnalités de bout en bout.

Le travail technique n’est que la moitié de l’histoire. Une partie essentielle de mon travail consiste à établir des relations avec d’autres équipes pour m’assurer que j’écris du code qui répond aux normes de leur système.

Pour moi, ce type de travail peut être à la fois écrasant et passionnant. Je m’épanouis grâce au large éventail de responsabilités et aux nombreuses opportunités d’apprentissage qu’il offre.

Voici cinq raisons pour lesquelles être « full stack » en valait la peine et a été inestimable pour ma croissance personnelle et professionnelle.

Même une équipe complète d’ingénieurs peut évoluer plus lentement qu’un ingénieur full-stack s’ils n’ont pas une compréhension plus large des systèmes et des outils au sein d’une organisation.

Cela peut arriver pour les raisons suivantes :

• connaissances fragmentées – la découverte et la rédaction d’une spécification technique peuvent prendre plus de temps car plusieurs ingénieurs doivent être impliqués.
• plus de réunions – un responsable peut avoir besoin de plusieurs réunions pour coordonner les ingénieurs avant que le développement puisse commencer.
• ingénieurs bloqués – souvent, un ingénieur peut rester inactif ou se concentrer sur un autre domaine en attendant qu’un autre ingénieur termine sa pièce.

Avoir des capacités de pile complète me permet d’éviter la plupart de ces inefficacités et d’agir rapidement.

Par exemple, après avoir appris la pile technologique dans une startup de taille moyenne, j’ai construit une fonctionnalité de bout en bout qui nécessitait de toucher cinq bases de code différentes, frontend + backend, dans deux langages de programmation différents, et qui a commencé à générer des revenus en quelques mois. .

Cela a attiré l’attention des dirigeants, qui ont été étonnés que je puisse construire ce produit par moi-même. D’après leur expérience, il faudrait une équipe complète pour construire quelque chose de similaire, exigerait plus de coordination et prendrait plus de temps.

Être full stack signifie avoir une vue d’ensemble de la façon dont divers systèmes fonctionnent ensemble. Cette perspective m’a souvent permis de trouver des réponses et des opportunités non vues par d’autres.

Voici quelques-unes des façons dont j’ai procédé :

• relancer un projet au point mort — j’ai aidé à relancer des projets ratés en les abordant sous un angle différent. Existe-t-il une interface plus simple au lieu d’une solution backend ? Serait-il écrit plus rapidement dans React ou sous la forme d’une simple vue Rails ? Pourrions-nous l’implémenter dans une autre base de code ?
• la pollinisation croisée des idées entre les équipes – tout en travaillant dans la base de code A, je pourrais trouver un modèle qui, à mon avis, serait utile pour la base de code B. De cette façon, j’agirai comme un pont entre les équipes et je plaiderai pour des pratiques qui pourraient être mises à l’échelle.

D’après mon expérience, trouver et établir des relations avec des experts du domaine est la clé pour apprendre rapidement et contribuer à chaque partie de la pile.

À cette fin, j’ai appris à communiquer et à créer de la bonne volonté avec différentes équipes.

Cela signifiait me présenter aux autres équipes et demander des conseils sur la meilleure façon de contribuer. Habituellement, je me concentrais sur des questions telles que :

• À quoi ressemble votre processus de revue de code ?
• Quels sont les objectifs à long terme pour votre base de code ?
• Où avez-vous une dette technologique que vous n’avez pas eu le temps de régler ?

Le dernier est mon préféré; Je construis la bonne volonté avec diverses équipes en m’attaquant à la dette technologique pour elles. Cela me facilite considérablement la vie lorsque j’ai besoin d’aide pour fusionner un PR plus tard !

Tout comme les équipes produit et marketing visualisent le parcours de l’utilisateur à travers des entonnoirs, les ingénieurs full-stack peuvent suivre le parcours de l’utilisateur à travers la pile technologique.

Le mappage du chemin de l’utilisateur, de l’inscription au paiement, pourrait ressembler à ceci :

• l’utilisateur atterrit sur le site marketing – application de site statique Gatsby
• connexion/inscription de l’utilisateur — Application NextJS et application mobile
• créer une nouvelle entrée utilisateur – API GraphQL intégrée à Ruby on Rails
• l’utilisateur soumet une commande — application mobile
• l’utilisateur passe par le flux de paiement – application de facturation React

Superposer l’entonnoir de l’utilisateur sur la pile technologique a été une superpuissance. Cela m’aide à voir clairement où dans la pile je dois plonger pour améliorer le décrochage des utilisateurs.

Par exemple, si vous me demandiez comment nous pourrions améliorer le taux de conversion d’inscription, je suggérerais d’expérimenter de meilleurs CTA sur l’application marketing qui conduisent à l’inscription, d’améliorer le temps de réponse de la demande d’inscription à notre API GraphQL ou de simplifier le formulaire d’inscription dans notre Application NextJS.

Comprendre l’ensemble de la pile est un moyen puissant de traduire les problèmes commerciaux en solutions techniques et d’apporter une perspective unique à la table d’idéation.

La résolution de problèmes attire efficacement l’attention des gens. On m’a demandé de donner mon avis sur des propositions techniques, d’encadrer des ingénieurs et de prendre en charge des projets en fonction de mon succès avec le développement full-stack.

Certaines des opportunités de leadership les plus intéressantes incluent:

• faire du « collage » – cela signifie effectivement accélérer les ingénieurs en les connectant aux bonnes ressources.
• améliorer la culture au sein des équipes – à mon avis, être full stack signifie travailler dans n’importe quel système, y compris les systèmes de personnes. Je joue souvent un rôle de gestion en participant à des stand-ups, en planifiant des réunions et en contribuant à des documents qui peuvent créer un alignement entre les équipes.

Les problèmes commerciaux respectent rarement les limites des bases de code dans lesquelles les gens préfèrent travailler. C’est pourquoi j’ai entrepris de développer l’état d’esprit et les compétences nécessaires pour travailler dans n’importe quel système.

En résumé, voici les principaux avantages que j’ai constatés :

1. aller plus vite (une fois que vous avez accéléré)
2. trouver plusieurs solutions à un problème
3. devenir un grand communicant
4. mieux comprendre le métier
5. devenir un chef

Alors, devriez-vous vous enfuir et devenir un développeur full-stack aujourd’hui ? Ça dépend!

Il y a beaucoup d’inconvénients à être full stack. Cela prend du temps, vous n’aurez pas les connaissances approfondies d’un expert du domaine et vous travaillerez souvent seul et manquerez de conseils.

Que vous travailliez pour une petite startup ou une grande entreprise, je pense que tout le monde peut bénéficier d’être même une * petite * pile complète.