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 themselves

by gregmac 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. I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message. That's the stuff that comes out in the Support cycle that I think people really only internalize if they learn the hard way.

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 ago
  Years 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 ago
  Nowadays 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 ago
    I, 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 ago
    Where 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 ago
      As comments, usually. As near to the tech debt as possible.
tetha 10y ago
> I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message. This is one of the reasons why my current shop has added a new rule. When dev gives my ops team a new release, one of the devs comes to our office and stays here during the initial deployment and test. It's a good feeling to see a dev equally confused about weird crap the application does because it doesn't log and it doesn't work and it's just weird. And for bugs in on-premise systems outside our network, the support devs have even more fun. Overall, this is a pretty funny development. Both teams grew a silly amount relatively speaking, and due to stress and other issues we had a couple of tensions between teams. But by now both teams are learning. Ops is annoyed because of some weird config, and dev hates this weird config because it's a huge pain in the code. Oh, teams talked, config was ripped out and simplified. Dev is desperate about a hard bug regarding request headers, because this might need a hotfix and logging and changes. The admin just shrugged and changed the apache access log with said header, and the problem was resolved 15 minutes later. I think this is one of the bigger lessons for me. Never assume something to be hard or easy for another team. My huge issue might be a 2 line change while removing a huge pain. Your issue might be something my config management already does.
- gregmac 10y ago
  I've had similar experiences, where I learned about something ops was doing -- such as a really complex script to configure something -- that was easily solved by a simple code change. I always pushed for feedback from ops, saying we'd make whatever changes they needed, but they never asked for much. What was happening is they just accepted the software the way it is, and because they were capable of writing this complex script, they didn't see the need to ask for help or changes. I've spent some time recently learning more about the specifics of their deployment and have some changes to make as a result (though since deployment is working, it'll be a slow change since it's more like technical debt and not an immediate problem). However, I think I'm actually going to suggest we do what you're doing, and actually make a developer go sit with ops whenever they deploy a new release. That's a great idea, thanks.

by gregmac 10y ago

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 ago
Years 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 ago
Nowadays 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 ago
  I, 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 ago
  Where 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 ago
    As comments, usually. As near to the tech debt as possible.

tetha 10y ago

> I think another good one is when you are fixing a broken production system, and end up having to revert to running a debugger on the code (involving various hacks to get connected to the production DB/etc), only to realize the entire problem was a simple configuration setting -- which would have been totally obvious and fixed in seconds if there was a bit more logging and/or a better error message. This is one of the reasons why my current shop has added a new rule. When dev gives my ops team a new release, one of the devs comes to our office and stays here during the initial deployment and test. It's a good feeling to see a dev equally confused about weird crap the application does because it doesn't log and it doesn't work and it's just weird. And for bugs in on-premise systems outside our network, the support devs have even more fun. Overall, this is a pretty funny development. Both teams grew a silly amount relatively speaking, and due to stress and other issues we had a couple of tensions between teams. But by now both teams are learning. Ops is annoyed because of some weird config, and dev hates this weird config because it's a huge pain in the code. Oh, teams talked, config was ripped out and simplified. Dev is desperate about a hard bug regarding request headers, because this might need a hotfix and logging and changes. The admin just shrugged and changed the apache access log with said header, and the problem was resolved 15 minutes later. I think this is one of the bigger lessons for me. Never assume something to be hard or easy for another team. My huge issue might be a 2 line change while removing a huge pain. Your issue might be something my config management already does.

gregmac 10y ago
I've had similar experiences, where I learned about something ops was doing -- such as a really complex script to configure something -- that was easily solved by a simple code change. I always pushed for feedback from ops, saying we'd make whatever changes they needed, but they never asked for much. What was happening is they just accepted the software the way it is, and because they were capable of writing this complex script, they didn't see the need to ask for help or changes. I've spent some time recently learning more about the specifics of their deployment and have some changes to make as a result (though since deployment is working, it'll be a slow change since it's more like technical debt and not an immediate problem). However, I think I'm actually going to suggest we do what you're doing, and actually make a developer go sit with ops whenever they deploy a new release. That's a great idea, thanks.