3 ms·

When you’re oncall and something broke.

• watwut 8y ago
  You are on call for coding? What kind of job is that? This sort of things should be really really rare. If it happens in any regularity, then tricky abstractions are not the main problem. Apparent lack of QA and overall quality is.
  • pdpi 8y ago
    Point is that it broke and you’re trying to figure out why and how to get it fixed. Sometimes looking at the code is the most expeditious way to get there.
    • watwut 8y ago
      If 30 min fix in the middle of the night is your limit, then you better never do any non-trivial project. But my point is, this should not play like this with any kind of regularity. At all. And it is not happening regularly for mission critical projects. It is not that we write without bugs either, it is more that you have processes and multiple systems to avoid middle of the night quick fixes into production.
    • coldtea 8y ago
      >Point is that it broke and you’re trying to figure out why and how to get it fixed Yeah, but the point was made to support an argument (that code should have fewer abstractions so that it's faster to grasp any part while reading in a hurry, as opposed to more abstractions so that it's shorter and more generic, even if that means having to study the big picture to get what some smaller part of code does). Now, if devs routinely had to quickly understand some local code at 3am to fix bugs, as per the example, then sure, fewer abstractions and more clear local code would be better. But since your example is contrived, where does that leave the main argument?