Do not panic (translation of the chapter in the book Passionate Programmer by Chad Fowler)

Why this book deserves translation

I want to share my opinion with the community about the book Passionate Programmer, the translation of one of the chapters of which is presented below. The book was published in 2009, but it is not very widely known among Russian programmers, nevertheless many who met her, consider it very worthy. Chad Fowler (the author of the book) did his best to convey his rich experience to readers (he is currently CTO 6Wunderkinder, he has over 20 years of experience in development and in view of his extensive experience and interests he is a welcome guest at Ruby and IT conferences) . Yes, I don’t remember how I found this book, but I remember that it was the preface from Kent Beck (the ideological inspirer of Test Driven Development and Extreme Programming) that was the reason to read it.

In this book there is no description of specific technologies, algorithms, etc., but there is just a bunch of tips on what every developer sometimes encounters: lack of motivation, choice of priorities, programming psychology, relationships with management and colleagues; By and large, a lot of instructions are given on how to make a bright programmer career. Of course, experienced developers may find some of his ideas fairly obvious, but for those who are just at the very beginning of their careers, reading this book will definitely be a good investment of time. A big plus is that the book is read very easily and, if you are fluent in English, you can actually read it in just a few days. Just wondering why our publishers have not yet translated it into Russian?

After reading the book, I became interested in Chad. Found his blog on the net. As it turned out, he began to lay out chapters from his book (2 chapters out of 53 have been published so far). I asked permission to translate for Habr, he replied that this is a good idea, but only first I need to send him a letter with what I specifically want to translate (apparently this wish was somehow connected with the publisher where the book was published) . After my answer there was a week of silence, I sent a second letter - there was no answer again. Then I received an invitation from him to Wunderlist (the service for which he is currently responsible). In general, I considered that if there was no explicit prohibition, and these chapters are already freely available, and he has not completely forgotten about me, then you can do the translation. In general, if the translation community is useful, I will continue to translate other chapters. Errors are possible in the text (I did the proofreading several times, but still suddenly), so I apologize in advance and ask you to inform me of all problems through private messages.
')

Do not panic

I started my programming career because I loved computer games. From the days when the games were launched from cassettes on my Commodore 64, I was simply fascinated by their interactivity and how deeply they could immerse the player in their world. I was embarrassed to admit this fact, but over time I realized that there was nothing wrong with that. Anyway, computer games turned for me a picture from the monitor screen into something more, with which I felt comfortable and that delighted me.

The favorite game was Doom from id Software. I especially liked the game mode on the network against other players - deathmatch. Those who wanted to play among themselves could connect to each other via a modem via a telephone line or through a normal serial connection and fight in small locations. I was very good at deathmatch. I even joked that this could be my profession - I was so good at it. Surprisingly, a duel with other players with its simple goal is in fact quite complicated. It requires the use of both good technical skills of the game and psychology, like an insane mix of chess and fast forward.

The best way to upgrade your skills in your business is to observe how the master works. In those days of my fascination with Doom, there was one such master who was known by the ironic nickname “Noskill” (“Insanity” is a pun) . Noskill was the reigning champion of Doom. People from all over North America could pay expensive phone bills just to try their luck at playing with him. Fights were saved using Doom's built-in recording feature. I reviewed each of them.

For me, the solution to the secret of Noskill mastery did not take much time. Of course, he was very good at the game itself, but there was also an obvious key to his success - he never panicked. Doom was such a game, the round in which could be completed in seconds after its start. It was really fast. I remember my first deathmatch: appeared, died, appeared, died, appeared, died. When in the end I could stay alive for more than a few seconds, I found myself running aimlessly along the corridor, hardly realizing where I am now.

But Noskill never did that. It was clearly seen in these notes that no matter how difficult the situation was, he was always relaxed and always knew what to do next. And it seemed that he always knew how the current context fits into the overall picture of the match.

Now, if you recall other games, especially sports, you will understand that all the best players share this quality. In fact, even characters from books and films that we admire also share this quality. Heroes never panic. They can get anything they want - a nuclear bomb aimed at their city or an airplane crash, but they can always find help, help the survivors, outwit the enemy, or at least not burst into tears.

It is also extrapolated to real life. Despite my best efforts in planning, my professional life was a series of emergencies and disasters. The projects were completed with great delay. My programs fell, which cost real money to my employers and the loss of trust in me. I said bad things to a bad vice president, nurturing a political enemy. Usually such things rolled in waves all together, they never came in turns.

In my worst moments, I panicked. I closed at home and was able to develop tactics, examining each event separately, without having an idea of ​​which picture is taking shape as a whole.

But looking back at all the disasters that occurred, it is obvious that none of them had a lasting, noticeable influence on my career. No matter how much I panicked, upset, whatever the scale of the depression, I dealt with all of these seemingly dangerous situations that were not really like that.

What did this panicking give me? Nothing. Was there an advantage in negative reactions to each of these situations? Not. What really contributed to the panic was the inability to be the best in those moments when I really had to be the best.

Yes, I have to admit that simply advising to let go of a panic in a stressful situation is easier than actually applying this advice in practice. It's like saying to someone: “Just be happy.” Of course, this is good advice, but how to do it? How can you avoid a state of panic when it seems that everything is falling apart? To answer this question, we need to think a little about why we panic.

We panic when we lose perspective. When something goes wrong, it's hard not to focus your attention on it. I am not saying that this is bad, and even to some extent it is a good way to solve problems. But, unfortunately, this approach becomes the cause of another problem: no matter how small the primary problem, it begins to seem that only she is important. The problem becomes more and more, the level of stress increases, and as a result our brains simply turn off.

Who is the worst computer user you know? For me, this is most likely one of my parents or one of my spouse's parents (I know who this is specifically, but I'm smart enough not to write their names here). Imagine that this person is sitting in front of his computer, trying to complete his working draft, when he starts to pop up an error message, no matter what he tries to do. Most of us have witnessed a similar situation. Inexperienced computer users instantly get upset and start doing different weird things. They frantically click and drag windows back and forth, ignoring the potentially useful error text that appears again and again. In the end, they become so excited that they call for help, of course, after making a complete mess in one or two related systems before the call.

Do not think that I gloat, I just want to describe this situation with such a main character, whom you supposedly know, and I want you to laugh heartily at yourself. This behavior is ridiculous. Is not it?

The funny thing about this is that we presented a real-life scenario in which a person works outside his comfort zone, when he encounters a problem and starts to panic. This is not much different from how I reacted in those moments when my development did not fit the deadlines, unexpectedly demolished the system, or simply disappointed the client. It all happened just in a different context.

Well, that's how I actually learned not to panic. When something bad happens and I start to feel that it is knocking me out of the rut and is about to lead to panic, I begin to compare myself with that disappointed user and laugh at myself. I analyze the situation from the perspective of a third party, as if helping my relative to cope with that raging text processor. Suddenly, the problem that seemed complicated becomes easy. And this bad situation is actually not that bad. I often encounter the fact that the solution of many problems is very simple and literally screams into my face, just like that dialogue with an error that tells you what to do next. If your mind does not run away and you can read the error message, the problem can be solved.

Act!

1. Start keeping a panic log. The point is to intercept a panic before it arises. This is possible if you develop your “real-time” awareness of the arising sensations and emotions. I learned to do this by analyzing the reactions and situations after the incident. I’m not cool enough to run a stream in the “background” to analyze emerging thoughts, but I found that if I practice analysis offline, I’ll get better and better by doing real-time analysis.

Saying that you will do your job better by analyzing the reactions, and actually doing it are two different things. Keeping a journal will help structure the process. Every day at a certain time (use the calendar with a reminder!), Open a text file and record any situation that caused you to panic, even if it was something of trifles. Once a week, looking through the list, evaluate the long-term consequences of each situation that caused the panic. Was it really worth the panic? What could be the most reasonable response to this situation? To make a hero in a movie about your life instead of panicking?

After some practice, you will find that the analysis will take place at the time, as soon as the panic creeps. By rationally exploring the causes of your panic in real time, you will realize that panic is receding and eventually dissipates.

PS On Habré in 2009, the project began translating this book:
Programming passion
A passion for programming. Chapter 2. Acknowledgments
A passion for programming. Chapter 3. Introduction
A passion for programming. Part 1 (Choosing a market). Start
A passion for programming. Part 1. Tip 2. Supply and demand
A passion for programming. Part 1. Tip 3. Coding is not all