Thoughts on building developer tools

I've been building tools for developers for quite some time. It's both my day job and at night job when I'm tinkering around with different configs, tools, etc... I'm like one of those people that like to optimise my setup by 20ms.

I seem to have a knack for it, as when I used to work with more business oriented stuff, I used to try to optimise our development workflow. So naturally, I moved to doing dev tools full time within my org. I should also say that building another CRUD application will kill me internally.

Anyhow, over those years I have noticed a lot of peculiar stuff related to creating good developer tools. In this letter, I want to share with you all I've learned and thought about deeply.

I've separated the list in to three different sections:

• Pre-development – things you do before starting development such as planning, finding idea, problem solving, and talking to people.
• Development – developing the proof of concept and pre-production version of your tool. This also includes getting feedback from alpha users and iterating before releasing it to production.
• Post production – once the tool is open to everyone. This phase includes maintenance, support, getting feedback, and possibly going back to the pre-development phase for upgrades.

Pre-development

This phase includes stuff like finding pain points, getting to know the problem and if it's worth solving, talking to potential users and possibly getting approval.

Below are some tips, I found useful in pre-development.

Finding pain points

Before I moved to Sweden, I used to work in a very factory like setting. We have a project the project manager and engineering lead break down the project into tasks and put them on the board. We do the tasks ticket by ticket.

When I first started doing developer experience work or moved to Sweden, I had to find the tasks and problems myself. I had to be proactive to be invited to the high impact tasks.

But how do you find those? Talk to people, really that's it. Just talk to people, talk to people in a higher position than you and ask what they think the problems are and investigate those.

80% of the stuff aren't worth your time but the 20% is. Another tip is to find something that genuinely excites you and is out of your comfort zone, might not be very impactful but hey, you learned something new.

You should also categorise what kind of problems you got. From my experience it usually boils down to its either a technical or an organisational challenge. Sometimes it's a hybrid of both too. This way you can figure out why hasn't the problem been solved before.

Have ambition

Sometimes the problems seem to hard. Maybe there are a plethora of technical and organisational reasons for so. I urge you to not throw away those problems and try to solve them.

These are the kinds of problems that will make your brain truly work and where your creativity can shine. It's what makes you grow as a developer and at the end of the day is more fun.

Pre-development checklist

Before building a tool, you have to answer the following questions:

• Who are the users of my tool? (e.g., developers, engineering managers, product managers)
• What kind of client does my tool have? (e.g., web app, CLI, API, SDK, language specific library)
• What pain point am I solving?
• What kind of problem do I have? (e.g., technical, organisational)
• How many people experience this problem?
• How often do they experience this problem?
• Do I have the right solution to this problem?
• Are there any other similar solutions?
• Do I have everything I need for my solution to work? (backing from stakeholders, resources such as time or energy)
• Will people use my solution?
• Can I quantify the improvements my solution will bring?

Knowing the answers to this question will help you figure out whether the idea you have is worth solving and if so, who are your customers and how to best serve them.

Development

This is the phase where you start to write code or vibe code (if you're fancy).

Create a proof of concept (POC) first and fast

Creating a POC shouldn't take you more than 2 weeks, if so then your doing too much. Your tool shouldn't fix all the problems in the world but one specific annoying one.

So focus on that one feature and get it done quick so you can demo it to potential users and see how they feel about it. Make sure it works too, I've seen too many times a demo where it works with their demo application.

This way you will confirm if your idea is worth pursuing further and you could get the support of stakeholders if you have an actual POC to back you up.

DX is king

DX stands for developer experience which is the overall experience of a developer using your tool. This is one of the most important metrics you should have.

But how does one measure DX you say? You ask other people to try out your tool or you could use it yourself.

You could do both but beware that as a creator of the tool, you're already have a bias. You know how the tool works and its limitations. So it's best to ask a potential user of your tool to try it out and see how what they think and pay attention to WHAT they ask and HOW they use the tool intuitively.

Use the tool yourself

This is kinda of a rule that I have for myself and my team that we must use the tools we create ourselves. At the end of the day, we build tools for developers and we are developers so we should also be able to use our own tools.

This gives us two main benefits:

• We can see how useful our tools are in solving our own problems and receive first hand feedback.
• We become more productive because of the tool and hence we can take on bigger problems.

The details matter

Developers are the type of people who would notice every small pet peeve so it's very important to create quality product. I'm not saying to ship slowly but ship with quality at least.

This is important because first impressions lasts with developers. For some reason if they see any shortcomings, they will have some negative bias that will be quite difficult to get past.

One example of details is to make sure your error and loading states are properly handled, you don't want to show a user your error stack. Just small quality of life features that are simple to implement will go far in building good will between you and your users.

Take documentation seriously

I know its easy to offload documentation work to AI or right to the end of the project but please don't skimp out on this part.

The documentation is the place where your users will learn how to use your tool. So make sure it's damn good. I like to take inspiration from popular open source projects such as Kuberentes and try to see how they have made their own docs.

It isn't only about the content but how the content is structured. You don't want to overwhelm the user at the same time. So make sure you have a bare bones quick start guide and once the user has something working he can read more advanced sections.

Post Production

Congratulations, your service is in production or in an alpha or beta state. What do we do from here? Well, here are several tips.

On changing cultures

If your tool requires some migration process or somewhat 10+ minutes onboarding setup then adoption will naturally be slow. I would first like to say to not worry. This is a lifelong DevOps problem that will exist in some form in all organisations.

People naturally tend to not embrace change and once they get in the habit of doing something in X way it won't be trivial to change them to use Y. That's why you have to play the slow game and find those early adopters that are willing to change and make sure they have the best experience as possible.

This will obviously take time and your users might have other priorities in the mean time. Maybe they are working on an important feature and can't afford resources for migration. This is totally normal and migrations come in packs, summar is usually a good time where teams have the resources for such stuff.

Take support seriously

This is one of the most important things I've learned while building dev tools. Make sure your support is on the A game. Have a dedicated person every week scour whatever slack channels you have and answer those questions fast.

This way you build 1000x good will with your users. This will increase your teams credibility and users will trust you more in the future. If you want very concrete advice, then I'd suggest:

• If possible always link to some documentation already written.
• If you see any common questions, add them to the docs.
• Don't overwhelm the user with so much information.
• Be empathetic and truly listen to them.
• Debug the issue yourself when you have to.

How to handle feature requests

As your tool gets traction, you'll naturally receive lots of feature requests.

You have to understand that you can't help everyone. Software engineering is a complex endeavour and there are too many variables. It's better to help 80% of the users then help 1-2%.

So here are some good questions to ask whether a feature is worth doing:

• Is this feature useful to more than 80% of the userbase?
• Does it align with the vision of the product?
• Do we have the resources and expertise to do it?

If you answer yes to all three questions then you got yourself a task. If not, then kindly and empathetically explain to your feature requester why this isn't possible and suggest alternatives.

I would like to talk about cases where you have a feature that:

• Aligned with your product vision.
• Useful to 80% of the users.

But you don't have the resources or expertise to do it. In those cases, you could collaborate with people who are very passionate about that specific thing to build the feature that you wish.

But make sure to keep in mind the ownership model, because at the end of the day if something goes wrong, it's you who is responsible.

Other tips that I couldn't fit in the three phases

Experiment

I like to give myself some time for different sorts of experiments. I don't like to make it an official task and do it during work hours, it's about experimenting with different ideas and seeing what sticks.

Personally, I find it so much fun and it brings me joy. Another added benefit is that I get to learn lots of different things. Make sure to talk to your manager about the before hand and also try not to get burnt out.

Software engineering is complex

I used to complain a lot about things that I don't know much about. I used to look at a teams setup and architecture and think, "this is stupid, they should've done it this way" or "why would they do that?"

Looking back at it, I cringe. I sounded so childish. I've learned over the years that creating software is not easy. There are lots of moving parts and requirements that only applied to a certain time.

I didn't know what constraints they had, maybe they were short staffed or had some business requirements. I don't know and neither do you.

So the lesson is, stop complaining and work within your constraints.

Make friends

The beautiful thing about my job is that I get to talk to all sorts of developer across the org and if your doing open source work then across the internet. You get to meet cool people doing cool stuff and lots of interesting things can flourish from that point onwards.

These people can help you in future projects or even future career opportunities and in general is fun.

I wouldn't have gotten into this subfield if I didn't create a tool that people liked and then I met a staff engineer that really propelled such projects and recommended me first to it.

Have fun

The final point I want to make it to simply have fun. See problems, solve problems, see bigger problems and solve bigger problems. If at any point, you stop enjoying the work your doing, I'd suggest to find another problem to solve that your passionate about.

Because in my humble opinion nothing can beat passion. We can't burn out, it's not work, it's fun.

Thanks for reading.