How to graze (s) cats, or Advice to a young programmer

    When the first Russian edition of the well-known book “How to Graze Cats” was published, dedicated to the difficult topic of managing wayward by nature professional and not very software developers, my more experienced colleague, the project manager, noted: “It would be more correct to call it“ How to graze cattle ”” . The phrase was remembered, and as the experience accumulated since then in interacting with programmers shows - a colleague was right.

    How Nena programmers see their colleagues

    On Habré there is a fair amount of articles devoted to software development methodologies, communication and interaction in the project team, selection and hiring of programmers. Without exaggeration, each such article collects a lot of angry comments from programmers, in which they blame “piemas”, testers, personnel department staff, analysts, customers - for anyone who just doesn't love themselves for shortcomings in a particular methodology or for failures in projects. In articles and in comments to them, the prevailing opinion is that the developer is always right. The prevalence of this opinion is due, among other things, to the fact that programmers make up most of the audience in Habr. At the same time, specialists who are not programmers are working in organizations and project teams. This article privately expresses the point of view of the one

    Today, My Young Friend, I will describe the world to you through the eyes of your colleagues and tell you about how you, the Software Developer, the Great and Always Right Programmer, appear to them in this world. Are you sure that you are the Center of the Universe, like your cat, and that everyone owes you a coffin before the end of the project. This your opinion is supported, among other things, by the quantitative superiority of your cohort in the project team, but actually in a good half of the projects in which you, a young or already graying, but still not getting enough mind-mind friend, the rest of the team is quiet hates for your omniscience and excessive self-conceit. Your snobbery is blocked only by the exorbitant and excessively inflated snobbery of the architect, but talk about that caste will go some other time.

    A business analyst hates you for the most time-consuming parts of specifications that were allegedly unrealized due to oversight.

    Testers hate you for rolling out the final build with corrections 5 minutes before the end of the working day and calmly going home, and they still have to spend several overtime hours in the evening checking fifty corrections and regression testing before tomorrow's release.

    The project manager hates you for spitting on him from the highest bell tower, because your future, as well as the salary in the company, does not depend on his opinion and feedback, but depend only on your immediate boss, who will almost always find a way to shield you for any failure of yours. Well, of course, he hates you even more than testers, because after they finish their testing and give the go-ahead for the release of the final build, he, at 11 o’clock in the evening, will still have to complete the creation of final release reports for deployment and maintenance teams for the customer.

    The support service hates you for the “self-documented” code and for the constant evasion of answers to their questions, even if the hours for supporting the alienated code are specially allocated in your schedule in the new project that you are assigned to.

    However, first things first.

    Life path of an ordinary programmer

    Somehow, after one successful project, I, with the consent of the head of the development department, prepared a presentation for the programming group, which, among other things, included a “graph” depicting the programmer’s life path, from its very beginning, coding in notepad at school age through the development of integrated development environments (20 years), defect management (25 years) and interaction with other groups of specialists and external contractors (30 years), before applying the practice of continuous integration and automatic development yvaniya releases, reaches to the appearance of gray hair35 years old (age milestones, of course, conditional, and serve only as an illustration to the average life path). A programmer, like no one else in the modern world, is forced to constantly learn and improve technically and professionally, and very many succeed very much in this. At the same time, most of those who write their first whistle-fraud program “Hello, World” and publish a resume on / immediately begin to spread their fingers at the interviews and proudly call themselves “a true professional”, - these are not in fact.

    In that project, one developer managed to forget to put the updated code in a common repository and two of his colleagues half an day in extreme mode tried to determine why the function does not work as stated? Another developer made a mistake in the deployment script, and if it had not been noticed by the project manager (!), The implementation of team collaboration results for the whole iteration would be delayed until the next cycle of code release into the product environment, i.e. for 2 week.

    Both specialists had more than one year of work behind them, they were professionals in software development, i.e. Received monetary compensation for their work, but did not code "for themselves" or in a free open-source project. Nevertheless, they made mistakes that are "childish" no matter what they look at. It’s a well-known thing, everyone experiences flaws; only the one who does nothing does not mow. But that’s why I wanted to make that presentation for developers to show, on the basis of my experience of advising various project teams, which problem areas almost any programmer has and what they lie not in the field of knowledge of a particular programming technology, but in related areas, where so beloved by you, MUD, designers and destructors end, and skills begin to work with requirements, tools, defects, planning, etc. Therefore, if somewhere while reading an article in any of the above examples you accidentally recognize yourself, and after reading it draw appropriate conclusions and manage to “grow above yourself” - others will rightfully see you as a professional in their field and will rejoice at that that work with you in the same project and team.

    Interaction with non-programmers

    Let it be known to you, My Skillful Friend, that other specialists with whom you work side by side in the project team, such as testers, analysts, technical writers, designers and others, are no less responsible for the success of the project than you , oh miracle of the universe . And all these nonhumans play a role no less, and in some projects even greater than your role as an encoder, and therefore competent and benevolent interaction with them is an integral and key part of your work, for which you receive a lot of money from an ATM twice a month (to the word - money is muchmore than all these people take out from the same ATM). You often look at them and their design needs from above or through your fingers, without the attention that they rightly demand. And they have needs and professional expectations, and various, depending on their roles.

    The analyst, for example, expects that you will not only quibble about and without each letter in the specifications, but also will conscientiously translate them into program code. And that you won’t do goggles when, during testing, they ask you why you didn’t implement the key function that was included in tomorrow’s release and laid down in the requirements before you were appointed to the project team a year ago, always there and since then has never changed a single letter.

    The tester has the right to expect from you a bug-free quality result of your work. When she was hired, she was promised and therefore she expects that she will not be part of the TDD development methodology, according to which you, MUD, “throw out” the unfinished product for testing and, based on its results, complete the missing pieces of functionality and correct obvious defects. And the tester certainly expects that you will not spread rot for the fact that she does not know how to test the product otherwise than manually, or that her skills in working with the database query language are much lower than yours. In the end, do not forget that they pay her for manual testing several times less than you do for programming, and that if she knew SQL as well as you did, then she would sit in your chair in front of your monitor, and not you,

    Engineering knowledge of technology

    Have you already finished kindergarten institute and at the interviews you successfully explain how the designer differs from the destructor? I’ll tell you a secret that the professional world of creating software is not limited to this knowledge, and if you continue to think that written and somehow executable code is sufficient result of your work for not getting lyuley from the project manager / customer to receive sn twice a month, you’re in in your future career, you will rake many more problems on your own head, and most importantly, you will be a source of persistent headache for everyone who is not lucky enough to work next to you.

    "Versioning? Commenting out the code? Adhering to coding and naming standards? No, I haven’t heard! ”So your colleagues say here and here in a variety of project teams and organizations. Young friend, you are whining about everything that is not directly related to “code jabbing”: about the need to add comments, cover the code with block tests in accordance with the standards set in the company or department, merging repository branches ... What can we say about more complex things that require advanced or truly highly qualified: test automation, implementation and support for continuous integration, setting up Bamboo-Cucumber-Maven-Puppet bundles, many hours of digging into system logs in search x evidence of software errors - all this is boring and dull for you, which do not allow you to improve your coding skills directly and which you find belittling your FAQ. Moreover, by refusing to use certain hardware, you, a professional software developer, often simply hide your inability to use them. I remember the reaction and the face of a programmer who, as an attempt to catch a hard-to-find “floating” defect, suggested using a profiler built into the IDE: I was told that it was not the dog’s job of the project manager to advise what tools the programmer should use in his work.

    Tool Skills

    How automated is your work within your workstation? Have you pumped your skills in working with regular expressions, creating and executing batch files? At the request of a colleague, tester, analyst or customer, can you parse a couple of hundred thousand lines of logs on a remote server in 3 minutes, find the necessary entry of the key parameter, pack the output, forward it to the specified address and return to the interrupted task? How quickly, MUD, do you know how to perform routine operations that require repeated repetition during the working day?

    As you know, starting compilation in modern development environments is possible by pressing F5 (or F6? Or F13? .. In the end, why do I, the project manager, need to know such things? You don’t know, MUD, how quickly, in a couple of minutes unload from Jira, format properly in Excel and send an e-mail to the customer about the defect report with blackjet and whorescharts and trends, but at the same time you never fail to pin your “piem” in your smoking room among your colleagues that he is dumb and does not know how the destructor differs from the designer). But for a fairly long career, I have not met so many programmers who use keyboard shortcuts on the keyboard to invoke certain standard actions — most use the slower mouse manipulator for this. Conditional "Tab - 1000 - Tab - 1 - Tab - 0 - Tab - Backspace - 2 - Ctrl + S - Ctrl-F6 - Enter, Alt-Tab, F5" in 6 seconds allows a real pro to do what by mouse flicking and poking with index fingers on the keyboard, a slow one does five long minutes. And when such operations are performed hundreds of times a day, in the context of an approaching deadline, another project manager sometimes wants to take and ......move such a “professional” away from the keyboard and make changes yourself / compile / lay out the executable code and give the go-ahead to the testing team that the new assembly is finally ready.

    Therefore, MUD, do not be lazy and spend time mastering the blind ten-finger printing and methods of effective work with tools and believe more experienced people, even if some of them are so unloved by you project managers - this time will pay off handsomely. In the meantime, you, young clumsy man, have not reached perfection in this - Go, bury yourself in the monitor and Write the Code, Bl ..!

    Labor assessment

    You can’t stand it when the project manager intervenes in the sacred process of “writing code.” But at the same time, you will never deny yourself the pleasure of letting out a caustic comment about “unrealistic” deadlines, “leaky” requirements, untimely requests for changes, incompetent project managers. When, within the framework of a particular methodology, they turn to you for expert opinion on assessing the labor costs for the next iteration or for the whole project, you make a surprised face and begin to “make excuses” about incomprehensible or incomplete specifications, unknown technologies, and that it’s not your thing at all to plan, you don’t have time for “bullshit” and that you’d better go and do the real thing - writing code. “Estimation of labor costs by the method of functional points? By analogy based on previous results? Based on the number of screen forms and database I / O requests? No, have not heard!"

    Therefore, a young friend, either keep quiet in a rag when it’s not your business to plan work in the project, or improve your own skills in issuing truly expert assessments, and not with your finger in the sky. And until you master the last - IPKB !!!

    Hindu Code

    One of your favorite pastimes is to criticize software code created by Indian developers. Don’t feed you bread, but just let us make fun of the “pasta” style of programming. More than discussing the “Hindu" code, you just love to chat about technology (see below). And all this despite the fact that you yourself call methods the proud name kolbasa (), unforgettably copy pieces of code to different places in the program and create classes the size of a dozen or two screens.

    By the insignificance of your own professional experience, МУД, you don’t know that shitthe code that you write yourself is often no better, and sometimes worse than the code that your southern colleagues create. Woeful programmers are present in any country, “don’t judge, let us not be judged”, and true professionals, I’ll tell you a secret, MJD, do not go down to the reproach of their colleagues on a national basis, and slowly improve their own qualifications and time, allotted for the creation of a software product, they spend directly on programming, and not on searching for straws in the eyes of others in a flaw in someone else's code.

    Endless technology discussion

    You endlessly discuss with other programmers what Java ++ is superior to C ## or what version number one hundred twenty nine fraction fifteen of any Javascript library is better than version one hundred twenty nine fraction thirteen. You never feel sorry for such discussions even in those days when 2-3 days or weeks remain before the end of an iteration or a multi-month project and the number of uncorrected serious defects assigned to you exceeds fifty.

    You do this without a twinge of conscience during working hours, and not on Friday nights or on weekends for a glass of beer. You are engaged in such chatter despite the fact that the question of choosing and using one or another technology in a product lies outside the scope of your competence (because the size of your competence, MJD, has simply not grown up yet), but you still spend time with your employer and project on unproductive trepot.

    Whining about "unnecessary" rallies

    Therefore, when, after you had just spent your time talking, I talked for 2 hours in the kitchen / smoking room with half a dozen of the same shit coders about the latest Google-Microsoft-Apple-Linus Torvalds framework / press conference, than stole a couple of people- days of development, you suddenly at the analysis of the completed iteration you declare that too many unnecessary meetings are held in the project and you need to shorten them - in response to this you want to yell only one thing: shut up and IPKB !!!

    Literate Russian language

    Well, in the end, as they say, the last, but far from the most unimportant. Even if you, MUD, are fluent in languages ​​such as C ## or Brainwave - this does not at all relieve you of the need to correctly write and speak Russian (and in English too, XXI century in the yard). Therefore, before the next time you will be able to write specifications, comments on the code, letters to the customer, or your clever articles and comments here or on some other resource for bydlokoderov - go and first learn the Russian language properly, bl ..! Do it so that whatever you write, any competent person would read it with ease and joy, and would not stumble on every spelling you make. Visit and memorize the contents of the site tsya.ruand remember already finally that the "tester" - a device for determining the values of the different electrical network parameters, and professional software test called the " tester " and that "functional" - a mathematical term for a set of software features is called "functional nost " bl .. !! 111


    I hope that the advice given above will suit you for future use, and over time you will become a real engineer for software development, a professional in your field who competently and politely interacts with colleagues in the workshop, performs his work efficiently and on time. I wish you success in your hard work! And please, always remember that your fellow non-programmers deserve no less love and respect with their work than yours and a cat.


    In the comments to the first edition of the article, the question was asked: where do you get such developers? Specially, of course, the author of the article did not select such people in his project teams, but there are similar shots in almost any organization.

    Of course, not all developers professionally working in the field of IT are similar to those described in the article. The author agrees with the widespread opinion that an expert programmer is 10 times more productive than his novice colleague. The productivity of an average-hand developer is about 3 times higher than that of a beginner, beggar or clumsy and productivity, the final exhaust from an expert, guru, "bison" is also about 3 times higher than that of an ordinary professional.

    In my experience, the quantitative ratios of the number of low-skilled developers to ordinary and ordinary to experts are about the same: 1 to 3 and 3 to 1. These proportions can vary greatly from one organization to another, but on average they are quite true. Throughout my career, I have had the opportunity to work with four people, whom I fully classify for myself in the category of “ stars ” (the extreme part of the “spectrum”). They knew everything necessary for the implementation of their tasks, plus much more than that, expertly evaluated labor costs, performed work within the allotted time, after they worked in the project, on the product or in the company, they left clearly documented artifacts.

    Ordinary"Programmers, those who knew how to do a lot of what the" stars "could, but not all together, there was an absolute majority. Their article, obviously, does not concern, or concerns only with the fact that some of the sketches given may make them smile like “but, yes, I remember, I remember that the company XYZ did the same, my God, what a fool I was then was (two / five / twenty years ago)! ”.

    About the same number as the “stars”, I met real “ gouging ”, just those who are unsightly described in the article: sneaky, hasty, dumb, looking down on all their colleagues who are not programmers in office (except for their direct boss), unwilling to learn, or unaware of the need for "ikspertov".

    This article is devoted to the last category.

    Also popular now: