La réflexion est une chose curieuse. Encore plus intéressant s'il repose sur de nombreuses années d'expérience. Sous la coupe, l'histoire du destin d'un programmeur à travers la bouche du directeur du développement de Parallels RAS Igor Marnat à la première personne. Profitez-en!
«Si vous n'avancez pas, vous ne restez pas immobile. Le monde va de l'avant, mais vous ne le faites pas. Ainsi, vous reculez! » © (Quelqu'un est très intelligent)
ÉpigraphePour moi, la programmation n'est pas encore devenue une routine, même si je la développe depuis plus de vingt ans. Je pense que cela est dû au fait que j'ai pris certaines mesures avant que mon fusible ne soit finalement tari.
Si la programmation est devenue une corvée pour vous, alors peut-être que mon expérience vous sera utile. Vous voulez changer quelque chose? Au moins quelque chose doit être changé (réflexion profonde, n'est-ce pas?). Nous devons nous déplacer quelque part. Et maintenant, à différents moments, j'ai essayé de me déplacer vers l'intérieur, de se déplacer latéralement et de se déplacer en largeur.
Mouvement profond
La particularité de notre travail est que chaque développeur doit être un spécialiste dans deux domaines - la programmation en tant que telle et dans le domaine pour lequel il crée des logiciels. Mieux et plus profondément le développeur comprend ces deux domaines, plus il sera en mesure de résoudre des tâches intéressantes. Plus la tâche est intéressante et étendue, plus le résultat est visible.
La plupart des programmeurs tirent leur motivation des niveaux supérieurs de la pyramide de Maslow - cognition, réalisation de soi et besoin de respect. Pour cela, il faut que, premièrement, le résultat de leur travail soit perceptible. Deuxièmement, ce résultat devrait voir la lumière, les gens devraient l'utiliser. La visibilité du résultat est évidemment étroitement liée à la taille de ce résultat, avec sa valeur, son poids.
Pendant le développement de logiciels pour les télécommunications, j'ai investi beaucoup de temps et d'efforts dans l'étude d'un nouveau domaine: le dispositif des processeurs à usage général et DSP, la mémoire, les systèmes de stockage, les protocoles réseau, les types de signalisation, les algorithmes de traitement du signal, en général, un tas de différents intéressants les choses de la téléphonie, des circuits, des réseaux.
Cela a pris plusieurs années (pendant lesquelles j'ai travaillé sensiblement plus de huit heures par jour). Cinq ans plus tard, j'ai travaillé au niveau architecte, participant à la création de la structure logicielle des nouveaux centraux téléphoniques, à l'architecture de leurs composants. J'ai écrit moins de code, développé des spécifications pour l'équipe, examiné du code complexe, travaillé sur certains composants, protocoles et pilotes critiques. Une bonne compréhension de l'appareil de chaque composant, des principes de son fonctionnement, de la communication avec le reste vous permet de développer une architecture produit, des protocoles de communication, des interfaces externes.
Évidemment, tout produit logiciel est le résultat du travail de toute l'équipe, mais avec mon niveau de participation au projet, je me suis senti impliqué dans la création non pas des composants individuels, mais du produit entier. En même temps, vous obtenez une conduite incroyable, il y a aussi plus de responsabilité.
En général, plus le programmeur est plongé dans le domaine avec lequel il travaille, plus il connaît le contexte, plus ses horizons sont larges, plus il peut faire son travail de façon intéressante.
Cela ne s'applique pas seulement à la disposition interne des composants du produit. Mieux vous connaissez vos utilisateurs, comment ils utilisent le produit, pourquoi et non autrement, quels problèmes ils ont, comment les produits des concurrents sont organisés, plus il sera intéressant pour vous de travailler.
Il est facile d’apprendre tout cela: vous devez communiquer davantage avec les équipes de support, de test, de mise en œuvre et avec les utilisateurs finaux du produit. S'il est possible d'établir une interaction de travail, de résoudre certains problèmes pour eux, de participer à un travail commun, alors c'est généralement super.
Soit dit en passant, il y a une autre remarque concernant l'organisation du flux de travail lui-même, qui est respectée, en particulier, par la philosophie DevOps et l'approche du développement et des opérations connue sous le nom de SRE, qui provenaient à l'origine de Google. Il faut s'efforcer d'éliminer la séparation entre les équipes de développement, de mise en œuvre et de support, le mouvement vers la collaboration.
Au cas où, je note que les RFC, les livres de couverture avec des animaux, la documentation des fabricants et la correspondance dans la plupart des communautés open source utilisent l'anglais comme moyen de communication standard. Il y a moins d'informations dans les traductions, elles sont souvent déformées et presque toujours en retard. De nombreux fabricants ne se soucient pas du tout de traduire la documentation. Par conséquent, au minimum, la capacité de lire des livres en anglais est une exigence assez basique, pour ainsi dire, hygiéno-sanitaire pour un développeur qui veut se développer.
Mouvement latéral
À bien des égards, l'intérêt du programmeur pour son travail est déterminé par son intérêt pour le domaine dans lequel il travaille. Par exemple, vous pouvez vous ennuyer avec les applications financières, mais il sera intéressant de travailler sur l'infrastructure de ces applications.
Parallèlement au développement de logiciels embarqués pour la téléphonie, j'ai travaillé sur un système distribué de collecte d'informations et de facturation des utilisateurs - et c'est un monde complètement différent, d'autres langues, d'autres plateformes. Ensuite - l'automatisation du déploiement, de la configuration et des tests, c'est le tiers monde, tout est à nouveau différent.
Peut-être pour revitaliser votre intérêt, vous devriez parler avec un collègue ou un patron, voir ce que les équipes font à proximité. Même un petit pas loin des activités habituelles peut faire une grande différence dans votre travail, vous donner une vision différente des choses. Comme le dit le dicton, le point de localisation détermine l'angle de vue
Mouvement en largeur
En entrant dans la téléphonie, il s'est avéré que je n'avais pas le temps de consacrer suffisamment de temps et d'attention aux autres projets sur lesquels je travaillais. La solution était évidente - j'ai commencé à travailler encore plus. Mais cela ne varie pas beaucoup. Avec un long travail la nuit et le week-end après un certain temps, je n'ai plus envie de travailler et je n'ai plus le temps de vivre. Mon patron et moi avons décidé d'embaucher un autre programmeur dans notre équipe. J'ai plutôt présumé mener quelques entretiens avec un swoop (le premier de ma vie de l'autre côté de la table), et j'ai réalisé qu'emmener une personne intelligente dans mon équipe n'était pas aussi facile qu'il y paraît.
Comment comprendre un étranger en peu de temps? Comment évaluer son professionnalisme et ses qualités personnelles? Sont-ils généralement importants, ces qualités personnelles? Ou le professionnalisme est-il important? À quoi devez-vous faire attention lors de l'embauche? Et comment le tournez-vous exactement? Maintenant, tout cela semble assez évident, mais quand j'ai embauché le premier ingénieur pour moi, c'était une vraie forêt sombre pour moi.
Comme d'habitude, j'ai commencé avec Google. J'ai trouvé plusieurs articles de Joel Spolsky, les ai avalés, j'ai lu les livres auxquels il a fait référence, puis des liens de ces livres, je suis allé étudier plus systématiquement, et donc, progressivement, j'ai commencé à plonger dans un nouveau domaine - la gestion de projet, l'équipe, la gestion du processus de développement lui-même.
Le processus de développement logiciel, comme tout autre processus de production, a ses propres chercheurs, son histoire de développement, ses meilleures pratiques, ses approches d'organisation. Beaucoup de ses aspects directement liés au développement, aux meilleures pratiques d'ingénierie, sont assez jeunes.
Par exemple, l'agile est apparu relativement récemment, il y a moins de vingt ans, CI - une trentaine, le livre classique de Frederick Brooks depuis une cinquantaine d'années. D'autres aspects liés à la gestion d'équipe, à la psychologie, à la motivation, à la gestion des processus dans l'organisation dans son ensemble, à l'organisation des communications sont universels, proviennent d'autres domaines depuis de nombreuses années et sont parfaitement applicables dans le domaine du développement.
J'ai lu pas mal de littérature sur le thème de la gestion d'équipe. Il me semble que ce sujet a été étudié de manière approfondie et approfondie en Amérique et au Japon. En plus des livres classiques sur le développement, l'ingénierie, la gestion, je recommanderais des livres de concepteurs d'avions soviétiques et russes et de concepteurs de fusées. En outre, NASA, NAVY, Toyota - ces organisations et entreprises investissent massivement dans l'optimisation de leurs processus, organisent des conférences internes pour leurs gestionnaires, les documents les concernant sont disponibles sur le réseau, il existe de nombreux livres d'art intéressants d'eux et à leur sujet. De plus, en plus d'excellentes informations sur les processus de gestion mis en place dans ces entreprises, la lecture sur les voitures, les avions, les missiles, les navires et leur développement est tout simplement très intéressante.
En général, les possibilités d'augmenter vos compétences dans le domaine de la gestion sont énormes, les tâches sont également très différentes. Vous pouvez commencer par organiser votre propre travail, en introduisant les meilleures pratiques d'ingénierie telles que les tests unitaires, les revues de code, l'intégration continue et la livraison continue, vous pouvez vous arrêter très loin. Et il vaut mieux ne pas s'arrêter :)
Conclusion
La pratique montre que si vous commencez à vous déplacer activement dans au moins une des directions ci-dessus, après un certain temps, un autre mouvement se produira inévitablement - dans l'échelle hiérarchique. S'il y a un tel désir, alors c'est aussi une option très intéressante. L'essentiel ici est de ne pas oublier l'équilibre nécessaire entre le travail organisationnel et technique que vous souhaitez maintenir.
Le développement de logiciels est un marathon qui dure toute une vie. Il y a toujours des délais, des délais, tout le temps il faut pousser un peu plus. Pour économiser de l'énergie et de la motivation, pour vous protéger contre l'épuisement professionnel, vous devez nécessairement changer, élevez la tête au-dessus de la routine, regardez autour de vous et regardez-vous et votre travail de côté. Théâtres, musique, concerts, bons livres et films sont obligatoires pour une utilisation périodique. Ou une résidence d'été. Ou la randonnée. En général, autre chose que du travail. Sinon, après deux ou trois ans, le travail cessera de toute façon d'être une joie.
Quant au travail, personne ne s'occupera de votre motivation et de votre carrière mieux que vous. Honnêtement, ce n'est pas que personne ne se soucie mieux - juste que personne ne se soucie du tout. Livres sur des spécialités, des domaines connexes, des conférences, la communication avec des collègues, mitaps - un mouvement qui, comme vous le savez, est la vie.
Si vous sentez qu'il est temps de changer quelque chose, vous pouvez commencer par de petites étapes. Pour ce faire, vous n'avez pas besoin de l'autorisation ci-dessus, d'un budget ou de travailler dans une grande organisation. Toutes les étapes que j'ai écrites, je suis allé plus haut dans une petite entreprise, en équipes de deux à dix personnes.
Quelques bons livres, beaucoup de désir et un peu de mouvement peuvent tous faire une grande différence. Bonne chance
Z.Y. Partagez vos expériences et vos astuces de vie dans les commentaires. Malheureusement, Igor n'est pas encore sur Habré, je télécharge du karma pour pouvoir l'inviter. En attendant, je lui redirigerai vos questions, le cas échéant. Merci de votre intérêt.