Theory and practice of time: what developers think about the management of working hours

( c )

Do you know when projects start to absorb all your time? Too many features to implement, too many errors found, excessive repair costs. On some days, you simply do not work fast enough, think poorly at the code, spend hours to correct one single error. And in order to aggravate the situation, you spend the remaining time on meaningless meetings, and not on work.

Of course, on such days you start working overtime to keep the sprawling fabric of reality in your hands. Pretty soon, such a schedule becomes the norm, and everyone gets used to the fact that you can write letters (and demand answers) at any time. There comes the moment of burning out. And then you start to think about time management practices.

Hundreds of people around, it seems, all they do is teach others. Let's be honest with each other: all the time management courses are written by psychologists, managers, anyone, but not developers. But after all, many of the fundamental things of time management and project management were invented by programmers ( Frederic Brooks: “If the project does not fit the deadlines, then adding labor will delay it even more” ).

Theory, dopamine, time running

Time is a subjective concept. Each has its own time, expressed in the ability to determine the duration of moments, the point of occurrence of future events, as well as the time of occurrence of an event relative to time stamps.

In 1962, the caver Michel Sifr conducted an experiment in which he spent two months alone in a cave. The experiment ended on September 14th, while Sifr thought it was only on August 20th.

Periods of wakefulness and sleep "cave explorer" in the amount of 24.5 hours. However, the subjective assessments of time intervals, both long (a day) and short-term (120 s), have changed - time has seemed to slow down. In later experiments, subjects switched from 24 hours to 48 hours (36 waking hours and 12 hours of sleep).

In another study, which lasted six months in a cave, the subject was able to spend about 50 hours for himself without any sleep or discomfort. Just for him, this time "flowed" much faster.

So what does the flow of time within us depend on? As modern research shows, everything is connected with the level of dopamine. The less dopamine in the basal ganglia of the central part of the brain, the faster the subjective minute flows for us. Therefore, interesting events related to the rise in the level of dopamine may pass unnoticed, and the boring, causing dopamine decline, last for a long time.

Not only the level of dopamine itself is important, but also the sensitivity of the receptors to it. The receptors are affected by various addictions (alcohol, drugs, gambling, etc.) and even constant thoughts about some good event that has not yet arrived can have a negative effect on the absorption of dopamine. People with low sensitivity of dopamine receptors always lack time.

[The neurotransmitter dopamine is one of the chemical factors of internal reinforcement and serves as an important part of the brain's “reward system” because it causes a feeling of pleasure (or satisfaction). Naturally produced in large quantities during a positive, according to the person’s subjective view, experience. ( C )]

Finding your favorite coffee beans, you are experiencing a surge of dopamine. The concentration of dopamine is gradually increasing. At each time point, signals from receptors about the predicted distance to the target come. When you find that the milk for coffee is sour, you experience a decrease in dopamine levels.

Dopamine is directly related to our work . If you do something boring, the process will seem endless. At the same time, in dangerous or unexpected situations, time can slow down, but not because “something is wrong” over time — the brain itself begins to work faster. That is why in childhood time stretches endlessly, and in an adult the years pass very quickly - most often we are not bored during adolescence, just the brain constantly processes new information, while adults often work based on their previous experience.

In addition, psychologist Aoif McLaughlin put forward the theory that all our gadgets distort the subjective perception of time. As the pace of life and information processing from various digital stimuli increases, the subjective sense of available time decreases.

There is a solution to this problem (in addition to the obvious restrictions on gadgets during rest) - the practice of meditation and awareness strengthens the dopamine system. It would be useful to learn how to accurately determine the time and live by the internal clock.

In order to check how your internal clock goes, you need to conduct a simple experiment: evaluate the interval of 3 minutes without hours. If you subjectively (apart from a second about yourself) find yourself close to the real three minutes, having made an error of just a few seconds, then you have a good dopamine level, normal receptor sensitivity, and probably measured life. So, the following tips will no longer be useful to you.

From the theoretical part of the move to the practical. Having dealt with the dopamine level and attuned to the correct subjective perception of time, we will sooner or later encounter external stimuli that will try to disrupt the established order. You can try to arm yourself with time management tips - there are a lot of them now. Or listen to the opinions expressed by other developers.

Practice, time, development

Itamar Turner-Trauring , the chief software engineer of Datawire , wrote a large article on productivity, from which we selected the main theses.

“Become more productive by working less hours.

This may seem counterintuitive, but working less hours a week can increase productivity. First, you focus on the task due to time constraints. Secondly, you lean toward smarter decisions.

A shorter work week improves your ability to focus.

Long work is counterproductive. You say to yourself in the evening: "I need to finish one little problem, I just need another half hour." But being tired, you actually spend another three hours. The next day you go to work tired and not focused and spend even more time on solving the problem.

You say: "It is evening now, and I am sorry that I did not fix it, but I will try tomorrow morning." The next morning you solve the problem in 10 minutes.

It would be a mistake to think that to solve a problem you just need to work more. Programming is automation, creating abstractions to reduce work. Often you can achieve a huge reduction in time and resources by figuring out the best way to implement an API or determining that certain functionality is not really needed.
Imagine that you have been given a task that needs to be solved in 2 weeks. And you estimate what is real for this task you need 3 weeks.

If you choose the path of least resistance, then you just sit down to work at night and on weekends.

But there is another possibility - 2 weeks ahead, a lot of work. Think about what you need to do to optimize this time. You can set aside a few hours just to think about the problem carefully.

Perhaps the solution will be to make the task 80% by writing such functionality that will leave the client happy until you finish the rest.

How to set the boundaries of a short productive week?

You will become more efficient if you can explain to the management where the limits of your work week are and then stick to them: “I’m going to work a 40-hour work week, unless an emergency situation arises.”

The most difficult thing in this regard is to adhere to your own rules: do not respond to emails after the end of the working day, do not agree to do “one little thing” at the weekend.

There are companies where this rule does not work - poor management or such a number of distractions that even a 40-hour work week cannot be effective. In such cases, you need to look for a new job and, in the framework of interviews, learn in advance about the work culture and methods of project management of potential employers. ”

Melissa Gregg , Intel’s chief engineer, author of The Counterproductive, which focuses on time management at work, adds useful information about the relationship between work culture and productivity:

“Companies encourage the heroism of an individual career because it is relatively easy to reward. In the high stakes game, individual characters get all the trophies, while the rest of the team gets nothing. Companies should strive (instead of luring the prospect of a career ladder) to create the right atmosphere: the priority should be to create good working conditions here and now, allowing more people to enjoy work. ”

Demian Turner , by PHPKitchen.com , has been working with open source web projects since 1996:

“Read the code of experienced developers; There is always a better, cleaner and faster way to do something. Do not reinvent the wheel.

Make sure your code is readable; if you can't understand it in six months, what will it look like for other developers?

Always try to simplify the interfaces; it’s much harder to write simpler code, but sequential refactoring will save you a lot of time. ”

Eliot Horowitz , CTO and co-founder of MongoDB , shares her opinion on the time spent in leadership positions:

“Regardless of whether you manage a team, division or all development in your company, when managers spend less than 30% of their time directly on the code, they face a significant deterioration in their ability to perform all their duties.

My opinion contrasts sharply with what many see as the expected path for developers who become team leaders. Every time you move up the career ladder, you are expected to spend significantly less time on code. The director is engaged in programming (if at all) in the hobby level.

This happened to me about a year ago, because the lion’s share of my time began to go away for interviews with candidates, management and strategy. Then I discovered that I overcame the threshold, after which my effectiveness as a technology leader began to decrease in proportion to the amount of time lost directly to programming.

I think that managers and directors should spend 30% of their time on programming. These can be specific days of the week or dedicated hours every day, but if you don’t find time for a code, you’re doing worse for yourself and the company. ”

Mickey W. Mantle has been developing software for over 40 years for Evans & Sutherland, Pixar, Broderbund, Gracenote and other companies. Ron Lichty has been developing software for 30 years for Apple, Fujitsu, Razorfish and Schwab. Their point of view is presented in the article :

"Dave Wilson, who led the development at Apple, Sun, HP, Portal and ParcPlace, shared the rule that helps to find great programmers:" Hire people who are developing in their free time just for fun. "

Although we never limited ourselves to hiring only those who were engaged in their own projects in their spare time, this indicator is a good litmus test for hiring the right people.

Another rule that we always follow: projects must run as marathons. You must establish the correct, healthy pace that will help win the race and hold out until the finish. This time should be limited by some framework: sometimes a programmer needs to work a lot, quickly move to the finish line of the project, but you should not expect that the programmer will always work at the same pace. ”

There are a lot of books on time management - so many that by downloading them to ships in printed form, you could sink an ocean flotilla. All the more surprising to know how rarely a bundle of time is considered with software development.

Real masterpieces in the field of time management for programmers in general piece product. We recommend Frederick Brooks’s book The Mythical Man-Month or How Software Systems are Created, which was published back in 1975, but for many, it may be relevant today.

Another recognized "classic" was released in 1999 - this is the "Cathedral and Bazaar" by Eric Raymond. The essay is based on the analysis of the development of the Linux kernel and considers the shortcomings of various models of free software development, including in terms of time costs.