Hi everyone! At first I wanted to reflect in the title something about personal effectiveness, but then I strongly rejected the idea. I want to note in advance that it will not be so much about achievement and the correct setting of the goal (although this is important), but rather about personal experience and the events that led me straight into the arms of this question (and it happened quite spontaneously). I will also highlight basic ways to simplify work, they are as simple as they are effective.
Background
For most of my development career (both front-end and full-stack), I've been thinking about an important task: code performance. However, my personal effectiveness somehow fell out of the zone of my interests ... Well, not that right at all, but I didn't stay there for a long time, so my knowledge in this area so far has been very, very limited and abrupt.
Skipping long explanations, I will go straight to ... The culmination of my story, which happened this summer. It so happened that absolutely all the stars that could do it came together. Everything was there: I actively disliked my project, and I was also transferred to a new one, which I liked (at that time) even less, “added” happiness and a close deadline, added fuel to the fire with regular incidents with the local environment, quite large problems in my personal life, the cancellation of the flight, thanks to which I was stuck in another city, if you add an epidemic here, you get a fairly complete and understandable picture. All this led to the fact that I began to burn: it was difficult for me to work, it was hard to perform more or less difficult tasks, all the time I wanted to run away somewhere: tea, YouTube, a book, etc. At some point, I realized that I could no longer work (well, right at all).This is understandable, because all my work in recent months has been built on self-compulsion: I forced myself to work. Pretty logical result.
The obvious ways to get out of this situation are to try to change the project or go on vacation. But, firstly, it doesn’t happen instantly, and, secondly, I didn’t know how much I would last after a vacation or on a new project. Then he asked himself the question: what do I, in fact, want? It turned out to be anything but programmable (amazing). For example, drinking tea (I wonder how other people answer this question, finding themselves in a similar situation, but perhaps we will never know). And I said to myself, "Okay, I'm going to have tea, but first I'll do something." And this is a very important point, trying to understand what I can do in such a state, I began to divide the task into microtasks and cut off unnecessary ones. It sounds simple and logical, moreover, these are the basics of design. However, in fact, not everything is so rosy. In the process of completing a task,we still look at the task as a kind of monolith, although it may have been broken down into its components before. Moreover, we are constantly asking hundreds of different questions, and what will happen if this happens (say, an error will come from the server).
To what extent to simplify the task
I split the task not into independent modules, but until they became elementary and ceased to cause internal resistance in me. In general, it may sound like this:
- Create a component stub with a base interface
- Connect her
- Add markup
- Transfer real data
- Add styles
- Write tests
If it will be difficult, then these steps can either be refined, or the component can be developed in parts. (How do you do it?)
Next, I want to draw attention to three important principles:
Dividing the task into elementary
In my case, the initial stage looked something like this:
- Stub a component with fishy text
- Add a route for her
- Check that she is connected
- Find out at which addresses you need to receive data from the server
The result of this decision:
- The tasks are elementary, even in this state I look at them with some relief, not disgust.
- It's easier to concentrate on tasks like this.
- Also reduced stress levels (I don't force myself, and the tasks are not that scary big)
Focusing attention on a narrow range of subtasks
- Less time spent on subtasks
- Less brain resources are spent
- As a result, the task itself is completed faster.
Limited time of one iteration
- I can easily agree with myself that now I will work for 15 minutes, and then I will take a pleasant break for 5 minutes. While convincing yourself (getting) to work all day will be harder and more frustrating
Let's sum up
In order not to waste my own and other people's time, I will try to do it as shortly as possible:
- Work is no longer stressful for me
- I got less tired by the end of the day
- The performance has increased in comparison with the non-stress value: earlier a task for 3 story points + writing tests took me 2 days, now it turned out no more than one and a half
- A more professional approach is to use a timer. I would like to talk about my successes (and failures, where can I do without them) in introducing the tomato technique another time.