How do I keep my employment perpetual if I don't build bugs?
Don't write bugs
31–40 of 113 posts
Re: Don't write bugs
#32I wish the author had expanded more. It would have been great to hear about the most frequent types of bugs they logged and other mitigation strategies.
Follow the C link: https://www.teamten.com/lawrence/style/
I also failed to find more details about the actual bugs, unless that is implicit in the style advice. Too bad, since actual detailed descriptions of bugs with reasoning about why they occured is usually quite interesting (and I'm always amazed by people who manage to keep notes about such).
The author says in the article that the style site is "unpublished", since the advice is too low-level and outdated. I actually think much of the very basic C advice is still sound and would agree with most of it, but it was kind of jarring when it jumped into "cute tricks", including Duff's device.
I have programmed in C for 25+ years, and have never used Duff's device in anger. While I could have used this guide in 1994 for the basic hints about good C, today I would be very sceptical reviewing code using Duff's device. :)
Re: Don't write bugs
#33We should offload this responsibility to our tools as much as we possibly can.
https://blog.codinghorror.com/falling-into-the-pit-of-succes...
Re: Don't write bugs
#34This doesn't seem to take into account different codebases. At work I may have a decade old piece of code that has been partially rewritten multiple times and gets constant updates - it's also communicating with the outside world in many ways. The skill required to manage code like this without any bugs or even compiler errors is immense. But writing a 1000 line brand new project from scratch in a sane language is pr…
Compile time errors are cheap and it would be silly to optimize for that. IDE just tells you: hey, this line, you forgot something. It is a few seconds to fix. It doesn't and CAN'T go to production. It doesn't need debugging. And, if 1 data point can tell something, it comes naturally - the more I code, the less (if any) compile time errors I get. But if I do, it takes seconds to fix them. Of course IDE and intellise…
The linked article literally says “write code that compiles successfully from the first time without bugs”.
Re: Don't write bugs
#35When writing code you have a mental model of the machine, and the language and libraries. Back in the day those mental models could be close enough to reality that writing bug free code could be a choice. It would take time but you can essentially run the program in your head.
This is an old timer, back when machines and abstractions were simpler.
The post makes sense in that context, but today you can't have a complete mental model of the thing you're coding. It's impossible. So bugs.
Maybe we need to simplify.
Re: Don't write bugs
#36When writing code you have a mental model of the machine, and the language and libraries. Back in the day those mental models could be close enough to reality that writing bug free code could be a choice. It would take time but you can essentially run the program in your head. This is an old timer, back when machines and abstractions were simpler. The post makes sense in that context, but today you can't have a compl…
But we HAVE simplified. I can now type 'fetch this data matching these conditions sorted by this' and be confident about not having any bugs in my code, while underneath there's millions of lines and decades of other people's work and solved bugs being run.
"Back in the day" they would spend weeks devising that system from scratch, hand-writing sorting algorithms, etc.
The mental model of software development is about the problem and domain nowadays, not the low level implementation details. Your job is to solve a business problem, instead of figuring out how to manipulate a CPU and its memory banks to do your bidding.
Re: Don't write bugs
#37Use tools that make it harder. Immutable datastructures, side effects constrained to a few places, good static typing etc. Where I worked before we had 100k LoC Elm projects with virtually no bugs. Now I'm working in a python/django codebase with probably thousands of small hidden bugs.
I think that's what the book and guidelines mentioned in the article are about. Best practices and design patterns for software development. For C, I can imagine the author promoting the use of Yoda conditions to prevent one category of bugs.
Overall, strictness and "anal" rules is how you can reduce the amount of common bugs - as long as they don't require too much active thought. Then you can focus on the domain, on the actual problem, and bugs on that level will be from your own limited understanding of said domain and logic, not the programming language, memory management, memory leaks, nil dereferences, etc. Those categories of bugs are solved problems, with either best practices, tooling / linters, analyzers, or newer and better programming languages.
Re: Don't write bugs
#38At first glance this may sound like advice for a baseball player - “don’t strike out” - but that’s exactly what good players do - they work at identifying the things that get them to strike out and try to minimize them. Tony Gwynn spent hours reviewing tapes of his at bats. Keeping a log of your mistakes and analyzing them is helpful in any number of things, including coding. Can you not write any bugs? Probably not.…
It really annoys me that whenever I argue for "don't write bugs" as a quality practice, people immediately respond with all sorts of justifications why that's not possible. Of course it's not. But that doesn't mean we can't improve. We spend time and money on CI, linting systems, sprint retros — so the allergy to "think more carefully about what you wrote" surprises me.
Maybe a slight rephrasing, "don't write stupid bugs"; there's a lot of small mistakes that people can make that can be solved by enforcing stricter rules, e.g. forcing the use of `===` in languages like Javascript and PHP to enforce the developer to think better about data types used.
Using linters, formatters, and IDE tools have taught me a lot of easily overlooked issues in those languages.
Re: Don't write bugs
#39Earlier quoted context omitted.
Compile time errors are cheap and it would be silly to optimize for that. IDE just tells you: hey, this line, you forgot something. It is a few seconds to fix. It doesn't and CAN'T go to production. It doesn't need debugging. And, if 1 data point can tell something, it comes naturally - the more I code, the less (if any) compile time errors I get. But if I do, it takes seconds to fix them. Of course IDE and intellise…
The linked article literally says “write code that compiles successfully from the first time without bugs”.
I do have some issue with that one, because it kinda implies that compiling is a big, expensive and final job. But with current-day languages and tooling, you can effectively run trial compiles constantly while writing the code. The sooner you spot an issue, the sooner it's fixed and the less painful it is.
I take the performance hit and prefer my editor to have syntax highlighting, syntax checking, linters and (at least at some point in my career) relevant unit tests automatically running in the background on save.
Re: Don't write bugs
#40You have control over the code you write yourself, but you rarely have control over what code others write - even if your code review process is incredibly rigorous, there's rarely resources to check every single line of code that people write. And his becomes more infeasible, as size and complexity grows. Furthermore, rarely can commercial products afford the luxury of such exhaustive protocols. Even slow moving, st…
There's a big category of issues and bugs that can be prevented by tooling and choice of language though, so make sure that those are in place at the start of a project. Shortlist: Typed language, linters, formatters, and set up your CI so that 'fast forward' on your main branch is off and anything is only merged after a rebase on top of main, a code review, and a green CI pipeline.
In theory, the only bugs that make it in production then are logic or requirements bugs. Having an extra step somewhere of a manual test might help mitigate those.