[codeulike]

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.

[wswope]

> 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?

[markerz]

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.

[atomicnumber3]

"It just doesn’t really get rewarded."

This is the entirety of the problem. Also why open source programs are so often "surprisingly" high quality.

Bad reward functions in companies don't just not reward people who do good work. It *actively punishes* them because stack ranking is a zero-sum game. And as much as people joke about stack ranking and lambast the dinosaurs who used to do it on purpose, it's still how it all actually work. It's just distributed stack ranking - each manager and manager of managers has their own local stack rank that bubbles up to who gets fired and who gets promoted.

So people who throw shit at the wall and make product that sell but have a shitty user experience get promoted and people who plod along and make things that work, or fix things that are broken (but not so much that they don't sell) filter to the bottom of the list and get cut, or leave when they don't get promoted or get raises.

Sure, there's some golden mix in between throwing shit at the wall and fixing key UX-ruining bugs. But these people still get outcompeted by people who purely ship n scoot.

[warkdarrior]

The author makes the insightful observation that they write non-buggy code by being careful, in contrast to the vast majority of developers who write code full of bugs. Being careful is left to the reader, but it should be easy. /s

[ozim]

Author makes insightful observation that once you start paying attention deliberately - after some time you won’t have to be deliberately careful because you will be careful by default.

There are devs who don’t pay attention and devs who pay too much attention to context of the change they are implementing. I think author also outlined which things one might pay attention to so they would be considered careful.

[debarshri]

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 thinking of all possible issues that can happen that becomes a blackhole and you dont deliver anything.

[swatcoder]

> 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 profitable and sustainable. And this speculative character has a way of bleeding down through the whole stack, but not for the sake that "bugs happen!" -- just for the sake that requirements will likely change.

As an engineer, you should always be writing code with a absolutely minimal defect rate and well-understood capabilities. From there, if you're working an a product subject to iteration (most now, but not all), you can strive to write adaptable code that can accomodate those iterations.

[swee69]

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

[debarshri]

I mostly agree with you.

In first few iterations of writing the code, you often don't have complete picture of capabilities, capabilities change on the fly dictated by change in requirement. There is no baseline of what minimal defect rate it. Over period of time and iterations you build that understanding and improve the code and process.

I'm not saying that you don't think before you write code but often over thinking leads of unnecessary over engineering and unwanted complexity

[hulitu]

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

I presume you didn't use any Microsoft operating system (or program). /s