Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Don't write bugs

teamten.com

Post reply on HN
Print view View original

11–20 of 113 posts

Re: Don't write bugs

#11

Post by code_biologist »

bombcar wrote: post #5

At 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.

Re: Don't write bugs

#12

Post by eeegnu »

When I do competitive programming, I celebrate the "one and done" moments where my first compile and test against the samples works, and then the submission too yields Answer Correct. Even for problems I'd consider hard I can semi reliably get this. But I find it much rarer for this to happen in my work, probably because I have to work with unfamiliar, often poorly (if that) documented code. But even with well written code, I don't have the same level of internal context juggling when making changes as I do with freshly written contest code, which I think is the key difference.

Re: Don't write bugs

#13

Post by Alekhine »

code_biologist wrote: post #11
bombcar wrote: post #5

At 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.

People are lazy and would rather pay out the ass for a way out of their problems than actually change. Becoming a better programmer is difficult. Spending money on CI is easy.

Re: Don't write bugs

#16

Post by ericmcer »

How often do we get to write green fields ground up code? Of course when doing that we try to architect stuff with no bugs. 80% of the job is refactoring old code, updating code that many other files depend on, updating/replacing dependencies and more. It is great advice if you just write C code in a silo, but the complexity of a modern app is beyond just re-reading stuff.

Re: Don't write bugs

#17

Post by AndrewDucker »

code_biologist wrote: post #11
bombcar wrote: post #5

At 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.

There's a big difference between "Analyse your mistakes so you're less likely to repeat them." and "Don't make mistakes."

The first sounds like sensible advice. The second sounds like a completely unrealistic thing that would only be said by someone who doesn't understand fallibility, or humans.

Re: Don't write bugs

#18

Post by lpapez »

eeegnu wrote: post #12

When I do competitive programming, I celebrate the "one and done" moments where my first compile and test against the samples works, and then the submission too yields Answer Correct. Even for problems I'd consider hard I can semi reliably get this. But I find it much rarer for this to happen in my work, probably because I have to work with unfamiliar, often poorly (if that) documented code. But even with well writte…

Same thing here. With LeetCode or AdventOfCode problems its usually simple "write test submit celebrate". With real world problems its usually like: try to reproduce a vague customer crash/fail report, have several meetings on how to handle the new unexpected scenario, rewrite a portion of the code to support this use-case, tweak everything until unit tests pass, send it to QA for detailed testing, maybe repeat...

Re: Don't write bugs

#19

Post by drewcoo »

code_biologist wrote: post #11
bombcar wrote: post #5

At 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.

"Don't write bugs" means opportunity cost and that's generally bad for business.

If bugs are business problems, figure out why and deal with the business problems. Maybe that means avoiding bugs but maybe otherwise changing the business makes more sense.

Re: Don't write bugs

#20

Post by ReganLaitila »

From what I think is the article's punch line, in context of software bugs:

"We put them there, and we can decide to not put them there"

I don't think this is strictly true. Sure from a strict computational theory or mathematical proof perspective we can 'produce no bugs' but from a meat-space reality standpoint programming ecosystems do not work this way.

The game changes when you need to ship some bits from one place to another, or demand contract on the representation of truths over time, or guarantee no interruption of service on vague notions of "indefinitely".

How perfect can any one individual execute the exacting theory of the stack: ASM(s), C-derivatives, OS Kernels, TCP/UDP, DNS, TLS, pythons/javascripts/golangs, HTTP, SQL-derivatives, libraries, frameworks, cluster orchestrators, oh my the list just keeps getting bigger each and every year...

So we write bugs, because we have to. Imperfect knowledge is part of our professional practice. Much like the sciences our bugs persist not because they were "wrong" but because we build on top of them as new facts emerge.

From the articles principle advice:

"If you want a single piece of advice to reduce your bug count, it’s this: Re-read your code frequently. After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them. That habit will save you more time than any other simple change you can make."

We do this. Programmers can tend to be narcissistic, we love reading our code we just wrote: oh the beauty, oh the wonderful shortcut, oh the performance, all while enjoying the quickly fading context in which we wrote it. If our knowledge was wrong in constructing the code, assumptions are still wrong while reviewing it. But in practice we run code reviews, automated compilation/linters/tests/etc to ensure that the quality of our code is not left to the individual programmer who is quick to forget that it was not for them in the first place. Bugs have a harder time surviving multiple perspectives (generally).

Now back to searching for this years bash incantations :)

Post reply on HN