Refactoring and Trust

Refactoring has many faces.

When you start out,

a fresh-faced developer, your only goal is to make your code Do The Thing. You forgot that semicolon or that loop was off-by-one and it took you the whole day to wade through those error messages to figure that stuff out and you’re on top of the world because you Fixed The Code and what do you mean change the code it WORKS NOW.

Some years pass,

you’re now more confident in your work and start thinking about the patterns you start seeing emerge. You start practicing DRY and understanding the usefulness of design patterns. You’re slowly exposed to the practice of refactoring - changing the code’s structure without changing its external interfaces - extracting a method here, an interface there, moving methods up the hierarchy, … You’re no longer designing your code, you’re redesigning it as both you and it change.

Most people do it out of either fun, pedantry or both. Fun, because you’re curious and it’s experience and the code just never quite looks right but the journey is interesting and you don’t have to worry about those pesky new product requirements while you’re fiddling around. Pedantry, because the two beasts of That’s Not The Way I Would Have Done It and It Must Be Done Right rear their heads. It’s Your Code and you can’t do anything until it’s Right. IT HAUNTS YOU!

(It Haunts Us by CommitStrip, the reason this blogpost was written in the first place)

Your Engineering Manager and your Product Manager? They just don’t understand you. They don’t understand that it NEEDS to happen. But you can FEEL it! They don’t own the code, they don’t write it, they don’t understand how terrible it is and how wonderful it would be once you’re done refactoring...

Some more years pass,

you’ve been programming for quite a bit of time now, and have been in a few teams, working on a few different projects and products. You no longer see the code you write as an artifact that could ever be complete. No, it’s all about forward motion and tradeoffs, what you can design relatively well and what you can’t, for now.

This understanding helps you more easily explain why not refactoring would be detrimental to this forward motion. You’ve learned to stand your ground when you understand the returns outweigh the investment, but also to accept when it’s not the right time. Refactoring is still fun and you’re still just as pedantic as you were, but you’ve gained PERSPECTIVE.

Your Engineering Manager and your Product Manager? Yeah, they still don’t understand refactoring. Their ears prick up when they hear that word. There’s always the next feature that needs to happen yesterday and the refactoring always takes a long time and I mean Those Pesky Developers Always Want To Refactor Everything. Oh, and worst of all, there’s never any result that can be measured. I mean, you can’t build the next feature, then go back to the old version of the code and build the feature again and show that it would have taken longer, right? Right? I meaaaaan… no, no, that’s just cutting off your nose to spite your face.

There are lots of reasons for this mindset from EMs and PMs, but I’d like to propose one of them -

Trust.

Sure, they trust you to do your job, churning out features, hunting down bugs and handling outages, but do they trust you as a Professional? To them, a Professional would not waste time on frivolous activities, like tinkering with the code just to see if it looks nicer or changing it just because it Doesn’t Feel Right. But wait, that was you just a few years back. Oh crap, maybe that’s the kind of behavior that was imprinted on them by their past experience with developers? I mean, these Past Yous aren’t wrong - they’re just learning - like you did.

How can you build that kind of trust? Well, that’s beyond the scope of this post. Maybe at a later time.

One last thing - I don’t know if that’s the pain your specific EM and PM are feeling. It might be. You should probably ask them. It’s a great start.