[johnfn]

A lot of the frustration I typically hear in this camp is something like “well I shipped a huge refactor that cleaned up all the code, why does no one appreciate that?” One particular interaction that got me thinking was a few years ago listening to an acquaintance telling me how he spent months meticulously cleaning up the data pipeline and making it perfect, and how no one appreciated this work.

Like, as an engineer, I don’t doubt that this work is valuable. But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.” You’d be like, uhh, okay, but how does that affect the rest of the company? More importantly, how does the PM distinguish engineers who are doing impactful work from the engineers who are doing the “bullet point formatting” work, of which surely some exist? From the perspective of a PM, these types of work can be hard to tell apart.

Really what you want to do is articulate what you plan to do, ahead of time, in a way that actually clicks for non-technical people. For instance, I was pushing unit tests and integration tests at my company for years but never found the political will to make them a priority. I tried and tried, but my manager just wouldn’t see it. Eventually, there was a really bad SEV, and I told her that tests would prevent this sort of thing from happening again. At that point the value became obvious. Now we have tests, and more importantly, everyone understands how valuable they are.

[jlund-molfese]

I agree! You have to also remember that, if you're the person pushing for something to be priority, it's your job to make it make sense to whoever is responsible for prioritization.

The easiest way to do that is to speak the same language everyone else is. Your product manager probably speaks in dollars (or euros, renminbi, etc). If you provide a good-faith estimate (ballpark ranges are totally fine) that increased test coverage or whatever your technical objective is will cost 200 dev hours, and save 400 dev hours on an annual basis, or reduce the rate of support tickets by 15%, or allow for X future business scenario to be supported or whatever, you'll generally have way better luck. My favorite "trick" is taking tech debt work, and framing it in a way so, not only do I not have to push for it as "tech work", but my PM will actually put it on the roadmap proactively because it just makes sense from a business perspective.

It also gets easier over time. You might get some skepticism at first, but if you have a history of delivering accurate estimates and results over months or years, you'll build trust with stakeholders such that what might've taken a round of meetings to convince them before, can now be a 10-minute conversation.

[creer]

Sure except that "saving money" is not what makes a company win, and so it's rightly not what makes a career. If you can show that building that new library for $X will streamline engineering by Y% which will allow doubling sales by launching 3 new products - NOW you have a good proposition. (Your "X future business scenario").

Saving money on the current product is only useful if the company has no clue where to go next. Since normally the current product will be gone in 2 years. It can be useful when your company is in long steady production, like a refinery where saving 0.5% would be huge.

This is something people often miss about dodgy code bases. Or about writing a large application in a weird choice for a language. IF you were able to deliver that application AND it's still profitable 5 years later, THEN already it was hugely successful. You can argue that it was not in the correct language and you are wrong because it was ALREADY hugely successful. Same for cleaning up the documentation.

[jlund-molfese]

I don't disagree, but I'm not sure if you meant to reply to my comment? I didn't make any references to saving money; the point I'm making is that spending 10 hours this week in order to have 10 additional hours of capacity (ability to build out new features tied to revenue) every month is often a bargain that makes sense.

In the context of full-time engineers, "saving time" actually means that time will be reinvested into product feature development, rather than resulting in less spending on engineering pay. Similarly, engineers spending less time on support, means they can spend more time on feature development.

[creer]

Your comment mentioned

> cost 200 dev hours, and save 400 dev hours

And I argue that this is rarely the right perspective. It's 200 hours NOW - and that the company doesn't have budget for. In order to save 400 hours maybe perhaps, if the stars align, two years from now. It's not the same budget. It's not the same time frame. It's not your dept's responsibility. In theory yes maybe but in most businesses, no. These 200 hours now are an investment. This 400 hours maybe perhaps are savings, not profit. They may allow an equivalent 400 hours spent on some profitable new product - but then just ask for budget for the profitable new product, don't worry about where that money comes from. That's sooo far above your pay grade, it's not even funny. If the idea for where to spend the 400 hours is worthwhile, the chairman will raise money to do it. Bring THAT idea to management. THAT would be well received.

In summary: the savings and the new product don't come from the same bits of the balance sheets. They don't affect the future company the same. The wasted 400 hours are already considered in the estimates for the next few years, they are essentially already amortized. They already don't matter. It's not fun for an individual engineer to consider that their work for the next 3 years is financially already long forgotten, lol (?), but basically yes.

It MAY be the right perspective for several levels of management higher up, if people are REALLY working on a 40 year perspective for, I don't know, a mainstream database package, a compiler. But nobody does (in first approximation).

It's also is a good viewpoint where crazy thin differences do make an impact (a refinery).

Still: Most companies that don't plan to be gone in two years do have a methods department or working group. People who do try and make the processes better. They have budget to do that. Bring the idea to them. Hell, even start working part or full time on their budget. But with the understanding that this is yet another group, mission, budget. It's not 200 hours here in exchange for 400 there. And this is a highly technical group - not CXO track except perhaps for a brief stint there.

[gtowey]

Although I agree with this, I can also think of a counter example by analogy.

If you're on a construction project and you, say, spend a bunch of time inspecting and maintaining the safety systems so that you prevent any accidents that seriously injure or kill someone, it's an all-too-common problem that management doesn't think you've done anything and doesn't reward the effort.

It's a huge failure of management that they don't seem to have any concept of benefits unless it can be quantified as ROI. And in the case where it truly is a life or death situation, I consider it a moral failure as well.

In fact, this scenario isn't even a stretch of the imagination. This is Boeing, right now.

[mrbombastic]

Yep, maybe i am destined to never make staff but I absolutely loathe that everything must be tied to some company wide target metric that moves in a quarter or it is invisible. Many things that are worthwhile and that companies absolutely should be doing are not easily measured on a quarterly timeline.

[dilyevsky]

This is commonly referred to as McNamara Fallacy

[andrew_lettuce]

I think what you're describing is communicating the value in terms that the audience understands and appreciates. This is really a sales skill and most developers have little experience or recognize it as such. A good manager can help here, and I agree that a strongly aligned staff dev and engineering manager can accomplish a lot. That's been my experience and I'm always grateful for devs who work this way too.

[imiric]

> But you have to imagine what it must sound like from the perspective of a PM or EM. Itd be like my PM saying “I spent the last month organizing all eng docs to be properly formatted with bullet points.”

If your managers think that, and don't understand the value of refactors, you've already lost. You can try explaining it to them, but if this is how they perceive that type of work, it's a sign that you're working at a company that doesn't understand software engineering.

Of course, new features have to be built, and bugs have to be fixed. Those are always priorities. But refactors are just as important for keeping the software in a maintainable state, precisely because they enable new features to be built faster, more efficiently, and in a more robust way.

[fullstackwife]

Think chefs at top restaurants for example: washing hands is something obvious, no need to get any customer infected with fecal bacteria in order to convince the restaurant management for investing into soap (hygiene takes time, you could serve additional customer!)

It is one of career progression milestones for a programmer when they can set a bar for their craftsmanship themselves. Successful SWE is someone who got hired at a team which does not require this kind of education. A team where this type of engineering hygiene is obvious like breathing.

[dilyevsky]

Im actually curious what happens in a professional kitchen when someone isnt pulling weight on menial tasks like scrubbing or batch prep. I know what usually happens in software teams - nothing

[rkomorn]

Having worked in professional kitchens, my experience is that nothing predictable happens.

It depends not just on management, but also on the personal relationship between management and the person, and on how bad the current market for staff is.

That said, the kitchens I've worked in were filled with people who worked as hard, or harder than the FAANG teams I was a part of.

[kubav027]

Agreed. I have always thought about refactoring as developer responsibility. If it needs to be done do it while working on real feature and update deadlines accordingly. That way it is way easier to justify it because you talk about it only with technical people. In long run it makes code base way better. This results in easier maintenance and faster development of new features.

[creer]

> In long run it makes code base way better.

is true but may be irrelevant. Your hierarchy may have the correct understanding: that this better code base will be irrelevant because the company would then be out of business (because you spent your hours on the wrong obsession). Or will be irrelevant because this product line will change to use an entirely different protocol. Or this engineering group will be working on a different product and different code base. Etc.

I feel that it's fine to do small refactors when they help YOU understand the issue you are working on. Anything beyond that does NOT go without saying. Anything beyond that may well be hours you are wasting on a non-existent issue. In theory worthwhile but the company / your engineering group does not live in theory

Now, ideally, when you discuss refactoring with your manager, they have an understanding they can share - so you can understand. And this will make it easier for the individual contributor to work this way and not that way.

[awesome_dude]

Just for the record, those have intangible results. They improve maintainability, reduce vectors for bugs (which are always based on misunderstandings) and increase velocity.

Absolutely none of those can be measured (hence intangible) which is why they are a hard sell

[creer]

> Absolutely none of those can be measured

They can be estimated (with a wild range) and that's still useful: If that impact is clearly in the noise, drop it. If that impact is clearly huuuge then set up some ongoing measurements and get started step-wise and demonstrate results. If you think you need to rebuild the whole thing before seeing any results, you see the world in a way that won't happen (except if your business is not delivering solutions but is selling solutions - in which case carry on). That doesn't mean the ground idea is incorrect.

[awesome_dude]

Can you demonstrate, or show how that would work (serious question)

[creer]

Sure. Let's take that idea:

> reduce vectors for bugs (which are always based on misunderstandings)

Is that really impossible to measure? (For cheap that is. Cheap measure, cheap estimate, cheap confidence). Is that really impossible to monitor?

Grab a random sample of 100 fixed bugs in the past 2 years. Go through them one by one. How many do you really seriously think would have been avoided? If it's not much more work, give it some weighting on confidence and impact or something. For how much addl work? Once you notice what you could count, restart from the top (re-randomize?) - it's only 100 bugs. Is it really 100%, or is it now that are looking at the data more like 10% at best? Was it really impossible to get data?

Now that you have an estimate, write it up and circulate it - It's risky: you could be volunteered to fix the problem and maybe you don't want that.

Would it really be impossible to monitor over the next year? (Still cheap data, cheap results - except if you really estimated 100% because now you were able to get real budget - even if too small - to attack it.)

Estimates, targets, budgets, deadlines are all different concepts. A fraught but carefully worked up estimate is rarely impossible.

Entire businesses get founded and funded on "impossible" estimates.

[awesome_dude]

Ah, I think that I get that, thanks.

Although to be clear, the estimates will "this is where we think that we will be saving money"

followed by a review (in 12 months time) that will be "this is what we think is the result, but it will include improvements from other vectors, such as better communication from business"

[creer]

Sure. This is rough engineering. If you identify a plausible significant cause, and you attack that, and you get useful improvement, people are not too likely to be overly concerned that there was some confounding factor in the improvement. If there is any excess, it's likely to be in the other direction: deciding that the likely improvement is not worth it. Engineers hate that kind of decision.