Lorsque la première édition russe du livre bien connu "Comment faire paître les chats" a été publiée, consacrée au sujet difficile de la gestion capricieuse par nature des développeurs professionnels et pas très logiciels, mon collègue plus expérimenté, le chef de projet, a noté: "Il serait plus correct de l'appeler" Comment faire paître le bétail "" . La phrase a été mémorisée, et comme l'expérience accumulée depuis lors en interaction avec les programmeurs le montre, le collègue avait raison.
Comment les programmeurs Nena voient leurs collègues
Sur Habré, il y a pas mal d'articles consacrés aux méthodologies de développement logiciel, à la communication et à l'interaction dans l'équipe projet, à la sélection et à l'embauche de programmeurs. Sans exagération, chacun de ces articles recueille beaucoup de commentaires en colère des programmeurs, dans lesquels ils blâment les «piemas», les testeurs, le personnel du service du personnel, les analystes, les clients - pour tous ceux qui ne s'aiment tout simplement pas pour les lacunes d'une méthodologie particulière ou pour les échecs des projets. Dans les articles et les commentaires à leur sujet, l'opinion dominante est que le développeur a toujours raison. La prévalence de cette opinion est due, entre autres, au fait que les programmeurs constituent la majeure partie du public de Habr. Dans le même temps, des spécialistes qui ne sont pas programmeurs travaillent dans des organisations et des équipes de projet. Cet article en ordre privé exprime simplement le point de vue de tel ou de l'autre côté, formé de l'autre côté des "barricades".
Aujourd'hui, mon jeune ami, je vais vous décrire le monde à travers les yeux de vos collègues et vous expliquer comment vous, le développeur de logiciels, le grand et toujours le bon programmeur, leur apparaissez dans ce monde. Êtes-vous sûr que vous êtes le Centre de l'Univers, comme votre chat, et que tout le monde vous doit un
cercueil de vie jusqu'à la fin du projet. Cette opinion est appuyée, entre autres, par la supériorité quantitative de votre cohorte dans l'équipe de projet, mais en fait dans une bonne moitié des projets dans lesquels vous, un jeune ou déjà grisonnant, mais toujours pas assez ami esprit-esprit, le reste de l'équipe est calme déteste votre omniscience et votre vanité excessive. Votre snobisme n'est bloqué que par le snobisme exorbitant et excessivement gonflé de l'architecte, mais parler de cette
caste ira une autre fois.
Un analyste d'entreprise vous déteste pour les parties des spécifications qui prennent le plus de temps et qui n'auraient pas été réalisées en raison d'une surveillance.
Les testeurs vous détestent d'avoir déployé l'assemblage final avec des corrections 5 minutes avant la fin de la journée de travail et de rentrer calmement à la maison, et ils doivent encore passer plusieurs heures supplémentaires dans la soirée à vérifier cinquante corrections et tests de régression avant la sortie de demain.
Le chef de projet vous déteste pour avoir craché sur lui depuis le plus haut clocher, car votre avenir, ainsi que le salaire dans l'entreprise, ne dépend pas de son opinion et de ses commentaires, mais dépend uniquement de votre supérieur immédiat, qui trouvera presque toujours un moyen pour vous protéger contre toute défaillance de la vôtre. Eh bien, bien sûr, il vous déteste encore plus que les testeurs, car après avoir terminé leurs tests et donné le feu vert pour la sortie de la version finale, il devra, à 11 heures du soir, terminer la création des rapports de version finale pour équipes de déploiement et de maintenance pour le client.
Le service d'assistance vous déteste pour le code "auto-documenté" et pour l'évasion constante des réponses à leurs questions, même si les heures de prise en charge du code aliéné sont spécialement allouées dans votre planning dans le nouveau projet auquel vous êtes affecté.
Cependant, tout d'abord.
Chemin de vie d'un programmeur ordinaire
D'une manière ou d'une autre, après un projet
réussi , j'ai, avec le consentement du chef du département de développement, préparé une présentation pour le groupe de programmation, qui, entre autres, comprenait un «graphique» décrivant le chemin de vie du programmeur, depuis le tout début, codant dans le bloc-notes à l'âge scolaire à travers le développement d'environnements de développement intégrés (20 ans), la gestion des défauts (25 ans) et l'interaction avec d'autres groupes de spécialistes et prestataires externes (30 ans), avant d'appliquer la pratique de l'intégration continue et du développement automatique yvaniya presse atteint
l'apparition de cheveux gris 35 ans (jalons d'âge, bien sûr, sous condition, et ne servent à illustrer le mode de vie en moyenne). Un programmeur, comme personne d'autre dans le monde moderne, est obligé d'apprendre et de s'améliorer constamment sur le plan technique et professionnel, et beaucoup réussissent beaucoup dans ce domaine. Dans le même temps, la plupart de ceux qui écrivent leur premier programme de
fraude au sifflet "Hello, World" et publient un curriculum vitae sur hh.ru / monster.com commencent immédiatement à écarter les doigts lors des entretiens et à se dire fièrement "un vrai professionnel", - ce ne sont pas en fait.
Dans ce projet, un développeur a réussi à oublier de mettre le code mis à jour dans un référentiel commun et deux de ses collègues une demi-journée en mode extrême ont tenté de déterminer pourquoi la fonction ne fonctionnait pas comme indiqué? Un autre développeur a fait une erreur dans le script de déploiement, et s'il n'avait pas été remarqué par le chef de projet (!), La mise en œuvre des résultats de collaboration d'équipe pour toute l'itération serait retardée jusqu'au prochain cycle de publication de code dans l'environnement du produit, c'est-à-dire pendant 2 semaines.
Les deux spécialistes avaient plus d'un an de travail derrière eux, ils étaient des professionnels du développement logiciel, c'est-à-dire A reçu une compensation monétaire pour son travail, mais n'a pas codé "pour lui-même" ou dans un projet open-source gratuit. Néanmoins, ils ont commis des erreurs «puériles» quoi qu'ils regardent. C’est une chose bien connue, tout le monde éprouve des défauts; seul celui qui ne fait rien ne tond pas. Mais c'est pourquoi j'ai voulu faire cette présentation pour que les développeurs montrent, sur la base de mon expérience de conseiller diverses équipes de projet, quels problèmes ont presque tous les programmeurs et ce qu'ils ne relèvent pas du domaine de la connaissance d'une technologie de programmation particulière, mais domaines connexes, où vous aimez tant, MUD, concepteurs et destructeurs, et les compétences commencent à fonctionner avec les exigences, les outils, les défauts, la planification, etc. Par conséquent, si quelque part en lisant un article dans l'un des exemples ci-dessus, vous vous reconnaissez accidentellement, et après l'avoir lu, tirez des conclusions appropriées et parvenez à «grandir au-dessus de vous» - d'autres vous verront à juste titre comme un professionnel dans leur domaine et s'en réjouiront. qui travaillent avec vous dans le même projet et la même équipe.
Interaction avec des non-programmeurs
Faites-vous savoir, My Skillful Friend, que d'autres spécialistes avec lesquels vous travaillez côte à côte dans l'équipe de projet, tels que des testeurs, des analystes, des rédacteurs techniques, des concepteurs et autres, ne sont pas moins responsables de la réussite du projet que vous
, oh miracle de l'univers . Et tous ces non-humains jouent un rôle non moins, et dans certains projets encore plus grand que votre rôle d'encodeur, et donc une interaction compétente et bienveillante avec eux est une partie intégrante et clé de votre travail, pour laquelle vous recevez beaucoup d'argent d'un GAB deux fois par mois (à en un mot - l'argent est
beaucoup plus grand que tous ces gens sortent du même guichet automatique). Vous les regardez souvent et leurs besoins de conception du dessus ou à travers vos doigts, sans l'attention qu'ils exigent à juste titre. Et ils ont des besoins et des attentes professionnelles, et divers, selon leurs rôles.
L'analyste, par exemple, s'attend à ce que non seulement vous chipotiez sur et sans chaque lettre dans les spécifications, mais que vous les traduisiez également fidèlement en code de programme. Et que vous ne porterez pas de lunettes lorsque, pendant les tests, ils vous demanderont pourquoi vous n'avez pas implémenté la fonction clé qui était incluse dans la version de demain et définie dans les exigences avant d'être nommé dans l'équipe de projet il y a un an, toujours là et depuis lors, n'a jamais changé une seule lettre.
Le testeur a le droit d'attendre de vous un résultat de qualité sans bug de votre travail. Quand elle a été embauchée, on lui avait promis et elle s'attend donc à ce qu'elle ne fasse pas partie de la méthodologie de développement TDD, selon laquelle vous, MUD, "jetez" le produit inachevé dans les tests et, selon ses résultats, finissez les éléments de fonctionnalité manquants et corrigez les défauts évidents. Et le testeur s'attend certainement à ce que vous ne propagiez pas la pourriture du fait qu'elle ne sait pas comment tester le produit autrement que manuellement, ou que ses compétences à travailler avec le langage de requête de base de données sont beaucoup plus faibles que les vôtres. En fin de compte, n'oubliez pas qu'ils lui paient beaucoup moins cher pour les tests manuels que vous pour la programmation, et que si elle connaissait SQL aussi bien que vous, alors elle s'asseyait sur votre chaise devant votre moniteur et non vous, car à qualifications égales entre vous, ce serait elle qui préférerait la laisser dans l'équipe et l'organisation, car, contrairement à vous, ayant franchi la difficile voie d'un testeur, elle ne répandra jamais la pourriture sur ses collègues comme vous.
Connaissances en ingénierie de la technologie
Avez-vous déjà terminé l'institut de
maternelle et lors des entretiens, vous expliquez avec succès en quoi le concepteur diffère du destructeur? Je vais vous dire un secret que le monde professionnel de la création de logiciels ne se limite pas à cette connaissance, et si vous continuez à penser que le code écrit et en quelque sorte exécutable est le résultat suffisant de votre travail pour
ne pas obtenir de lyuley
du chef
de projet / client pour recevoir sn deux fois par mois, vous êtes dans dans votre future carrière, vous ratisserez beaucoup plus de problèmes sur votre propre tête et, plus important encore, vous serez une source de maux de tête persistants pour tous ceux qui n'ont pas la chance de travailler près de chez vous.
"Versioning? Commenter le code? Adhérer aux normes de codage et de dénomination? Non, je n'ai pas entendu! " Alors dites vos collègues ici et ici dans une variété d'équipes de projet et d'organisations. Jeune ami, vous vous lamentez sur tout ce qui n'est pas directement lié au «jabbing de code»: sur la nécessité d'ajouter des commentaires, de couvrir le code avec des tests de blocs conformément aux normes établies dans l'entreprise ou le département, fusionner les branches du référentiel ... Que dire de des choses plus complexes qui nécessitent des fonctionnalités avancées ou vraiment hautement qualifiées: automatisation des tests, implémentation et prise en charge de l'intégration continue, configuration des bundles Bamboo-Cucumber-Maven-Puppet, plusieurs heures de fouille dans les journaux système à la recherche x preuve d'erreurs logicielles - tout cela est pour vous l'ennui et la lie qui ne vous permettent pas d'améliorer directement vos compétences en codage et que vous trouvez dépréciant votre FAQ. De plus, en refusant d'utiliser certains matériels, vous, développeur de logiciels professionnel, cachez souvent simplement votre incapacité à les utiliser. Je me souviens de la réaction et du visage d'un programmeur qui, dans le but d'attraper un défaut "flottant" difficile à trouver, a suggéré d'utiliser un profileur intégré à l'IDE: on m'a dit que ce n'était pas le travail du chien du chef de projet de conseiller les outils que le programmeur devrait utiliser dans son travail.
Compétences d'outils
Dans quelle mesure votre travail est-il automatisé au sein de votre poste de travail? Avez-vous développé vos compétences pour travailler avec des expressions régulières, créer et exécuter des fichiers batch? À la demande d'un collègue, testeur, analyste ou client, pouvez-vous analyser quelques centaines de milliers de lignes de journaux sur un serveur distant en 3 minutes, trouver l'entrée nécessaire du paramètre clé, emballer la sortie, la transmettre à l'adresse spécifiée et revenir à la tâche interrompue? À quelle vitesse, MUD, savez-vous comment effectuer des opérations de routine qui nécessitent des répétitions répétées pendant la journée de travail?
Comme vous le savez, le démarrage de la compilation dans des environnements de développement modernes est possible en appuyant sur F5 (ou F6? Ou F13? .. En fin de compte, pourquoi le gestionnaire de projet a-t-il besoin de savoir de telles choses? Vous ne savez pas, MUD, à quelle vitesse, en quelques minutes déchargez de Jira, formatez-le correctement dans Excel et envoyez un e-mail au client au sujet du rapport de défaut avec des graphiques et des tendances de
blackjet et de putes , mais vous ne manquerez jamais d'épingler votre "piem" dans le fumoir parmi vos collègues que ce n'est pas stupide sait en quoi le destructeur diffère du constructeur). Mais pour une carrière assez longue, je n'ai pas rencontré autant de programmeurs qui utilisent des raccourcis clavier sur le clavier pour invoquer certaines actions standard - la plupart utilisent le manipulateur de souris plus lent pour cela. Onglet "Conditionnel" - 1000 - Onglet - 1 - Onglet - 0 - Onglet - Retour arrière - 2 - Ctrl + S - Ctrl-F6 - Entrée, Alt-Tab, F5 "en 6 secondes permet à un vrai pro de faire quoi en effleurant la souris et en poussant avec des index sur le clavier, un lent fait cinq longues minutes. Et lorsque de telles opérations sont effectuées des centaines de fois par jour, dans le contexte d'une échéance proche, un autre chef de projet veut parfois
prendre et ...... éloigner un tel "professionnel" du clavier et apporter des modifications / compiler / mettre en page le code exécutable et donner le feu vert au groupe de test La nouvelle version est enfin prête.
Par conséquent, , ne soyez pas paresseux et passez du temps à maîtriser l'impression à dix doigts aveugle et les méthodes de travail efficaces avec des outils et croyez des gens plus expérimentés, même si certains d'entre eux sont si peu aimés par vous, les chefs de projet - ce temps sera très payant. En attendant, vous, jeune homme maladroit, n'avez pas atteint la perfection en cela - Allez, enterrez-vous dans le moniteur et écrivez le code, Bl ..!
Évaluation du travail
Vous ne pouvez pas le supporter lorsque le chef de projet intervient dans le processus sacré d’écriture de code. Mais en même temps, vous ne vous refuserez jamais le plaisir de laisser un commentaire caustique sur les délais «irréalistes», les exigences «qui fuient», les demandes de changement intempestives, les chefs de projet incompétents. Lorsque, dans le cadre d'une méthodologie particulière, ils se tournent vers vous pour obtenir un avis d'expert sur l'évaluation des coûts de main-d'œuvre pour la prochaine itération ou pour l'ensemble du projet, vous faites une grimace surprise et commencez à «faire des excuses» sur des spécifications incompréhensibles ou incomplètes, des technologies inconnues, et que ce n'est pas votre truc du tout pour planifier, vous n'avez pas le temps de faire des "conneries" et vous feriez mieux d'aller faire la vraie chose - écrire du code. «Estimation des coûts salariaux par la méthode des points fonctionnels? Par analogie sur la base des résultats précédents? Sur la base du nombre de formulaires d'écran et de demandes d'E / S de base de données? Non, je n'ai pas entendu! "
Par conséquent, un jeune ami, soit gardez le silence dans un chiffon quand ce n'est pas à vous de planifier le travail dans le projet, ou améliorez vos propres compétences pour émettre des évaluations vraiment expertes, et pas avec votre doigt dans le ciel. Et jusqu'à ce que vous maîtrisiez le dernier -
IPKB !!!
Code hindou
L'un de vos passe-temps préférés est de critiquer le code logiciel créé par les développeurs indiens. Ne vous nourrissez pas de pain, mais laissez-nous simplement nous moquer du style de programmation «pâtes». Plus que de discuter du code «hindou», vous adorez simplement discuter de technologie (voir ci-dessous). Et tout cela malgré le fait que vous appeliez vous-même les méthodes du fier nom kolbasa (), copiez inoubliable des morceaux de code à différents endroits du programme et créez des classes de la taille d'une douzaine ou de deux écrans.
Par l'insignifiance de votre propre expérience professionnelle, , vous ne savez pas que le code que vous écrivez vous-même n'est souvent pas meilleur et parfois pire que le code créé par vos collègues du Sud. Les programmeurs lamentables sont présents dans tous les pays, "ne jugez pas, ne soyons pas jugés", et de vrais professionnels, je vais vous dire un secret, MJD, ne vous adressez pas au reproche de leurs collègues au niveau national, et améliorez lentement leurs propres qualifications et leur temps, alloués à la création d'un produit logiciel, ils passent directement à la programmation, et non à trouver
aux yeux des autres
des pailles dans les failles du code des autres.
Discussion technologique sans fin
Vous discutez sans fin avec d'autres programmeurs de ce que Java ++ est supérieur à C ## ou quel numéro de version cent vingt-neuf fraction quinze de n'importe quelle bibliothèque Javascript est meilleur que la version cent vingt-neuf fraction treize. Vous ne vous sentez jamais désolé pour de telles discussions, même dans les jours où il reste 2-3 jours ou semaines jusqu'à la fin d'une itération ou d'un projet de plusieurs mois et le nombre de défauts graves non corrigés qui vous sont attribués dépasse cinquante.
Vous faites cela sans un pincement de conscience pendant les heures de travail, et pas le vendredi soir ou le week-end pour un verre de bière. Vous êtes engagé dans de telles discussions malgré le fait que la question du choix et de l'utilisation de l'une ou l'autre technologie dans un produit dépasse le cadre de votre compétence (car la taille de votre compétence, MJD, n'a tout simplement pas encore grandi), mais vous passez toujours du temps avec votre employeur et projet sur trepot improductif.Se plaindre des rassemblements "inutiles"
Par conséquent, lorsque, après avoir passé votre temps à parler, j'ai parlé pendant 2 heures dans la cuisine / fumoir avec une demi-douzaine des mêmes codeurs de merde à propos de la dernière conférence / presse de presse Google-Microsoft-Apple-Linus Torvalds, que j'ai volé quelques personnes- jours de développement, vous soudain, à l'analyse de l'itération terminée, vous constatez qu'il y a trop de réunions inutiles dans le projet et vous devez les raccourcir - en réponse, vous ne voulez que crier: tais-toi et IPKB !!!Alphabet russe
Enfin, comme on dit, le dernier, mais loin d'être le plus insignifiant. Même si vous, MUD, parlez couramment des langues telles que C ## ou Brainwave - cela ne vous évite pas complètement d'avoir à écrire et à parler correctement le russe (et en anglais aussi, XXI siècle dans la cour). Par conséquent, avant la prochaine fois, vous pourrez écrire des spécifications, des commentaires sur le code, des lettres au client, ou vos articles et commentaires intelligents ici ou sur une autre ressource pour bydlokoderov - allez d'abord apprendre correctement la langue russe, bl ..! Faites-le pour que tout ce que vous écrivez - toute personne compétente le lise avec facilité et joie, et ne tombe pas sur chaque lettre d'orthographe. Visitez et mémorisez le contenu du site tsya.ruet rappelez - vous déjà enfin que le « testeur » - un dispositif pour déterminer les valeurs des différents paramètres du réseau électrique et test de logiciels professionnels appelé le « testeur » et que « fonctionnelle » - un terme mathématique pour un ensemble de fonctionnalités du logiciel est appelé « fonctionnel Nost » bl .. !! 111Épilogue
J'espère que les conseils donnés ci-dessus vous conviendront pour une utilisation future, et au fil du temps, vous deviendrez un véritable ingénieur pour le développement de logiciels, un professionnel dans son domaine qui interagit avec compétence et politesse avec des collègues de la boutique, effectue son travail efficacement et dans les délais. Je vous souhaite du succès dans votre travail acharné! Et s'il vous plaît, rappelez-vous toujours que vos collègues non programmeurs ne méritent pas moins d'amour et de respect pour leur travail que le vôtre et un chat.
Addition
Dans les commentaires de la première édition de l'article, la question était posée: où trouver ces développeurs? Surtout, bien sûr, l'auteur de l'article n'a pas sélectionné de telles personnes dans ses équipes de projet, mais il existe des plans similaires dans presque toutes les organisations.Bien sûr, tous les développeurs travaillant professionnellement dans le domaine informatique ne sont pas similaires à ceux décrits dans l'article. L'auteur est d'accord avec l'opinion répandue qu'un programmeur expert est 10 fois plus productif que son collègue novice. La productivité d'un développeur à la main moyenne est environ 3 fois plus élevée que celle d'un débutant, d'un porteur de litière ou de l'ineptie et de la productivité, l'échappement final d'un expert, gourou, "bison" est également environ 3 fois plus élevé que celui d'un professionnel ordinaire.D'après mon expérience, les ratios quantitatifs du nombre de développeurs peu qualifiés / ordinaires et ordinaires / experts sont à peu près les mêmes: 1 à 3 et 3 à 1. Ces proportions peuvent varier considérablement d'une organisation à l'autre, mais en moyenne, elles sont tout à fait vraies. Tout au long de ma carrière, j'ai travaillé avec quatre personnes, que je classe entièrement pour moi-même dans la catégorie des « étoiles » (la partie extrême du «spectre»). Ils savaient tout ce qui était nécessaire pour la mise en œuvre de leurs tâches, plus bien plus que cela, évaluaient les coûts de main-d'œuvre de manière experte, effectuaient des travaux dans le temps imparti, après avoir travaillé dans le projet, sur le produit ou dans l'entreprise, ils laissaient des artefacts clairement documentés.« Ordinaire"Les programmeurs, ceux qui savaient faire beaucoup de ce que pouvaient faire les" stars ", mais pas tous ensemble, il y avait une majorité absolue. Leur article, évidemment, ne concerne pas, ou ne concerne que le fait que certains des croquis donnés peuvent les faire sourire comme «mais, oui, je me souviens, je me souviens que la société a fait la même chose à XYZ, mon Dieu, quel idiot j'étais alors était (il y a deux / cinq / vingt ans)! ».À peu près au même nombre que les «stars», j'ai rencontré de vrais « gouging », juste ceux qui sont décrits inesthétiques dans l'article: sournois, hâtifs, stupides, regardant tous leurs collègues qui ne sont pas des programmeurs au bureau (à l'exception de leur direct patron), peu disposé à apprendre ou ignorant la nécessité de "ikspertov".Cet article est consacré à la dernière catégorie.