You need to set aside time to think at work

You need to set aside time to think at work

Coding is a small part of the job of a developer. We spend a lot of time at whiteboards, drafting designs. We spend a lot of time reading code. And we spend a lot of time thinking.

We all think about code. A lot. But what about everything else? Are you thinking about the design? How about the decisions you’re making right now and the impact they’ll have on you, your team, and others now and down the line?

Mistakes tend to happen precisely at the moments we aren’t thinking. Sometimes we’re just on autopilot. Other times, we’re focused solely on the task at hand, forgetting about how it will impact other future decisions.


We need to start thinking clearly about the problems we’re solving. Decision impact is one of the big ones for sure. Too many decisions are made in a silo. How are the changes you’re making today affecting others?

What about months down the line? This is often one of the big differences between junior devs and senior devs. Senior devs tend to be thinking about the long term product strategy. Junior devs often miss this. Start thinking deeper about this if you want to advance your career.

Speaking of careers, we should be thinking about our own. This is something I missed early in my career. You know those questions you always hear, “where do you see yourself in five years?” You don’t have to think that far ahead, in fact that might be a bit foolish. Things tend to change a lot and hardly go the way you expect. But start thinking about what type of career you want to have. How can you align what you’re doing in your day job to further your career goals? Alignment between organization goals and personal goals is the best way to motivate.

How to do it

But how can we find this time? Often the demands of the job prove difficult to work in time to actually think. There are steps we can take to combat this.

Block off time on your calendar. People do not do this enough. Don’t be a slave to your calendar, make it work for you. Too often we allow our calendar to get populated by too many meetings. Step one is to just block off time so that meetings aren’t scheduled on specific times. On top of this, you have to make sure people respect that time.

That leads me to a follow up idea. Know when to say no. Decline meeting invites that overlap with time you’d like to spend thinking. Decline meetings where you won’t provide value. You don’t need to go to every meeting. I found it very liberating to start removing myself from many meetings where I didn’t think my presence really benefited myself or others. You’ll find people actually respect you more when you do this. It may be hard at first, as people may not expect it from you. But once a precedent is set, you’ll be much happier.

Find a quiet place. Its not good enough to be at your desk, there are too many distractions. See my last article. Finding a quiet area will prove hugely beneficial. This will really allow you to think and reflect.

Grab some tools. Tools like mind maps, brain dumps, and others improve your thinking. They get things out of your head and in front of you. This allows you to clear all the crud that’s in your head and focus on what’s important. It can also save you sometimes when your memory fails you.

Should you do it?

Hopefully I’ve convinced you that you need to make thinking time a priority in your own career. You’ll find that it can improve your coding without even touching a computer. You’ll improve your product by building a plan and thinking through the impacts. And most importantly, you’ll improve your career, by taking control of the direction you want to go, rather than letting others drive it. So I challenge you to set aside time at work and really think about all these things, and others.

Know the problem you’re trying to solve

Know the problem you’re trying to solve

You sit down to start a new project. You start setting up the environment, maybe its a web service you're writing. As you're going along, you think, "what if I want to switch the database on the backend?" So you start to add in an abstraction layer there. You pack up for the night and promise to yourself to finish it tomorrow.

As tomorrow rolls around you think, "Gee, that DB abstraction is really boring to work on, so I think I'll work on something else." And this happens the next day, and the next…

Sound familiar? Maybe this happens to you at work too, you start designing a new service, and you make sure its scalable to 1000s of requests per second. But then your service is serving 10's of requests per day and you're already too late to the game.

This happens all the time, we get derailed with the technical details and totally miss focusing on the problem we were trying to fix in the first place. We take way too long to produce a solution, and end up either losing interest on a personal project, or bringing a work project to market way too late.

In my last blog, stop coding by coincidence, I detailed how we can bring the practice of mindfulness into coding. In this one, I'd like to dig into how mindfulness can help us with the problem of over engineering.

Over Engineering

Over the course of nearly a year, I worked on a team that developed software to allow a doctor to beam in to a room in a hospital and facilitate a consult. We were replacing a system that was supposedly not keeping up with the demands placed on it, while also being difficult to change.

The team worked tirelessly iterating on the new product we developed. We laid out new designs with a nice micro-service architecture. We used AWS auto scaling groups to scale the product for the future. We built the product to be extensible for future use cases, building a platform rather than just a product.

We built a great software product, technically, the final product was leaps and bounds better than its predecessor. And then we brought it to users… and they liked it!

But (you knew the but was coming) when traffic started hitting our servers, it was very slow. We thought it would grow quickly, but the business contracts that were to be supporting the product fell through.

We had built a technical success that wasn't being exercised enough to make the effort worth it. And you can probably guess what happened next. Although we executed quickly, we were up against too tight of timelines to roll it out to other lines. The project pivoted, and much of the work that had gone into building the product felt wasted.

It wasn't all bad though, the product was able to pivot and get reuse in a different area. It still isn't seeing the traffic to justify the scaling engineering that went into it. And had we spent more time focusing on what was truly wanted by the users, perhaps we could have rolled out a solution quicker and more focused on their needs.

So where does mindfulness come in?

The thing is, this story is hardly unique. Stories like this one is why the agile movement picked up so much steam. But we were practicing agile, we produced working software every two weeks that we put in front of users. So even with the best efforts, this can still happen.

But there were plenty of moments to right the ship, and that's where I can see mindfulness playing a role. Many hours were spent discussing designs on a whiteboard. Architecting out grand solutions. Many code reviews were had that suggested better and more performant ways of doing things. These small day to day interactions provide all the opportunity we need to refocus ourselves.

Mindfulness doesn't have to be exclusive to coding, we can practice it any time. Those times at the whiteboard, it is useful to think to yourself, what are we really doing here, are we solving the right problems? And the same with the code reviews, thinking, is it worth investing the extra effort here, is this the correct problem to be solving.

This can also happen directly coding. In my last blog, I referenced TDD and how it focuses you on the problem at hand. I want to reiterate that sentiment. TDD draws the boundaries for you, enabling you to solve just the problem you're trying to solve. It can help you think carefully about whether or not you need to solve a grander problem. It allows you to be mindful of the iterative steps you're taking to solving that problem, and how much work is left to meet the real requirements.

There's more to do

Over engineering and focusing on the wrong problem are mistakes that happen every day. They happen for a myriad of different reasons in many different situations.

Of course, mindfulness is just part of the equation. It is no silver bullet for the problem of over engineering. In fact, it is really just the catalyst to get you started down the path of thinking about how to prevent it.

If we can be mindful of the small decisions we make day to day on our projects and how they'll impact us down the line, we'll all be better off.

Stop coding by coincidence, start coding mindfully

Stop coding by coincidence, start coding mindfully

Dave Thomas and Andy Hunt coined a phrase I love in their book the Pragmatic Programmer. They refer to a process of “programming by coincidence”. They contrast this with “programming deliberately”. We can capture this idea with a more relevant phrase and repurpose it a bit as “mindful coding”. The names pretty accurately describe these ideas, but let’s dive a little deeper.

Programming by Coincidence

We’ve all been there. You write some code, it doesn’t work. “What’s happening, I was sure it would work”, you thought. “It’s late, let’s just flip the greater than sign to a less than sign in this expression… Holy shit it worked! Done!”

We all code like this from time to time, you might have even been guilty of this exact thing. I know I have been. But guess what, we both know this code is going to be hard to maintain. If by some miracle it is easy to maintain, it is pure coincidence.

So how did this happen? Developers work on a ton of different things. Our attention is pulled in a myriad of directions. Unfortunately, this causes things like this. You may not even remember writing a piece of code, you were so distracted while writing. How could you possibly guarantee its “correctness”.

This is something TDD was trying to solve. Break a problem into such small steps you can’t possibly mess it up. Even if you didn’t apply your full attention, you’ve made a guarantee that the code will do certain actions and things would be ok. You passed the unit tests before you could move on.

But TDD isn’t enough. This clearly doesn’t guarantee that your tests are even worthwhile. So what is the alternative?

Mindful Coding

This is where mindful coding comes in. Writing code deliberately that solves the problem you’re trying to solve.

This is clear when trying to debug why your code doesn’t work. Take a step back, think about what you’re trying to solve. Rather than just flipping that greater than sign, think about what criteria you’re trying to meet. What are you invariants?

Breaking the problem down helps a lot here too. Chunk it out, solve the smaller bits first. How do the pieces fit together? Don’t just mash them together, then we’re right back into our mindless coding.

I introduce the concept of mindful coding very deliberately. For me, it draws an obvious parallel to the mindfulness movement. If you aren’t aware of it, read up.

Mindfulness is about being present in the moment. Being aware of what you’re doing. You’re walking somewhere, but to do that, your legs are moving. You can feel the ground in your feet when you take a step, that kind of thing.

Let’s apply that same idea to coding. You’re writing your if statement. Why are you writing it? Oh yeah, we need to make a choice here. What are our two choices. Let’s wrap the choice in a function to make it more clear to the next reader.

See where I’m going with this? Mindful coding leads to code that someone else might be able to read because we’re constantly being attentive to what we’re putting on the screen.

How to code more mindfully

So how can we write code while being more mindful about what we’re writing? There are many techniques we can use to pull this off.

  • Understand the code you are modifying. This might sound self explanatory, but let me dive in further. Kent Beck discusses exploratory testing in his book TDD. This is exactly the type of thing we need to be doing to understand the code we’re working on better. Furthermore, code that doesn’t have unit tests could benefit from them, and so will your understanding in writing them. Write tests that explore how the code functions, why it functions that way, and where it functions unexpectedly.
  • Slow down. So many of us are in a race to finish what we’re doing. Of course we are, we’re all fighting tight deadlines, and its hard to predict the future. But the reality is that 9 times out of 10, slowing down will speed you up in the future. Slowing down, being aware of what you are writing, will pay off in spades when you come back to this same code tomorrow.
  • Have a plan. Do you know what the plan is going to be before you put code to screen? Take a look at this video, where google shows you how to do one of its interviews. Pay attention to how the interviewee describes his plan before writing it out. They look for this because it allows a developer to think through their intentions before writing out what they’re doing blindly.
  • Building on that… know your assumptions. If you have a plan, you must have built that plan on something. You might have already detailed these in unit tests, and I think this is one of the great insights that Beck was trying to get to with TDD. You’re literally testing your own assumptions in your unit tests, so think through them.

There are many other ways to remain mindful while coding, these are just a few from my own perspective.

We could all code a bit more mindfully

I’ll be the first to admit, I’m not always great at this. I sure try to be, but there are times I find myself lost in my own code. But that moment that you come to, you recognize your own ignorance, is a critical moment. Take note of those moments, they are the most important. It is mindfulness at work, and the key to a new feedback loop to help yourself be just a bit more mindful next time.