Comments by "" (@retagainez) on "John Carmack: Best programming setup and IDE | Lex Fridman Podcast Clips" video.

  1.  @taipoxin  I doubt you need a height adjustable table. Just get a chair that can adjust height (which most of them do) and make sure your arms line up with the tabletop. If you're sitting too much, you're probably also staring at the screen too much. Get up and walk and take more frequent breaks. You'll be okay if you sit a little longer than usual, but also understand that you are failing as a programmer if you are forcing yourself to focus for too long on a complex task.
    1
  2. This is the real nugget of wisdom. It's often NOT about specific tooling. Engineers often jump to offering specific tools as their first piece of advice and it's terrible for this world where innovation is key.
    1
  3. Odd, I've found the videogame industry is somewhat archaic and somewhat behind typical engineering practices in other sectors of the tech industry. Perhaps UX and UI is one standout aspect not commonly seen in enterprise works.
    1
  4.  @reneb86  Java is just a tool, like any other programming language. The ideas of more recent engineering practices involve automated test suites, IaC, and CI/CD. The video game industry has a very distinct gap in knowledge and experience pursuing such things, I've noticed. So much so that they advocate against these ideas in favor of "hardcore programming", all the while it's a known anti-pattern and hurts code design to not implement them. I think there's a culture and clique within the gaming industry which focuses too heavily on gaming aspects rather than engineering a good game. In my eyes, if you have the proper development environment you will only focus even more on the broad and high-level picture of your game, the more important bits, rather than get stuck in a low-level coding rut and focus on lines of code or something tedious. There's a reason why some of the most renowned and long-living games have focused on excellent tooling for content creation and mod-ability. Testing the tooling becomes the focus, rather than testing the game. You get a well-tested game purely as an accident. It's a philosophical approach and one that is largely lost in today's non-visionistic games. Java has an ecosystem which promotes CI/CD, automated testing, and so forth, but Java might not be a great tool for game development alone. (Though there are projects that argue against this idea anyway). The point is, language choice and tooling choice doesn't matter. What matters is you choose your tooling and create it as needed, and also test it well. This accidentally solves the question of "how do I test my game?" and lets you focus on validating harder-to-test things like UI/UX.
    1
  5. ​ @reneb86  Thank you for your thoughts, and I understand that game developers might use CI / CD tooling (and this doesn't come to me as a surprise, particularly if we reluctantly view games like Fortnite), but it needs to be addressed that all kinds of devs still largely misinterpret the overall message of something that is a principle, not tooling. Same with automated testing. I do not disagree with much of what you say, but I often feel it's the reflection of the differences of the overall game dev culture (and similarly reflective of overly-pragmatic engineers in ordinary enterprise programming). Still, even with pragmatism in mind, you can still design well and not sacrifice things like design and abstraction. For simplicity's sake of calling it "enterprise programming," enterprise software engineers do indeed iterate quickly and pragmatically, just as game devs do. But this doesn't affect their ability to embrace and understand CI / CD, XP, DDD, BDD, and TDD. Security companies for example are faced with rigor and flexibility issues. Same with NASA, where they needed critical components of software, but not at the expense of design and test-ability. Like I said, I feel that the video game industry is exceptionally behind in practices for the sake of pragmatism. Favorably, for game devs, it is far more subjective to have certain bugs. Similar to game devs, it is often seen in "agile" enterprises that claim they use CI / CD tools, but misinterpret principle completely. Case in the point (and I'm making a very large distinction here and trying not to sound pedant), CI / CD is most certainly not a tool. Likewise, regression testing is indeed automated testing, but the emphasis here lies once again on a singular tool. Talking about regression testing inherently misses the point of what test harnesses and unit tests do. When referring to "getting lost in the low-level" aspects of programming, I'm often not thinking about optimization. Instead I'm talking about not being able to think abstractly enough because your mind is too tied up with low-level complexity. In the optimization argument, non-functional testing is most certainly a possible test scenario, and can be covered in critical areas. Instead, what I am often thinking about when we discuss "getting stuck in the low-level thinking," it is about the over-emphasis on low-level code design. Engineers that intentionally live in very low-level and high cognitive load areas of the code while dealing with high-level features are not abstracting correctly and not organized correctly (Conway's law). It's not a matter of whether they've gone high enough in the abstraction tree, it's that their design is fundamentally flawed, they made the wrong kind of tree. Optimization has its own unique thought process that shouldn't be conflated with refactoring and general code design. Examples below: NASA’s Mars rovers use component-level testing (e.g., ChemCam lasers in vacuum chambers) to validate subsystems before integration, mirroring CI/CD’s "shift-left" testing ethos. Enterprise Java ecosystems (e.g., Spring Boot) institutionalize practices like TDD and modular design, even when pragmatism demands rapid iteration. Intel’s microprocessor validation involves fuzzing ALUs with billions of test vectors before chip integration—akin to unit testing in software. Even with a monolithic game dev like Epic Games, we still see issues where Legacy codebases (e.g., Unreal Engine) resist refactoring due to intertwined systems, even despite their attitude to CI / CD. Non-functional testing (e.g., load testing GPU code) can be automated, as seen in automotive crash simulation.
    1
  6.  @alivepenmods  You don't HAVE to use VIM to use Linux. I think CS engineers, SWEs, any kind of tech engineers, severely overstate tooling in a world full of tools. Over-abstraction can just be a symptom of using tools in a high-level tech stack. The problem isn't the tech stack or tooling, because you may very well end up making your own tool. I hate that the first go-to suggestion that engineers make is to suggest a specific tool, rather than offer something a bit more abstract and philosophical. You could learn the important elements of Linux by simply working a sysadmin role. You can, in that same sysadmin role, also realize why something DevOps is important, too, and why manually administrating a system is an anti-pattern today. The real key is not the tooling, it's the learning and being open-minded. Being open-minded is the real barrier and mental block for programmers and engineers. It's not about silly metrics like words per minute, lines of code per project, etc.
    1
  7. I don't think Casey Muratori contributes much except for being dogmatic and loud about certain things. That's unhelpful and rage bait.
    1
  8. Im surprised at how many people rely on debuggers instead of crafting test suites. Sure, you can't do it for all dev environments, but even for those ones you can, I'm still surprised it's purposefully avoided. You save so much debugging time on a good test suite.
    1