Back when I was a first-year physics graduate student, one of my favorite professors used to get on my case about using pencil instead of pen for my notes and problem sets.
He’d say, “think and then commit with ink!”
As I progressed through my studies, I realized that my use of the pencil was a symptom of something deeper. I’d developed the habit of trying to get toward a solution by writing equations down and having to erase my errors as I went along.
This is fine at first. But when a complete equation involves so many complexities and spans multiple lines, you begin to confuse the activity of writing for clear thinking, diving in for the sake of starting. Using the act of writing as a way to figure out what’s going on in a physics problem can end up obstructing itself and taking too long for a good feedback loop to form. It becomes difficult to actually think because there are so many adjustments and things on the page to take in.
I eventually did switch to ink.
Committing to Ink in Code
Nowadays I spend most of my days writing code. Yet some of my most proudest moments have involved coming up with an alternate solution that allowed me to write no code at all — or even better, to delete a bunch of code.
Those times have one thing in common: instead of tackling a problem by immediately starting to code solutions, I’ve taken a step back, gotten away from the keyboard, and just thought about the problem at hand.
Writing code can be a lot like doing physics in pencil. At first, for simple things, it’s usually fine. However, as the complexity of the code grows, it becomes more and more difficult to keep producing code that both runs and allows you to keep thinking.
If you jump into projects and problems by coding like how I was writing and erasing in pencil, at some point you get lost in the details and you have to stop to make sure things are running. The process and your problem-solving become inefficient. Just getting stuff done, which is what people seem to be talking about all the time, is not all good when all the doing is haphazard and you have to expend energy and resources to go back later to erase and fix things.
It’s usually far more streamlined to first think and then commit.
Manager Thinking —Do It Before You Manage
Recently I’ve been thinking a lot about my role as a manager at iDoneThis and how the “get it done” attitude can infect the problem-solving of management just as it does for physics and coding. You can get into the bad habit of managing in pencil for the sake of doing stuff, commit to decisions and directions as you go along a bit too quickly, resulting in confusion and inconsistencies that end up taking a high toll on the people you manage.
Now, I know nothing of what the workplace used to be a few decades ago, so I might as well romanticize it. I bet you nobody had an activity feed or a dashboard for the type of knowledge work that’s prevalent now. While tracking and data are very useful when it comes to management, collecting any data about employees’ work has a cost. (TPS reports, anyone?)
Naively collecting and studying activity data just because the myriad online services we use provide it sets up a poisonous incentive: doing to appear active. This is certainly not manager thinking. It’s doing stuff in pencil, creating too much information to form efficient, meaningful feedback loops for effectively managing people.
So it’s important to be very mindful about what data to collect and analyze, and when. The successful manager will only want to collect and look at data in such a way that the very activity of doing doesn’t hamper his employees’ ability to think and commit within their own jobs.
Liked this post? Subscribe to our free newsletter for more great content on productivity, management, and how to work better!