Work diary programmer

wikipedia.org

I want to tell you a little about a useful work practice that has been great for me for some years now. Oddly enough, not all developers use this. Perhaps most simply did not occur. Fill the gap, we will conduct a session of educational program.

The very idea of ​​a working diary is very simple. Starting work on the next task, I start a new text file in a special folder. In it I write all the thoughts that come to mind while working on this task:

• What problem i solve
• What actions do I plan to perform and in what order
• What actions have already taken, and what they led
• What are my assumptions about the nature of the problem?
• What difficulties and neponyatki arise
• Who are your colleagues and what should you talk about?
• What prevents me from taking the next step
• And stuff like that

In general, I try to keep everything more or less useful.

It usually looks something like this:

How exactly does this help

Unload your head! The more thoughts you need to keep in memory at the same time, the less resources are left to the thoughts themselves. Writing down all the plans and tasks is the basic principle of the GTD technique. For developers, this is especially true: we usually have to deal with very complex tasks that are difficult to load into the head entirely. Throwing off thoughts and ideas in the diary, we free up the head for reflection.

It is easier to recall the details of solving the problem. For many programmers (and for knowlege workers in general), the most productive mode of operation is the “flow” - full immersion into one task. Continuous focus on one goal without switching to others. However, sooner or later you have to take a break and do something else (even though household chores), and return to your current task after some time. With the help of the diary, you can quickly remember what we stopped at last time, and where to go further. Saves time and effort to return to the stream.

Also, sometimes you have to turn to old tasks after months and years to repeat them or at least find out the details of what has been done. The head will not be able to keep all the nuances of the task after such a period of time. And nothing will happen to the records.

We keep small utility facilities. For example, references found in the course of work. Or useful code snippets. The next time you need a similar piece of code, you do not have to restore it from memory. You can simply find in the diary through the search.

We formalize an incomprehensible problem - this is how it is easier to solve. Many people know the so-called "duckling method" , which helps to solve incomprehensible questions. You tell your problem to the listener in detail (in the role of which even a simple toy can act), and it often happens that while you formulate the problem, the brain finds its solution.

This approach works great without a listener! It is enough just to take and describe in detail your problem in the diary, the more detailed the better. And this is great, especially for introverts: you silently print something to yourself and find the solution yourself. No need to talk to anyone - beauty!

Solving a complex technical problem often resembles wandering through a maze. They moved in one direction - they stumbled upon a wall, went in a different direction - they met an abyss. Along the way, they discovered the treasure in the side tunnel, but they did not immediately take it. Work diary is a map of the maze, with all its turns, traps and nishtyak.

Diary disadvantages (or not?)

It is easy to see the weaknesses of this approach. However, they are not so scary!

An extra waste of time. Yes, keeping a diary takes a lot of time. Not in all cases, you can afford this luxury. Is it permissible to write down your plans in a diary, when you need to urgently roll a fix onto a dropped prod ?

On the other hand, an emergency condition is a rather unnatural thing for an intellectual worker. In this mode, it is difficult to do things qualitatively, the risk of a mistake somewhere increases. Mistakes lead to new abrasions, and there it’s not far to stall into a deadly corkscrew!

At such times it is better to slow down, think a little, clearly understand the causes of the problem - and do everything right. It rarely happens that the first solution that comes to mind is not at all the right one. I think you have already understood what I am leading to: slowing down when solving problems is not only non-harmful, but also useful. And the diary will only help in this!

By the way, nothing prevents to describe the work done in the diary immediately after the emergency fix.

Alice sleeping

Duplication of work. I’m sure many readers by this time have already matured this question: " We already have a team task tracker, isn't it enough for journaling? "

I have no definite answer to this question. The circumstances of all are different, and it would be wrong to approach all with one measure. I can only say for myself. In the diary, I allow myself to write absolutely anything. The smallest reminders for yourself, the questions "did this thing, what are we doing next?", The key phrase "I'm stupid," and so on. Sometimes it's dozens of entries per day! If you write all this to the task tracker, colleagues will vomit because of the volume of spam and ban me forever.

Therefore, only filtered entries go to the tracker. Copy & paste, copy & paste ... Duplication of effort is obtained, but not so much. The total benefits of the diary still outweigh.

Too lazy to keep a diary. Perhaps the most significant and most serious drawback. Of course, to work with the diary has to spend a significant amount of effort and attention. The brain resists it as much as it can. He loves to save energy, although he does not always do it in the right places.

I also had periods when I gave up and temporarily retreated from keeping a diary. But nevertheless, invariably he returned to this practice over and over again, its advantages are too great!

How to make so that laziness did not get in the way? I have a couple of tips. The most important thing is to try to make keeping a diary as convenient and enjoyable as possible. Use your favorite text editor, reduce the amount of auxiliary manual actions, minimize inconvenience and focus on the main thing - fixing important points.

A more formal approach helps. The brain has the maximum resistance when there are no records on the task yet, but there are already a lot of ideas in my head, and I want to quickly check them all. It is important at this point - at the very beginning of work on the task - to apply a volitional effort and remind myself: "I have a rule that I keep a diary." Create a file and write all your ideas into it. The remaining entries will already go much easier.

Useful techniques

I will also mention a few additional tricks that help in the work on the diary.

Select the format of the diary. Simple plain text is not always enough when we work with code. I myself use markdown and I am completely satisfied with it: the syntax is supported by all popular editors, it is convenient to visually select headers, code, quotes, etc. But beware of imposing a markdown reader. This format has an alternative, for example: Restructured Text, Wiki, Orgmode . The main thing that is required of the format is not to cause irritation when reading and writing - otherwise the diary will not live long!

Use snippets. Some operations occur more frequently than others when working with a diary. For example, I used to start the next entry with the time stamp, so that later it was easier to navigate. It's pretty obvious that typing a date every time with your hands is too tiring (sometimes dozens of times a day!). Here it is worth referring to the capabilities of a text editor to make your work easier. I used to work in Vim, and for him there is an excellent Snipmate plugin. Now it is enough for me to write the word time, press Tab - and the time stamp is automatically generated! Similar gadgets have, perhaps, every advanced test editor.

Keep backups. The longer you keep a diary, the more valuable the information stored in it begins to be. Do not be superfluous to take care of her safety! I set up autocommit in git and backup to the bare repository inside Dropbox by cron . Now you can sleep well and not be afraid that the diary will disappear along with the dead disc.

We describe the context with all the details. Not an obvious, but very significant moment! While working on a task, many things seem obvious, so they may not get into the diary. But here passes some time, and the whole context is pushed out of memory. We open the diary again, see some scraps of records and can not remember anything. It will be possible to restore only what was recorded.

Imagine that we are working on a web application, and stumble upon it in an error. Will there be much benefit from the diary that is being kept like this?

I pressed something and everything broke: (((((

It will be much more useful if both the specific page of the application, the problematic button on it, and the text of the error get into the record.

Finally

wikipedia.org

I do not claim the laurels of the discoverer of this method. Proscharennye comrades successfully use it for more than one hundred years.

Surprisingly, it may seem that the idea that the work diary will be useful not only to the venerable inventor, but also to the modest hard worker-programmer. But it is so. The diary is one of the tools that facilitates the path to the heights of professional skill. Everyone is free to decide whether to apply it in their work. And I will be glad if my article at least slightly increases the number of those who are ready to try!