Tips for being a solo developer at a startup

I’ve been the only developer at TRIBE for a year and I’ve been CTO here now for 6 months. Previously I was on a team of around 30 developers where I spent the majority of my time happily coding away while neglecting to develop some of the other skills that I believe are necessary for building a product.

While there are pros and cons for working for both large and small development teams, I don’t think people often talk about working on a team of one. I thought it would be useful to share some of the tips I’ve worked out over the past year to help anyone else who’s working as the sole developer at a company.

Be disciplined

When I first moved to TRIBE I relished the freedom of being able to work on what I wanted. I no longer had to do standup each morning, I no longer had long sprint planning meetings and I no longer had a product manager chasing me up on each of my tickets. As long as I produced the features the rest of the team needed I could go at my own pace.

However, I found I started to become lazy. I would just work on what I immediately needed to and wouldn’t push myself as much as I should have. A member of the team would ask me to do something and I would immediately jump on it because I had no structure or roadmap for where the tech was going. I had no process.

Earlier this year we did a big piece on the roadmap for the next year and I decided to go back to having a more structure process. I decided to do two week sprints and have a formal sprint planning and a retrospective with another non-technical member of the team. I started using story points again to try and work out my velocity. So far, I’m please to say, this has been very effective. I now have more focus on what I’m working on in the next two weeks, I can plan more efficiently and I can let the team know when to expect the features they have requested.

As a additional bonus, I have found it incredibly satisfying to work in sprints. You really feel like you’re making progress and you slowly work through the daunting pile to tickets in the ‘to do’ column. At the end of each sprint I email the rest of the team to let the know what has been done and released. This helps me focus as I’m keen to make these emails as impressive as possible so I try to ensure as many tickets are finished as possible.

Keep it simple

If you’re running a site that needs to be up 100% of the time and that you need to be able to fix any problems that come up, make sure it is as simple as possible. If something goes wrong and you don’t know how to fix it you’re going to need to rely on your own ability to debug and, lets face it, stack overflow. If you’re using a established framework (I use Ruby on Rails) it’s very likely another developer has had the same problem and you will hopefully be able to find the answer relatively quickly. Otherwise, hopefully the community is active enough to answer your questions.

However, if you were to use some hot new language/framework that has only just come out, its very unlikely you’ll have the same type of support available. You’ll spend far more time banging you head against the wall trying to work out what’s happened.

When I moved to TRIBE, I inherited the codebase off an agency that had been working on it. I was lucky enough to find everything is great condition with everything unit tested and well laid out. But then I started to look at the front end of the app and realized they had used jQuery everywhere, without a hint of React. Having previously worked with React and Redux as I was pretty upset and I was planning to immediately move everything over. However, as time went by I realized why this was actually a clever move. Firstly, did we really need a framework like React/Redux at the moment? The site is a straight forward e-commerce site with nothing fancy on the frontend. Pages were fast to load and there weren’t any complicated interactions needed. Secondly, jQuery has thousands of libraries/tutorials/answers on stack overflow. This would mean I could solve any issues I needed just by googling. Sure, you’re site might be different, but for me its been great keeping my front-end stack as simple as possible.

I’m sure in the future as the site gets more complicated I’ll look into implementing React/Vue, but so far I’ve had no need for them.

Schedule time for tech debt and bugs

There is no doubt that tech debt is going to build up in your app and that there are going to be bugs, but how you deal with them is important. If you let bugs build up, you can get overwhelmed and you’ll end up losing revenue for the company in some way. And if tech debt builds up too much, you’ll get to the point where you’re spending all your time trying to catch up rather than building new features.

My strategy for tackling them is as follows: Dedicate some time a day a week to look through your bug list and tackle some of the harder ones. I spend the first hour of the day doing this as because debugging care require more brainpower and abstract thinking than working on normal features so I want a fresh mind. If a member of your company comes to you with a bug, don’t let that interrupt what you’re working on. Acknowledge the bug, write it down and how to replicate and then put it into your backlog to look at when you next have some time.

As for tech debt, make sure you dedicate time to fixing it. I schedule quarterly ‘Tech Debt Weeks’ which are weeks where I’m allowed to work on whatever I like. I build up a list of what I want to work on over the quarter and then I try and get through as many of those tickets as possible in that week. I find it incredibly useful and allows me keep the codebase fresh.

Don’t be afraid to spend time planning

At my last job I spent the majority of my day coding. That’s what I would do 9-to-5 and with the occasional planning meetings or retrospective. However, it was never me deciding to have these meetings, I was always asked to come to them.

When I started working solo I was nervous about actually setting aside time to plan out my next feature or to work on the roadmap. These are very important parts of building a website and should not be overlooked.

I know it sometime feels like you’re most productive when coding away and building the next feature. However, taking a step back and asking if that really is the best feature to be working on right now, or maybe if there are two features that would work well together that you could take into account with what you’re working on now. Without the luxury of a product manager to make these decisions for you, you need to make sure you look at the bigger picture and dedicate time to thinking through the roadmap.

Get help with code review

While I’m a one man team I get two freelancers to code review my work. While their knowledge of the codebase is never going to be as good as mine, they can always spot code smells and problems with my code that I miss. By getting them to review my code I know I can’t be lazy and I’m sure I write better code because of it.

It also gives me an outlet for talking about more technical stuff that the rest of my team don’t understand. I found a lot of my technical growth when working in a big team was from talking with others, pairing with them and talking through challenges. That’s something I miss working solo but by having two developers who I can chat about workflows/technical books to read/new techniques with I feel like I can keep up to date.

Keep up to date with the latest trends

Listen to technical podcasts. Read technical books. Learn about new techniques and concepts by yourself. Without having team mates to chat about these things with you’re going to have to put in the extra effort to learn them yourself. It can be tiring and seem like you’re not progressing the website/app you’re working on, but you never know what you might learn and when that might become useful.

Log everything

I guess this one is relevant for everyone, not just solo developers. Make sure everything that happens on the site is logged in someway or other. The most frustrating thing is the world is being asked why something has happened and having no way of finding out. Make sure you have easily accessible logs and that you’re comfortable with using them

There are many benefits of being a solo developer at a company but it does require a different mindset to working in a team or from being freelance. You need to be disciplined with yourself and push yourself to improve. When stuff goes wrong, it’s going to be you who fixes it no matter where you are and who you’re with. But the rewards of seeing a website grow, and hopefully the company with it, is huge.

I hope you find these tips useful, and please share below if you have any of your own.