korrents

korrents · The Pragmatic Engineer Podcast

Why performant code matters (but gets widely ignored), with Casey Muratori

Casey Muratori · 1h 53m · youtube.com ↗

26 korrents from this recording

1h
Casey Muratori did not write this page.

Every claim below is a statement made in this recording, quoted word for word and linked to the second it was said, so you can hear it rather than take our word for it. The wording comes from the transcript published alongside the recording; the sentence above each quote is our reading of the claim, not their wording.

  1. 0:18:28 · watch on youtube.com↗

    Our reading

    Performance cannot win a market on its own: against an incumbent held up by network effects, being far more responsive is a nice plus and nothing more.

    Their wordsmaybe performance could be part of a package where you try to take on one of those players. like, hey, look at how much more responsive our thing is than theirs. Might be a nice plus, but that's not going to be sufficient.
    Interesting
  2. 1 min later

  3. 0:19:45 · watch on youtube.com↗

    Our reading

    A decade of arguing that software is too slow has started to work: new products are now attacking established categories on a performance pitch alone, and getting traction.

    Their wordsI also see people attacking major product categories now with performance-based pitches. Things like File Pilot or the Blick video editor, like things like this that have been coming out lately where it's like, oh, really performant software to try to take on uh incumbents in a space and they've been getting traction.
    Interesting
  4. 1 min later

  5. 0:20:51 · watch on youtube.com↗

    Our reading

    A 300-millisecond response budget is not an achievement but an admission: 300 milliseconds is an eternity in computing, and a product pitching it shows how far the bar has fallen.

    Their words300 milliseconds is like an eternity in computing, right? And so if you're talking about like our pitch is that we're not more than 300 milliseconds, that just shows you how the bar was so far past where it probably should have been for something.
    Interesting
  6. 1 min later

  7. 0:21:36 · watch on youtube.com↗

    Our reading

    The software industry is massively underperforming its hardware, by factors of ten to a hundred, and people refuse to believe the numbers when you say them.

    Their wordsIt's just like we are massively underperforming and people don't believe it when you say 10x 100x but it's actually true and we've seen a lot of proof of it as you point out.
    Interesting
  8. 3 min later

  9. 0:24:09 · watch on youtube.com↗

    Our reading

    Optimization means measuring the gap between your code and what the hardware could theoretically do, not making changes and checking whether the statistics improved.

    Their wordsWhat is the underlying hardware capable of doing at its theoretical peak? And then you measure the delta between that theoretical maximum and what you have achieved.
    Interesting
  10. 3 min later

  11. 0:27:37 · watch on youtube.com↗

    Our reading

    Source code in any language tells you nothing about what the CPU is actually asked to do; only the compiler's assembly output does, and reading it is a skill every serious programmer should have.

    Their wordsIf I look at the assembly language output from that compiler, I know exactly what the CPU is being asked to do. And it's not that hard to be able to learn to read assembly language so that you can see very quickly is the CPU being asked to do the things that I think it should be asked to do them.
    Interesting
  12. 3 min later

  13. 0:30:22 · watch on youtube.com↗

    Our reading

    Assembly is far simpler to learn than the modern web stack: anyone who can vertically centre a div can learn to read it.

    Their wordsit's really much easier if you can understand how to center a div as they say if you can vertically center a div in HTML then you can probably learn assembly language I would say
    Interesting
  14. 5 min later

  15. 0:35:23 · watch on youtube.com↗

    Our reading

    The speed of a system is set by its longest serial dependency chain, which is a property of the architecture and cannot be parallelised away afterwards.

    Their wordsthe performance of your software is generally determined by the longest serial dependency chain because it's something that cannot be parallelized.
    Interesting
  16. 1 min later

  17. 0:35:57 · watch on youtube.com↗

    Our reading

    "Optimize it later" would be safe advice only if every engineer already knew how to avoid the architectural mistakes that no later optimization can remove.

    Their wordsIf every uh software engineer knew to watch out for false serial dependency chains, things where they were creating series of dependent operations that could not be optimized away or other sorts of architectural problems like that that cannot be easily fixed, then the world would look more like just wait and optimize the hotspot, right?
    Interesting
  18. 1 min later

  19. 0:36:56 · watch on youtube.com↗

    Our reading

    Everyone on a team who makes architectural decisions must understand performance, because a codebase that can be optimized later only ends up that way on purpose.

    Their wordseverybody on your team who is making architectural decisions, those people must know performance and they must make decisions that will allow the other people downstream of them to use an architecture which can be optimized later. If you don't do that, you're just rolling the dice.
    Interesting
  20. 3 min later

  21. 0:40:18 · watch on youtube.com↗

    Our reading

    The steady stream of "we had to rewrite the whole thing because it was too slow" engineering blog posts is the proof that deferring performance to hotspot optimization does not work.

    Their wordsThey've got blog posts of we had to rewrite this whole thing because the performance was bad. If it was always hotspots that made your performance bad, you'd never have to rewrite the whole thing. So, we know that that doesn't work anymore.
    Interesting
  22. 4 min later

  23. 0:43:49 · watch on youtube.com↗

    Our reading

    Hand-optimizing hot spots barely matters any more, because the libraries are already fast and CPUs are extremely good at running bad code quickly; what is left is architecture.

    Their wordsOne of the reasons that you don't see hotspot optimization as a thing that really matters that much anymore and one of the reasons I advise that architecture and and not making bad decisions is much more important is because a lot of libraries already have been optimized for you that you might use.
    Interesting
  24. 1 min later

  25. 0:44:43 · watch on youtube.com↗

    Our reading

    Writing software far better than most of what ships today does not take an expert: you do not have to know very much at all.

    Their wordsSo the good news is in order to write software that's much better than a lot of the software you use today, you don't have to know that much.
    Interesting
  26. 7 min later

  27. 0:51:20 · watch on youtube.com↗

    Our reading

    How data is laid out and how it is accessed are architectural decisions with nothing to do with hot spots, and the difference between two layouts can be enormous.

    Their wordswhen you're working with a lot of data, the the difference can be massive if you structure it in one way versus structuring another way, right? Again, architectural decisions that have nothing to do with hotspots, they're how all the data is laid out and what the access pattern is, right?
    Interesting
  28. 2 min later

  29. 0:53:11 · watch on youtube.com↗

    Our reading

    Understanding how a modern CPU executes code is a few months of work, not a four-year degree, and it should be ordinary equipment for a software engineer.

    Their wordsYou go to school for four years to learn this. There's no reason you can't learn this in a few months. It's not that hard.
    Interesting
  30. 14 min later

  31. 1:07:23 · watch on youtube.com↗

    Our reading

    The games industry already ran the experiment everyone expects from AI, when engines became licensable, and the results were not good news.

    Their wordsI've said like the licensable engine thing kind of was our AI transition already unfortunately and uh I regret to inform you that the news is not probably that positive.
    Interesting
  32. 1 min later

  33. 1:08:42 · watch on youtube.com↗

    Our reading

    Once the barrier to making a game collapsed, making a good game stopped being enough: no game gets noticed organically any more, so shipping without a marketing plan is unwise.

    Their wordsIt's it's so massive that there is no way that your game will be organically noticed anymore pretty much period.
    Interesting
  34. 3 min later

  35. 1:11:37 · watch on youtube.com↗

    Our reading

    Graphics have stopped selling games: most of the market by revenue no longer cares how a game looks, so new games now compete with the entire back catalogue.

    Their wordsBut a large portion of the gaming market by revenue doesn't really care what the game looked like all that much uh in a sense that whatever we're doing today is good enough. So 10 years from now if the games look much better for some reason no one will really think of that as a huge differentiation differentiator in terms of sales.
    Interesting
  36. 7 min later

  37. 1:18:34 · watch on youtube.com↗

    Our reading

    The specific rules taught as clean code are simply bad programming practices, and they get worse when you apply them together.

    Their wordsIf you look at those things, they're kind of just bad programming practices. I I don't really know how else to say them. They don't mesh well when you put them together.
    Interesting
  38. 2 min later

  39. 1:20:46 · watch on youtube.com↗

    Our reading

    What clean-code polymorphism really costs you is not the virtual call but the optimizations the compiler can no longer perform once it cannot see what runs.

    Their wordsBut it's the cost of the compiler not being able to do any optimizations. That's the actual cost. And that cost can be severe.
    Interesting
  40. 2 min later

  41. 1:22:54 · watch on youtube.com↗

    Our reading

    Development should never be driven by tests: how much to test is an engineering decision to be costed project by project, not a methodology to adopt by default.

    Their wordsI would say the part that I don't like about test-driven development is the testdriven part. I don't think development should ever be driven by tests.
    Interesting
  42. 3 min later

  43. 1:25:50 · watch on youtube.com↗

    Our reading

    There is no trade-off between well-architected code and fast code: in practice, the code that is architected properly is also the code that runs quickly.

    Their wordsI have never really understood the sort of mentality of there's a difference between code that is like well architected by some principles and code that runs quickly because in my experience usually the code that is architected properly is also the code that runs quickly.
    Interesting
  44. 6 min later

  45. 1:32:14 · watch on youtube.com↗

    Our reading

    Much of the wisdom programmers pass on to each other is nonsense that nobody ever tested, and refusing to be dogmatic about untested practice is what marks out a good engineer.

    Their wordsI find there's a lot of like received programming wisdom that's just nonsense. Like clearly no one's ever tested it and if they did they would have found out that it's that there's no actual basis for it.
    Interesting
  46. 3 min later

  47. 1:35:09 · watch on youtube.com↗

    Our reading

    Refusing to write code with AI can be a philosophical decision rather than a productivity one: the reason to program something is that you want to program it.

    Their wordsit's more about what do you want to do? Like what why are you spending this time, right? It's a philosophical question, not a productivity question.
    Interesting
  48. 9 min later

  49. 1:43:40 · watch on youtube.com↗

    Our reading

    The absence of a visible productivity jump from AI proves nothing, because a real ten percent uplift across the board would be impressive and almost invisible from outside.

    Their wordsThen there's another possibility which is that it actually already has worked but just the productivity boost isn't as big as would be obvious if people got 10% more productive. That would still be pretty impressive because it's hard to get a 10% across the board uplift.
    Interesting
  50. 7 min later

  51. 1:50:33 · watch on youtube.com↗

    Our reading

    Programmers should be reading research papers and crawling their references, and the fact that almost none of them do is a bigger gap than any book recommendation could close.

    Their wordsI want to recommend that people read a paper. I'm trying to get more people to just to just read papers because I realized I read a ton of papers.
    Interesting