411–420 of 512 posts
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Earlier quoted context omitted.
It's called "systems analysis". Programmers are generally pretty terrible at it because it requires holistic, big-picture thinking. But it used to take up the bulk of the design activity for a new enterprise system.
And the result was usually a complex system that no one needed and could maintain. Successful refinement is needed when you try to accomplish something from the ground up, refining it as you're adding features. Not locking yourself in the ivory tower drawing UML diagrams and drafting requirements. Doing and thinking go in pair, not separately.
At this point I can't help but conclude that to a certain class of writers, "economic incentives" are a form of benevolent god who will surely, inevitably make things better in directions they care about, and those who believe this also believe the overwhelming and constant evidence to the contrary of their position is just a temporary anomaly Whatever the hell economics was supposed to do, right now it seems to be c…
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Are you seriously claiming that technical debt doesn't exist?
Meanwhile, the complexity of the average piece of software is drastically increasing. ... The stats suggest that devs are shipping more code with coding agents. The consequences may already be visible: analysis of vendor status pages [3] shows outages have steadily increased since 2022, suggesting software is becoming more brittle. We've already seen a large-scale AWS outage because of this. It could get much worse.…
I'm not saying it's wrong, because I haven't actually looked for alternative sources, just that the source isn't great.
I don't fully agree this optimistic view. Unfortunately, for now, coding agents produce code that, if not further optimized upon "human" request, often generates more complexity than necessary.
It's true that this requires more computational effort for the agents themselves to debug or modify it, but it's also true that the computational cost is negligible compared to the benefit of having features working quickly.
In other words: agents quickly generate hyper-complex and unoptimized code. And the speed of delivery provides more immediate benefits than the costs resulting from bad code.
On the other hand, it's also true that the "careful eye" of an experienced developer can optimize and improve the output in a few simple iterations.
So overall (and unfortunately) the "bad code", if it immediately works, can wins against (or with) a good code.
I find most developers fall into one of two camps: 1. You treat your code as a means to an end to make a product for a user. 2. You treat the code itself as your craft, with the product being a vector for your craft. The people who typically have the most negative things to say about AI fall into camp #2 where AI is automating a large part of what they considered their art while enabling people in group #1 to iterate…
Just because one falls in the "Cha bu duo" camp and (potentially) looks down on the "Kaizen" types doesn't mean the two products are equivalent.
That also doesn't mean that slop / cha bu duo / made in china products are bad, mind you. They have their place, and occasionally a Kaizen approach would be detrimental to getting "something" done quick and dirty that will likely work ok anyway. The danger is in believing that just because they're "ok" this means they are equivalent (or at least largely overlap) with the more refined products, which is demonstrably false and can be a dangerous attitude to have.
Earlier quoted context omitted.
> No one has ever made a purchasing decision based on how good your code is. absolutely false. > The general public does not care about anything other than the capabilities and limitations of your product. also false. People may not know that the reason they like your product is because the code is so good, but everyone likes software that is mostly free from bugs, performs extremely well, helps them do their work qu…
> The longer your product exists the more important the quality of the code will be. This obsession so many have with "get it out the door in 5 seconds" is only going to continue the parade of garbage software that is slow as a dog, and uses gigabytes of memory to perform simple tasks. For now. We only call it slop when we notice it. Majority of AI text, music, images, videos and code is indistinguishable and you use…
I really don't think this is true. If it was, we'd be able to point to countless examples of things assumed not to be AI that actually were, but there's a dearth of such examples.
Earlier quoted context omitted.
No-one comes out of the womb caring about code quality. People learn to care about the craft precisely because internal quality -- cohesion, modularity, robustness -- leads to external quality (correctness, speed, evolvability). People who care about code quality are not artists who want to paint on the company's dime. They are people who care about shipping a product deeply enough to make sure that doing so is a ple…
Code quality is a side-effect of caring. The most important part of product design is caring at all levels. However it's caring about the external details that is the most important. Coding language is largely a function of the population of good coders in your areas. Code evolvability is almost entirely subjective.
Explain how?
Code evolvability is one of the extrinsic quality markers ( https://www.pathsensitive.com/2023/07/the-11-aspects-of-good... ).
If it's easy to add new features without creating bugs, the code is evolvable. Else, it's not. Does not seem very subjective.
Why build each new airplane with the care and precision of a Rolls-Royce? In the early 1970s, Kelly Johnson and I [Ben Rich] had dinner in Los Angeles with the great Soviet aerodynamicist Alexander Tupolev, designer of their backfire Bear bomber. 'You Americans build airplanes like a Rolex watch,' he told us. 'Knock it off the night table and it stops ticking. We build airplanes like a cheap alarm clock. But knock it…
Soviet engineering wasn't sloppy. It was designed for robustness, loose tolerances and simplicity. It was well thought out design. In the same way that as much thought went into the cheap alarm clock than went into the Rolex watch, maybe even more so, the engineers just had different requirements. It takes a lot of work to make cheap, low precision parts work together reliably. The Rolex has it easy, all the parts ar…
aka "fitting".
I wrote a blog on why Soviet-style engineering is bad https://blog.est.im/2026/stderr-04