Être programmeur peut être intéressant et amusant, mais être développeur de logiciels est un enfer. Les ordinateurs sont logiques, les gens ne le sont pas. Hélas, dans l'industrie du logiciel moderne, ils ne paient pas pour la programmation. Ils paient pour le développement de logiciels, ce qui implique d'effectuer des tâches en équipe - avec d'autres personnes. Les commandes sont composées de personnes capricieuses, pas de classes et de méthodes Java.
Le succès d'un projet logiciel dépend d'ingénieurs intelligents qui sont souvent paresseux, ignorants, égoïstes, irritables et tout simplement misérables. Le succès dépend de personnes qui, souvent, ne savent pas comment communiquer, partager leurs connaissances, diriger et obéir et suivre les instructions. Cela dépend de notre capacité à former des équipes et à participer à leurs activités. Et aussi de nos compétences sociales - parfois dans une bien plus grande mesure que des compétences techniques.
Drame Je suis d'accord. Ce drame s'applique à chacun de nos frères de la profession, donc si vous voulez survivre dans une telle profession, lisez ce livre.
Egor Bugaenko .
Le développement logiciel implique aujourd'hui plus que l'écriture de code. Il ne s'agit pas d'algorithmes, de formules, d'octets, de fichiers ou de protocoles. Et pas sur les instructions, les opérateurs, les tests unitaires, les interfaces utilisateur ou les scénarios de déploiement. Et pas même en termes de performances, d'évolutivité, de tolérance aux pannes ou de fiabilité. Tous ces composants sont importants, mais ils ne rendent pas un programmeur plus efficace qu'un autre, ou une équipe de développeurs a plus de succès que ses concurrents. Un rôle décisif dans le monde moderne des logiciels et du matériel est joué par autre chose: ce ne sont pas des ordinateurs, mais des personnes.
Le succès d'un projet logiciel dépend de personnes qui sont souvent paresseuses, ignorantes, égoïstes, ennuyées et simplement malheureuses. Cela dépend de personnes qui souvent ne savent pas comment communiquer, partager leurs connaissances, gérer et obéir et suivre les instructions. Cela dépend de notre capacité à former des équipes et à participer à leurs activités. Et aussi de nos compétences sociales - parfois dans une bien plus grande mesure que des compétences techniques.
Dans ce livre, vous rencontrerez un petit groupe de programmeurs, d'architectes et de cadres qui sont payés pour créer des logiciels. Au cours des plus de deux cents pages suivantes, ils résoudront les problèmes, contourneront les situations de conflit et discuteront des caractéristiques du travail d'équipe. J'espère que leurs dialogues et monologues vous aideront à comprendre l'importance de l'aspect social du développement de logiciels et, par conséquent, à devenir un développeur ou un leader encore meilleur.
Chapitre 1
Adrian
Être programmeur peut être intéressant et amusant, mais être développeur de logiciels est un enfer. Les ordinateurs sont logiques, les gens ne le sont pas. Hélas, dans l'industrie du logiciel moderne, ils ne paient pas pour la programmation. Ils paient pour le développement de logiciels, ce qui implique d'effectuer des tâches en équipe - avec d'autres personnes. Les commandes sont composées de personnes irrationnelles, pas de classes et de méthodes Java. Je vais trouver un emploi dans l'une de ces équipes et y survivre. Je peux écrire en Java, mais cela ne suffit pas pour réussir. D'autres compétences y seront nécessaires. Et je n'ai pas encore développé certains d'entre eux.
Mineurs et mineurs
J'ai dit au secrétaire:
- J'ai un rendez-vous avec Chris, il m'attend.
Un jour, j'aurai ma secrétaire, mon bureau, mes programmeurs, ma startup avec des investisseurs et la grande mission que nous allons suivre. Et je serai célèbre et couronné de succès. En attendant, je n'ai pas besoin de payer le logement. Il semble que ces gars-là soient assez riches pour faire affaire avec moi au cours des prochains mois, et il semble qu'ils aient aimé mon CV. Maintenant, je dois les convaincre que je rêve de rester avec eux pour toujours.
Étant donné que toute architecture logicielle est le produit des activités des personnes, pour améliorer un produit, il est d'abord nécessaire d'améliorer les personnes.
"En fait, c'est elle," répondit sèchement la secrétaire.
Chris est apparu une minute plus tard. Nous allons dans la salle de réunion, elle propose du café, mais je demande un verre d'eau. Elle sort et je sors automatiquement mon téléphone et vérifie Facebook. Chris revient avec un verre d'eau et accompagné d'un mec en T-shirt foncé avec le logo GitHub. Elle dit qu'elle est très heureuse de vous rencontrer et part. Le nom de Dude est Adrian, il est développeur. Nous commençons une conversation. Avec ses questions, il donne l'impression d'une personne assez expérimentée. Je me sens assez à l'aise - il est évident que je suis technologiquement supérieur à lui, donc il n'y a clairement rien à craindre.
«Nous avons besoin de quelqu'un pour réparer notre architecture», résume Adrian après une demi-heure.
«Vous avez plutôt besoin de quelqu'un pour vous corriger avant de pouvoir faire quelque chose avec l'architecture», ai-je pensé, mais j'ai dit à voix haute:
- Je serai ravi de vous aider. Il me semble que votre projet est intéressant tant sur le plan technologique que du point de vue des processus métiers. Je n'aime pas vraiment travailler sur des projets ennuyeux, peu importe combien ils en paient. Je préfère être passionné par mon entreprise, donc je veux faire quelque chose d'intéressant et de moderne.
Adrian sourit avec mélancolie. Peut-être qu'il a entendu cela de chaque deuxième personne assise dans cette pièce ...
Il me pose une question difficile:
"Quand êtes-vous prêt à commencer?" De combien de temps avez-vous besoin pour mener à bien vos projets en cours? Nous recherchons une personne à temps plein.
Il semble très fier de ce qui a été dit. Apparemment, ils pensent qu'un emploi à temps plein sera un bien absolu pour moi. Je me suis déjà rendu compte que je devrais siéger dans ce bureau de neuf à cinq heures, en travaillant sur mon salaire. Bien que je n'aie pas ma propre startup, apparemment, ce sera le cas. Cette semaine, c'est la troisième entreprise où je suis interviewé. Les deux précédents ne m'ont pas encore répondu, même s'il me semblait que je leur convenais. Ce mec a l'air beaucoup plus désespéré. Je soupçonne que ses serveurs tombent en panne presque toutes les deux nuits, et cela deviendra mon problème dès que je signerai le contrat. Je dois faire attention.
"Peut-être qu'une semaine suffit pour terminer tout le travail."
Je dis ce que j'ai à dire, même si maintenant je n'ai pas de projet, pas de travail, pas de revenus. Je ne peux pas lui dire la vérité - vous devez suivre les règles du jeu. Je dois avoir l'air populaire et très occupé. Mais d'un autre côté, la promesse de tout faire en une semaine semble-t-elle logique? Sur quel type de projet est-ce que je travaille maintenant que je pourrais le terminer en seulement une semaine? Bien sûr, nous comprenons tous les deux que c'est un mensonge ... mais nous comprenons aussi que nous ne pouvons rien y faire.
Une personne qui promet d'être fidèle à une entreprise cesse immédiatement d'être fidèle à une autre.
- Depuis combien de temps travaillez-vous dans cette entreprise? Je lui demande de changer de sujet.
«Deux ans», répond Adrian.
- Avez-vous créé la plupart des projets de l'entreprise?
- Oui, je suis le premier développeur ici. Il y a deux ans, j'ai rencontré Tony, notre co-fondateur et directeur technique. Vous le verrez lors de la prochaine entrevue.
Je vois avec respect qu'Adrian parle de lui. Pourquoi, Tony lui paie de l'argent.
- Je serai ravi de le rencontrer! J'ai répondu et nous avons mis fin à la conversation.
Chris m'a écrit trois heures plus tard. Tony veut me voir demain matin. Elle dit qu'Adrian a parlé positivement de moi. Apparemment, ils sont intéressés. Les deux sociétés précédentes sont toujours silencieuses, je peux donc travailler pour Tony. Bien que je ne sache même pas combien ils sont prêts à payer, l'annonce dit que le salaire est «décent».
Je ne veux même pas m'imaginer travailler pour quelqu'un d'autre. Je peux me sentir assez à l'aise dans leur bureau, faisant semblant d'être intéressant pour moi, riant des blagues de Tony et demandant à Adrian comment vont ses enfants. Mais je ne veux pas écrire de code pour eux ou, pire, être responsable de leurs échecs techniques. Et c'est ce qu'ils vont essayer de faire: mettre autant de choses que possible sur mes épaules.
Je ne suis pas du tout paresseux. J'adore écrire du code, mais le faire pour que l'autre personne devienne millionnaire - non, merci. Ma vie vaut plus que le salaire qu'ils peuvent offrir.
"Combien un employeur peut-il payer?" - La bonne question qu'un spécialiste devrait se poser.
Honnêtement, je pense que c'est précisément cette attitude qui est la mienne qui a été la véritable cause des problèmes que j'avais rencontrés dans mon travail précédent (et dans plusieurs travaux avant cela). Tout le monde voulait que je sois un bon employé, et je voulais faire ce que j'aime: traduire mes propres idées en écrivant du code en Java. J'ai déjà été licencié quatre fois, mais je n'ai que 29. Jusqu'à présent, ce n'est pas une carrière très impressionnante. Qu'est-ce que je fais mal?
J'ai entendu à plusieurs reprises différentes personnes: lorsque l'employeur vous interroge, vous devez également l'interviewer. Cette approche me semble juste, mais pas parce que vous devez être sélectif lors du choix d'une entreprise, dont nous voulons faire partie - ils sont tous les mêmes au stade initial, juste des noms, des marchés et des budgets différents. Nous devons «les interviewer pour notre part» pour démontrer que nous nous intéressons particulièrement à eux. C'est comme apprendre à connaître une fille2: vous devez poser des questions et prétendre que vous êtes intéressé par son âme, et pas seulement par son corps.
Au début, chaque nouvelle entreprise, équipe ou projet est un mystère. Peu importe le nombre de questions que vous posez sur leurs processus DevOps, leurs principes de gestion et leur analyse statique, car toute réponse peut être un mensonge, leur invention ou cela peut ne pas fonctionner du tout comme ils l'imaginent. Je n'écoute jamais ce qu'ils disent lors des premières interviews. Voici ce à quoi je prête attention: 1) l'argent qu'ils sont prêts à me payer; 2) la taille de l'équipe; 3) le poste qui me sera proposé.
La question de l'argent est évidente: plus le salaire est élevé, mieux c'est. Non seulement parce que je suis gourmand et préférerais Mercedes-Benz plutôt que Chevrolet, mais aussi parce qu'un bon financement signifie que le projet est précieux et intéressant. Considérez cela du point de vue du marché: s'ils peuvent payer plus que d'autres, ils ont de l'argent quelque part.
Le salaire est le principal indicateur explicite de l'importance de votre contribution au marché.
Peut-être ont-ils réussi à attirer de gros investisseurs (ce qui signifie qu'ils croyaient en leurs idées); peut-être qu'ils gagnent déjà un revenu décent (il en résulte que le consommateur les apprécie plus que leurs concurrents). Ou peut-être que le fondateur a hérité de quelques millions et les a investis dans une startup folle (ce qui signifie qu'au lieu d'être gaspillés à Vegas, ces dollars réchauffent le marché grâce à l'entreprise à laquelle je suis invité à participer).
Dans tous les cas, l'argent est un indicateur de l'importance de cette activité particulière sur le marché. Plus il y a d'argent, plus la demande du marché pour ce projet est importante. Lorsque le projet sur lequel vous travaillez manque d'argent, il est temps de passer à un autre, plus important pour le marché. Cette approche peut sembler déloyale, mais elle est toujours vraie si vous vous souciez de vos clients, et non des patrons qui réduisent leurs salaires toutes les deux semaines.
Choisir un projet qui paie moins et qui «semble plus intéressant» est à la fois injuste et illogique. Ce n'est pas aux programmeurs de décider à quel point c'est intéressant et précieux. Ces décisions devraient être prises par le marché, représenté par des clients ou des investisseurs solvables. Et ils nous transmettent les décisions prises à l'aide de nos salaires. Lorsque le salaire augmente, le marché est satisfait de ce que nous faisons pour cela. Lorsque le salaire baisse - il est temps de se poser la question: pourquoi faites-vous toujours ce travail pour le marché, si le marché ne l'apprécie plus?
Le deuxième indicateur important pour moi est la taille de l'entreprise. Trop petit et trop grand ne sont pas bons. Lorsque l'entreprise est trop petite, les spécialistes techniques sont obligés de combiner de nombreuses responsabilités, d'effectuer des tâches diverses: écrire du code, configurer des serveurs, préparer des présentations pour les investisseurs, et même organiser des meubles et réparer une machine à café. Du point de vue de la carrière, c'est la dégradation et le risque de perdre du temps. En conséquence, vous devrez faire beaucoup de travail qui n'est pas lié à la position immédiate, juste pour aider l'équipe à survivre.
Les grandes entreprises sont trop politiques, les petites sont trop chaotiques.
Et les chances de survie des petites entreprises sont plutôt faibles (comme le disent les statistiques). Je préfère éviter les projets qui emploient moins de 20 techniciens.
D'un autre côté, toutes les grandes entreprises ont un problème différent: la politique. Les gens n'y travaillent pas - ils se battent les uns contre les autres. Je survivrai soit au niveau inférieur de la hiérarchie de l'entreprise, détenant le titre de "développeur senior" et recevant une tasse une fois par an le jour de mon anniversaire, soit je deviendrai un maître de l'intrigue dans un groupe particulier de crétins. Aucune des options ne m'attire. Je ne voudrais donc pas aller dans une entreprise qui emploie plus d'un millier de personnes.
Le troisième facteur auquel je prête attention est le poste qui m'est offert. Je fais référence à la position réelle dans la hiérarchie. Toutes les entreprises se caractérisent par une hiérarchie d'employés, quoi qu'en disent les adeptes de l'holacratie. Il y a toujours un supérieur, puis il y a des gens qui lui obéissent (jusqu'au niveau le plus bas). En restant au niveau inférieur, j'essaie toujours d'éviter. Non seulement parce que j'ai de l'estime de soi, mais aussi parce que je suis paresseux. Plus vous êtes bas dans la hiérarchie, plus vous avez de travail à faire et moins vous obtenez d'argent. La division du travail en action (et pas seulement dans le domaine du logiciel).
Par conséquent, plus le poste proposé est bas et plus il est technique, plus il y aura de difficultés: je devrai travailler pour quelqu'un, pas pour moi. C'est exactement ce que je déteste faire. Je suis prêt à travailler dur quand je sais que le résultat sera le mien. Mais dans les équipes de développement avec une couche de gestion épaisse, les niveaux inférieurs créent des revenus qui sont consommés par les niveaux supérieurs. Alors à quoi ça sert de rester en bas?
Avez-vous déjà entendu parler de l'expérience que Didier Desor et ses collègues ont menée à l'Université de Nancy? 2 Ils ont prélevé dix cellules identiques, chacune ayant planté cinq ou six rats mâles. Pour obtenir de la nourriture, les rongeurs devaient traverser un petit trou, nager dans l'aquarium jusqu'à la mangeoire, prendre de la nourriture et revenir en arrière pour la manger (il était impossible de manger directement de la cuve). À la fin de l'expérience, dans toutes les cages, les rats étaient divisés en deux groupes - proies et non proies. Les mineurs ont nagé pour se nourrir et les mineurs leur ont volé cette nourriture.
Que nous apprend cette histoire? Que vous travailliez ou voliez. Les rats ne connaissaient pas les dix commandements. Ils n'avaient aucune idée que le vol était un péché. Il semble que la nature n'ait rien contre le vol (pour elle, c'est la répartition naturelle des rôles). De même, pour certaines personnes, le travail est l'activité préférée. Pour d'autres, le vol est plus courant.
Nous, bien sûr, ne sommes pas des rats, et notre comportement est beaucoup plus compliqué, mais le principe général est le même: nous travaillons ou assignons le résultat du travail des autres. Des hiérarchies de contrôle ont été inventées afin de contrôler ce processus et d'éviter des batailles constantes (comme entre des rats en cage). Nous ne nous battons plus avec nos patrons, nous leur donnons simplement les avantages que nous produisons, en croyant en la justice. Bien sûr, ils produisent eux-mêmes quelque chose, mais les avantages qu'ils apportent sont nettement moindres et le salaire plus élevé.
Plus vous êtes haut dans la hiérarchie, moins vous devez en faire spécifiquement et plus les autres vous sont crédités.
Sur cette base, la position la plus pratique pour moi dans le système moderne de «mineurs et mineurs» est de ressembler à un mineur, mais de recevoir un paiement en tant que mineur. En d'autres termes, ressembler à un ingénieur logiciel qui travaille dur, en réalité, ne faisant pratiquement rien.
La grande majorité des équipes dans le domaine du développement logiciel ne parviennent pas à faire en sorte que les programmeurs donnent le meilleur d'eux-mêmes. Le manuel, en particulier aux niveaux les plus élevés, ne comprend pas la différence entre Java et JavaScript. D'un autre côté, à un niveau inférieur, il est plus difficile de tromper le patron, prétendant écrire du code, mais affichant en fait une nouvelle publication sur Facebook à ce moment-là. C’est pourquoi plus ma position est élevée, mieux c'est. Personne ne comprendra ce que je fais réellement, donc je peux faire ce que je veux. Je participe à des projets pour lesquels je suis payé, mais je préfère le faire quand je veux et quand c'est vraiment nécessaire. Pas à neuf heures du matin.
»Plus d'informations sur le livre sont disponibles sur
le site Web de l'éditeur»
Contenu»
ExtraitPour Khabrozhiteley 25% de réduction sur le coupon -
Notre code