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.

The distracting world of software development

The distracting world of software development

On a typical work day, I get interrupted from what I’m working on about 9000 times, or about once every three seconds. At this point I’m a pro at getting interrupted.

Now, obviously, this is hyperbole, but the point is valid. As developers, there are a lot of different pulls on our attention. Of course this isn’t unique to developers. But as tech companies move to open floor plans, the need to be able to focus, despite those distractions, is growing.

I’ve focused a lot lately on the idea of mindfulness while coding, but it is easy to see how distractions can prevent that. Any interruption can snap you out of your focus, and suddenly you’re rabbit-holing down a path you never intended.

Preventing Distractions

Ideally, we can remove our distractions. I’ll touch on a number of ways I personally attempt to remove distractions from my work.

External Distractions

The first type of distraction we’ll need to deal with is external. This is interruptions coming at you from outside your control.

My number one way to attempt to block these interruptions is probably everyone’s most common. Headphones. You simply have to get yourself a decent pair of headphones as a developer. This is crucial even if you don’t listen to music! Other than drowning out background noise, headphones provide an immediate visual cue that you are in monk mode. They say, “Now is development time”.

Of course, they don’t always work. Not only will some people not respect the headphones, sometimes people just consider their thing the priority. Hopefully, your office provides you some side rooms. At my office, these are called “JITs”. Anyone can grab these rooms at any point and just work. If your office doesn’t provide these, I recommend getting cozy at Starbucks.

These strategies can help reduce the interruptions caused by drive-bys, but Slack and other applications can be just as annoying. I have two main strategies for dealing with these.

Number one, block off your calendar. Put time on your calendar for dedicated tasks. If you need to write that new feature, put a spot on your calendar specifically to work on that. This does two things. One, it prevents others from scheduling time there, and notifies them you are busy. You can also put up auto replies and go away on slack if that helps. But two, it sets aside mental space for you to work on that task.

Two, turn off notifications. This has a bigger effect than you might realize. I actually do this in most of my life, but at least temporarily disabling notifications on your laptop can be a big deal while trying to focus. Slack, especially, has a tendency to be distracting. On mac, use do not disturb mode.

Internal Distractions

For me, this is the harder one. Narrowing your focus to just the task at hand. I have multiple tricks I do to this end. In fact, turning off almost all notifications, which I mentioned previously, on both my phone and laptop all the time is something I do to help this.

Not everyone is willing to take that plunge though, so that’s where focus apps come in. There are a variety of these out there, but here is one: focus booster. These apps work by blocking access to a variety of typically distracting sites. Facebook, reddit, twitter, these sites aim to keep you locked in them. As a result, they are addicting, and sometimes we need help to stay off them. These apps help with that.

This next tip will probably be met with some resistance, but hear me out. Switch to a single monitor setup. Using one monitor keeps you focused on the one thing you’re working on. If you can’t do that, use two, but position one directly in front of you. I’ve seen many developers position the second monitor vertically, this also helps delineate which monitor is your focus. But nothing beats a single monitor for this.

To enhance the single monitor lifestyle, use full screen apps. This keeps you in the app your working on. Get good at alt-tabbing (on windows) or switching desktops (on mac). This has been one of the best hacks for my productivity. Not only does it make the app easier to use, it keeps you constrained in the app. No more checking Facebook on the side.

Dealing with distractions

As we all know, not all distractions can be prevented. Sometimes we just have to deal with them. This is where things get difficult. We may have to break social norms. We may have to attempt to dislodge the status quo.

The biggest single thing you can do is learn to say no. Often, when coworkers come to you with a request, it can be hard to turn them away. But when you’re really focusing, this can be the best way. Take a note of it, and move on (I mean a literal note). Follow up when you’re not focusing. Or don’t, because the likelihood is that it isn’t a priority for you.

This can be hard. We want to help others. But you have to know your boundaries. Deliberately setting those boundaries can go a long way to know when its ok to let yourself help someone.Those boundaries can also enable us. Use those boundaries to set expectations with others. Tell them your boundaries, and they will respect it. This can help remove the awkwardness of the no all together, you never even get to that stage.

Finally, mindfulness (you knew I’d come around to it eventually) can help us realize these moments. Oftentimes, when these interruptions come up, we react without even thinking about it. If we can slow down, and take the time to see what is happening, we’ll be better for it. Mindfulness can be the key that enables you to say “no”.

How do you remove distractions?

These are some of my techniques, but I’d love to here yours. For me, this is a constant learning process, and really no two people are the same. Some techniques work with some people, some with others. If you’d like to share, drop a note in the comments!

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.