• 0 Posts
  • 23 Comments
Joined 6 months ago
cake
Cake day: August 7th, 2025

help-circle




  • I can live without documentation and comments, but then you’ve got to write really well-structured, self-documenting code. Which means long variable names (or better: local constants) that describe exactly what’s in them, and function names that describe clearly what the function is for, and readable code that shows what it does.

    But perhaps expecting that kind of discipline from people who lack the discipline to write documentation, was not entirely realistic.


  • The system I’m working on is shit. The devs all know it, the users all complain about it. It needs to be fixed, and not only do I seem to be the person most driven to fix it, it turns out I’ve been hired explicitly to replace the shittiest part of it. So that’s actually pretty good, right?

    Except my PO doesn’t quite want me to do that yet. First, he needs me to shovel more shit onto it. Shit that’s going to be the first stuff that I’ll replace once I get to replace stuff, and then that stuff will be a lot easier, whereas now it would be a lot harder and too slow to be useable. But new features are more important than making this useable.

    He’s a nice guy, but he doesn’t get technical priorities, and priorities are the primary responsibility for a PO.










  • This does sound very interesting. I should have said the debuggers I’m familiar with don’t do it. Or if they do, I have no idea how.

    Certainly setting breakpoints on certain conditions instead of just a line, would help a lot. Being able to step backwards through the execution even more so.


  • I can also see the variables change by logging them.

    Debuggers are great if you want to see in detail what’s going on in a specific loop or something, but across a big application with a framework that handles lots of things in unreadable code, multiple components modifying your state, async code, etc.; debuggers are a terrible way to track what’s going on.

    And often when I’ve found where it goes wrong, I want to check what was happening in a previous bit of code, a previous iteration or call. Debuggers don’t go back; you have to restart and run through the whole thing, again finding exactly where it went wrong, but now just a bit before that, which is often impossible.

    With logging, you just log everything, print a big warning where the thing has gone wrong, and scroll back a bit.

    Debuggers are a fantastic bit of technology, but in practice, simple logging has helped me far more often. That said, there are issues where debuggers do beat logging, but they’re a small minority in my experience. Still useful to know both tools.





  • That’s not what I picked up from it. The biggest idea that it presents very early in the book is that of a shared subjective truth: most of the things that make up our society, like countries, laws, corporations, etc. do not exist objectively; they only exist because we all believe in them. Objectively, these things don’t exist, but our society is built upon everybody agreeing that these imaginary orders exist, and we’re constantly inventing new imaginary structures on top of that.