The most important article on software development ever 

Really enjoyed this. Thank you!

I'm so glad I found Handmade Hero when I did. I was getting really annoyed by OOP and I didn't know there's another way. Every way you looked OOP was just assumed as 'the' way to go. Then Casey extended his hand from the heavens and said "There is a simpler way my child. Programming doesn't have to be a pain in the ass". It was hard. It took a couple years. Now finally I can say that simple procedural code is how I roll. Not even a hundred men could drag me back to the eldrich nightmare that is OOP. I am also happy to have found your channel. Whenever I see Casey or Handmade in general recognized I feel warmth in my heart (but not like heartburn the good kind of warmth). Keep up the good work, love your videos. More of this 👏❤

I've been on a big mental health journey and thinking a lot about systems growing organically and addressing needs of systems and it's very funny how much this organic idea of growth coincides with this compression analogy. This honestly makes very clear to me why I have been so burnt out and frustrated in this industry. I freeze every time I'm trying to create code because I'm so worked up about whether or not it will be written exactly the way that the higher-ups want and the harder I try the worst it seems to get. Thank you for sharing this article and elaborating on it because I feel like this brings together a lot of the things that I've learned over the past 8 years about how I need to not get in my own way and it's nice to feel excited about the idea of programming again. It got bad enough that opening my IDE would caused my heart rate to spike big time

I can't watch it now, but can't wait to. Something's telling me this going to be good.

Amazing. I have been programming, in all kind of languages, since 1974. Long before OOP was a thing. Of course when OOP arrived with the general use of C++ and Java I added that to my toolkit. Soon though I started to feel uncomfortable about it. As the years went by that discomfort became pain. But I could never really put my finger on what I felt the problems were I was experiencing. It's so great to find that someone described eloquently what as nagging me, and such a long time ago already.

Your videos are great, stuff like this is why it's often more helpful to learn programming yourself than learn from a professor. Mainstream programming tries to teach us how to handle more complexity, but in reality all we need is to keep our code from being complex in the first place.

Based. I enjoyed this commentary. I had a similar experience, but it was with Brian Will's videos about how OOP is never the correct solution. I later found this article and handmade hero.

I really enjoy your reflections, maybe you should start a podcast about game and software development and maybe philosophy also.

I've been thinking about this in the past days. I've listened to this talk at least 4 times now. I absolutely agree that "semantic compression" makes programming a lot lot more pleasant. Besides that, just like anything in programming, it might be a good idea to partially question it. I came up with a few cases where it might be a good idea to create a function, even if it is only called in one place. - The first thing that came to mind, was a draw function. In simple enough games, where you have just a few entities you want to draw, it might be a good idea to define a draw function on that, and leave it at that. Even if it is only called once in the main drawing phase, I personally like it better not to have that logic in my main function, but define it to the struct that is being drawn. Of course in anything larger, you might want to create an interface/generic function to do that. So in the case of an interface, you have to define the draw function for that struct/class. However, in languages where you have compile-time reflection ( like in ZIG btw :D ) you could define a generic function that draws any struct with let's say a sprite field, position and size. - The second argument I can think of is testing. Let's say you're making a game where only the player can pathfind (by clicking on the screen). In that (extremely specific) case, by the rules of semantic compression, you'd just implement the pathfinding where the mouse input is handled. So in this case, not only the input handling got longer (not necessarily a bad thing), but also you cannot test the pathfinding without also constructing mocking environment for the mouse input. As I said in the beginning, I absolutely agree with this general way of programming. The way I'd put it is: Write the code that is necessary to solve your problem. And when you see repetition, absolve that. After that how many functions, files or even languages you split your project into is personal preference (with advantages and disadvantages). One last thing is that it might be valuable experience to work in a highly complex, OOP environment, or at least not a complete waste waste of time ( or maybe this is my way of coping :D ). I worked in a hyper c++ environment for 2 years, where abstractions were king. In the software we had a way to visualize all the inheritances and connections between all the objects (it might as well could have been a spider-web generator). In the tribe that I worked in (around 30 people) there were around 5 people who could see this whole mess through. Development and fixing bug was pain, I felt really helpless. Every time I could get so far, before getting lost in the forest of abstractions, when I inevitably had to ask for help from 1 of the 5 people who could have helped. That was my first job as a student and luckily I came across videos and articles that challenged OOP, and I tried them for my thesis, and really liked it. Even if that 2 years was pretty bad (the job itself, the people were amazing), I learned why over-abstracting might not be as good as it might seem (for me at least), and I know a few pitfalls to avoid.

Yeah. I try to explain this to entry level developers that they don’t have to follow “best practices”, which change from one year to the next. It’s much more important to build an application or a system in a way that makes sense to you. For me, organizing code into files and folders that align with my mental model is one of the most important aspects of software development. Also, keep in mind that just because you “can” doesn’t mean you “should”. In this case, just because your chosen language supports classes and objects, that doesn’t mean that you must use them, or even that you should use them. They are optional. I only use classes and objects when doing so is “easier” than using functions and structs. There are definitely cases where this is true, like, for instance, chess pieces, where the “type” of the piece affects its behavior. In this case, having a base class with a virtual function is easier than a switch case statement with every chess piece type in multiple places. I’ve found that this approach almost always results in code that works the first time you run it, which is pretty rare, in my experience. You really do get to decide how complicated you want your life as a software developer to be.

It took my a long time to get off the OOP train, simply because most (all?) jobs needed OOP; also a lack of any senior/teacher guidance. But the unsaid realization that OOP is like the politician who promises a bunch but does quite the opposite in insidious ways was getting stronger and I finally jumped ship.

Some of us slightly older programmers knew better when the whole OOP thing came down, and just never adopted that. Learn C and Assembly before you start doing abstractions, but starting out something like Pascal or nowadays Python is a good choice before you get into making things efficient.

Hopefully you find the opportunity to work on an efficient team! I watched the entire video and it essentially describes agile software development vs waterfall development - rather than OOP specifically. This concept of semantic compression also lines up well with well-established development principles like SOLID, YAGNI, etc, which are implementation-agnostic. Note that it *is* important to have *some* up-front conversation about the project so that the team can have a shared understanding and each team member knows what to expect from someone else's work (eg: interfaces, data structures, etc)

Code that is more abstract can be said to be “less concrete”

personally, im just starting out and im looking more towards frontend and js , but this was a cool video nonetheless , i have liked it so it may find someone who might benefit even more from this . again ..good job

this was a great listen, thanks for sharing. so much gold here but there is some important nuance here I've seen missed (not by you, but generally). what's discussed here is about **programming**. not project management, not system design, none of that. i agree whole-heartedly that semantic compression is the best way to write code, but i've seen people take this approach to the rest of the job that we do as engineers. if you're tasked with setting up a new new full-stack feature that integrates with a number of different services with which you have little experience, you really shouldn't just fire up your editor and start typing away. once you hit the coding stage, then by all means just start building until you get the feature working, but do some thinking before hand to see if what you are about to try is even possible / efficient at a high level.

I always thought it was a weakness of mine to approach programming this way

Do you think problems arise, when you work in bigger teams? Because maybe when everyone codes for themselfs, you will come up with different "compressions", and your code is not compatible. Or you end up doing double the work.

It just sounds right doesn’t it? However I would love more examples of code compared to really nail it. Do you have more examples besides the one in the post?

I don’t think it’s necessarily “wrong” to use OOP but I do see your point. One thing I noticed is you never once used the term “functional programming” but isn’t that what this really comes down to? functional programming > OOP. I think that’s your point anyways. Or at least thinking about solving problems in a functional way rather than getting caught up in abstraction

Hello, I know that you are a fan of handmade hero and I also see many other people saying the series is great. I checked it out and considered watching it, however the videos are so long, they go slow, and it seems non-eventful. The whole series is like 600+ one hour videos, so im wondering how you and many other people got through the series. Do you recemmend watching it all or watching it in a certain way? Is it even good to watch anymore? I like the concept of going from scratch but it seems to slow and boring.

Idk, I don't disagree with any major point ig but this seems to imply that imperative code is "simpler" and somehow a better way to think. Code is definitely not inherently procedurally oriented and you're never actually "figuring out what the processor actually needs to do", the latter is just another convenient abstraction for imperative programming. As for the former, procedural code had to be invented, "functions" are as fictional as "objects". Code isn't inherently this or that, we get to (\have to) choose for ourselves how to structure our code. This idea that procedural programming is the "default" and everything else is ideology is ironically closer to what philosophers (specifically "theorists") would consider ideology. Another thing I find weird is this popular execration of abstraction; programming is all about abstraction, it's turtles all the way down (though programmers tend to have strange ideas of "abstraction"*) and it's really not true that there's some universal "goldilocks zone" of "right level of abstraction" (whatever that means). I would also argue that abstraction is *the* way to do semantic compression because you're essentially breaking down the problem into a simplified form that's easier to think about (and yes, I think easier is in some sense entailed by definition). Even the wikipedia article for abstraction has a section for "compression". The abstractions that are appropriate depend on what you're doing: if the implementation details are important, then abstracting them away is not a good idea but otherwise they're distractions/noise, e.g. errors in code can be on the higher abstraction level meaning you've basically modeled the problem incorrectly, or they can be on the implementation level where the programmer has made a mistake in the implementation of the abstractions (like a memory leak, null pointer dereference, or just made a mistake in the realization of the abstraction) and mixing those levels will result in a confusing debugging process. I find many declarative/functional constructs like map, filter, fold, composition etc to be more "semantically compressed" than their equivalent imperative conterparts: you're working with something more conceptual rather than imperative, stateful processes. In general (and imo), thinking about (pure) transformations on data is often less taxing than working through what the (abstract) processor is doing step-by-step and keeping track of state etc. You can reason locally about the transformations, all you need to know is the type. Contrary to what "procedural zealots" say, it's also more honest in the sense that you don't have to pretend you're programming according to "how computers really work", you're freed from the unessential "low-level" details of your platform (modulo leaks ofc). Also your abstractions are composable, which I think helps with coming up with better abstractions because you're essentially just naming a composition of abstractions, which is much easier to think about than stateful procedural abstractions in general. *strange ideas of "abstraction": abstraction pretty much boils down to naming some common pattern. You have some objects (not in the OO sense, more general) and you notice an underlying structure that they all have in common so you give that structure a name, thus stripping away the unnecessary detail (this doesn't have to be generalizing, e.g. you can specialize a HOF and give the resulting thing a name). "Why Functional Programming Matters" by John Hughes has some great examples of abstractions. Also, outside of compsci, humans do this all time time without thinking about it at all. By contrast, programmers slap together a bunch of functions and fields into a class and equate that process with abstraction. I mean the resulting class is an abstraction, but really that's a specific way to implement abstractions in code and not the only way that programmers create abstractions. Abstraction isn't synonymous with classes, or class hierarchy, or inheritance, or UML, or top-down deisgn etc. And I'm not just being a nitpicker: I think there's an important distinction between "an abstraction" and what you and so many others are criticizing. It's important because the critique is valid but like I mentioned earlier, programming is ALL about abstractions regardless of on "what level" you're working on. Arguably there's nothing to programming but shuffling around and creating abstractions.

But the thing which the author of that article did is precisely an abstraction! :D He abstracted away the minute details of the fiddling with numbers and gave the actual UI actions actual names. This is called an "extract function" refactoring. In the process, he invented an object of the conceptual class PanelLayout. What was described in that "semantic compression" article was literally an OOP as it is. We also removed a "mixed abstraction level" code smell in the process. It was extremely funny to see the amount of slander towards OOP, refactoring and abstraction in that article given that the author immediately proceeded doing exactly them lololol. :D

What the simga is in the thumbnail? A bug, a fish?

Frankly, it's a bad article. The author complains about people who try to force their way of programming on you, and then proceeds to do exactly that. And the argumentation is bad too. We've got this criticism of OOP: "First, you look at the real world problem - say, a payroll system - and you see that it has some plural nouns in it: “employees”, “managers”, etc. So the first thing you need to do is make classes for each of these nouns. (...)" Well... no. The central part of a payroll system are going to be payrolls. If the only relevant piece of information about "employee" or "manager" is the person's name, then you don't need any classes for them, a simple string inside the payroll class will do. So the presented issue (proliferation of classes) is not an inherent flaw of OOP, but rather poor design. Then there's a description of some prototyping and refactoring, really nothing magical about that. It's pretty much impossible to write a bigger chunk of software (OOP or not) any other way. There's nothing wrong with some rudimentary up-front design (which will likely go through multiple phases or refactoring) either. It often helps you to discover dependencies or issues you didn't consider earlier. And "because I enjoy trashing object-oriented programming" just reeks of bias. So yeah, Casey is definitely a smart and capable programmer, but that's just not good criticism. I agree on one thing though: purists are not worth listening to. Now a piece of advice from me: remember, software is a just tool. So the most important thing is that it needs to get the job done. In other words, as long as it meets the requirements, you're golden. It doesn't need to have perfect design, use fancy features, it doesn't need to be OOP, procedural or functional. It only needs to be good enough.

Did anyone else have a low key panic attack when he said that he wasn’t born in 2014? All of a sudden, I felt really old for some reason… 😳 It took me a second to realize what he meant. 😏

Initial example feels like a strawman. Why not start with Role interface and concrete implementations. It's still OOP but you avoid confusing hierarchies. Genuflecting? Ivory towers? Feels like a lot of whining about having to fit in with whatever "ideology" is established on a product and demanding a shift to Casey's "ideology." If there is a structure that works for a team, dumping just because there is another way of accomplishing the same thing seems counterproductive in every sense of the word.

It's strange, but I just read that article the other day. I appreciate your perspective, but I don't think this article is as good as you do. I disagree with Casey here regarding the definition of terms, especially with regards to the word refactor because that's precisely what he did to the code mentioned in the article. I also disagree with him claiming that the resultant code isn't object oriented because it definitely is that, if not in a puritanical sense that would rightfully garner hate, he did in fact create an object and orient functions around it. The key takeaway for me is that everything should be in moderation, and if that was all he said then fine, but the part where he all but claims that planning is a bad idea I completely disagree with. Writing a simple outline is how you direct things so that you don't go off the rails in a project. It's also the best way to organize your thoughts in how a project should go. Now admittedly it does take a lot more skill, but if the project you're working on requires optimization, a lack of planning will make that a more difficult refactoring job later on. Anticipating the correct direction to go in a project is a skill that more developers need to develop. Avoiding micromanaging a project is yet another skill that more developers should have. Both are difficult skills to acquire, but all of the best developers that I've known have had those skills.

Heretical. How DARE YOU be more efficient. Don't know you that lowers cloud compute fees? HOW WILL CLOUD COMPANIES LIVE?!?!? What will we do with the extra ram?

41:24 YES YES YES. After you're done actually solving the problem, the torture begins. After a long time of feelign like shit I realised that all I am doing is guessing what a lead developer likes, there's no objective task that I am working towards. It's most often about making Big Important Dev Person look Big and Important so they absoutely have to make everyone rewrite perfectly working code four times and start minimum two metaphysical research papers about meaning of the word 'action' or some shit. Whatever, man.