Interruption Driven Development



In theory, at a job, work is passed down to you. You don't have to figure out what to do next, your manager will line up your next task. In reality, we don't live in a vacuum. Developers are perfectly capable of identifying pain points in the application. They can make a case on why they should work on these issues.

I rarely find myself without anything to do at work. There is always a task in my mind that I know I can work on but don't have the time to. I currently work at a start up, and my queue is filled with things I should work on. Completing them would make our service more stable, improve team work, and most probably help us generate more money. But like most startups, my real work comes from the daily interruptions.

These are things that we have not anticipated. Customers reaching out and asking for a feature, misunderstanding in the way the product works, and unexpected bugs. We all want to create great product with amazing features, but as long as interruptions are still common, they are the priority.