How to be efficient

Sat, Jun 8, 2019 ❝How to be efficient, using your brain to work for you.❞

Contents

This is a reflective article, in which I look back at the last years of open source development, done in my personal time, and professional engineering at work.

I’m writing this given the assumption that the mind does not have a single “state of mind” that is suitable for all types of work, but rather has various possible states and not all types of work are suitable for all states. We may be limiting ourselves by actual brain capacity sooner than we think, if we rely on our memory for everything.

Setting circumstances and expectations

Not everything can be solved at once. The more complicated or comprehensive the problem, the more time it will take to master it. It helps to set the right circumstances and have the right expectations.

1. Make sure that different types of work are available to be picked up:
   • simple tasks
     Trivial pieces of work that need to be done, but are by itself not very difficult or exciting or inspiring.
   • complicated assignments
     Assignments where you need to pay attention and use your brain, i.e. they are non-trivial, but the solution is already known.
   • complex problems requiring a definitive solution
     The problem may not be well understood yet, the solutions may be non-existent or the definitive solution not selected yet.
2. Create - for yourself - an overview of the gathered information, including the problem (goals, limitations, scope, etc.)
   Basically, you’re off-loading the whole problem onto a piece of paper, a mindmap, a Markdown document, or whatever flavor of persistence you prefer. Rereading this information at a later time, may help you to realize new things.
3. Try to identify open issues in your problem early. Solve them - without rushing - in due time. Give your brain time to comprehend the problem-space and its context. Let your brain process and play with the problem before forcing out a solution.
4. Do not aim for “the solution”. Instead, inventorize which characteristics a viable solution must have. Evaluate the characteristics for each solution. Select solutions that score positively for relevant characteristics. Ignore characteristics that do not really matter, or preferably, choose solutions which have the least number of characteristics of the “do-not-really-matter” type, i.e. prefer the simpler (reduced, restrictive) solution.

Realize that SCRUM will try to restrict in-sprint work to the classes simple tasks and complicated assignments, as the 3rd class has no solution available yet, i.e. it is not “ready”. Therefore, if that type of work would be added, it would provide a significant chance to explode, minimizing the chance of finishing the sprint successfully.

Increasing headspace

There are a few tricks to create more headspace, i.e. off-load other concerns from your mind so that you have capacity to spare for the problem you are currently working on.

1. If you are juggling multiple problems at a time, write things down. You allow your brain to off-load issues which creates space for your problem.
2. If it is necessary to create time, get coffee, take a walk, have a look through the window to a (hopefully) nice and tranquil natural environment.
3. If the problem is too complex to solve, or too complicated to get in your head, break it down. Find it’s core constituents. Try to separate individual concerns. Almost no problem is a comprehensive monolithic whole that is too large to keep in your head, yet indivisible.
4. If you do not seem to be able to break down the problem any further, iterate over solutions by just trying a first approach and seeing where it leads you. Learn from the failed or partially viable attempts at a solution. Then iterate with the additional knowledge you have gained.
5. If you are stuck with a problem, validate “known” information:
   • Is it really of concern? (separation of concerns, scoping)
   • Is it really relevant at this time? (iterations)
   • Is it really a full truth? (Is information missing? Are all details correct?)
   • …
6. Start on a few tasks of a different nature: drop the problem you are struggling with and pick it up at a later time. Next time, you will have a new perspective on the problem. By switching tasks, you can effectively force your brain to tackle a different problem.
7. Buy your brain some time by performing a few simple tasks, such that part of your mind can process the problem in the background. There are “background processes” in the brain that, by picking a simple task, are allowed to continue imagining solutions, while you perform the simple task. This does not work with complicated assignments, as you need to pay full attention. You can also use this to give your brain some time to relax and wind down in general.
8. While performing tasks, do not rely on using your memory for everything. Make a checklist! Why spend headspace on trivial facts if you can use it for representations of a complicated problem or assignment?
9. Reduce context switching to a minimum, especially unprepared/unplanned context switches. Context switching literally drains energy. You feel tired at the end of a day with many context switches.

All of these tricks help to clear your mind and focus on a single task at a time. Many tricks help you to stop multi-tasking. Some tricks help you to find the task that is appropriate for your state of mind.

From experience

Most problems, puzzles, challenges - however you want to call them - I was able to solve by clearly identifying the actual problem. Then reduce the problem-space by ignoring as-of-yet irrelevant characteristics, scoping, and putting unnecessary demands out-of-scope. Then come up with a suitable solution for that which is left. Do not speculate on the future, but be aware of what is requested now and restrict your solution to the minimal requirements needed for what is requested. The issue with speculating for a potential future, is that you most likely do not have the full future request in scope, hence your preparations are either incomplete or (completely) wrong. In either case, you will need to “rework” your preparation anyways. If, on the other hand, your “future preparation” work is done, but “the next feature” lost priority, then you have created yourself a maintenance burden for an unsuitable, unwanted piece of functionality or, at the very least, logic; a very real source of technical debt.

Reducing a problem may sound simplistic, or maybe it is described naively ("real-life problems are more complex"), but in many cases it actually works. In order to understand the problem, you need to find out if you are aware of the true problem. Be sure to ask “why?”, repeatedly. See if you come up with the same derived problem statement that was originally stated. If not, check and align on what is the real problem. It is only when you really understand the problem, that you can come up with a suitable solution. By restricting the problem, you are restricting its requirements, hence you reduce the problem space and corresponding solution space. This makes for a smaller problem to solve, which takes less time to solve regardless of the chosen solution.