4 ms·

> No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal.

by nandemo 14y ago

> No, not even at entry-level. 90% maintenance is a disaster. 60 to 75 percent might be typical for entry-level programmers, and that's bad, but 90 is abysmal. In my experience and from what I've gathered from friends and coworkers over the years, ratios like that are actually quite normal. And it doesn't have to do with entry-level vs. senior. I suppose a lot of HNers are working at tech startups or otherwise companies that build software-based products. But there's a lot of custom software out there (I'd say the large majority of running software as well as the large majority of software being written is custom, though I have no data to back that up). So lots of devs are either working in-house for non-software large companies, or working for companies that build custom software for such companies, and that usually entails a lot of maintenance work.

mgse 14y ago
I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year. I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing. And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago. As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.
ryanmolden 14y ago
I think it has more to do with primarily only having experience with code you wrote yourself or a small codebase written by yourself and others. I have a tongue in cheek saying of "If you haven't maintained code written by others then you probably write code like an asshole". You learn a lot about what never to do by working with very large (and/or very old) codebases that you yourself didn't design. Also, to be fair to the people that did design them, even your greatest most beautiful design will look terrible to some people, and likely to posterity.

by nandemo 14y ago

mgse 14y ago

I'd agree. Those ratios sound pretty reasonable for firmware. Actually, 60% was probably a good year. I worked on i&p series servers at IBM and a vast majority of what we did wasn't really new functionality. It was more adapting the existing code base to the next gen hardware. Power on sequences had to be modified, hardware access went from GPIO to I2C and vice-versa, and the rules of what could be plugged into where under what conditions were always changing. And once everything was working, you've got years of support to look forward to. It wasn't uncommon to get pulled into discussions for products released 5+ years ago. As an aside, hardware enablement might not be flashy work, but it can be loads of fun even if you're not writing massive amounts of new code. Sure, the documentation stinks and the first pass of hardware is about as good as airport TP, but it is amazing feeling when it finally works.

ryanmolden 14y ago

I think it has more to do with primarily only having experience with code you wrote yourself or a small codebase written by yourself and others. I have a tongue in cheek saying of "If you haven't maintained code written by others then you probably write code like an asshole". You learn a lot about what never to do by working with very large (and/or very old) codebases that you yourself didn't design. Also, to be fair to the people that did design them, even your greatest most beautiful design will look terrible to some people, and likely to posterity.