4 ms·
As someone who's been doing mostly maintenance recently, it's pretty clear why: 1) reading a pile of code and trying to figure out how it works and being const
by wwweston 11y ago
As someone who's been doing mostly maintenance recently, it's pretty clear why:
1) reading a pile of code and trying to figure out how it works and being constrained by someone else's solutions is considerably less fun for most developers than writing something new and making decisions about how the system will be put together
2) It's much harder to point to what you did or talk up your accomplishments. Particularly to management.
- x0x0 11y agoYou forgot the bit where you often get blamed for the consequences of decisions you didn't take that are firmly cemented into extant code.
- JustSomeNobody 11y agoRe 1. I think it's actually quite fun to take a piece of code, understand it and change it to meet new requirements. There's a good healthy challenge in that. I think a big part of the reason devs hate it is because they can't read code well. They can write it, but not read it. (I realize I'm generalizing, but it is based on some experiences.) Re 2. This is very true.
- st3v3r 11y agoNot to mention that all of the praise for the project has already been given out. All that there is left is angry users yelling that something isn't working now. It's a pretty thankless job.
- nitrogen 11y ago1: it can actually be a lot of fun if you look at it as a sort of digital archeology. You are exploring an ancient world! I enjoy it. 2: write reams of documentation for every function and module and service you decode, check them off on a checklist, and point out how you generated x pages of new docs and analyzed y% of a previously mysterious codebase. Then when you refactor, you get to point out how many thousands of lines of obsolete PL/SQL code you replaced with 10 lines of Ruby.