3 ms·

I think a lot of companies are shooting themselves in the foot in this respect. They bias themselves towards people with visible portfolios of greenfield work,

I think a lot of companies are shooting themselves in the foot in this respect. They bias themselves towards people with visible portfolios of greenfield work, then hire them to do maintenance. Not only does this select negatively for the type of person who would be good at maintenance, it also sends the signal that maintenance is a career dead-end.

danieltillett 11y ago
Does anyone want to maintain old code as a job? I agree that there is a major issue between what companies say they want and what they actually reward people for. Be a team player and work on code maintenance, but when we promote or recruit we want a “rock star” who has 100 projects on GitHub.
- vonmoltke 11y ago
  > Does anyone want to maintain old code as a job? I actually think it's really fun. Of course, my attraction to engineering has always been to figuring out how things work and making them better. Unfortunately, most maintenance is just ticket-punching. I love the kind of maintenance that is "find a way to speed up the critical path in X" or "find the source of the intermittent crash in Y" rather than "change every occurrence of FONT_COLOR='#239a11' to '#239a33'".
  - p4wnc6 11y ago
    I take this even further. I think all maintenance should be framed by the business as: >What ideas do you have about how the solutions to these specific bugs/tickets/requests can simultaneously improve the existing system, even in ways unrelated to the specifics of the bugs/tickets/requests. How can we give business priority to those ideas? The difference is that if you challenge someone to not just meet a minimal set of criteria to "solve" a bug/ticket/request, but to use their wits to go further and not just solve it, but solve it in a way that creatively improves things around it too, then they'll be way more engaged. Almost all studies on this sort of thing have shown that you get higher quality work, people work faster in this set up, and they generally report feeling satisfied about it. This was a big part of the book Peopleware, where it talks about how in software at least, the notion that you have to trade-off speed of implementation against quality of implementation is a total myth -- just not borne out of any data measuring task completion time, degree of spec completeness, and bugs. To me, things like Agile tend to get politicized in a company and then get misused, to the point where rote emphasis on minimally clearing tickets ruins any chance to let people be creative about how they solve maintenance issues. And at the end of the day, even if you have great system architects, usually it is the maintenance developers who have really seen the nitty gritty of the codebase and have the most intuition about good refactoring design choices.

danieltillett 11y ago

Does anyone want to maintain old code as a job? I agree that there is a major issue between what companies say they want and what they actually reward people for. Be a team player and work on code maintenance, but when we promote or recruit we want a “rock star” who has 100 projects on GitHub.

vonmoltke 11y ago
> Does anyone want to maintain old code as a job? I actually think it's really fun. Of course, my attraction to engineering has always been to figuring out how things work and making them better. Unfortunately, most maintenance is just ticket-punching. I love the kind of maintenance that is "find a way to speed up the critical path in X" or "find the source of the intermittent crash in Y" rather than "change every occurrence of FONT_COLOR='#239a11' to '#239a33'".
- p4wnc6 11y ago
  I take this even further. I think all maintenance should be framed by the business as: >What ideas do you have about how the solutions to these specific bugs/tickets/requests can simultaneously improve the existing system, even in ways unrelated to the specifics of the bugs/tickets/requests. How can we give business priority to those ideas? The difference is that if you challenge someone to not just meet a minimal set of criteria to "solve" a bug/ticket/request, but to use their wits to go further and not just solve it, but solve it in a way that creatively improves things around it too, then they'll be way more engaged. Almost all studies on this sort of thing have shown that you get higher quality work, people work faster in this set up, and they generally report feeling satisfied about it. This was a big part of the book Peopleware, where it talks about how in software at least, the notion that you have to trade-off speed of implementation against quality of implementation is a total myth -- just not borne out of any data measuring task completion time, degree of spec completeness, and bugs. To me, things like Agile tend to get politicized in a company and then get misused, to the point where rote emphasis on minimally clearing tickets ruins any chance to let people be creative about how they solve maintenance issues. And at the end of the day, even if you have great system architects, usually it is the maintenance developers who have really seen the nitty gritty of the codebase and have the most intuition about good refactoring design choices.