> Some of the best tech management advice I received was to never get explicit approval for refactoring from your immediate boss - whether you're the line engineer or CTO. Instead, you pad dates as needed to get the refactoring work done implicitly.
This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
Is it your claim that among FAANGs it is a normal practice to say "This will take X weeks" when in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X?
That these companies don't treat engineers as a cost structure the way you were talking about. This creates a drastically different culture since tech has a seat at the table, and the CFO can't just willy-nilly makes demands that impact the entire engineering organization without consent. It makes a big difference.
> That these companies don't treat engineers as a cost structure the way you were talking about.
That's absurd. The reason those companies are making money is because they are costing every single thing. That's the reason why tech gets a seat at the table -- it is a cost and its top of the line managers understand that this is a liability and drive that understanding through the entire tech organization.
> The reason those companies are making money is because they are costing every single thing
Terribly untrue. This is fundamentally what makes them "technology" companies, because of how engineering expenses are treated on the P&L and the say it has at the C-level.
There's a fundamental different between how things roll-up n your 3 sheets, vs. how your company internalizes those numbers and acts upon them.
You've made a lot of broad generalizations without backing anything up with specific examples. It's difficult to have a conversation with theoreticals and ideas.
> in reality it will take Y weeks to implement and K weeks to refactor something else where Y + K is X
This is misleading, you should not be refactoring some other random code. You should be refactoring the code you are adding to/changing as part of the work. And it should be in proportion to the size of the change.
Who established the process control? The same developer that does the refactoring? Because if it is done by someone above him on the org chart then the developer has to either lie about what he is doing or he has to break it down into the refactoring + feature.
This is the thing that I cannot agree with what so ever. Companies do not employ developers to write beautiful code. Companies employ developers to write code to support business. Every single code base that shipped contains warts that became obvious as soon as the final commit was one, which means that refactoring is a cost and costs need to be accounted for and prioritized according to business objectives ( which at the end is making money -- the money that pays developers salaries ).
reply