Don't complain about pager alerts. Change something.

The cliche goes that artists must suffer for their art. But as a developer, should you also expect to suffer?

Y’know, there’s something to be said about the motivating experience of getting woken up by a page in the early hours. You’ll never let that happen again. But unless you’re building specifically to minimise your exposure then all you can apply are sticking plasters.

So, what does a framework for avoiding those dreaded 2AM page alerts look like?

There’s a lot of advice out there and the best of it falls into three groups:

• Be intentional
• Be honest about risk
• Buy, don’t build.

Even then, most of that comes down to one key take away: the resilience of your platform in getting value to users is the only thing that matters.

There are no prizes for writing your own framework in an exotic language or tuning every last aspect of your server OS. Shipped code is everything.
Let’s unpack each one.

Be intentional

Starting a new project is like opening a toy box. There’s a world of possibilities. New technologies jostle for attention alongside old favorites. You get to learn by doing.

Always wanted to try a NoSQL database? Great! Now, you can. Bored of React? Try VueJS, instead!

But before you do, ask yourself a question: are you building a potential business or are you playing? Either answer is fine but the outcome is different.

If learning something new is really what you want to do then create a hobby project. Playing with novel tech is great. But love it for what it is. It’s a chance to learn, not a business in the making.

If delivering value to users is your main goal, then you need to be sure of how that impacts your technology choices. If you were an architect building an extension to your own house, you might experiment with unusual materials and techniques. If you’re building a new apartment block for clients, then you’d stick with tried and true methods that meet the brief, the budget, and the deadline.

So, when you come to open that toy box, be intentional in making choices that simplify delivering value to your users.

Be honest about risk

Whether you're bootstrapped or funded, building a business is risky enough. Choosing a battle-tested tech stack is just one part of reducing risk.

When we’re excited about a project, especially one that we’re building into a business, it’s easy to misjudge risk. To some extent, that’s healthy. Focus only on what could go wrong and you’d never open your laptop.

I may be misremembering it, but there’s a saying that goes something like, “forewarned is good for your forearms”. Either way, knowing up front what might go wrong gives you a fighting chance when it does go wrong.

Mapping out your risks doesn’t have to take long. Get a whiteboard, take each major part of your stack in turn, and write out anything that’s a realistic risk. Even thinking about the obvious stuff will help you come up with solutions.

Buy, don’t build

The last part is the easiest because it requires you to do less. Think back to why you’re doing this. There’s some unique value that you can bring to the world. Your one job is to deliver that value as efficiently as possible.

If building your dream means working evenings and weekends, why would you want to spend them reinventing the wheel? And this isn’t just the obvious stuff. You probably haven’t considered writing your own frontend framework and no one is writing server side code in Assembly language. But building your own server infrastructure and spending a chunk of your time on devops has become normalised in our culture.

Outsource. Buy, don’t build. Find the fastest route from successful pull request to seeing that code in production. Deploy your product on a platform like Heroku, Google Cloud Run, or AWS Elastic Beanstalk. The point is to find the right tool for the job and then pay someone else to look after it, rather than deploy your code to a stock VM image that you need to manage into the wee hours.

As the solo dev on a project, it’s your responsibility to stand on the shoulders of all those developers who went before you. Take advantage of other people’s expertise. If, later on, you need to swap a component out for something you’ve written yourself then take that decision when the need arises. It’s better to launch with off-the-shelf components that work rather than get stuck never finishing a home-grown solution.

Sleep well, most of the time

Bugs happen. Third-party systems go down. Corner cases become startlingly apparent at the moment you realise you hadn’t considered them.

None of the advice here is to say that you can avoid the unknown. Instead, it’s about reducing your exposure to risk. Choosing Rails, Spring, or Django gives you the backing of a worldwide cohort of developers who have solved the same problems you’re working on. Mapping your risks gives you time to address them before they become a problem. Buying-in tooling and platforms means you can trust specialists to look after the commodity parts you need but that don’t make a material difference to your end users.

There’s a shared duty in a small development team. So, there will be times when you get paged out of hours. However, the tech stack you choose has a significant impact on the reliability of your product. Boring tech makes the world go round. Learn the weird stuff through side projects. Choose proven tech for work and you’re more likely to get a better night’s sleep.

• Pink clock photo Mpho Mojapelo
• Toys photo Vanessa Bucceri
• Whiteboarding photo This is Engineering RAEng