[li4ick]

You know, reading these comments is absolutely hilarious. It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer. That's it. No, you're not capable of making something twice as fast if only you cared or had the time. If you haven't done it as a constant exercise, you can't.

[robby_w_g]

> It's because of this and that, hundreds of excuses that dance around the simple truth: you're an incompetent programmer.

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.

[magicalhippo]

> in my industry they don't care about performance until it's a noticeable problem

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

[brhsagain]

I don't think the structure of the "business requirements" argument is correct, and I will try to explain why.

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.

[onion2k]

you're an incompetent programmer

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.

[brhsagain]

The flaw in this point is, there are really only a handful of measures that actually matter: writing performant code, shipping quickly, delivering business requirements (really this is an official sounding way of saying "doing the actual thing the program needs to do"), and eliminating bugs.

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.

[jskdndkfm]

100%. Just claim that documentation and tests are cargo cults, take up previous cpu and memory like it’s 1985, and pretend that your shite, undocumented, unmaintainable, untestable, shift-right code is perfect.

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

[li4ick]

I mean, sure, this comment sounds nice on a web forum, but some of us have 0 hesitance bucketing others on a scale of competence. Looking at the state of software I interact with on a daily basis, I really don't care about being nice anymore.

[onion2k]

some of us have 0 hesitance bucketing others on a scale of competence

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.

[marcosdumay]

> some of us have 0 hesitance bucketing others on a scale of competence

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

[li4ick]

This makes absolutely 0 sense.

[asynchronous]

The sentiment here and in most of industry is: “and that doesn’t matter.”

[lesuorac]

The general problem though is that "and that doesn't matter" isn't backed up by anything but gut feeling.

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.

[mavhc]

Also depends mostly on your size.

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

[theamk]

The argument is not that performance optimization does not matter at all, but rather than low-level performance optimization, like rewriting compilers, writing your own custom storage system, or rewriting it in unreadable speed-optimized C++ is worth it.

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.

Do you have many of your servers run CPU-bound C++ apps you wrote? If not, don't bother eliminating class hierarchies, optimize your core logic instead.

Do your webapps spend most time waiting on database and microservices? See if you can eliminate or cache those, the wins are going to be much bigger than rewriting it in Rust.

Is your GraphQL compiler too slow? Unless you are FAANG with hundreds of thosands of developers and hundreds of people to spare, you will get much more bang-for-the-buck with some smart caching or just getting a bigger machine for CI jobs.

According to levels.fyi, the average senior SW engineer in San Francisco is $312k/year. With overhead, the actual cost is likely $500k/yer or so. There is _a lot_ of servers you can buy for that money before you can justify maintaining your own custom version of the existing software solution.

[lesuorac]

> The argument is not that performance optimization does not matter at all, but rather than low-level performance optimization, like rewriting compilers, writing your own custom storage system, or rewriting it in unreadable speed-optimized C++ is worth it.

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.

[alex7734]

In some sectors software quality truly does not matter beyond a certain point (and the bar is really low). The customer very rarely has the resources or the time to try all the alternatives, especially if switching afterwards is expensive so if your marketing is good and your product works and has the needed features, you get sales, and if it's not, you don't.

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.

[archagon]

Hot tip: if you come into a conversation for the sole purpose of condescendingly insulting everyone, maybe put the phone down and take a breather.

On a related note: https://xkcd.com/359/

[li4ick]

I have no idea how you would take what I wrote as an insult. It's insulting to me that people are paid 400k a year and still think that what I wrote is somehow NOT the baseline. It's not even a debate. I'm gonna take my own advice from the past and block HN for another 3 years and get back to work. Good luck.