💾 Archived View for soviet.circumlunar.space › sweater › hindsight › 2021-05-04-do-tools-matter.gmi captured on 2023-03-20 at 18:26:54. Gemini links have been rewritten to link to archived content

View Raw

More Information

⬅️ Previous capture (2022-07-16)

-=-=-=-=-=-=-

<- Hindsight >>= Foresight

Next: We don't need programmable money

Previous: How big is small enough

4 May 2021

Do development tools matter?

When do I think it is okay to force a choice in editors or operating systems.

In Doma, we have started using flakes for development shell set up, because at some point we started requiring fetching reproducible toolchain versions that aren't yet packaged in Ubuntu LTS.

An example of a reproducible dev env seen in the best create-react-app template ever made.

Mission-ciritcal stuff

ITSEC and OPSEC are very important considerations, so the primaryreason to force certain OS / Editor and even a device is if what's being developed is high assurance. Nobody would like for developers to develop mission critical codebase using malware/spyware or a cracked version of Sublime.

When the company is not in software business

In the discussion that made me write this post, there was a mention of Garmin SDK being only compatible with Eclipse. I agree that it's not ideal that some companies are not inclusive in terms of OS/IDE/Editors they support officially. However, it's important to understand that if these companies aren't software companies (and Garmin is certainly strictly a hardware company), it's unfair to hold them to the standards of toolchain inclusiveness of software companies with a similar budget. We should be content with the fact that there is *an* SDK.

Editors

As far as editors are concerned, the biggest consideration is making sure that formatting is consistent across the contributors. If the community is small enough, it's possible to save a lot of time on consistency by forcing a particular language server and a particular formatter config. This is virtually free, as long as the community members agree on the fact that tools don't matter as much as results and efficiency. However, as the companies grow, the overhead on managing the changes becomes lower than the cost of forcing uniformity in editors. For instance, recently in Serokell (which is a medium-sized company), me and a colleague couldn't agree on the format of a patch. So I just sent a patch the way I wanted and the person in charge of upstreaming it converted it to what is established in their practices.

It took us negligible (but non-zero) amount of time: something like fifteen minutes.

Operating systems

As far as operating systems are concerned, I have even more positive experience with forcing Ubuntu LTS everywhere, including deployments. Companies that develop product, not sell a service arguably _should_ force OS as a way to guarantee that development environment works reproducibly 100% of times and is possible for a new person to set up in under an hour, you're doing really well. It is even more true when said company operates on a smaller budget or has mission-critical infrastructure. This is something my friends from one of German HFT software development companies explained when they were criticising the fact that in Serokell we're using Nix and NixOS! They were largely right: Serokell's recent move to Nix flakes was expensive! Our maintenance of haskell.nix and our pins for nixpkgs is expensive and unavoidable. Of course, we are OK with suffering the costs since we're approaching 100 employees and we actually need pluralism, thus we need Nix. For Doma, however, which is my and my life partner's side-business, we were achieving great results at the start with forcing Ubuntu LTS everywhere on a 10$/mo budget. As we grew, however, we have started using Nix tentatively, just for development environments.

We first install single-user Nix like this

We use home-manager and install it with this script

It also enables direnv

We use cab404's direnv extension for VSCode

But we should use the official one, I guess

Conclusion

A while ago, I figured that tool selection matter way less than people think, the cult of keyboard is overrated (you should think more than you type), and that a good professional will be good even whilst developing in Go or PHP. While I agree with the idea that anyone should be free to use whatever tool they want, I would consider being able to force a toolset and a toolchain as a luxury that should be used smartly, to everyone's benefit, and for the right reasons. If used well, it can turn into a huge competetive advantage and eliminate a ton of costs.