How to graze (with) cats, or Tips for a young programmer

When the first Russian edition of the well-known book “How to feed cats” was published, it was dedicated to the difficult topic of managing wayward by nature professional and not-so software developers, my more experienced colleague project manager noticed: “It would be better to call it“ How to feed cattle ”” . The phrase was remembered, and as the experience of interaction with programmers that has accumulated since then, the colleague was right.

How programmers nen see their colleagues

Habré has a fair amount of articles on 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, who blame “peems” for testers, personnel, analysts, customers — anyone but not loved ones — for the shortcomings of one methodology or another. In articles and in comments to them the opinion prevails that the developer is always right. The prevalence of this opinion is due, among other things, to the fact that programmers make up the majority of Habr's audience. At the same time, specialists and non-programmers work in organizations and project teams. This article privately expresses the point of view of that other side, formed on the other side of the “barricades”.

Today, My Young Friend, I will describe to you the world through the eyes of your colleagues and tell you about how you, Software Developer, Great and Always Right Programmer, appear to you in this world. You are sure that you are the Center of the Universe, like your cat, and that everyone owes you the coffin of life until the end of the project. This is your opinion supported by the quantitative superiority of your cohort in the project team, but in fact in a good half of the projects in which you, young or already graying, but never got a mind-mind buddy, take part, the rest of the team is quiet hates for your omniscience and excessive self-conceit. Your snobbery is blocked only by the exorbitant and overly bloated snobbery of the architect, but this caste will be discussed some other time.


The business analyst hates you for the most time-consuming parts of the specifications that are unrealized, ostensibly due to random oversight.
')
Testers hate you for rolling out the final build with corrections 5 minutes before the end of the working day and quietly going home, but they still have to spend several overtime hours in the evening checking fifty fixes and regression testing before tomorrow's release.

The project manager hates you for spitting on him from the highest bell tower, because your future, like the salary in the company, does not depend on his opinion and feedback, but only on your immediate superior, who will almost always find a way to shield you for any your failure. Well, of course, he hates you even more than the testers, because after they finish their testing and give the go-ahead for the release of the final assembly, at 11 o'clock in the evening, he will need 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 constantly evading the answers to their questions, even if in the new project you are assigned to, your schedule specifically allocates hours to support the alienated code.

However, first things first.

The life of an ordinary programmer

Somehow, after one successfully failed project, I, with the consent of the head of the development department, prepared a presentation for the programming group, which included, among other things, a “schedule” depicting the “programmer's life course”, from its very beginning, coding in a notebook 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 attained the appearance of gray hair 35 years (age milestones, of course, conditional, and only serve to illustrate the way of life averaged). A programmer, like no one else in the modern world, is forced to constantly learn and improve in technical and professional terms, and many people are very, very successful in this. At the same time, most of those who, writing the first “Hello, World” program in their life and publishing resumes on hh.ru / monster.com, immediately begin to spread their fingers during interviews and proudly call themselves “real professionals”, - such are not really.

In that project, one developer managed to forget to put the updated code into a common repository, and two colleagues tried to determine half a day in extreme mode - 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 postponed until the next release cycle of the code in the product environment, i.e. for 2 week.

Both specialists had more than one year of work behind them, were software development professionals, i.e. they received monetary compensation for their work, but not codes for themselves or in a free open-source project. Nevertheless, they made mistakes that are “childish” from which side you look at them. It’s a well-known thing, everyone has flaws, only those who do nothing do not mow. But because I wanted to make that presentation for developers, to show on the basis of my experience in advising various project teams, which problem areas almost every programmer has, and that they are not in the knowledge of this or that programming technology, but just related areas, where you end up so loved by you, MJD, designers and destructors, and begin the skills of working with requirements, tools, defects, planning, etc. Therefore, if somewhere, while reading an article in any of the examples given, you accidentally recognize yourself, and after reading it, you draw proper conclusions and manage to “grow above yourself” - others will rightfully see you as a professional in their field and will rejoice 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 responsible for the success of the project no less than you , oh miracle of the universe . And all these nonhumans play a role no less, and in some projects even more than your role as a coder, 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 twice a month from an ATM. the word - the money is much larger than all these people take out of the same ATM). You often look down on them and their design needs down or through your fingers, without the attention they rightly demand. And the needs and professional expectations they have, and different, depending on their roles.

The analyst, for example, expects that you will not only find fault with and without every letter in the specifications, but will also conscientiously implement them in the program code. And that you will not do amazed eyes, when during testing you will be asked why you did not implement the key function that was included in tomorrow's release and laid down in the requirements before you were assigned to the project team a year ago, it was always there and never since has it changed a single letter.

The tester has the right to expect from you a bug-free, qualitative result of your work. When she was hired, she was promised and therefore she expects that it will not be part of the TDD development methodology, according to which you, MUD, “throw out” the unfinished product into testing and, following its results, you will finish missing pieces of functionality and fix obvious defects. And the tester certainly expects you not to spread rot to her because she cannot test the product except manually, or that her skills in working with the query language to the database are significantly lower than yours. In the end, do not forget that they pay her for manual testing at times less than you did for programming, and that if she knew SQL as well as you did, then in your chair in front of your monitor she would have sat and not you, because with equal qualifications between you, it would prefer her to be left in the team and organization, because, unlike you, going through the difficult path of the tester will never spread rot to colleagues in the shop as you do.

Engineering knowledge of technology

You have already graduated from a kindergarten institute and at interviews you successfully explain how a designer differs from a destructor? I will tell you in confidence that the professional world of software creation is not limited to this knowledge and if you continue to think that the written and somehow executable code is a sufficient result of your work for not getting people from the project manager / customer receiving the salary twice a month - you are your future career you will still have a lot of problems on your head, and most importantly - you are a source of a steady headache for all who are not lucky enough to work with you.


“Versioning? Commenting code? Sticking to coding and naming standards? No, I have not heard! ”So say your colleagues here and there in a variety of project teams and organizations. Young friend, you everywhere know everything that is not directly related to "code splashing": the need to add comments, cover the code with block tests in accordance with the standards set in the company or department, merging branches of the repository ... What can we say about more complex things that require advanced or really high qualifications: automation of testing, implementation and support of continuous integration, setting up bundles of Bamboo-Cucumber-Maven-Puppet, many hours of digging in the system logs in the search Evidence of software errors - all this is dull and dreary for you, which do not allow you to improve your coding skills and that you find demeaning your personal data. Moreover, you, a professional software developer, often simply hide the inability to use them. I remember the reaction and the face of one programmer who, as an attempt to catch the hard-to-find "floating" defect, suggested using the profiler built into the IDE: I was told that it was not a project manager's business to advise what tools a programmer should use in his work.

Toolkit skills

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

As you know, a compilation launch in modern development environments is possible by pressing the F5 key (or F6? Or F13? .. In the end, why me, the project manager, should 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 a report on defects with blackjet and whores graphs and trends, but you will never pin up your peeks among your colleagues in the smoking room, which is stupid and not knows how the destructor differs from the constructor). But for quite a long career, I have met not so many programmers using combinations of CBD on the keyboard to invoke certain standard actions — most use the slower mouse for this. Conditional “Tab - 1000 - Tab - 1 - Tab - 0 - Tab - Backspace - 2 - Ctrl + S - Ctrl-F6 - Enter, Alt-Tab, F5” in 6 seconds allow a real pro to accomplish what he wanted with a mouse and poke index fingers on the keyboard clumsy makes five long minutes. And when such operations are performed a hundred times a day, in the conditions of an approaching deadline, a different project manager sometimes wants to take and ...... move such a “professional” away from the keyboard and make changes / compile / put the executable code yourself and give the test team a go-ahead That the new build is finally ready.


Therefore, the MUD, do not be too lazy and spend time on mastering the blind ten-finger print and methods of working effectively with the toolkit and trust more experienced people, even if some of them are so unloved by you project managers, this time will pay you back a hundredfold. In the meantime, you, young clumsy, have not reached perfection in this - Go, look at the monitor and Write the Code, Bl ..!

Evaluation of labor costs

You can’t stand up when a project manager intervenes in the sacred process of "writing code." But at the same time, you will never deny yourself the pleasure to release a caustic comment about “unrealistic” deadlines, “holey” demands, untimely requests for changes, incompetent project managers. When, within the framework of a particular methodology, you are asked for expert opinion on the assessment of labor costs for the next iteration or the entire project, you make a surprised face and start “making excuses” about incomprehensible or incomplete specifications, unknown technologies and that this is not your business do planning, you do not have time for "nonsense" and that you better go and do the real thing - writing code. “Evaluation of labor using 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, the young friend, or shut up in a rag, when none of your business concerns the planning of work in a project, or improve your own skills in issuing truly expert, and not "finger in the sky" assessments. And until you master the last - IPKB !!!

Hindu code

One of your favorite activities is to criticize the program code created by Indian developers. You do not feed you with bread, but let me just scoff at the "macaroni" programming style. More than discussing the “Hindu” code, you just love talking about technology (see below). And this is all despite the fact that you yourself call the methods the proud name kolbasa (), unforgettably copy pieces of code into different places in the program and create classes a dozen or so screens.

Due to the insignificance of your own professional experience, MUD, you have no idea that shit code that you write yourself is often no better, and sometimes worse than the code that your southern colleagues create. Grief-programmers are present in any country, "do not judge, you will not be judged," and real professionals of the business, I tell you in secret, the MJE, do not stoop to defame their colleagues on a national basis, and slowly improve their own qualifications and time, allotted for the creation of a software product, is spent directly on programming, and not on the search for straws in another's eye defects in another's code.

Endless discussion of technology

You are endlessly discussing with other programmers what Java ++ is superior to C ## or than the version number one hundred and twenty nine fractions fifteen some Javascript libraries are better than the version one hundred twenty nine fractions thirteen. You never feel sorry for such discussions even on those days when there are 2-3 days or weeks left until the end of an iteration or a multi-month project and the number of uncorrected serious defects assigned to you exceeds fifty.

You shamelessly do it during working hours, and not on Friday evening or on weekends over a beer. You are engaged in such a chatter, despite the fact that the question of choosing and using this or that technology in a product lies outside your area of ​​expertise (because the size of your competence, MJD, is simply not old enough), but you still spend the time of an employer and project on unproductive chatter

Blame for "unnecessary" rallies

Therefore, when, after you had just done it, 2 months in the kitchen / in the smoking room with half a dozen of the same shit coders about the latest framework / yesterday’s Google-Microsoft-Apple-Linus Torvalds press conference, said what had stolen a couple of people days of development, you suddenly declare on the analysis of the completed iteration that there are too many unnecessary meetings in the project and you need to cut them down - in response to this, you only want to shout: 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, perfectly know such languages ​​as C ## or MozgoEb - this does not at all save you from the need to write and speak Russian competently (and in English too, the 21st century is in the yard). Therefore, before the next time you will be able to write specifications, code comments, letters to the customer or your multi-story articles and comments here or on some other resource for bylokloderov - go and first learn Russian, bl ..! Do it so that whatever you wrote - any literate person would read it with ease and joy, and not stumble on every spelling of your spelling. Visit and memorize the contents of the tsya.ru website and finally remember that a “tester” is a device for determining the values ​​of various parameters of the electrical network, and a software testing specialist is called a “ tester ” and that “functionality” is a mathematical term, and the capabilities of the software product is called “functionality”, bl .. !! 111

Epilogue

I hope that the advice given above will be good for you, and over time you will grow into a real software engineer, a professional in your business, who will competently and politely interact with his colleagues in the shop, do his job efficiently and on time. Successes to you in your hard work! And please, always remember that your non-programmer colleagues deserve no less love and respect than your cat.

---

Addition

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

Of course, not all developers who work professionally in the IT field are similar to those described in the article. The author agrees with the widespread opinion that a programmer-expert is more productive than his novice colleague 10 times. The productivity of a medium-sized developer is about 3 times higher than that of a novice, a loser or clumsy, and productivity, the final exhaust from an expert, a guru, a “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 fairly accurate. For all the time of my career, I happened to work with four people, whom I fully attribute to the category of “ stars ” (the extreme part of the “spectrum”). They were able to do everything necessary for the implementation of the tasks assigned to them, plus much more than that, skillfully evaluated the labor costs, performed the work within the time allotted to it, after their work in the project, on the product or in the company, they left clearly documented artifacts.

“ Ordinary ” programmers, those that were able to do a lot of what the “stars” could do, but not all together, were an absolute majority. Obviously, this article does not concern them, or only concerns the fact that some of the sketches can make them smile like “yes, for sure, I remember the company XYZ did the same, my God, what a fool I was then was (two / five / twenty years ago)! ”.

Approximately as many as the “stars”, I met these “ razdolbaev ”, just those that are ugly painted in the article: znazek, hurry, unintelligent, looking down on all his colleagues who are not programmers by position (except for his immediate chief), unwilling to learn or not seeing the need for “ikspertov”.

The last category is dedicated to this article.