Every so often, I’ll receive an email or a comment asking how one fights “Developer’s Block.”

Of course, not everyone phrases it or labels it that way, but that’s what it is. In short, people will generally say that they want to work on something or build something, but when they sit down to try to do so, they aren’t sure where to start or what to build.

This isn’t to say that they aren’t capable, but that they’ve simply hit a wall as it relates to figuring out what to build.

No idea.


And I think any developer who has attempted to work on something outside of their 9-to-5 knows this feeling all too well.

Developer’s Block: Push It Out of the Way

One of the things that I’ve noticed is that some people approach writing code much like they do writing words. They allot a certain amount of time at some point during the day when they sit down and say “Okay, now I’m going to work on acme project.”

The thing is: Writing code is not like writing, then again, it’s a lot like writing.

Makes total sense, right?

Push the block out of the way.

Push the block out of the way.

If you’re someone that allots time to sit down and write, and is able to successfully to do so, then I imagine one of three things has happened:

  • You’ve got an idea of what you’re going to write before you sit down to write
  • Inspiration happens to hit you the moment that you sit down to write (and this does happen, sometimes)
  • You’re sitting down to write free form and let something emerge during that time

With the exception of the last example, the first two are predicated on the idea that you’ve got something you want to do before you sit down to work, and that’s key to overcoming Developer’s Block.

But this does raise the question of how do you actually find that thing that you want to build or work on (assuming that you don’t already have something in mind).

1. Scratch An Itch

This has been used time and time again. In fact, I imagine that if you ask most designers or developers how they came up with the idea for one of their projects, they’ll say that they wanted to create something that would help themselves.

The “scratch you own itch” example is used so much that it’s almost becoming a cliche, but that doesn’t make it any less true.

Find a way to scratch it

Itch? Find a way to scratch it.

So one thing I tell others (as well as myself) is to keep an eye out for something when you’re at you’re computer and you get frustrated that you can’t accomplish a certain task. That is a source of inspiration for a project.

And if there’s a similar product that’s already available to do it, don’t let it discourage you. How brands of ketchup exist? How many different kinds of “To Do” applications are there?

It doesn’t matter that something else may already exist. It’s clearly not solving the problem in a way that’s best for you – hence the itch! – and the learning that will come from working on it will still create value for yourself.

2. Help Someone Else Scratch An Itch

Another suggestion that I make (and that’s based 100% on experience) is that if you’re having a hard time brainstorming an idea, or trying to figure out exactly what it is that you’d like to work on, there are plenty of things that others are working on that need help.

It's just like the buddy system, right?

It’s just like the buddy system, right?

In fact, I’d argue that this is true now more than at any other time in the history of software development – GitHub alone is enough to prove this case.

Find a project that you like, that you’ve used, that interests you, that you’re familiar with, that you know is lacking, or whatever and go work on it. An entirely different type of learning can come from integrating a new feature or a resolving someone else’s bug than can ever come from working on your own stuff.

3. Just Get It Working

Finally, just try to experiment. If you see a feature in a program that you like, or you’re curious as to how any given application achieves X, Y, and/or Z, then try to implement that same feature on your own.

Look at the source code, or don’t: It’s not so much about “the solution” as it is actually understanding how the solution is implemented. If you sit down to try to make something happen yourself, you’re going to learn. If you sit down to pour over someone else’s code, you’re going to learn.

It's Working

It’s a no lose situation.

And don’t worry about shipping it or not. It doesn’t matter of what you work on is incomplete, or if it’s not something that’s useful for anyone else. The experience that you gain and the learning that comes from integrating it will carry over into future projects.

Where Inspiration Hits

Finally, I’m one of those people who’s built in such a way that some of the better ideas for projects, blog posts, and the like often come when I’m not at a computer.

To that end, I always have my phone, a notebook, or something with which to capture an idea. And though I don’t think this is something that works for everyone, it’s something that I think works for a lot of people.

So much of writing – be it words or code – is conceptual that it doesn’t have to take place in front of a computer. After all, how many ideas for stories and applications alike have come when people are away from the pen or the keyboard?

It’s the same thing.

So pay attention for whenever the inspiration hits and take notes. You’ll be able to work on it later, but in the mean time, you’ve got something that’s going to let you fight off developer’s block for a little while longer.