Comment by Aeolun | Hacker News Reader

Comment by Aeolun | Hacker News Reader

Parent Full thread

> shipping projects on time, and under budget, especially when they are large in scope and involve complex technologies or large teams that you've led, and especially when those projects have impact on the company's bottom line, those project are considered major impact and and those engineers are amply rewarded

Wasn't the point of the article that the Grunt work that has to be done and makes things better for everyone in the future isn't rewarded at all? That work may have an impact on the bottom line of the company, but be spread out over years of maintenance and prevented (potentially disastrous) bugs. However, as the author states, it's almost impossible to quantify that.

You cannot tell your selection committee 'I refactored code and that'll save us probably 100 bugs in the next year, times 2 hours per bug, at $300 per man hour, a $60000 savings.'.

Whereas it's easy to tell them 'I built a new feature x, in the past 10 weeks it's been running it's improved sales by 3%, leading to increased profits over the next year of $60000'.

Both 'earned' the company the exact same amount of money, but the first one is much more speculative.

Disclaimer: manager at Google.

You make an interesting point, and I'd like to suggest an alternative lens to view it from, as a thought experiment. Let's say company X values work that benefits company X, and that's why they hired you and pay your salary. You've given two examples of promotion rationale, one in which you clearly and objectively demonstrated the impact of the work. And the other, speculative, as you say. Now speculative implies not necessarily real -- it's possible that your guess about how much it will probably save could turn out to be wrong. If you don't have a way to measure this, how do you know that it's the case? It feels good to refactor the code, but just consider for a moment the possibility that you could travel through time and see the future results of current behavior. What if you fast-forward and discover that refactoring that code had no benefit? Now return to the current time: is it actually worth doing? If you're spending time refactoring that code at the expense of developing the feature? Maybe this is why company X prefers to promote people based on actual impact rather than speculation.

Perhaps another solution here is to look for ways to measure the impact of that refactoring. Surely your bugs go through some kind of bug tracker, and you would be able to count the before and the after? Is there no line on no graph anywhere that shows an improvement attributable to the refactoring? Can peers at least speak to how crappy the code was before and how much easier it is to work with now? Perhaps the new employee got up to speed in record time because of it? If, at the end of the day, there's absolutely no way to show that this work was valuable, then perhaps... and here's the part we don't like to think about as engineers... perhaps it wasn't all that valuable. Here's the part we like to think about even worse: you could spend 6 months of your career working really hard on something that turns out to be a dud. And it may be entirely rational that you don't get a promotion on the back of that work.

I'm not saying this is how Google works, or describing any particular situation, but I find it valuable to consider different points of view.

To me, this thinking seems like a sure way to get an unmaintanable mess. Now, just polishing a codebase forever without adding any features obviously isn't a valuable way to spend time. But the difference between changing one value in one configuration struct and it having no unforseen side effects and having to go trough multiple classes and reasoning about possible thread races etc. Can make a huge difference in feature adding time. However, how do we measure this?

If all features were equal, like widget production, we'd definitely be able to prove or disprove the productivity boost, but I haven't ever worked in a context where this is the case. There's no guarantee that feature implementation time will go down, maybe it did just not go up as much as it would otherwise, maybe people manage to make more useful features in the future, or at least not as much less useful as they would have been (we would expect utility/feature to go down as a system matures)

When I worked in a two-person team it was easier, of course, the time I spent on improving the code base I soon got back when I had to implement new functionality on a short deadline, this reflected well on me in performance reviews. The problem in a larger team is that it might be someone else who is able to implement a feature quickly due to my improvements.

My guess is that we should be lucky that there are guys like the OP who naively spend time on "low impact" code improvements even though they might not reap the rewards. Without them we would only have people doing the bare minimum to implement new features with a big ball of spaghetti as a result, where projects are abandoned just because no one is willing to maintain them any more. (does this sound like some company we know?)

I guess what I'm describing is that we might end up with a prisoners dilemma situation, where optimising for short term measurability represents defection.

> You cannot tell your selection committee 'I refactored code and that'll save us probably 100 bugs in the next year, times 2 hours per bug, at $300 per man hour, a $60000 savings.'.

You can't? Especially if you have documentation of the bugs that were previously happening, this is very solid evidence. Another one I've seen, "This would cause a weekly page a 2 am, and half the time ended up being an all day problem that needed to be put out. This no longer happens and is worth $X of engineering time."

I would agree though that second example "built a feature that saved $60000" is a stronger statement because it's so much more quantifiable to the businesses bottom line.

To go back to my original point though, we all (not just managers, but the entire team) should constantly be pushing to get ourselves to objective measure. The more subjective measures are used ("I refactored this code which is now easier to read") the more you allow the bad politics I outlined earlier where a boss and his buddy team up to get raises. It's very toxic and should be avoided at all costs.

Reply on news.ycombinator.com