alt Hacker NewsYea I largely agree with you on that point. I think when discussing Jon, Casey (and to add another, Mike Acton), there's actually a series of advice that they give that get lumped into a whole, and people don't really see the parts of what they're saying and instead focus on the part that sounds most critical to their work.
I do agree that if you take from their "teachings" that every dev needs to optimize every thing, and never use any other language than system languages, that advice is myopic for most devs. However, I don't really see them arguing for that, at least not entirely.
From following their teaching for a while, they mostly preech about the following things which I agree with, even when talking about higher-level languages, technologies.
- Get the clowns out of the car: Don't make things needlessly expensive. Write simple procedural code that maps cleanly to what the hardware is doing. This is essentially stating OOP, large message passing, and other paradigms that abstract the problem away from the simple computations that are happening on your computer is actually adding complexity that isn't needed. This isn't about tuning your program to get the highest amount of performance, but rather, just write basic code, that is easy to follow and debug, that acts as a data-pipeline as much as possible. Using simple constructs to do the things you want, e.g. an if-statement versus inheritence for dynamic dispatch.
- Understand your problem domain, including the hardware, so you can reason about it. Don't abstract away the hardware your code is actually running on too much where you lose vital information on how to make it work well. I've seen this many times in my professional career, where devs don't know what hardware the code will be running on, and this inevitably makes their code slower, less responsive to the user and often drives up cost. There are many times in my early career (backend engineering), that just simplifying the code, designing the code so it works well for the hardware we expect, greatly lowered cost. The hardware is the platform and it shouldn't be ignored. Similarly, limitations that are imposed by your solution should be documented and understood. If you don't expect a TPS greater than some value, write that down, check for it, profile and make sure you know what your specturm of hardware can handle, and how much software utilization of that hardware you're getting.
- Focus on writing code, and don't get bogged down my fad methodologies (TDD, OPP, etc). Writing simple code, understanding the problem more deeply as you write, and not placing artifical constraints on yourself.
Now each of these points can be debated, but their harder to argue against IMO then the strawmany idea of them proposing that you must optimize as much as possible. And they argue that you will actually be more productive this way, and produce better software.
FWIW, you may have some datapoints showing that they do propose what I called a strawmany version of their ideas, but I have seen them advocating for the above points more so than anything else.
---
I do want to add, for Jon Blow, I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past, and had no problem with their output in terms of gameplay or performance. From his talk about civilization ending relating to game dev, he's more concern that if no one tries to develop without an engine, we as a civilization will lose that ability.
Replies
Aha! I think I know my contention with this advice now. Who can actually disagree with this? Like I'm saying yes to everything, no one I know would say no to this. Never had a coworker say aloud: "I want to write code to make things worse."
These are the platitudes of our industry that no one disagrees with. Like you said, this is what Blow + Muratori teachings can be distilled into. But there is something worse it also assumes, coming from such people.
Both Blow + Muratori have extremely privilege dev careers that a good ~80% us will never achieve: they have autonomy. The rest of us are merely serfs in someone's fiefdom. Blow has his fief, Muratori his. They can control their fiefs but not the majority of us devs. We don't have autonomy in the direction of the company, we don't control the budgets, we don't even control who we interview or hire.
Assuming that this onus of organizational standards has to be placed on someone with no authority to dictate it isn't just. Also as someone who has consumed content from these two for about a good 8ish years as their videos pop into my feed: I've never see them advocate for workers to be empowered to make their environments better. They mostly just trash on devs that have no authority.
With that mindset I need to seriously decouple myself from these people. Plenty of other devs advocate for the same things in our craft while also advocating for better rights as workers.
> I don't think he has a problem with people using engines. From what I've seen he's played, and loved games that used engines in the past
He's also said quite openly that if you're only starting, it's fine if you reach for a ready-made engine. It's that you should try and understand how things and systems work as you progress.
Yes, this is well put. I was heavily influenced by Casey back in 2014 and the advice I give juniors now is always that first point about "getting the clowns out of the car". There's a lot of crossover with the "grug brained developer" here too, which is much more aligned with the web/enterprise world.
I find it very hard to convince people though. It runs counter to a lot of other practices in the industry, and the resulting code seems less sophisticated than an abstraction pile.