Live data from Hacker News

You should write "without bugs"

korshakov.com

41–50 of 91 posts

Re: You should write "without bugs"

#41
Writing code with fewer bugs is a function of experience. But, the reason is not entirely what you would think it is. Sure, a lot of it is anticipating problems previously experienced, and writing code that handles problems, or entire classes of problems, previously encountered.

However, with more experience comes a better understanding of the general metastructure of code, and therefore an ability to hold more code in your head at a time. (Compare for instance the well-known increased ability of chess masters to memorize chess boards, compared to non-chess players.)

When you’re an inexperienced programmer, you need to write the code down (and run it to test if it works) before you know if the code and algorithm solves the problem. This makes the inexperienced programmer take shortcuts while writing down the code, in order to get the code written down as fast as possible, while it is still clear in their mind.

The experienced programmer, on the other hand, can easily envision the entire algorithm in their head beforehand, and can therefore spare some extra attention for adding error checking and handling of outlier cases, while writing the code for the first time.

Also, as the article states, when you make a conscious habit of always writing code which checks for all errors and accounts for all outliers, it becomes easier with time; practice makes perfect, as it were. This is essentially a way to speed up the natural process described above.

Re: You should write "without bugs"

#43

This feels like fluff. You can think a few steps all you like but bugs will creep in, those you can’t think about, those in areas you don’t quite understand, those that require weird sequences of events.

The key, IMO, is having awareness about when you don’t quite understand something, because that means you can’t reason about the code to prove it correct to yourself in your head. And then, avoid shipping code in such a state at (almost) all cost. This awareness can be trained, and I suspect that the author’s virtually-bug-free shipping record is based on that. My personal experience is that bugs are nearly always caused by code where I ignored my inner uncertainty about the code.

Re: You should write "without bugs"

#44

That was a nice read, and I'll try to incorporate it in the future. Lately I've been victim of letting too much pressure from clients build and I ended up spending 5 days on a major feature (built on legacy messy code) and in the process of making it better and adding a new features I ended up breaking few things here and there, which didn't play nicely with my refactor. Which costed me another few days of work. I gu…

The cool thing is you’ve got the rest of your career to benefit from what you just learned :)

Re: You should write "without bugs"

#45
I do my best. I usually have so few bugs in my final ship products, that it's not worth it to have a tracker.

Getting there, though, I have lots of bugs. It's just that I want them gone, before I pat my app on the butt, and send it out into the field.

I often see people use Voltaire's phrase "Perfect is the enemy of the good," to justify writing bug farms. I'm not sure that this is what he meant.

Re: You should write "without bugs"

#46
post #35

In grad school I took a formal methods class where we proved properties about programs that completely changed how I think about bugs. The main things I took from the class were 1. Correctness of a program is distinct from its performance. 2. Program correctness can be proven. 3. Optimizing for performance often makes it harder to prove correctness. I do not actually use formal methods in my work as a developer, but…

Correctness of a program is usually distinct from performance.

One obvious exception is code processing secret data. There, performance variance creates observable side-effects (timing side channels) which can be used to determine the secrets' values.

Another is any sort of hard real-time system, where performance is critical to correctness. For example, a brake-by-wire system that took 10 seconds to respond to the pedal being pressed would be incorrect, because of poor performance.

Otherwise, I agree. There might be some other exceptions, but striving for correctness first is a good way to write code.

Re: You should write "without bugs"

#47
post #17

I clicked on this because of the crazy title but its actually a really inisghtful article, e.g. "Conversely, there are people with commitment issues; they want to experiment non-stop and thus have no faith in robustness." ... like there's this belief that bugs will just happen anyway so why worry about them. But the authors point is that a little bit of extra thought and work can make a lot of difference to quality.

> the authors point is that a little bit of extra thought and work can make a lot of difference to quality Care to bring home the thesis on how that’s actually really insightful?

There are two examples that come to mind:

I’ve caught multiple production bugs in code review by just carefully reasoning about the code and changing some variable names to match my mental model. I didn’t quite understand how bad it was, but I could tell it wasn’t right so I left a comment saying “this seems wrong”. What happened after? It was merged without addressing and it triggered a P1 regression in production two weeks later. Like the author said, it takes time and energy to truly understand a program and think through all the modes of execution. BUT I think it’s a worthwhile exercise. It just doesn’t really get rewarded. In my experience, this happened at least twice a year over my last 10 years of working in software.

The other example is blindly accepting AI generated code, which I think is an extension of copying template / boilerplate code. You take a working example and massage it to do what you want. It includes so many things that either aren’t needed or don’t make sense, but it works at first glance so it’s submitted and merged. For example, build configs, JSON or YAML configs, docker container build files, helm charts, terraforms, gradle builds. It takes a lot to learn these things so we often just accept it when it works. It’s exhausting to learn it all but if you do, you’ll be much better at catching weird issues with them.

I think the problem is we trick ourselves into thinking we should spend more time coding than anything else, but it’s everything else that causes us more problems and we should build the muscles to handle everything else so that we waste less time on those mistakes. We’re often already really good at shipping features but terrible at finding and handling bugs or configs or builds or infrastructure or optimizing for performance.

Re: You should write "without bugs"

#48
His strategy for Russian language was sort of how I approached math in college when it started getting difficult and more abstract - I found that when I wrote in pencil, I would frequently make mistakes because of all the erasing and scratching out and going too quickly. So I started showing up to exams with only a pen - forcing me to sit and think very carefully about whatever I was about to write, and if I couldn't manage to do that, would force me to keep an 'extra' scratch piece of paper where I could be sloppier. My grades transformed instantly.

I don't really approach code this way, but I do prefer to fully think through a problem before I begin banging it out. This has upsides and downsides. Honestly though, I am very wary of anyone in tech that says something "absolutely" has to be done a certain way. An example - I have a convention with executable convenience scripts where I will label them per environment, in the naming of the file, and separate them by directory that way. It often gets pointed or yelled at me about "DRY" being violated, and now I have to maintain 3 separate sources of these, etc., when I could simply have a parameter I pass in to do the same thing. That would make it "productionalized", why all this repeat code everywhere???

Well, yea, I could. But, knowing me and how long I've done certain things, it's stupid easy to forget in the moment when you're tired or distracted what you are doing and where and do the wrong thing in the wrong place - which can be a total disaster that far outweighs whatever I am gaining from DRY principles. I find the better engineers I work with aren't so strictly rigid with their thinking and tend to do the same types of cost/benefit/risk analysis to whatever approach they choose.

Re: You should write "without bugs"

#49
post #41

Writing code with fewer bugs is a function of experience. But, the reason is not entirely what you would think it is. Sure, a lot of it is anticipating problems previously experienced, and writing code that handles problems, or entire classes of problems, previously encountered. However, with more experience comes a better understanding of the general metastructure of code, and therefore an ability to hold more code…

Experience has taught me to test.

A lot.

I always find bugs, when I test, no matter how "perfect" I think my code should be.

Also, I find that a lot of monkey testing is important. AI could be very beneficial, here. I anticipate the development of "AI Chaos Monkeys."

https://littlegreenviper.com/various/testing-harness-vs-unit...

Re: You should write "without bugs"

#50

If you actually want to write software without bugs: Assume that your code will have bugs no matter how good you are. Correct for that by making careful architecture decisions and extensively test the product yourself. There’s no silver bullet. If you put in enough time and make some good decisions, you can earn a reputation for writing relatively few bugs.

Yup.

When I test, I always find bugs. Never fails.

Watching this posting dive down from the HN front page has been interesting (and expected).

Post reply on HN