There is a lot of writing on what makes a productive system. I aim to convince you that the details don't matter beyond personal preferences. What does matter is that in order to be productive you must separate the time you are doing from the time you are thinking.

SPORTS

Sports, fundamentally, are divided into periods of doing vs. periods of thinking. The practice is an incredibly cognitive task that requires analysis of past performances and current skills. The performance, conversely, requires almost no thinking whatsoever. The actions come naturally from countless hours of repetition and practice.

Top athletes often speak of “muscle Memory” and “reflexes” during periods of peak competition. Muscle memory (or motor memory) is a phenomenon when a physical action becomes so ingrained that we no longer need to spend cognitive energy to perform it correctly. We are simply able to do it naturally without thinking.

MUSIC

Musicians experience similar motor phenomena when playing their instruments. Music practice is arduous work pouring over notes and fingerings. Building the motor memory to play ridiculously complicated pieces quicker and more fluidly than we would otherwise be able to do is fundamental to how musicians are evaluated. Sight-reading is the act of grading musicians on their ability to perform a piece with minimal preparation, usually only a few minutes.

GETTING THINGS DONE

Your mind is for having ideas, not holding them. -- David Allen

Arguably one of the most famous productivity systems, GTD, fundamentally divides its activities into doing and thinking.

During the thinking period, you analyze your inbox, reflect on past performances, and determine which steps to take next. During the execution period, you delay thinking or analyzing in favor of execution until the next allotted thinking period. Any thoughts that occur to you during the execution period are recorded and not thought of until the cycle restarts.

SOFTWARE ARCHITECTURE

The fundamentals of architecture fit very naturally into this paradigm as well. Most architectures split the segments that require business logic from the segments that only act.

For example, the MVC architecture is a classic architecture that follows this paradigm. The Model only contains data, and the Views do whatever the Controller asks them to do. they do not contain business logic. they merely understand how to execute tasks in their respective world (rendering). The Controller, on the other hand, only understands business logic, the controller can determine what to do but does not understand how to do it. it delegates that step to the view.

VALUES AS BOUNDARIES

Gary Bernhardt gave a good talk in 2012 about setting values as the boundaries. The meaning of this talk suggests that you should split the logic of “how” you determine a value from “what” that value does. The notion of single responsibility fits in pretty well. These are all just specific instances of splitting thinking from doing. Part of your system understands “how” to determine a value (this Is the thinking bit). The other executes on “what” to do (the doing bit). This allows your code to naturally grow and scale because of the parts that need to think, don’t do, and the parts that need to do, don’t think.

HOW to apply this

The application here is simple. If you feel overwhelmed Start simply. Separate your planning process from the actions. The thinking from the doing. A simple approach to this is to plan the next day at the begininning of the day with a simple list.

Something a little more advanced looks like bullet journaling, which applies structured planning and check-in times over the basic structure.

An advanced version of this looks something like Getting things done or some variation therein.

Personally, I lean more on the simpler version of these things.

• Spend 5 minutes at night / morning planning the major things you want to accomplish in the next day
• Revew the week (hits & misses)
• Spend 30 minutes every few months setting larger goals / Reviewing the previous season.

The 98% remaining time is focused on execution, knocking the set goals off my list. I don’t plan or review during this time.

Designers are, almost by definition, problem solvers. Every field values them differently, but a good designer needs to understand the field in order to solve whatever it is they are designing for. Hence, it’s difficult to be a good designer without understanding the problems of the field you’re in.