3 ms·

>The most obvious thing to miss is that the code works. Oh, but the only reason I'm currently reading that awful code is that it doesn't!

• brudgers 10y ago
  When I read awful code that does not work, there are two typical contexts: 1. I wrote it and it never worked. 2. I changed something and broke working code.
  • mst 10y ago
    3. I wrote it, it can obviously upon inspection never have worked, but it was running fine in production for months until I noticed the problem and collapsed the superposition.
    • marvy 10y ago
      cf. 1st law of cartoon physics http://www.dgp.toronto.edu/~karan/courses/csc2529/cartoonlaw.htm http://www.dgp.toronto.edu/~karan/courses/csc2529/cartoonlaw...
  • timthelion 10y ago
    That's not the case for all programmers though. When I re-wrote the device handling code in Docker, I wasn't reading code that I had written, I was reading code that was broken and that others had written. The point though is, to realize that the code evolved. When I searched through git blames, I saw that various parts of the code that wrote to cgroups had been added by various people in no coordinated fashion. Does this mean that the individuals were bad programmers? Individually, their commits looked fine. Need to add access to /dev/tty? Add a line of code to the src/tty.go file that writes to cgroups. Sounds perfectly reasonable, right? But it is not reasonable, when you find that you have 12 different places in the code that write to cgroups, and you find that the cgroups code actually needs to be unified to support standard cgroups, lxc, and systemd implementations, and the naive "add a line to the end of that cgroups file in /proc" only works in one of those configurations... So yes, the code was shit, but the coders weren't.
    • deleted 10y ago
      [deleted]