3 ms·
> There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselv
by jjp 10y ago
> There's nothing like fixing a stupid but critical bug in old crappy code that is so bad you can't imagine how anyone wrote such garbage and considers themselves a professional.. and then realizing you were the one that wrote it. That's a nice wake-up call.
Alternatively there's nothing like having a junior colleague investigating a defect in code you once wrote ask you what it does and then have to publicly declare that that it was crappy garbage that you can no longer decipher.
- laythea 10y agoYears ago, I was the junior in this situation. Being very careful about how to criticize code publicly/not criticize is a skill in its own right!
- ionforce 10y agoNowadays I always write future proofing code. Like, if I need to make a bad decision/tech debt, I will leave ample documentation explaining why and providing alternatives in a hypothetical better future. My future self is always happy that this is the new standard. High quality, documented tech debt.
- pards 10y agoI, too, started leaving comments for myself and other future maintainers to explain why a bad decision or awkward solution was chosen at the time, and offering the list of things I tried along with potential future improvements. Explaining the constraints under which the bad decision was made is important so that my future self can evaluate whether those constraints are still valid.
- KajMagnus 10y agoWhere do you write this documentation? Directly in the source code? Or in something like github's wiki? Or something different? If not in the source code, then how do you make the docs discoverable for people reading the source?
- ionforce 10y agoAs comments, usually. As near to the tech debt as possible.