Quatre ans en tant qu'ingénieur logiciel dans une startup à forte croissance, j'ai appris des leçons très précieuses sur lesquelles je réfléchis ici. C'est une liste qui s'allonge et je continuerai à la compléter.

Le travail est en constante évolution . Surtout quand l'entreprise est petite. Quand j'ai commencé chez OpenGov en tant que 180e employé, je ne pouvais pas dire si je ferais le même travail que je faisais à l'époque, un mois plus tard. Les choses évoluent rapidement, l'entreprise essaie de trouver sa place sur le marché et cela s'accompagne d'exigences en constante évolution.
Vous êtes la culture . Lorsqu'une entreprise est petite, chaque nouvelle chose, processus ou amélioration technique introduit par vous peut être adopté par l'ensemble de l'organisation d'ingénierie. (ou dans certains cas, l'ensemble de l'entreprise) et pourraient faire partie de la culture à mesure que l'entreprise grandit. À mon avis, c'est très gratifiant et tout le monde n'a pas cette opportunité. Cherchez toujours des choses que vous pouvez améliorer et essayez de démarrer une discussion. Vous n'avez pas à faire tout le gros du travail vous-même ; identifier ce qui pourrait être amélioré et faire ce premier pas va un long chemin.
Touchez chaque partie de la pile . Dans une startup travaillant comme ingénieur, les rôles ont rarement une limite claire des « choses » sur lesquelles on peut vous demander de travailler, en particulier en tant qu'ingénieur junior. Vous pouvez vous attendre à travailler sur le frontend, le backend, l'infrastructure, les bases de données et bien plus encore. De la préparation d'un backlog JIRA pour une fonctionnalité au déploiement du code associé, tout fait partie du travail.
Les choses se cassent. Vous déployez un morceau de code qui casse le système ou ne se comporte pas comme il le faisait dans un environnement de pré-production. Parfois, l'infrastructure tombe en panne et vous ne pouvez rien déployer du tout ! Ce sont autant d'occasions d'apprendre et de s'améliorer. Chez opengov, même si nous avions une équipe de devops dédiée pour gérer des problèmes comme ceux-ci, nous, en tant qu'ingénieurs, avons également été exposés au côté opérationnel du génie logiciel.
La documentation est importante. Comme nous sommes occupés à écrire et à expédier du code, la documentation a tendance à passer au second plan. Il vaut la peine de prendre du temps, à cadence régulière, pour créer de nouvelles documentations et tenir à jour celles qui existent déjà. Une bonne documentation, est à mon avis le signe d'une équipe performante. Au fur et à mesure que les gens vont et viennent, en particulier pour les startups, la documentation est ce qui aide à intégrer de nouvelles personnes et à diffuser les connaissances de divers systèmes et domaines au sein des membres existants de l'équipe.
La communication est difficile . Pour obtenir l'adhésion de différentes parties prenantes à un projet technique, vous devez expliquer comment il apporte de la valeur à votre client. Vous souhaitez passer les prochains sprints à refactoriser la gestion de l'état de votre application ? Eh bien, préparez-vous à l'expliquer au produit ou à votre EM (qui à son tour devra l'expliquer aux supérieurs) pourquoi c'est important. Parfois, il y a un avantage direct pour l'utilisateur final, comme des temps de chargement plus rapides de l'application, une meilleure UX, etc. D'autres fois, l'avantage serait une meilleure expérience de développement qui accélérerait le développement de fonctionnalités à l'avenir. Quoi qu'il en soit, former correctement ce récit peut être délicat et même si vous n'êtes pas impliqué dans ces négociations, je vous suggère de toujours faire un zoom arrière et de regarder votre travail d'un point de vue utilisateur.
Trouver le bon mentor. Comme dans d'autres disciplines, le mentorat peut changer la donne en tant que jeune ingénieur. Un mentor n'a pas à vous tenir la main pour vous apprendre quelque chose, mais plutôt à vous pousser dans la bonne direction. Ils ont une vaste expérience dans le domaine, sont des professionnels chevronnés et sont prêts à partager leurs apprentissages avec vous. Contactez les personnes de votre équipe / entreprise que vous admirez et discutez d'un problème que vous résolvez, d'un document de conception technique que vous écrivez ou de tout ce sur quoi vous avez besoin de conseils.

Mémoires de génie logiciel