"Writing documentation and fixing bugs" If you word it that way, it sounds incredibly easy. Actually, what that person did was identify problems in legacy soft

"Writing documentation and fixing bugs" If you word it that way, it sounds incredibly easy. Actually, what that person did was identify problems in legacy software, reverse engineer them (a hard thing), document them (reduces maintenance/extension costs), and fix problems. A company Google's size will be making most of its revenue on legacy systems that constantly need extension, repair, and refactoring. They'll sometimes do something clean-slate but improving legacy stuff is a high-impact skill. So, a mix of hard and useful work on numerous legacy systems that can be used to improve revenue-producing systems does sound like it merits some senior, software engineers. Heck, at a lot of companies, there's always senior software engineers guiding people through legacy projects just out of fear of breaking mission-critical systems. Usually a mix of a knowledgeable veteran and some junior coders for grunt work. Whereas, making new features on well-documented, well-tested systems is so easy in comparison that it surprises me that this alone can get people into senior positions if evaluations are done right.