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

Being a programmer can be interesting and fun, but being a software developer is hell. Computers are logical, people are not. Alas, in the modern software industry they don't pay for programming. They pay for software development, and this implies completing tasks in a team - along with other people. Commands 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 directions. It depends on our ability to form teams and participate in their activities. And also from our social skills - sometimes to a much greater extent than from technical skills.

Drama? I agree. This drama applies to each of our brothers in the profession, so if you want to survive in such a profession, read this book. Egor 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 these components are important, but they do not make one programmer more effective than another, or some team of developers is more successful than competitors. A decisive role in the modern world of software and hardware is played by something else: these 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, manage and obey, and follow directions. It depends on our ability to form teams and participate in their activities. And also from our social skills - sometimes to a much greater extent than from technical skills.

In this book, you will 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, circumvent conflict situations, and discuss the features of teamwork. 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 leader.

Chapter 1
Adrian

Being a programmer can be interesting and fun, but being a software developer is hell. Computers are logical, people are not. Alas, in the modern software industry they don't pay for programming. They pay for software development, and this implies completing tasks in a team - along with other people. Commands are made up of irrational people, not Java classes and methods. I am going to get a job in one of these teams and survive in it. I can write in Java, but this is not enough for success. Other skills will be needed there. And some of them I have yet to develop.

Miners and miners

I told the secretary:

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

Someday I will have my secretary, and my office, and my programmers, and my startup with investors, and a big mission that we will follow. And I will be famous and successful. In the meantime, I don’t 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 of staying with them forever.

Since any software architecture is a product of people's activities, in order to improve a product, it is first necessary to improve people.

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

Chris appeared a minute later. We go to the meeting room, she offers coffee, but I ask for a glass of water. She goes out, and I automatically get my phone out and check Facebook. Chris comes back with a glass of water and accompanied by a dude in a dark T-shirt with the GitHub logo. She says she is very glad to meet you and leaves. Dude's name is Adrian, he is a developer. We are starting a conversation. With his questions, he gives the impression of a person quite experienced. I feel quite comfortable - it’s obvious that I am technologically superior to him, so there is clearly nothing to worry about.

“We need someone to fix our architecture,” Adrian summarizes after half an hour.

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

“I will be happy to help.” It seems to me that your project is interesting both technologically and from the point of view of business processes. I do not really 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 smiles melancholy. Perhaps he heard this from every second person sitting in this room ...

He asks me a difficult question:

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

He seems very proud of what was said. Apparently, they think that a full-time job will be an absolute good for me. I already realized that I would have to sit in this office from nine to five, working out my salary. While I do not have my own startup, apparently, it will be so. This week this is the third company where I am being interviewed. The previous two have not yet answered me, although it seemed that I was suitable for them. This dude looks a lot more desperate. I suspect its servers crash almost every second 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 work.”

I say what I have to say, although now I have no project, no job, no income. I can not tell him the truth - you must follow the rules of the game. I have to look popular and very busy. But on the other hand, does the promise to complete all things in a week seem logical? What kind of project is it that I am 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 can not 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 answers.

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

- Yes, I'm 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 how respectfully Adrian speaks of him. Why, Tony pays him money.

- I will be glad to meet him! I answered, and we ended the conversation.

Chris wrote me three hours later. Tony wants to see me tomorrow morning. She says Adrian spoke positively of 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 announcement says that the pay is “decent”.
I don’t even want to imagine myself working for someone else. I can feel quite comfortable in their office, pretending to be interesting for 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: shift as many things as possible onto my shoulders.

I'm not a lazy person at all. I love writing code, but doing it so that the other person becomes a millionaire - no, thanks. My life is worth more than the salary they can offer.

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

Honestly, I think that it was precisely this attitude of mine that was the real cause of the problems that I had encountered in my previous work (and in several works before that). Everyone wanted me to be a good employee, and I wanted to do what I like: translate my own ideas by writing code in Java. I've already been fired four times, but I’m only 29. So far, not a very impressive career. What am I doing wrong?

I have heard many times from different people: when the employer interviews you, you must also interview him. This approach seems right to me, but not because you need to be choosy when choosing a company, which we want to become a part of - they are all the same at the initial stage, just different names, markets and budgets. We must “interview them for our part” to demonstrate that we are especially interested in them. This is like getting to know a girl2: you need to ask questions and pretend that you are interested in her soul, and not just her body.

At first, 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 can be a lie, their invention or it may not work at all as they imagine it. I never listen to what they say at the first interviews. Here is what I pay attention to: 1) the money that they are willing to pay me; 2) the size of the team; 3) the position that I will be offered.

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

Salary is the main explicit indicator 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 are already earning a decent income (it follows from this that the consumer values ​​them more than their competitors). Or, perhaps, the founder inherited a couple of millions and invested them in a crazy startup (this means that instead of being squandered in Vegas, these dollars heat the market through the business I am 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 demand for this project. When the project you are working on runs out of money, it's time to move on to another, more important for the market. This approach may seem disloyal, but it is still true if you care about your customers, and not about the bosses who cut their salaries every couple of weeks.

Choosing a project that pays less and that “looks more interesting” is both unfair and illogical. It is not up to programmers to decide how interesting and valuable this is. Such decisions should be made by the market, represented by solvent customers or investors. And they convey to us the decisions made with the help of our salaries. When the salary rises, the market is pleased with what we do for it. When the salary goes down - it's time to ask the question: why are you still doing this work 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 are not good. When the 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 degradation and the risk of wasting time. 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 rather small (as statistics say). I prefer to stay away from projects that employ less than 20 technicians.

On the other hand, all large 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, holding the title of “senior developer” and getting 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 attract me. So I would not want to go to a company that employs over a thousand people.

The third factor that I pay attention to is the position offered to me. I am referring to the actual position in the hierarchy. All companies are characterized by a hierarchy of employees, no matter what adherents of holacracy say. There is always a superior, then there are people who obey him (down to the lowest level). Staying on the lower 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).

Therefore, the lower the proposed position and the more technical it is, the more difficulties there will be: I will have to work for someone, not for myself. This is exactly what I hate to do. I am ready to work hard when I know that the result will be mine. But in development teams with a thick managerial layer, lower levels create income that is consumed by higher levels. So what's the point of staying down?

Have you ever heard of the experiment Didier Desor and his colleagues conducted at the University of Nancy? 2 They took ten identical cells, each planted five or six male rats. In order to get food, rodents had to get through a small hole, swim through the aquarium to the food trough, take some food and swim back to eat it (it was impossible to eat directly from the trough). By the end of the experiment, in all cages, rats were divided into two groups - prey and non-prey. The miners swam for food, and the miners stole this food from them.

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

We, of course, 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. Control hierarchies were invented in order to control this process and to avoid constant battles (as between rats in cages). We no longer fight with our bosses, 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 specifically and the more others are credited to you.

Based on this, the most convenient position for me in the modern system of “miners and 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 practically nothing.

The vast majority of teams in the field of software development are not able to get programmers to give all their best. The manual, especially at the highest levels, does not understand the difference between Java and JavaScript. On the other hand, at a lower level, it’s more difficult to fool the boss, pretending to be writing code, but actually posting a new Facebook post at that time. That’s why the higher my position, the better. No one will understand what I'm actually doing, 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 details on the book can be found on the publisher’s website
» Contents
» Excerpt

For Khabrozhiteley 25% discount on coupon - Our code