I got into programming because of some code maintenance I did for a hobby project. After dabbling with it at uni I'd rejected programming because I just couldn't picture myself doing the 'boring janitorial' bits.
Turns out it is kind of fun to do, particularly if the programmer who went before you was kind of bad, because then there is this puzzle solving aspect to it, of figuring out:
(a) what it is that the code actually does
(b) what it is that the bad programmer intended it to do
(c) how to reconcile (a) with (b)
On the other hand, doing maintenance work professionally is terrible, because most clients put you in this catch-22 situation:
(1) the code is running in prod (with various kludges and workarounds to get around the broken bits)
(2) because of #1 they don't actually want you to make any changes because they might break the system
(3) any fix involves change
(4) hence you cannot fix anything without the client freaking out, even though you are specifically hired to fix things
Maintenance work in that kind of scenario sucks big time.
Disclaimer: I can actually design code properly, so unlike the author my green-fields projects don't turn into unmitigated disasters.
i came here to post about the catch-22 situation. like the author, i actually enjoy bugfixing and improving old, crappy code - but when i have to fix one very specific bug because they can't find a workaround for it, but be careful not to touch anything else, because of the whole network of workarounds and kludges in place, things just get depressing.
It's a trust thing. Also a "better the devil you know than the devil you don't".
The most depressing thing I've ever seen in maintenance was a project that got sent into prod with 300+ known defects, they hired other people to fix the defects, when the defect count got below ~50 they bought back the same guy who had screwed up phase 1 so badly to do phase 2 for them.
Turns out it is kind of fun to do, particularly if the programmer who went before you was kind of bad, because then there is this puzzle solving aspect to it, of figuring out:
(a) what it is that the code actually does
(b) what it is that the bad programmer intended it to do
(c) how to reconcile (a) with (b)
On the other hand, doing maintenance work professionally is terrible, because most clients put you in this catch-22 situation:
(1) the code is running in prod (with various kludges and workarounds to get around the broken bits)
(2) because of #1 they don't actually want you to make any changes because they might break the system
(3) any fix involves change
(4) hence you cannot fix anything without the client freaking out, even though you are specifically hired to fix things
Maintenance work in that kind of scenario sucks big time.
Disclaimer: I can actually design code properly, so unlike the author my green-fields projects don't turn into unmitigated disasters.