I’ve been preaching something similar for a while - you get good (and faster) at what you practice, so if you practice writing bad code you’ll get good at writing bad code. If you practice writing good code (by whatever your standard of good is), you’ll get good at that and it will come out faster and more naturally.
You should write "without bugs"
71–80 of 91 posts
Re: You should write "without bugs"
#72Earlier quoted context omitted.
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...
> 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." Well, you just made me realise that there is still a use for those LLMs beside generating propaganda. The problem, i guess will be, that nobody will be willing to spend time on those bug reports.
> nobody will be willing to spend time on those bug reports.
That's basically a question of culture.
Bad culture will result in bad results, no matter what tools and techniques we use.
Re: You should write "without bugs"
#73having to work with financial system or payment system really teaches me a lot of correctness
I mean when we talk about money and company can potentially bankrupt within few minutes because how easy today to move money, things can get south pretty quick
Re: You should write "without bugs"
#74Earlier quoted context omitted.
I think there's always argument that you don't know what you don't know. How much thought do you put on writing code with out bugs. Bug could be caused by the business logic, the language internals, the runtime environment internal and variation. I think what people often ignore writing piece of software is an iterative process, you build, deploy and learn from the operation and you fix and repeat. If you keep thinki…
> writing piece of software is an iterative process Often, yes. Absolutely. > you build, deploy and learn from the operation and you fix and repeat. But no, not at all in this way. This is generally not necessary and definitely not a mindset to internalize. Commercial software products are often iterative, especially for consumer or enterprise, because they need to guess about the market that will keep them profitabl…
> As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities.
I think the problem with the purists is that this is just a moral claim - it's not based on how businesses + marketplaces actually work. The lower you attempt to crank the defect rate (emphasis on the word "attempt"), the slower you will iterate. If you iterate too slow, you will be out-competed. End of discussion. This is as true in open-source as it is in enterprise SaaS. And in any case, you're just begging the question: how do we determine the "absolutely minimal" rate in advance?
> you can strive to write adaptable code that can accomodate those iterations.
This is a damaging myth that has wasted countless hours that could have otherwise been spent on fixing real, CURRENT problems - there is no such thing as writing "adaptable" code that can magically support future requirements BEFORE those requirements are known. If you were that good at predicting the future you would be a trader, not an engineer.
Re: You should write "without bugs"
#75Earlier quoted context omitted.
> It is not practical to prove correctness for the vast majority of programs, That is the excuse i hear a lot from software developers, when everything they do is to test the expected behaviour of a program, without any edge case. And this is also the reason why iMessage and WhatsUp are full of one click exploits.
The comment you were replying to is about formal proofs of correctness, probably using tools like Rocq (formerly Coq) and TLA+. These tools can take an extreme amount of time to use and require specialised skillsets that are difficult to hire for. They go far beyond standard software engineering practices like unit and E2E testing. It is genuinely, seriously not practical to verify the average startup's SaaS web app…
It is possible that the person you replied to wasn't confused by that. I've certainly come across the type of developer who'd deride the lack of ability to formally test their code then, in the next breath, click through the happy path of their code and send it.
Re: You should write "without bugs"
#76Re: You should write "without bugs"
#77I don't think anyone says you should just casually ship bugs. Quite the contrary, most are ok with the idea that, if you see a bug, fix the bug. But, there can be no doubt that there is diminishing returns on chasing down every potential bug. This reads to me like the idea that a rich person walking down the road wouldn't pick up a $20 they happen to see at their feet. Of course they will. Why not? What they don't do…
> I don't think anyone says you should just casually ship bugs.
I'm not going to link to it, but there's an old post from someone here, that pretty much sums up the zeitgeist.
They say that if the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much.
That is, quite literally, making the conscious decision to "casually ship bugs."
Re: You should write "without bugs"
#78I will remember this advice the next time I decide to write a bug.
Yes, don't write bugs and your code will be bug free.
Re: You should write "without bugs"
#79I don't think anyone says you should just casually ship bugs. Quite the contrary, most are ok with the idea that, if you see a bug, fix the bug. But, there can be no doubt that there is diminishing returns on chasing down every potential bug. This reads to me like the idea that a rich person walking down the road wouldn't pick up a $20 they happen to see at their feet. Of course they will. Why not? What they don't do…
> I don't think anyone says you should just casually ship bugs. I'm not going to link to it, but there's an old post from someone here, that pretty much sums up the zeitgeist. They say that if the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much. That is, quite literally, making the conscious decision to "casually ship bugs."
I mean, is that a general feel across industry, or something a rando online offered up as a witty quip? I have never worked anywhere where people were casual about shipping bugs. Some of the healthier places I've been have focused on not getting worked up when you do. Don't take pride in it, but don't sweat the small mistakes. You will make them, whether you want to or not.
Re: You should write "without bugs"
#80Earlier quoted context omitted.
> I don't think anyone says you should just casually ship bugs. I'm not going to link to it, but there's an old post from someone here, that pretty much sums up the zeitgeist. They say that if the code quality on your MVP doesn't physically disgust you, you're probably focusing on code quality too much. That is, quite literally, making the conscious decision to "casually ship bugs."
I mean, is that a general feel across industry, or something a rando online offered up as a witty quip? I have never worked anywhere where people were casual about shipping bugs. Some of the healthier places I've been have focused on not getting worked up when you do. Don't take pride in it, but don't sweat the small mistakes. You will make them, whether you want to or not.
I wouldn’t know, but it was certainly presented as a “general feel,” and, anecdotally, almost every interaction that I’ve personally had with “modern” tech companies (in fact, with one, it resulted in a multimillion-dollar disaster), have shown me that “feel.”
The disaster I mentioned was particularly heartbreaking, because the tech was solid, and the people behind it, were good, but they absolutely refused to give respect to Quality, and everything went to shit.
Just look at the way any discussion of Quality Development gets treated on HN. This very post nosedived, ten minutes after it posted. The only reason that it’s still around, is because it must have been “second-chanced.”