11–20 of 39 posts
If done right optimizing for performance also achieves readability and maintenance. There is an edge case when you rewrite a loop with SIMD or use branch less programming. It is so rare but a focus of so many articles. I do see a lot of system that are both slow and hard to maintain because people focus on maintenance. They create abstractions upon abstractions in the name of maintainability to later find it does not…
Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives. While we talk about maintainability, we all admire Fast Inverse Square algorithm. Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety.…
Wow, TIL.
This blog post reads like AI slop. I doubt that the author even read the result, as it's readability is subpar. In general AI slop is more readable than this soup of bullet points. This feels like eternal September, but powered by LLMs.
I mostly agree with the author that optimizing a code base for change should be the number 1 priority, but I think it is different topic than for example application performance. And it is not an either-or ... you can actually do both, the question - as always - is if you should do it all. - Optimizing for change is basically the key principle of agility. Too ofter it is confused by many people with being fast in del…
And I as a user absolutely hate programs that do this. Put an "updated" message with a timestamp if you want, but don't pointlessly waste my time.
Earlier quoted context omitted.
> If you have high team fluctuation, optimize for readability. Or better: If you have high team fluctuation, optimize that first so your team is actually effective.
You can't fix faulty management as a developer. You can structure a code base around it.
Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives. While we talk about maintainability, we all admire Fast Inverse Square algorithm. Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety.…
I skimmed through NASA’s coding manual a while back, and one of the things that I took away from it was that optimizing for readability is optimizing for safety.
It’s just that it’s hard for me to see it as readability because I’m not familiar with the problem domain. For example, their ban on reentrancy would definitely require me to rewire my brain a bit. But, for what they are doing, that is a readability decision: they needed to be able to guarantee that a spacecraft’s firmware couldn’t experience a stack overflow, and reentrant code makes it much harder to reason about stack growth.
Author fails to acknowledge that there are many fields where we ship only once and we should strive towards that if we want to avoid running firmware updates on our ultrasonic knives. While we talk about maintainability, we all admire Fast Inverse Square algorithm. Optimize for what best serves your purpose. If you have high team fluctuation, optimize for readability. If you develop a spacecraft, optimize for safety.…
i don't. that guy basically made the same game over and over again, while nearly everyone else was innovating in game design, reaching new audiences, etc. that's what change is about!
and then, he blows up the next thing he's put in charge of (VR), and blames everyone but himself. how many billions did he get and he couldn't figure it out? every bit of ethos from that guy was bad, it's not just the one little ethos of the hardcore little optimization algorithm, it's every ethos.
Earlier quoted context omitted.
> If you have high team fluctuation, optimize for readability. Or better: If you have high team fluctuation, optimize that first so your team is actually effective.
You can't fix faulty management as a developer. You can structure a code base around it.