Les programmeurs débutants passent beaucoup de temps à acquérir les connaissances nécessaires pour terminer l'interview. Ils
résolvent les problèmes et améliorent leur curriculum vitae. Mais la partie la plus intéressante commence après que le programmeur ait reçu la position souhaitée - dans une startup, sur Google, sur Amazon ou ailleurs. Il s'avère souvent que les connaissances et les compétences qui ont aidé une personne à trouver un emploi ne correspondent pas à ce que vous devez savoir et être en mesure d'effectuer ses tâches quotidiennes.
L'auteur de l'article, dont nous publions la traduction aujourd'hui, dit que l'équipe dans laquelle il travaille s'est inspirée
de l'
histoire de TechLead sur 7 habitudes de programmeurs hautement efficaces. Les membres de l'équipe ont décidé d'exprimer leurs propres réflexions sur cette question. Ici, sous forme de conseils, fournit une analyse de 7 compétences de programmeurs efficaces.
1. Apprenez à lire le code de quelqu'un d'autre
Tout le monde sauf vous écrit un code affreux. C'est pourquoi la capacité d'un programmeur à travailler avec le code de quelqu'un d'autre est une compétence précieuse. Cette compétence donne à celui qui la possède beaucoup de bien.
Le programmeur doit être capable de comprendre le code de quelqu'un d'autre. Après tout, c'est son travail. Peu importe à quel point ce code est déroutant ou mal écrit. Soit dit en passant, «le code de quelqu'un d'autre» peut être ce qui a été écrit par le programmeur lui-même, disons, il y a un an.
Cette compétence affecte positivement le programmeur de deux manières. Premièrement, la possibilité de lire le code de quelqu'un d'autre permet de comprendre comment fonctionne un code de mauvaise qualité. En parcourant le travail des autres, vous pouvez découvrir quelles techniques sont des travailleurs et lesquelles ne le sont pas. Deuxièmement, et plus important encore, cela permet de révéler les particularités de la perception du code de quelqu'un d'autre par d'autres personnes, de savoir quel code est perçu facilement et lequel est difficile.
Si vous lisez le code de quelqu'un d'autre et y trouvez quelque chose que vous n'aimez pas, essayez de ne pas en parler. Cela augmentera votre crédibilité aux yeux de vos collègues.
Faites attention à ceux avec qui vous travaillez, à l'importance d'écrire du code facile à maintenir, à l'importance des bons commentaires. Cela renforcera davantage votre statut dans l'équipe.
Votre propre code doit être conçu avec une qualité telle qu'il serait clair et sans documentation. En fait, les bons programmeurs n'ont pas besoin de documenter le code. C'est une perte de temps, le temps qui serait mieux consacré à la programmation et aux réunions.
La capacité de comprendre du code de faible qualité, entre autres, aide à apporter des modifications à ce code. Parfois, cela signifie éditer du code dans lequel quelqu'un n'est pas très bon. Par exemple, un jour, nous sommes tombés sur un script impliquant des technologies telles que PowerShell, Python et Perl. En Perl, nous ne comprenions pas très bien. Cependant, nous avons réussi à comprendre le projet assez profondément, à comprendre l'essence de ce qui se passait et à apporter les modifications nécessaires au code. Cela est devenu possible grâce au fait que nous comprenions le code que nous devions changer, y compris le code des scripts Perl.
La capacité de comprendre le code de quelqu'un d'autre augmente la valeur du programmeur car il peut comprendre comment même les systèmes sophistiqués sont organisés, de sorte que lorsque vous les regardez, quelqu'un d'autre abandonne tout simplement.
2. Développer un flair pour les projets infructueux
Il existe de nombreuses compétences qui prennent du temps à maîtriser. L'un d'entre eux, qui, nous en sommes sûrs, mérite d'être maîtrisé, consiste à comprendre quels projets vous ne devriez pas traiter et quels projets avec un degré élevé de probabilité peuvent entraîner une «course à la survie».
Dans les grandes entreprises, les programmeurs travaillent toujours sur de nombreux projets. Mais tous ces projets ne seront pas terminés. Tous ne seront pas bénéfiques. Parmi eux, il peut y avoir ceux qui n'ont pas de sens commercial (du moins pour le programmeur). Certains projets, généralement prometteurs, peuvent souffrir de lacunes managériales. Cela ne signifie pas que vous devez abandonner certaines idées immédiatement après avoir réalisé que vous n'êtes pas d'accord avec ceux qui les proposent. Cependant, si l'auteur de l'idée ne peut pas expliquer clairement les avantages que l'entreprise peut apporter au projet après son achèvement, alors un tel projet ne vaut peut-être pas la peine de démarrer.
De plus, certains projets peuvent être trop axés sur la technologie plutôt que de résoudre un problème particulier. Cela nous permet parfois, même au tout début des travaux, de comprendre que l'achèvement d'un tel projet n'apportera pas beaucoup d'avantages.
Afin d'apprendre en un coup d'œil à reconnaître les projets non prometteurs, vous devez participer à de nombreux projets de ce type. Par conséquent, si vous êtes au stade initial de la carrière d'un programmeur, ne passez pas trop de temps à essayer d'évaluer les perspectives de tous les projets qui vous parviennent. Au fil du temps, vous développerez un instinct intérieur, guidé par lequel vous pourrez rapidement reconnaître les projets voués à l'échec.
3. Évitez les réunions
Quoi que vous travailliez, vous ne pouvez pas vous passer de réunions. Cela s'applique à tout le monde. Le fait est que vous devez trouver un langage commun avec les chefs de projet, les utilisateurs, les clients. Cependant, les réunions ont une caractéristique désagréable: parfois, elles prennent soudainement presque toute la journée de travail. C'est pourquoi il est très important d'apprendre à éviter les réunions inutiles. Il serait peut-être préférable de ne pas «éviter les réunions», mais de s'efforcer de «contrôler le temps consacré aux réunions». Le but est de ne consacrer du temps qu'aux réunions réellement nécessaires, à celles qui contribuent au développement des projets.
La méthode de gestion du temps la plus courante pour les réunions consiste à allouer chaque jour un bloc de deux heures, qui se transforme en réunion continue. Beaucoup organisent des réunions récurrentes à l'heure qu'ils jugent la plus appropriée. Ces réunions sont utilisées pour discuter des problèmes de travail.
Une autre façon de gérer le temps est de venir travailler plus tôt que les autres afin de gérer votre entreprise. Par exemple, nous préférons faire exactement cela. Et en passant, si vous venez tôt au bureau, il sera beaucoup plus calme de travailler là-bas que d'habitude. La plupart des gens qui arrivent tôt se ressemblent. Ils le font afin d'avoir le temps de faire face à leur travail. Par conséquent, ils n'interfèrent pas avec le travail des autres.
Dans notre cas, cela est important pour les membres individuels de l'équipe. Le fait est que notre travail prend du temps pour se concentrer pleinement sur une certaine tâche. Pour le moment, nous ne communiquons avec personne. Bien sûr, il y a des situations où, pour résoudre un problème, vous devez en discuter avec quelqu'un et travailler ensemble. Mais une fois toutes les questions résolues, le développeur n'a plus qu'à écrire du code. En général, nous parlons d'entrer dans une certaine zone de confort dans laquelle le programmeur peut constamment garder à l'esprit tout ce qui est lié à la tâche qu'il résout. S'il est constamment interrompu, il peut avoir de la difficulté à revenir rapidement à ce qui l'a distrait.
4. Master GitHub
Lorsque vous regardez certains programmeurs de haut niveau, vous avez l'impression qu'ils ont commencé à utiliser GitHub le tout premier jour de leur vie. Ils comprennent la signification de chaque commande et paramètre, ils gèrent facilement leurs affaires.
Mais d'autres rencontrent d'abord GitHub lors de leur premier emploi. Pour eux, GitHub est un véritable enfer, construit à partir d'équipes obscures et de processus mystérieux. Ils ne sont jamais complètement sûrs de ce qu'ils font. C'est pourquoi toutes sortes de "tricheurs" sur GitHub sont très populaires.
Ce qui précède est vrai pour tout système de contrôle de version. S'il est utilisé correctement, il est très utile. Si vous l'utilisez mal, cela interfère terriblement avec le travail. Un simple PR ou commit peut facilement se transformer en cauchemar qui prend plusieurs heures à un programmeur. Ce temps sera consacré à démêler les subtilités des branches et des fourches. De plus, si vous oubliez régulièrement de télécharger la dernière version du référentiel sur votre machine, vous pouvez constamment gérer les conflits de fusion. Il n'y a rien de bon là-dedans.
Si vous avez besoin d'une «feuille de triche» sur GitHub - faites-le.
Apprenez à travailler de manière productive avec GitHub. Dans ce cas, peu importe comment vous y parvenez.
5. Écrivez un code simple facile à entretenir
Certains programmeurs novices ont le trait suivant: ils essaient, dans un projet, de réaliser tout ce qu'ils savent. Le point ici est qu'ils s'efforcent d'utiliser leurs connaissances sur la programmation orientée objet, les structures de données, les modèles de conception et les nouvelles technologies dans chaque morceau de code qu'ils créent. Cela complique inutilement le code en raison du fait qu'avec cette approche, la tâche du programmeur peut facilement être affectée par, par exemple, les modèles de conception qu'il a déjà mis en œuvre dans la pratique.
Il existe un équilibre entre des structures de projet trop complexes et un code simple. Les modèles de conception et la programmation orientée objet sont conçus pour simplifier le code dans les projets à grande échelle. Cependant, plus nous recourons à l'abstrait et à l'encapsulation, plus il y a de boîtes noires dans nos solutions, plus il est difficile de déboguer le code de telles solutions.
6. Apprenez à dire non et à prioriser
En fait, cette recommandation peut être donnée à n'importe qui - au moins un analyste financier, au moins un programmeur. Mais on peut noter qu'il y a un sentiment que tout le monde veut quelque chose de spécial de la part des techniciens. Par exemple, si vous êtes ingénieur en analyse de données, des tâches bien plus étendues que celles que vous êtes censé faire peuvent vous être proposées. Certaines équipes ont besoin d'une sorte d'échantillon de données, d'autres ont besoin de données récapitulatives et d'autres ont besoin de nouveaux pipelines.
Il convient de noter que la capacité d'établir des priorités et la capacité de dire non peuvent en fait être deux compétences distinctes. Cependant, ces compétences sont étroitement liées les unes aux autres. Lorsqu'il y a un besoin pour l'un d'eux, le second est généralement nécessaire. La priorisation est lorsque le temps est consacré uniquement à ce qui a un impact sérieux sur l'entreprise. Et la capacité de dire non est un refus de faire le travail que quelqu'un d'autre devrait faire.
Apprendre de quoi nous parlons peut être difficile, car les gens s'efforcent souvent de résoudre tous les problèmes qu'ils posent. Cela est particulièrement vrai pour ceux qui viennent d'apprendre et d'obtenir leur premier emploi. Auparavant, dans leurs études, on leur confiait des tâches qu'ils maîtrisaient bien. Maintenant, au travail, ils attendent la même chose et s'efforcent de ne décevoir personne.
Ici, vous devez comprendre que dans les grandes entreprises, il existe un nombre infini de tâches. La chose la plus importante est de n'assumer que les tâches qui peuvent être résolues.
De nombreuses compétences ne sont pas testées lors d'un entretien. Ils sont rarement disponibles à l'école. Souvent, cette situation ne se produit qu'en raison des caractéristiques de l'environnement d'apprentissage et non parce que quelqu'un ne veut pas montrer aux élèves les tâches réelles auxquelles ils peuvent être confrontés dans la réalité.
7. Apprenez à réfléchir à la façon dont votre développement sera utilisé.
Il y a une compétence pour laquelle il est difficile d'organiser un test lors d'un entretien. Les situations dans lesquelles il est nécessaire sont difficiles à reproduire pendant les études. Il s'agit de la capacité de voir les erreurs que peut faire l'utilisateur final d'un système logiciel. Nous appelons généralement cela "réfléchir aux cas d'utilisation du programme".
En fait, cette «pensée de scénario» n'est qu'un nom plutôt doux pour ce qu'on appelle la «protection contre le fou».
Par exemple, comme la majeure partie du travail du programmeur consiste à prendre en charge le code, il doit souvent changer le code, qui est étroitement lié à autre chose. Même un simple changement de quelque chose nécessite une recherche de tous les endroits où il est utilisé. Par exemple, un objet, une méthode, une API d'un certain système peuvent changer. Si vous apportez une modification irraisonnée au système, cela peut «casser» le travail de parties complètement inattendues du programme. De plus, nous parlons de changements de n'importe quelle échelle - même quelque chose comme un changement de type dans la base de données.
Cette compétence comprend également la capacité de trouver et d'analyser des situations limites qui peuvent survenir lors de l'utilisation du système. Cela inclut également la capacité de comprendre un schéma de décision de haut niveau au stade de la conception.
Cela s'applique également au développement de plus grandes parties de systèmes, tels que des modules ou des microservices. Lorsque vous commencez à résoudre de tels problèmes, vous devez réfléchir à la façon dont les entités que vous prévoyez de créer seront utilisées. Vous devez réfléchir aux scénarios de leur utilisation abusive, aux différentes options pour leur utilisation et au fait que ce que vous créez sera probablement utilisé de manière totalement évidente à première vue.
Le processus d'écriture de code n'est qu'une partie du travail de résolution d'un certain problème. Il est facile de créer un programme qui fonctionne bien sur votre ordinateur. Mais le code avec lequel quelqu'un d'autre travaille peut facilement se comporter très différemment que prévu à l'origine. Comment le code que vous écrivez sera-t-il utilisé dans la production? Avec quels systèmes devra-t-il interagir? De quels processus peut-il faire partie? Ne semblerait-il pas trop primitif et limité à un programmeur qui devrait le soutenir après quelques années? Ce sont des questions très difficiles.
Résumé
Dans cet article, nous vous avons présenté un aperçu de 7 compétences communes aux programmeurs hautes performances. Nous espérons que vous avez trouvé parmi eux ceux que vous voudrez développer vous-même.
Chers lecteurs! Que conseilleriez-vous de maîtriser à quelqu'un qui aspire au professionnalisme en programmation?