- Hacker's Delight

If this is true, then these problems are already solved. And, given the nature of software, they do not need to be solved again. The reality is that every single piece of software ends up being unique at the edges. It's what makes software great, but also so challenging. It's also these edges that take your 1 page of requirements and turn them into an ambiguous, conflicting set of 50 pages.

There's a lot of induced demand in software development. We have spent the last 70 years on incredible productivity improvements through better tooling, language design, frameworks, etc. But all that has done is create more demand, both for functionality and usability. Now that animations are cheap to add to UIs, people want to have them. Automating tasks that can be done quite cheaply by humans is becoming cost effective in ever more fields. Software of complexity that would be unimaginable in the 50s is used for purposes as mundane as many-to-many short messages.

Lots of software is unique, but at the same time there's also lots of software or software features that just recently became cheap enough to implement to be worth doing. And those can sometimes be quite simple in their requirements.

Yes, we can add more specs but these alone should be pretty daunting.

Is making an app to connect in Bluetooth to an infrared camera trivial?

Is making a 55Gib fizzbuzz non-trivial?

For the camera, there are tons of unspecified behaviors and baked-in assumptions. Is the user configuring the camera, or are we discovering any/all cameras of a certain type? Authentication? What should happen when the connection fails? What if the bandwidth isn’t sufficient (e.g., due to distance or congestion) to deliver the full take from the camera in realtime? How will camera malfunctions be detected, handled, and reported?

A hobby project or prototype can ignore most of this, and insist that you turn it off-and-on if anything looks odd; a fancy turnkey security system should carefully consider all of this and more!

If you're building to solve real problems(tm) you don't need a PM to pad out tickets with filler.

I’ve dealt many times with real people, who present me with a real problem, but no single concrete solution.

If the PM doesn’t take the proper time to understand the problem (and try to find the real, underlying problem that often exists) — Or rushes into a solution without proper evaluation — Or just generally wants to quickly churn user asks into tickets — then the result is the same.

I generally agree that, in my experience, a good senior software engineer is well suited to teasing out “the real problem” and getting to a properly detailed solution even without a PM.

However, that doesn’t mean I don’t think there’s potential value in a PM that can set a broader vision of the product and help prioritize tasks. But the good ones do so by working with and deferring often to his or her software dev team, and NOT by working “top down”.

Classic arrogance and naivety from a Casey follower. Name call all you want, you can't hand wave the reality that the business determines the requirements, and in my industry they don't care about performance until it's a noticeable problem. Oh and the requirements they gave you are solving problem X when they really want to solve problem Y, so your optimal solution to problem X needs to be deleted.

I write correct, readable code as performant as it can be in the time I'm allotted. Call me incompetent, but it's what I'm hired to do.

All this bickering and harsh feelings are stemming from the author's inability to understand that different industries have different priorities.

Yeah, I've done several dozen 10x or more performance improvements on our codebase. It's not always trivial, but most of the time it's not super-hard either.

In fact just today I did a 10x speedup of a query. After a couple of hours analyzing the issue, the fix was relatively simple: populate some temp tables before running the main query. A bit more complex than just running the query, but not terribly so.

Why hadn't we done that before? Because a customer suddenly got 1000x the volume of the previously largest user of that module, and so performance was suddenly not acceptable. It's 5 years since we introduced the module...

To a first approximation, the reason modern software is slow isn't due to failure to optimize this algorithm or that code path, but rather the entire pancake stack of slow defaults — frameworks, runtimes, architectures, design patterns, etc. — where, before you even sit down and write a line of "business logic" code, or code that does something, you're already living inside a slow framework written in a slow language on top of a slow runtime inside a container with a server-client architecture where every RPC call is a JSON blob POSTed over HTTP or something. This is considered industry standard.

The "business requirements" guy is basically saying, I have to ship this thing by friday, I'm just going to pick the industry standard tools that let me write a few lines of code to do the thing I need to do. Ok, but that's the tradeoff he's making. He's deciding to pick up extremely slow tools for the sake of meeting his immediate deadline. That decision is producing unacceptable results.

It's not enough just to say people have different priorities. Selecting an appropriate point on multivariate system of tradeoffs is part of the skill of being a programmer. And if there's no point on the curve that delivers acceptable results in all categories — if, given a certain set of tools, it's not possible to ship quickly and deliver acceptable performance — then it should be an impetus for the programmer, the craftsman, to find better tools, improve his skills, push the "production curve" outward, until he can meet all the requirements.

For instance, a large percentage of modern programmers don't really know how to program from first principles, and tell the computer to do precisely and only the thing it needs to do. Essentially they only know how to glue tools together. Then in their head they're like, well gee, given that skillset, I could either (1) spend a bunch of time optimizing "hot spots," writing crazy algorithms, heroically trying to fight through all that slowness... or I could just (2) deliver the business logic and call it a day. Then they call this "prioritizing business requirements." No, there's a third, alternative, better option, which is to use better tools, which might initially be harder and more time consuming and less ergonomic to use, and then learning to get good with those tools, putting in the practice, recognizing patterns, thinking faster over time, coding faster... all of this is part of what mastering the trade of programming is about.

At the end of the day, there is just an ethic of self improvement and craftsmanship that is totally missing from programming today, and it surfaces whenever this debate comes up.

The problem with this line of reasoning, eg "if you write slow code you're incompetent", is that it applies to everything that programmers do - if you write slow code you're incompetent, if you write buggy code you're incompetent, if you write undocumented code you're incompetent, if you write untested code you're incompetent, if you write code slowly you're incompetent, if you write code that doesn't fulfil all the requirements perfectly you're incompetent, and so on for each and every measure someone dreams up to measure how good code is.

You'll very quickly find there are no competent developers.

The other things are just proxies for the real measures, that people made up, and in fact are often harmful to the main goal. Like "documenting code" and "writing tests" a lot of the time are just cargo culting to make people feel like they're being responsible and following "best practices" without actually improving the measures that matter. I think that the other unlisted metrics in your "every measure someone dreams up..." are likely to fall under this category.

There isn't an infinite number of possible measures like you're suggesting, there's a finite number and a rather small number at that. You can definitely be really good or really bad at quickly shipping performant bug-free code that does its job. The problem in this debate is that one side is completely ignoring one of these measures, and trying to claim that it's because they have to prioritize the other ones, and that this is just an inevitable tradeoff, rather than that we lack the skill as an industry to do all of these things at an acceptable level. Being a good programmer may involve more axes than being a good chess player, but I think the claim that there are so many axes that it negates the existence of programming competence reductios to absurdum pretty quickly.

Working with your type sucks. Confidently incorrect all the fucking time.

Sure, and what I'm saying is that there are many scales, and all of us are at the incompetent end of some of them.

Yeah, people like that exist... That has a strong and reverse correlation with competence.

When FB dove into the numbers, they found they could save 50% in hardware costs. That _does_ matter.

It may be the case that your company has a 20k server rack to support 20M of sales and so it doesn't matter. But unless you've actually looked up the cost you shouldn't be making the claim because it's unbacked; it's just a bad faith arguement.

The cost to rewrite your system to be twice as fast is about the same if you have 20k of hardware costs or 20M, but one saves 10k and the other 10M. Only one offsets the cost of the programmers

People use these excuses for all kinds of performance arguments besides low-level/etc.

> You don't need to do a deep analysis to tell if optimization is needed or not, it is enough to assume best-case improvements and compare it to your FTE + overhead cost.

Sure, my point is people haven't even done rough math of FTE + overhead cost or even best-case improvements while still making those claims.

---

Less w.r.t. the article and more w.r.t. li4ick's comment. I've found numerous 10x gains in performance just by swapping an O(N^2) with an O(N) one (typically converting code using a List to using a Set instead). That doesn't cost 312k and if the original author was more concerned with performance they wouldn't've done things that way.

Is it terrible that the app takes minutes to add a few thousand numbers? Of course it is. But it does not matter, the customer is used to software being terrible so he won't waste the time and money to switch to another software that is probably also terrible.

Software is often aimed at solving problems and making processes more cost-effective. Founders are often most interested in solving their own problems, problems of their friends, or the most valuable problems of their customers. For B2B companies to customers are other businesses. The greatest cost for businesses are employee costs. Solving the employee cost, but eliminating employees, is a great target for business owners.

I'm not a coder but I code; not sure if that makes sense. I sort of know a bit of regex, but find it utterly painful and not worth the time.

I'm an amateur, effectively, with little time. I like AI tools for coding, because I can input a request, and get sample code. I know enough to be able to read most of the code that I get back, but not enough to be able to easily write such code on my own.

These types of tools, in my opinion, have the potential to make people like me, and even people who are much less knowledgable than me, productive programmers. This could be transformative.

Sure, we won't be as good or productive as real programmers, but that's beside the point.

In other words, what you're referring to with "that's about it" could still transform quite a few lives.

This sounds kinda like contemporary Chinese text entry. Nobody remembers exactly which strokes in what order, but can feed some parameters into an app and get back candidate characters.

Of course the characters are a simple enumeration, while what you get from a coding-helper app is still a form of electronic hairball and requires a second look, and a third.

To be honest, I feel a bit of relief every time AI fails to do something. Like, okay, we've got a few more years...

It looks more like refining a search pattern(like one might do with an LDAP query) on the part of the operator than it does an algorithm "fixing", "changing", and "being guided". It's interesting how we anthropomorphism the output of this algorithm compared to other APIs, even though the algorithm is closer to oher APIs than it is a human as far as we understand.

What is really interesting with ChatGPT compared to other interactive software is that you can give instructions the way you would do it with a human. You can literally copy paste a compilation error, with no more context, and it will fix the previous program it generated. Even just pointing vaguely to something like “that does not look correct, you forgot some edge cases” will result in an improved version.

Yeah those are impressive but basically toys. Although at the moment it's clearly still a research prototype. For some things it works really well and beats Google by saving dozens of clicks and repeated searches, for others it's just plain wrong.