Profile picture
Hillel @Hillelogram
, 15 tweets, 3 min read Read on Twitter
One of the problems of the whole "static vs dynamic typing" correctness debate is that switching your language is incredibly expensive for a marginal benefit. Most of the biggest wins in correctness come from process. Here's some _empirically_ great ways to make your code safer!
Code review: study after study shows that code review will save your butt. You only need one reviewer to find a ton of issues and potential errors. This works for any project in any language!
Self review: before you submit code for code review, take a ten minute break then print out the code and review it yourself. This can find up to half the errors that others would find, and it's super efficient to boot!
Checklists: you're gonna wanna tailor this to your project, but having a set of things to check before merging or deploying is incredibly helpful to avoid oversights. "Did I load test this code?" "Are there enough comments?" "Did I add any NOMERGE?" Once again, language-agnostic.
Linting: the kinds of linting you can do is language dependent, but still a low-effort win. At the very least, it saves time on style arguments in code review. gofmt is a really great example of this, but almost all languages have something similar.
Documentation: write architectural overviews, design docs, call flows, whatever. We know that good docs make software much more understandable, which means less chance of an error. We just don't write docs because we're lazy. Let's write more docs!
Comments: yes, you should write descriptive comments. Same benefits as docs, but at a lower level. "But my code is self-documenting!" No it isn't. "But comments can be wrong!" So can the code. "But nobody updates comments!" Make that part of the checklist then. Comments are good!
Planning ahead: boy oh boy this is such a game changer. I don't even mean formal specifications or feature engineering: literally taking an hour to sketch out your plan on paper is enough to save you a ton of pain. You'll have a better, less error-prone design.
Code metrics: I don't mean "lines of code" or "test coverage" here. I mean things like "the most referenced files" or "the places in the codebase with the most churn." With trends in metrics you can predict where bugs are _likely_ to be, even if nothing looks wrong yet.
Bug tracking: what if bugs follow the Shewhart rules? If we get their rate to statistical control, we can find systemic causes in our code and process that contribute to the bug flow. This is probably the most controversial idea on here, but I have faith in the Word of Deming.
Sleep: if people are sleep deprived, they make more mistakes. Fixing that will boost the projects software quality more than any other thing you do. Same goes for nutrition and exercise.
Overwork: we've known for decades that long hours and death marches are less efficient in the long run than keeping a steady, reasonable pace. And the long run here is "a few weeks". Plus it's a morale killer, which has its own costs. Burnout will fucking wreck your quality.
Investing in training: more experienced engineers make fewer mistakes and have higher quality output. But isolated conferences and talks will barely change anything: you have to give people dedicated time for deliberate practice.
Private offices: please
All of the above, with one or two exceptions, have been empirically, rigorously shown to significantly improve your software quality and correctness. Once you've implemented all of those, then and only then is it finally time to consider things like "programming language".
Missing some Tweet in this thread?
You can try to force a refresh.

Like this thread? Get email updates or save it to PDF!

Subscribe to Hillel
Profile picture

Get real-time email alerts when new unrolls are available from this author!

This content may be removed anytime!

Twitter may remove this content at anytime, convert it as a PDF, save and print for later use!

Try unrolling a thread yourself!

how to unroll video

1) Follow Thread Reader App on Twitter so you can easily mention us!

2) Go to a Twitter thread (series of Tweets by the same owner) and mention us with a keyword "unroll" @threadreaderapp unroll

You can practice here first or read more on our help page!

Did Thread Reader help you today?

Support us! We are indie developers!

This site is made by just three indie developers on a laptop doing marketing, support and development! Read more about the story.

Become a Premium Member and get exclusive features!

Premium member ($3.00/month or $30.00/year)

Too expensive? Make a small donation by buying us coffee ($5) or help with server cost ($10)

Donate via Paypal Become our Patreon

Thank you for your support!