4 ms·

Reminds me of Jonathan Blow's talk: [Software is in Decline](https://www.youtube.com/watch?v=FeAMiBKi_EM https://www.youtube.com/watch?v=FeAMiBKi_EM). I think

Reminds me of Jonathan Blow's talk: [Software is in Decline](https://www.youtube.com/watch?v=FeAMiBKi_EM https://www.youtube.com/watch?v=FeAMiBKi_EM). I think one reason why software is slow because managers don't allocate time to improve performance unless it gets worse than "good enough". For me that meant taking time to improve performance without being told or telling anyone how much time I spent trying to improve performance. When I used to work on Android in a large company my favorite low hanging fruit was looking where people used `Cursor.getColumnIndex(String columnName)`. People would call it inside a loop for every row in the query result. This was a surprisingly large time sink according to the profiler. Some developers just don't know or care about performance. I depended on a system that had very large list of banned/blocked IP addresses. This list was stored as a giant array of hundreds of `BigInteger`s. Each time the function was called to determine if an IP address was banned it would convert hundreds of strings into an array of `BigInteger` and then loop through the array checking against each one.

el_oni 4y ago
I've recently been able to work on performance for our product mainly because our tester has been complaining that it takes too long to run all of the integration tests. I got to dig in to some hotspots in our code, some hotspots in the test suite code and speed things up significantly. It's incredibly rewarding work. But as the blogpost says, you need to know how things work (and get good measurements) to be able to make a difference. Knowing what tradeoffs to make, such as caching things to trade off memory usage for computation vs reworking algorithms to be more effecient in the first place, is tricky and not something you can necessarily hand over to a junior dev.
- wadd1e 4y ago
  Reading this just made me question why there isn't a shift from typical leetcode style interviews to interviews where you're asked to do do things like find places to optimise code from a tiny toy app and debug it etc. It seems like an almost universally useful skill and even with people trying to "game" such interviews, it would produce good engineers who know how to optimise what they write. I have read accounts of such interviews happening, but from my (limited, so feel free to correct me) knowledge, they're certainly not the norm.
fatnoah 4y ago
> Cursor.getColumnIndex(String columnName) It's amazing how performance killing patterns transcend the operating environment. I remember profiling a loop-intensive .NET app many years ago and noticed a massive number of framework-level calls to a getOrdinal(columnName) method to find the numeric index of a column from its name. That was triggered by a programmer calling row.GetColumnValue(columnName) method. Though it was fast, it was called millions upon millions of time. I realized a few orders of magnitude worth of performance improvement by manually getting the ordinals on the first iteration, caching them, and then using them for subsequent iterations. I love performance profiling and improvement. It was almost never "roadmap" work, but something I just did.
Zetobal 4y ago
The real issue is that too many developers love the end result, aka the shiny app, but not the sweat and tears that go into creating it. So, most apps are just hastily thrown together to show off on Git, LinkedIn, Matrix or wherever else they can get their fix of validation. Just take a look at the multitude of lazy chatgpt apps, like the one currently reigning supreme at HN's #1 spot!
- 7speter 4y ago
  But premature optimization is the root of all evil and all that. Premature is any point before some flaw causes at scale chaos, btw
TigerTeamX 4y ago
Interesting talk
commandlinefan 4y ago
> unless it gets worse than "good enough" And even then, it's "come up with a quick fix by tomorrow morning to address the problems caused by the mountain of other quick fixes that created the problem in the first place".
tharne 4y ago
> Some developers just don't know or care about performance. I disagree. The reason developers and managers don't care about performance or more generally, good software, is because customers don't care about it. There's no incentive to build more robust future-proof software unless someone is willing to pay for it. Given the choice between cheaper "meh" software with tons of shiny new bells and whistles and better-designed, but more expensive software with fewer new features, guess which one the customer is going to go with 9 times out 10? It's like how everyone loves to complain about the poor service and general crappiness of commercial air travel. We all do it, but almost all of us also buy the cheapest flight we possibly can and then wonder why the airlines ended up cutting so many corners.
tstrimple 4y ago
I’m hoping that one day more developers realize code quality doesn’t drive business value. Except for a niche market (APIs built for developers), the apparent code quality matters very little for delivering actual value. The actual value which then becomes the salary of the developers who all seem to claim the business has no idea what they are doing. Code quality is a trade off. Sometimes that trade off can result in a ROI by lowering long term maintenance costs enabling you to deliver new feature more cost effectively. Sometime that trade off means that your startup was too late to the market and a competitor was bought by Microsoft instead. Regardless, the trade off needs to be discussed and the options weighed. I get that programmers want to view themselves as craftsmen making a work of art. I’m sure there are plumbers obsessed about crafting the perfectly soldered joint. I respect both of them for their efforts and passion, but have to acknowledge both misunderstand the role they are being paid for the majority of the time. For all of Jonathan Blow’s wisdom, I find that too often he’s just a curmudgeon yelling at kids to get off his lawn and waxing poetic about how much better it was in his day. He suffers from the same malady that so many people seem to fall into throughout the generations. That the new generation is shit and everything is falling apart has been a consistent theme for the last two thousand years at least. Quite frankly it’s old and boring.

el_oni 4y ago

I've recently been able to work on performance for our product mainly because our tester has been complaining that it takes too long to run all of the integration tests. I got to dig in to some hotspots in our code, some hotspots in the test suite code and speed things up significantly. It's incredibly rewarding work. But as the blogpost says, you need to know how things work (and get good measurements) to be able to make a difference. Knowing what tradeoffs to make, such as caching things to trade off memory usage for computation vs reworking algorithms to be more effecient in the first place, is tricky and not something you can necessarily hand over to a junior dev.

wadd1e 4y ago
Reading this just made me question why there isn't a shift from typical leetcode style interviews to interviews where you're asked to do do things like find places to optimise code from a tiny toy app and debug it etc. It seems like an almost universally useful skill and even with people trying to "game" such interviews, it would produce good engineers who know how to optimise what they write. I have read accounts of such interviews happening, but from my (limited, so feel free to correct me) knowledge, they're certainly not the norm.

fatnoah 4y ago

> Cursor.getColumnIndex(String columnName) It's amazing how performance killing patterns transcend the operating environment. I remember profiling a loop-intensive .NET app many years ago and noticed a massive number of framework-level calls to a getOrdinal(columnName) method to find the numeric index of a column from its name. That was triggered by a programmer calling row.GetColumnValue(columnName) method. Though it was fast, it was called millions upon millions of time. I realized a few orders of magnitude worth of performance improvement by manually getting the ordinals on the first iteration, caching them, and then using them for subsequent iterations. I love performance profiling and improvement. It was almost never "roadmap" work, but something I just did.

Zetobal 4y ago

The real issue is that too many developers love the end result, aka the shiny app, but not the sweat and tears that go into creating it. So, most apps are just hastily thrown together to show off on Git, LinkedIn, Matrix or wherever else they can get their fix of validation. Just take a look at the multitude of lazy chatgpt apps, like the one currently reigning supreme at HN's #1 spot!

7speter 4y ago
But premature optimization is the root of all evil and all that. Premature is any point before some flaw causes at scale chaos, btw

TigerTeamX 4y ago

Interesting talk

commandlinefan 4y ago

> unless it gets worse than "good enough" And even then, it's "come up with a quick fix by tomorrow morning to address the problems caused by the mountain of other quick fixes that created the problem in the first place".

tharne 4y ago

> Some developers just don't know or care about performance. I disagree. The reason developers and managers don't care about performance or more generally, good software, is because customers don't care about it. There's no incentive to build more robust future-proof software unless someone is willing to pay for it. Given the choice between cheaper "meh" software with tons of shiny new bells and whistles and better-designed, but more expensive software with fewer new features, guess which one the customer is going to go with 9 times out 10? It's like how everyone loves to complain about the poor service and general crappiness of commercial air travel. We all do it, but almost all of us also buy the cheapest flight we possibly can and then wonder why the airlines ended up cutting so many corners.

tstrimple 4y ago

I’m hoping that one day more developers realize code quality doesn’t drive business value. Except for a niche market (APIs built for developers), the apparent code quality matters very little for delivering actual value. The actual value which then becomes the salary of the developers who all seem to claim the business has no idea what they are doing. Code quality is a trade off. Sometimes that trade off can result in a ROI by lowering long term maintenance costs enabling you to deliver new feature more cost effectively. Sometime that trade off means that your startup was too late to the market and a competitor was bought by Microsoft instead. Regardless, the trade off needs to be discussed and the options weighed. I get that programmers want to view themselves as craftsmen making a work of art. I’m sure there are plumbers obsessed about crafting the perfectly soldered joint. I respect both of them for their efforts and passion, but have to acknowledge both misunderstand the role they are being paid for the majority of the time. For all of Jonathan Blow’s wisdom, I find that too often he’s just a curmudgeon yelling at kids to get off his lawn and waxing poetic about how much better it was in his day. He suffers from the same malady that so many people seem to fall into throughout the generations. That the new generation is shit and everything is falling apart has been a consistent theme for the last two thousand years at least. Quite frankly it’s old and boring.