Three Ways to Develop, #1: Working Solo

This year, as Atomic’s offices have gone fully remote due to the global pandemic, I’ve learned a lot about the different ways you can work on software and the importance of balancing how you spend development time. Pair programming is great, but sometimes, I just need a break.

In this three-part series, I’ll be exploring different ways to work on software development with and without your teammates. Hopefully, this will help you find a better balance when building your code.

Today I’ll talk about working solo — just you and the code. It’s probably the default approach for most developers who just want to bang out some code and ship it. It’s the easiest way, by far, to get code from your head onto the screen.

Solo Work Is Quick Work

Working alone on code can be very beneficial. If it’s a space where you are knowledgeable and comfortable, working alone can give you the chance to write quality code in a relatively short timespan. You might even experience flow, the mental state of focus one enters when focusing on a problem that matches their skillset. That perfect balance and satisfaction in seeing your work makes working alone an appealing option.

Exploration & Learning Alone

Everyone learns in their own way and at their own pace. Trying to do a group investigation into a new database framework doesn’t make a lot of sense because everyone will want to approach it differently. Someone might want to spend a few hours reading documentation, while another person wants to jump into a tutorial.

Solo time is perfect for these kinds of learning and investigation opportunities, making space for you to learn what needs to be learned in a way that’s best for you. Even if the whole group needs to learn, why not give yourselves a few hours to investigate separately, and then join back up to discuss together what you’ve learned? Odds are that everyone will have found something a little different while learning in their own way.

Quiet Time

Another reason that I personally like working solo is because working with other people is hard. You have to explain your thoughts and ideas, pay attention to other thoughts and ideas, potentially get into arguments about the best route forward, and after all that, continue doing everything else you would be doing on your own. That kind of attentiveness takes more energy than solo work, and sometimes you just need a break.

Finding something that you can do on your own and running with it is a great way to give yourself a break from the “always-on” mindset of working closely with others. Give yourself that quiet space to still be productive.

No One’s Perfect

There are very clear downsides to working solo all the time, and those should not be disregarded. It’s easier to miss a logical error if you’re the only one looking at your screen. You have no way of knowing any other perspectives on how a problem might be solved if you’re the only one looking into it. It’s also much easier to lose yourself in your thoughts and expectations, making you more likely to miss an oversight.

Trusting yourself to be always right — every single time — is just not realistic. It’s important to leverage the knowledge and skills of your teammates to help you write the best code that you can. If you find yourself struggling or just need another set of eyes on some code you’re not confident in (or maybe you’re too confident in), then break out of your solo box and get some help. Your codebase and your teammates will thank you for it.


Working solo can be an effective way to get work done quickly, but it certainly has its downsides. It’s important to balance it with other approaches to getting development work done. Tomorrow, we’ll look at how and when to leverage pair programming.

Three Ways to Develop

  1. Working Solo
  2. Pair Programming
  3. The Swarm