This post was originally published at meluski.com
Programming problems tend to stick with you if you don't intentionally disassociate. They are a slightly (only slightly) more benign version of the antagonist from “It Follows”. They follow you in the shower, in your car, to the gym and back. And then if they touch you, you crumple into a lifeless quivering mass, whimpering and wondering why you didn’t read more programming books or go to that conference in Iceland last year (probably because you were too busy working on the previous programming problem to do something normal, like book a hotel room).
I'm not sure whether it is something cultural or unique to my experience, but historically I have approached learning, personal growth and work through a brute force framework, a "sleep when I'm dead" mentality which, unsurprisingly, often left me cranky and moody. The only answer to learning something new was to pile it directly on top of my already overloaded brain with little regard for capacity or sanity.
What finally got me is one of the core teachings of Barbara Oakley, which is that the brain needs to achieve a state of diffused thinking in order to learn something more completely. This was, for someone who constantly allowed himself to be mired in the details of their work (and in programming, there are always details), a revelation.
Rest is the crucible of mental persistence, motivation, and endurance. We all need the energy to keep moving through the day and drive complex problems forward. Many problems are deeper wells then they initially appear, and plumbing them becomes taxing. At a certain point, you have to wonder if continually driving forward with no breaks is actually less effective, time-wise, then throwing yourself ten or fifteen minutes to recover and think of something else, like dinner.
Lately, I work in concentrations, intervals of twenty-five minutes (or more, because finding a clean stopping point is critical). I find that when I make a timer and shut my distraction windows (Slack and Messages) I am more able to work through sticky issues. That is how I structure my days now, even when planning the night before - I may give myself two hours of straight coding time, with the understanding there are going to be three to four twenty-five minute sessions, with downtime in between each.
And there is where the real glue happens. When I take a break from work, it means I have to stop and do nothing, allow the mind to become unmoored. That doesn’t mean pumping my brain full of Twitter or the news. That means, sitting there and absorbing all the data and complexity I just pushed through my brain hole - particularly if I am doing challenging work, or trying to move through a new concept, technology or programming paradigm. When turning theory into practical application, the brain needs space to connect all the disparate things.
What you have here is a bit of weight and counterweight. On the surface, all the work appears to be done in the blocks of pure work. This is what someone can wave in front of their peers and manager, link them to the commit list and allow them to be amazed at the throughput.
I think there is just as much going on when you stop and would argue that it's actually more critical. Grinding through is workmanlike, it creates value by virtue of checking the boxes on the task list. Stopping work, absorbing and reflecting is when the compounding happens - when getting the shit done meets up with memory, conceptual knowledge and whatever else matters to what you're doing. This is where you might see a separation between people who do the same job for years and years and people who move on to more conceptual roles. That's just a theory, but not too wild a one, I think.
Top comments (0)