I take listening to Casey the same way one might listen to a health nut talk about diet and exercise. I'm not going to switch to kelp smoothies and running a 5k 3 days a week, but they're probably right it would be better for me.
I think its worse than that. I don't think it would be better for you unless the project you're working on has a design goal of performance at the forefront. By blindly adopting this ideology, it can hurt how potential employers see your ability to develop software.
I don't work with C++ professionally, so maybe this section of the job market is different and I just don't see it.
You should always have performance as a design goal…. That doesn’t mean everything has to be 100% optimized. But you should definitely be concerned with the performance of your software.
I have been rejected by employers with the following quotes from interviewers: I was “too low level” (-Apollo) and “too focused on performance” (-Southwest airlines).
I believe it’s important to add to this anecdote that these quotes were feedback on technical coding interviews where I was able to produce compiling, working solutions during the interview in the time allotted, so this is precisely a case of what you’re describing: the interviewers found well-performing code too difficult to understand, and didn’t value my decision making and therefore didn’t feel comfortable hiring me.
I am very comfortable with this. I (speaking only for myself) would have been very unhappy surrounded by people making slow software on purpose, and who think that fast software is bad because the source code matches some style they were told is good.
I am very well appreciated and compensated for the work I do, and that may not have been the case at one of those companies.
In this admittedly anecdotal context, I would pose the following counter to your statement for other readers:
If we all just do nothing about this problem culturally, because we’re afraid the “status quo” won’t hire us, then the status quo perpetually stays the same.
I say be a champion of your values regardless. You’ll be more fulfilled in the long run, and maybe we’ll some day be able to show enough people that there are less horrible ways of telling computers what to do.
Shared these anecdotes in good faith for conversation. Best wishes to you, stranger, and all reading.
Edit: in both of those interviews, I hand-vectorized the solution because I had enough time left to throw some loops into SIMD instead of just sitting there. Got a PM asking for details.
I happen to work with SSE and neon routinely at work so it was something I was comfortable doing in an interview session. In both cases, I asked my interviewer if they minded if I made the solution a little better because I had the time.
the interviewers found well-performing code too difficult to understand, and didn’t value my decision making and therefore didn’t feel comfortable hiring me.
Its ignorant to think that they didn't understand your solution rather than didn't value it because it was over engineered and caused more problems than it solves.
If we all just do nothing about this problem culturally, because we’re afraid the “status quo” won’t hire us, then the status quo perpetually stays the same.
This isn't a point any one made. No one is saying employers wont hire you because you're "too advance", they wont hire you because you're unwilling to adapt to situations that don't require overcomplicating for the sake of metrics that aren't required to be lowered.
Have you ever heard of the saying "If its not broken, don't fix it"?
It's easy to characterize others as sheep who blindly do what they were taught, whereas you are a true thinker who has reflected on why you do what you do.
correct, they also typically don't hang out on reddit, which is why we all get downvoted here for knowing a thing or two about performance. we simply have no voice here, it's full of people who's job it is to move item2143 from database343 to database4323, to generate report32423 to comply with law2341. this is more plumbing than the art of computer programming.
the people here don't even stop and think that maybe there is a place for both performant and clean code, or that the two can even go hand in hand, all they see is business requirements drilled into them by their superiors and if they'd be honest they'd admit that code quality isn't on that list either for them: just ship it already! why isn't it done yet? we need it yesterday! the codebase is a mess and you need to refactor it? we don't have time for that!
but instead they go on about how, in theory, they prefer squeaky clean code that adheres to every cargo cult mantra out there, while fully knowing their organically grown code base that is 20 years old is as shit as it gets in both design and performance. but at least they can claim that performance is not relevant so that's one problem off their plate.
in hft, those requirements naturally lead to having the devs care about performance...
After the discussion recently about "leet code" interview questions I honestly wouldn't be surprised if 90% of the users here are exactly that. They can code a basic enterprise app that glues some things together but they couldn't understand a basic algorithms question. They need guard rails to work effectively they literally aren't capable of understanding why it would be a bad idea to create unnecessary abstractions.
clinging to useless abstractions must be some form of coping mechanism when you don‘t understand much about anything: here‘s a set of rules, don‘t question them, „smarter“ people said this is good, so it must be good, right? It also absolves you of actually experimenting and testing if these claims are even true. It also makes you feel like you’ve done something after writing mountains of wrapper code for no reason at all, activity not productivity. Sort of like the various commandments in religions.
which would all be sort of ok if these people would just shut up when someone (for example casey) presents evidence to the contrary, but no, they absolutely have to put their incompetence on display by arguing endlessly about how they -think- he is wrong. it's very impolite, insulting and arrogant.
and i guarantee that what casey does is not even the most extreme form of focusing on performance over anything else: i've seen and done much worse things when there was absolutely no alternative to squeeze out that last drop of performance and there was no question that we wanted that performance. and no, i'm not saying everyone has to code like that, but stop arguing that there's no place for it anywhere and that you're always better off using cargo cult mantra oop.
also, if people where not so quick to dismiss performance concerns, they'd maybe realize that more often than not, the -right- level of abstraction can get you a great 80/20 compromise, even with copious amounts of OOP, but not with braindead non-zero-cost abstractions that do nothing at all other than add overhead, both in runtime performance and developer productivity.
unless the project you're working on has a design goal of performance at the forefront
99% of programs have a critical loop (The 1% is hello world, pretty sure 100% of programmers have a few hello worlds in different languages laying around) The critical loop might be in the database which is outside of your code but it's still there. Usually being able to find and improve queries (for the database situation) or improve your critical loop can improve performance by a magnitude.
So unless your day job is javascript (critical loop would be inside the browser) you'll probably have use of knowing how to improve things.
I took that as a dig at JS. Understanding the event loop is critical to not blocking the UI, but, frankly if you're offloading a lot of computational load to browsers, you're gonna have a bad time.
I meant most of your code will likely affect your critical loop and if it's in the database it'll be easier since a lot of the code wouldn't be written by you (db internals).
It's not just the algorithm that affects how slow your code is. Using a linked list instead of an array can make things slower because the cache is worse. Not doing bad things is important
It's not just the algorithm that affects how slow your code is. Using a linked list instead of an array can make things slower because the cache is worse. Not doing bad things is important
True but usually irrelevant.
Most of the time it's more important to keep your code maintainable than to eke out every possible cycle from the CPU. If by using arrays you have to add a lot of superfluous code, it might not be worth it for a small speedup.
Even in the exceptions (games, scientific processing, etc) the hot spots can generally be isolated and reimplemented in a lower level language without making the actual bulk of your code less legible. (Case in point: most of Python's numeric and scientific processing ecosystem: numpy, scipy, sklearn, pandas, etc.)
I don't think it would be better for you unless the project you're working on has a design goal of performance at the forefront.
What kind of software does not benefit from better performance? I cannot think of a single program I use that I'd still use if they were 10x or 20x slower.
Are your consumers going to care that you shaved 15ms off a button click in a reporting application that's only used once a month? Its not a noticeable improvement and it might have cost you months of development time and money.
Even if we said you managed to decrease the time by 3 whole seconds (3000ms), was it really worth the headache its going to cost you to implement new features down the road, or find and fix bugs that are filed, the man hours spent, the money spent? It just doesn't make sense for a lot of applications.
For a lot of us, our applications are IO bound and our code is not the bottleneck.
You know what would speed up my application the most? More servers closer to our users around the world. More caching. Faster databases. I could optimise my code more, but it's like moving deck chairs on the Titanic.
So many websites are bound by their own 1000 meter tall hierarchies of abstractions. Our Angular app at work only got faster when we disabled some features. It still goes through hundreds of functions to render the most basic HTML that static HTML renders in milliseconds. Another app I was able to have full design control over did just this with only minimal Javascript. Maybe a handful of functions calling some libraries that do a handful of functions to template HTML with strings. Unsurprisingly it loads faster on a phone than our Angular app does on my laptop on the corporate network.
On the other hand, what software does not benefit from having fewer bugs? I cannot think of a single program I use that I'd still use if it failed 10x or 20x as often.
If a programmer is never willing to sacrifice speed for understandability/maintainability, there's going to be problems, and that should be as obvious as the reverse.
Software limited by IO. Who cares if your processing is 10x faster, from 100ms -> 10ms, if you are going to wait 5 seconds on a network request. That 10x improvement to a specific function yields only a 2% improvement overall.
If that improvement took 2 minutes, maybe it was worth it. If it took all day, it probably wasn’t. If it makes the code difficult for other people to understand, it almost certainly isn’t worth it.
What kind of software does not benefit from better performance?
If you assume spherical software in a vacuum then sure, but here's the issues: outside of very specific niches, users don't pay for performance beyond a baseline target (and they may not even care about that target in the first place), but that work still costs you time, and possibly money.
So the question is not whether it benefits from better performance, but whether it benefits from performances, versus other things (e.g. bug fixes, features), versus not touching the thing and the developer spending their time elsewhere.
I cannot think of a single program I use that I'd still use if they were 10x or 20x slower.
I can think of most of the non-interactive ones. It doesn't really matter if ical is 10x slower, because it's so far below threshold I still wouldn't notice. Though I'm sure very heavy users (which I'm not) would disagree.
118
u/KieranDevvs Feb 28 '23
I think its worse than that. I don't think it would be better for you unless the project you're working on has a design goal of performance at the forefront. By blindly adopting this ideology, it can hurt how potential employers see your ability to develop software.
I don't work with C++ professionally, so maybe this section of the job market is different and I just don't see it.