Developer Tools
In this article we won’t go over any specific tools but more ideas about what to consider and what your tools should help your developer with. While this may seem broad and not as useful I have found it far more useful over time as tools are replaced and systems evolve the ideas behind why you use tools stays the same.
Let’s dive deeper into what that actually means. Why do you have tools in the first place? To remove complicated or repetitive tasks so that you can ensure they are done correctly or on a regular basis. And the end goal of this is to reduce the overhead on people who interact with your system and provide a consistent way to do the required tasks. This can range from code completion, linting, formating, code search, compilation, testing, validation, and so many more. In the end the goal of these tools is to strike a balance between an abstraction that makes these tasks easier and providing enough freedom to complete all your tasks. Everyone just wants to complete their tasks faster so they can move on to the next thing or go home to see their friends or family or just to relax. If you can find and use tools that take 4 hours of work and turn it into 30 min of work with the same end product why keep taking 4 hours?
This is mostly illustrative as their is rarely a tool that can make that large of a change on it’s own but if you evaluate your tools that way. Making sure the tool doesn’t slow you down but actually makes your job easier then as you stack those benefits you can see some significant improvements. You also need to make sure that it doesn’t require too much overhead for the benefit you are getting.
The best way to think about developer tools is that you have a some kind of golden path or happy path that is easy for developers to follow but also gives them the freedom to go off and do what they want. With the knowledge that those choices come with the cost of extra maintenance that might not be supported by other teams and experts that they currently rely on. Making these tradeoffs clear and transparent makes it easier for to decide teams when they really need to break the mold and when they can fit in the golden path. I want to make sure that distinction is clear because making it impossible to use anything else removes a lot of potential to improve but also making it a free for all creates barriers internally that might not actually need to be there.
When looking at developer tooling you should look at the time spent setting up a workspace, the time spent updating a workspace, how long build/tests take, how quickly a developer can get a full cycle from feature request to accepted for deployment done. This includes, build, test, test coverage, lint, formatting, CI runs, fuzzing, review, code completion, codemods, and anything else that could help provide feedback and improvements to your developers. Another thing to consider is the ordering of these tasks. The fastest tasks should be run first so that feedback is gain as quickly as possible. It also means that as more stages pass more confidence can be gain in the changes.
The goal with these stages is to help a developer gain insights into any problem areas or give them confidence that their changes are quality and ready for release. You should look at this work like building your ideal pair programming buddy. Try to find the feedback that people want and how to provide it quickly so that people can either improve without any blame or gain confidence in their changes.
A good example of this would be code completion and codemods. The code completion tools should help your developer be more productive and stay up to date with coding style and recommendations. The codemods can help with large scale changes, help stop regressions to old styles or to ensure updates are enforced. Allowing anyone to write and use codemods also makes it easier for one persons knowledge to be spread across the whole codebase or organization without putting a huge load on that individual.
It can be very useful to think of this stage more as a programming partner instead of a blocker to get your changes released. Think of adding tests or tools to your CI as adding feedback you would want someone to give you without any blame or communication problems. This can help improve less experienced developers faster without them being self-conscious of using more experienced peoples time. It can also remove some of the problems that come with conveying issues in a pr conversation. Additionally it can help increase velocity without larger overhead and provide everyone with peace of mind and help when they make a mistake. Everyone on your team will make mistakes from jr all the way to your most experienced people that’s normal and creating consistent fast and blameless ways to find and fix those problems is the way everyone can improve together.
