The book "Our code. Craft, profession, art "

Being a programmer can be fun and fun, but to be a software developer is hell. Computers are logical, people are not. Alas, in the modern software industry do not pay for programming. Pay for software development, and this implies the execution of tasks in a team - along with other people. Teams are made up of wayward people, not Java classes and methods.

The success of a software project depends on smart engineers who are often lazy, ignorant, selfish, irritable, and simply miserable. Success depends on people who often do not know how to communicate, share knowledge, lead and obey, and follow instructions. It depends on our ability to form teams and participate in their activities. And also from our social skills - sometimes to a much greater degree than from technical skills.

Drama? I agree. This drama concerns each of our fellows in the profession, so if you strive to survive in such a profession, read this book. Yegor Bugaenko .

Software development today involves more than writing code. This is not about algorithms, formulas, bytes, files, or protocols. And not about instructions, operators, unit tests, user interfaces, or deployment scenarios. And not even about performance, scalability, fault tolerance or reliability. All of these components are important, but they do not make one programmer more effective than another, or some kind of development team is more successful than its competitors. Something else plays a decisive role in the modern world of software and hardware: they are not computers, but people.
')
The success of a software project depends on people who are often lazy, ignorant, selfish, annoyed and simply unhappy. It depends on people who often do not know how to communicate, share knowledge, lead and obey, and follow instructions. It depends on our ability to form teams and participate in their activities. And also from our social skills - sometimes to a much greater degree than from technical skills.

In this book, you meet a small group of programmers, architects, and executives who are paid to create software. Over the next more than two hundred pages, they will solve problems, bypass conflict situations, discuss teamwork features. I hope that their dialogues and monologues will help you understand the importance of the social aspect of software development and as a result become an even better developer or executive.

Chapter 1
Adrian

Being a programmer can be fun and fun, but to be a software developer is hell. Computers are logical, people are not. Alas, in the modern software industry do not pay for programming. Pay for software development, and this implies the execution of tasks in a team - along with other people. Teams are made up of irrational people, not Java classes and methods. I'm going to get a job in one of these teams and survive in it. I can write in Java, but for success this is not enough. There will need other skills. And some of them I still have to develop.

Miners and non-miners

I told the secretary:

- I have a meeting with Chris, he is waiting for me.

Someday I will have my secretary, my office, my programmers, my startup with investors, and a big mission that we will follow. And I will be famous and successful. And while this is not, I need to pay for housing. It seems that these guys are rich enough to deal with me over the next few months, and it seems they liked my resume. Now I have to convince them that I dream to stay with them forever.

Since any software architecture is a product of people’s activities, it’s necessary to improve people first of all to improve the product.

“Actually, this is her,” the secretary answered dryly.

Chris appeared a minute later. We go into a chat, she offers coffee, but I ask for a glass of water. She goes, and I take out my phone on the machine and check Facebook. Chris returns with a glass of water and accompanied by a dude in a dark T-shirt with the GitHub logo. She says she is very happy to meet you and leaves. Dude name is Adrian, he is a developer. We start the conversation. With his questions he gives the impression of a person quite experienced. I feel quite comfortable - obviously, technologically, I surpass it, so I obviously have nothing to worry about.

“We need someone who fixes our architecture,” Adrian sums up in half an hour.

“Rather, you need someone who fixes you before you can do something with architecture,” I thought, but said out loud:

- I'll be glad to help. Your project seems to me interesting both technologically and in terms of business processes. I do not like working on boring projects, no matter how much they pay for it. I prefer to be passionate about my business, so I want to do something interesting and modern.

Adrian melancholy smiles. Perhaps he heard it from every second person sitting in this room ...

He asks me a difficult question:

- When will you be ready to proceed? How much time do you need to complete your current projects? We are looking for a full time person.

It seems that he is very proud of what has been said. Apparently, they think that full time will be an absolute blessing for me. I already realized that I would have to sit in this office from nine to five, practicing my salary. As long as I do not have a startup, apparently it will be so. This week is the third company where I am interviewed. The previous two have not yet responded to me, although it seemed that I approached them. This dude looks much more desperate. I suspect his servers fall almost every other night, and this will become my problem as soon as I sign the contract. I need to be careful.

“Perhaps a week is enough to complete all the cases.”

I say what I have to say, although now I have neither a project, nor work, nor income. I can not tell him the truth - you must abide by the rules of the game. I have to look demanded and very busy. On the other hand, does a promise to complete all the tasks for the week look logical? What kind of project is it that I'm working on now that I could complete it in just a week? Of course, we both understand that this is a lie ... but we also understand that we cannot do anything about it.

A person who promises to be loyal to one company, immediately ceases to be loyal to another.

- How long have you been working in this company? - I ask him to change the subject.

“Two years,” Adrian replies.

- Have you created most of the company's projects?

- Yes, I am the first developer here. Two years ago I met Tony, our co-founder and technical director. You will see him at the next interview.

I see the respect with which Adrian speaks about him. Still, after all, Tony pays him money.

- I would be glad to meet him! - I replied, and we ended the conversation.

Chris wrote me three hours later. Tony wants to see me tomorrow morning. She says that Adrian spoke positively about me. Apparently, they are interested. The previous two companies are still silent, so I can work for Tony. Although I don’t even know how much they are willing to pay, the ad states that the remuneration is “decent”.
I do not even want to represent myself working for someone. I can feel quite comfortable in their office, pretending to be interested in me, laughing at Tony’s jokes and asking Adrian how his children are doing. But I do not want to write code for them or, worse, be responsible for their technical failures. And this is what they will try to do: put as many things as possible on my shoulders.

I'm not lazy at all. I love to write code, but to do so in order for another person to become a millionaire - no, thanks. My life is worth more than the salary they can offer.

“How much can an employer pay?” Is the right question that a specialist should ask himself.

Honestly, I think that it was my attitude that was the real cause of the problems that I had encountered in my previous work (and several jobs before). Everyone wanted me to be a good employee, and I wanted to do what I liked: to implement my own ideas by writing Java code. I have already been fired four times, and in fact I am only 29. So far, not a very impressive career. What am I doing wrong?

Many times I have heard from different people: when an employer interviews you, you must also interview him. Such an approach seems to me to be correct, but not because you need to be picky when choosing a company, of which we want to become a part, they are all the same at the initial stage, just different names, markets and budgets. We need to "talk with them on our part" to demonstrate that we are particularly interested in them. It's like meeting a girl2: you need to ask questions and pretend that you are interested in her soul, and not just the body.

At the beginning, every new company, team or project is a mystery. It doesn't matter how many questions you ask about their DevOps processes, management principles and static analysis, because any answer may be a lie, their fiction or everything may not work the way they imagine it. I never listen to what they say at the first interview. That's what I pay attention to: 1) the money they are willing to pay me; 2) team size; 3) the position that I offer.

The question of money is obvious: the more the salary, the better. Not only because I am greedy and would prefer a Mercedes-Benz rather than a Chevrolet, but also because good funding means that the project is valuable and interesting. Consider this in terms of the market: if they can pay more than others, they have money from somewhere.

Wages are the main clear indication of the importance of your contribution to the market.

Perhaps they managed to attract large investors (which means they believed in their ideas); perhaps, they already receive a decent income (it follows from this that the consumer values ​​them more than the competitors). Or maybe the founder inherited a couple of millions and invested them in a crazy start-up (this means that instead of being squandered in Vegas, these dollars warm up the market through a business I’m invited to participate in).

In any case, money is an indicator of the importance of this particular business in the market. The more money, the greater the market need for this project. When the project you're working on runs out of money, it's time to switch to another, more important for the market. This approach may seem disloyal, but still it is fair if you care about your customers, and not about the bosses who cut your salary every couple of weeks.

Choosing a project that pays less and that “looks more interesting” is both unfair and illogical. It’s not for programmers to decide how interesting and valuable it is. Such decisions should be made by the market represented by solvent customers or investors. And they bring to us the decisions made with the help of our salaries. When the salary rises, the market is satisfied with what we are doing for it. When the salary goes down - it's time to ask: why are you still doing this job for the market if the market no longer appreciates it?

The second important indicator for me is the size of the company. Too small and too big will not do. When a company is too small, technical specialists are forced to combine a lot of responsibilities, performing diverse work: writing code, configuring servers, preparing presentations for investors and even arranging furniture and fixing a coffee machine. From a career point of view, this is a degradation and risk of time loss. As a result, you will have to do a lot of work that is not related to the immediate position, just to help the team survive.

Big companies are too political, small ones are too chaotic.

And the chances of survival of small companies are quite small (according to statistics). I prefer to stay away from projects that employ less than 20 technical experts.

On the other hand, all big companies have a different kind of problem: politics. People do not work there - they fight with each other. I will either survive at the lower level of the corporate hierarchy, bear the title of "senior developer" and receive a mug once a year on my birthday, or I will become a master of intrigue in a particular group of cretins. None of the options attracts me. So I would not like to go to a company in which more than a thousand people work.

The third factor to which I pay attention is the position offered to me. I mean the actual position in the hierarchy. For all companies, a hierarchy of employees is typical, whatever the adherents of holacracy may say. There is always a top manager, then there are people who obey him (right down to the lowest level). Staying at the bottom level I always try to avoid. Not only because I have self-esteem, but also because I'm lazy. The lower you are in the hierarchy, the more work you have to do and the less money you get. The division of labor in action (and not only in the field of software).

Consequently, the lower the proposed position and the more technical it is, the greater the difficulties: I will have to work for someone, not for myself. This is exactly what I hate to do. I am ready to work when I know that the result will be mine. But in development teams with a fat management layer, lower levels create income that is consumed by higher levels. So what's the point for me to stay on the bottom level?

Have you ever heard of the experiment that Didier Dezor and his colleagues conducted at the University of Nancy? 2 They took ten identical cages, in each one they planted five or six male rats. To get food, the rodents needed to crawl through a small hole, swim through the aquarium to the feeder with food, take some food and swim back to eat it (it was impossible to eat directly from the feeder). By the end of the experiment, in all cages, the rats were divided into two groups - earners and non-hunters. The hunters swam for food, and the minders stole this food from them.

What does this story teach us? That you either work or steal. The rats did not know about the ten commandments. They had no idea that stealing was a sin. It seems that nature has nothing against theft (for her it is a natural distribution of roles). Similarly, for some people, work is the preferred activity. For others, theft is more familiar.

Of course, we are not rats, and our behavior is much more complicated, but the general principle is the same: we either work or assign the result of the work of others. Management hierarchies were designed to control this process and avoid constant battles (like between rats in cages). We no longer fight with our superiors, we just give them the benefits that we produce, believing in justice. Of course, they themselves also produce something, but the benefits they bring are clearly less, and the salary is higher.

The higher you are in the hierarchy, the less you need to do and the more results others assign to you.

Based on this, the most convenient position for me in the modern system of “earners and non-miners” is to look like a miner, but receive payment as a miner. In other words, to look like a hard working software engineer, in reality, doing almost nothing.

The vast majority of teams in the field of software development are not able to force programmers to give all the best. Management, especially at the highest levels, does not understand the difference between Java and JavaScript. On the other hand, at a lower level, it is more difficult to fool a boss by pretending to write code, but in fact publishing a new post on Facebook at this time. That is why the higher my position, the better. No one will understand what I actually do, so I can do what I want. I participate in projects for which I am paid, but I prefer to do it when I want and when it is really necessary. Not at nine in the morning.

»More information about the book is available on the publisher's website.
» Table of Contents
» Excerpt

For Habrozhiteley a 25% discount on the coupon - Our code