Comment j'ai arrêté de haïr et suis tombé amoureux du développement

L'article Fear and Loathing in IT m'a rendu triste. Non pas parce que je partage les sentiments de l'auteur, mais parce qu'ils sont partagés par de nombreux bons développeurs, se tuant eux-mêmes, leurs projets, l'industrie et le progrès humain en général. Voici un mahanul, hein?


Peu importe à quel point je suis un futuriste enthousiaste et un adepte de l'automatisation, cet article est plus banal qu'un avenir meilleur. Par conséquent, je laisserai le sort de l'humanité la prochaine fois. Maintenant, je veux enfin parler des énormes volumes de négativité, de douleur, de peur et de haine qui se cachent dans les profondeurs de la communauté informatique, recouverts d'une petite couche chaude de technologie hype et de solutions d'ingénierie cool.

Clause de non-responsabilité


D'après ma propre expérience, je sais à quel point il est difficile d'appliquer ce qui est discuté dans l'externalisation, en particulier sur des projets de grande envergure. Je ne veux pas que la plupart des développeurs pensent "bien, maintenant" et clôturent l'article, mais je ne sais pas comment attirer, mais je ne veux pas tromper non plus. Par conséquent, je vous demande: allez-y, tout n'est pas si mal.

Complexité excessive


L'auteur de l'article original a souligné la chose évidente: le développeur ne contrôle plus le fonctionnement de sa solution. Pour beaucoup, c'était très confortable, donnant un sentiment de calme et de contrôle. Et ce confort reste le point de départ: jusqu'à présent, malgré le passage de la catégorie des créateurs à la catégorie des artisans, le programmeur essaie toujours d'apprécier le processus de création de quelque chose à partir de rien. En utilisant les créations d'autres personnes, ce plaisir ne peut pas être atteint, vous vous sentez au mieux une mosaïque , des pierres sélectionnées avec succès. (Mais la mosaïque est aussi un art, qu'est-ce qui ne va pas ici? Hmm ...).

Acceptez l'inévitable. Seuls certains personnages mythiques pouvaient créer des planètes à partir de rien. En utilisant les composants appropriés, en appliquant des approches bien connues et en réfléchissant soigneusement , vous pouvez créer un système élégant et apprécier comparable à celui d'une création "pure". Et cela fonctionnera à tous les niveaux: de la nouvelle énumération à la conception d'un système à forte charge.

Techniquement, tout n'est pas si rose. Et deux choses sont à blâmer: le temps et les collègues. Nos décisions doivent répondre à deux critères: les coûts doivent être inférieurs aux bénéfices à moyen terme escomptés et les coûts de support inférieurs à ceux à long terme. Par conséquent, avec les volumes de développement existants, nous arrivons inévitablement à des décisions comme «utiliser ce client partout»: c'est rapide, et toute l'équipe sait comment travailler avec. Et si le client est assez populaire, les futurs membres de l'équipe pourront le faire. Recherchez un équilibre entre les extrêmes de la création exaltée et du transport sans âme, profitez-en pour le trouver!

Trop et entrevues


Le choix du composant parfait pour la solution actuelle est peu probable. Même s'il existe, il est un sur mille. Chaque développeur / équipe / entreprise choisit quelque chose pour lui-même, apprend à contourner les pièges ... et commence à exiger la même expérience des autres. C'est stupide. Aussi stupide que de s'accrocher à un contrôle perdu sur votre création.

Chaque fois que je lis une autre histoire de la douleur de l'interview «ils veulent connaître la liste complète des changements dans ES6», je suis triste. Ils ne veulent savoir qu'une chose: conviendrez-vous à leur équipe. Et «ils» sont nous, seulement de l'autre côté de la table. Nous ne savons pas comment demander et nous ne savons pas comment répondre.

Brisez ce cercle vicieux de l'incompréhension! Arrêtez de passer des entretiens et commencez à chercher un emploi pour vous-même. Dites ce que vous pensez. Acceptez que votre équipe soit l'une des vingt. Trouvez-la.

Arrêtez de chercher quelqu'un qui sait la même chose et commencez à chercher quelqu'un qui vous donnera quelque chose de nouveau. Demandez ce qui est important pour vous. Acceptez qu'en posant des questions sur les connaissances, vous rédigez simplement un résumé détaillé. Trouvez quelqu'un qui parlera le même langage d'ingénierie avec vous, partagez vos principes et vos approches de développement.

Les informaticiens


Aussi des gens. Les gens sont différents, tout en étant xénophobes; un trait assez utile en termes de sélection naturelle. Cela n'aide pas de travailler en équipe, et peu de choses peuvent être faites à ce sujet: il sera intéressant pour les dames de jouer leurs jouets ensemble, les ingénieurs hardcore, en créant quelques mots, créeront des choses éternelles ensemble.

Acceptez: les gens sont différents. Si vous avez besoin de personnes, recherchez «votre».

La quantité maximale de haine est probablement associée aux managers. Et nous voici de nouveau dans un cercle vicieux: le manager ne veut pas ou ne peut pas faire son travail - et donc nous nous détournons de lui et faisons tout nous-mêmes. Il est inutile de toute façon. Cette question va dans

Entreprise


De nombreuses copies sont cassées sur le champ de bataille de Business with Technology. Je n'ai pas envie de me répéter, je vais donc omettre une grande partie du contexte et aller directement au point principal.

Seul le développeur est responsable des béquilles dans les solutions. Seule l'entreprise (représentée par PO, PM, directeurs, etc.) est responsable des échecs du projet. Et ici, vous avez besoin de beaucoup de force. Apprenez à calculer le prix des solutions rapides. Apprenez à prouver qu'économiser un mois maintenant entraînera deux mois de dépassement demain. Ou pas. Acceptez qu'un bon code ne résout pas les problèmes par lui-même, mais les entreprises ne veulent pas s'enfoncer dans la dette technique!

Vous pouvez refuser de jouer au bingo Bulshit. Appelez un chat un chat avant qu'ils ne vous atteignent et vous les appellerez beaux . Un développeur peut se permettre d'être honnête - il n'a ni budget ni responsabilité. Dans un pincement, il est facile pour un développeur de trouver un nouvel emploi où il a un peu moins peur de l'honnêteté. Donnez votre avis d'expert honnête sur le problème et la solution et laissez l'entreprise la résoudre. Et distinguer la réticence à décider de trouver une solution. Nous avons habitué l'entreprise au fait que vous pouvez faire un hack rapide. Ils savent que si vous poussez un peu, nous donnerons le résultat cinq fois plus vite. Il s'agit d'un rejet de la décision, et nous ne devons pas nous livrer à un tel comportement. Le manager, à la recherche d'une solution, va décomposer et prioriser, en essayant de montrer le résultat en temps voulu. Et nous sommes obligés de vous y aider.

La malédiction de l'externalisation
Tout ce dont je parle a beaucoup de sens lorsqu'une structure apparaît entre l'entreprise réelle et le développeur, pour lequel l'entreprise est le développement lui-même. La causalité naturelle est sérieusement affectée lorsqu'il existe un aspect pour lequel le développement et le bon fonctionnement de l'entreprise ne sont pas importants. Pour lequel seul le montant des ressources consacrées au développement est important, et le plus sera le mieux. Et même lorsque les sous-traitants permettent aux développeurs de communiquer directement avec le client, d'autre part, dans les profondeurs d'une grande entreprise, il peut y avoir un gestionnaire indifférent, irresponsable et mou. À un moment donné, je viens de fuir une situation similaire et je n'ai rien à conseiller.

Le développeur doit comprendre l'entreprise juste assez pour que le temps de formulation des questions et de compréhension des réponses soit comparable au temps de recherche d'une solution technique. On ne peut plus dire «donnez-moi un gâteau et je ferai tout», un tel gâteau est presque toute la solution. Notre travail ne consiste plus à réorganiser les octets manuellement, nous avons maintenant beaucoup plus de temps pour analyser l'ensemble de l'image. Mais nous ne devons pas accepter "il y a un tas de tâches, trier ce qui est là et comment." Les entreprises gagnent très souvent du temps à trouver une solution commerciale, et la tâche du développeur est de voir qu'il n'y a rien à développer, et de le signaler à l'entreprise. C'est un travail difficile et pas pour tout le monde.

À propos de moi


À 20 ans, je codais depuis des jours et je suis allée travailler volontiers.
À 25 ans, j'ai vu à quel point tout était mauvais et a souffert, m'attendant à vendredi et à un projet pour animaux de compagnie dans lequel tout va bien.
A 30 ans, je suis passionnée par le travail ... rencontrant avec bonheur vendredi et week-end.

Je ne sais pas ce qui se passera dans 5 ans, mais j'espère que je ne serai pas déçu par les croyances actuelles.
Notre domaine nous donne beaucoup - liberté d'expression, de développement, de connaissances, d'expérience intéressante et d'argent décent. Notre région est très jeune, c'est encore un artisanat, et nous n'avons pas de dynastie d'ancêtres artisans. Nous ne savons pas encore comment y travailler. Par conséquent, nous sommes en colère, souffrants et épuisés.

Ma décision est la présomption de rationalité. Je ne tire plus de conclusions sur une personne par son code, ses e-mails ou par glisser-déposer. Plus encore, j'essaie de ne pas mal penser à cause de ce qu'il dit ou fait. Après tout, alors que nous travaillons sur une cause commune, et jusqu'à ce qu'il dise directement «Je veux nuire au projet», il est mon allié, et ensemble nous pouvons faire plus qu'individuellement.

Personne ne l'a dit jusqu'à présent, même si je pousse parfois des collègues dans ce coin :)

Source: https://habr.com/ru/post/fr479296/


All Articles