[rkangel]

I am a firm believer that the most important superpower a software engineer and their team should have is refactoring.

By refactoring what I mean is continually revisiting the architecture of your code, identifying common functionality, better organisation of code, better abstractions. The right decisions for your codebase change as it evolves and so you need to keep reexamining these (implicit) decisions.

Continuously incrementally refactoring your code enables so many things to work better. Your example here is a great one - don't implement something you don't have a direct need for. Don't design for it. If you have a culture of refactoring then you can be confident that in the future if that need crops up, you can implement it with appropriate refactoring that the result will look at least as good as if you designed it in up front. If you don't refactor as a team, then you have to do it now, or putting it in later will result in a mess.

[marcodave]

Which brings up the topic of treating code like cattle, not like art.

Code should be treated as expendable and transient, your clever implementation might be considered deprecated in a month due to changes in requirements/design.

Unfortunately it's not easy to convey this idea as a team lead. People get "attached" to their code and the idea of refactoring is viewed as mostly unnecessary and dangerous (I wrote the code, I'm not gonna rewrite it)

[talkingtab]

This. I did not decide to do this, but over time I refactor things. As I gain experience doing that, I realize I have started to write "refactorable code" (you heard it hear first. In JavaScript land (I'm a fan by the way) this is inevitable. JQuery, React, hooks, context, promises, async, ES6, on and on.

The churn in JavaScript is painful, as many people note, the code I started with is now both smaller, clearer and easier to refactor. So yes to refactoring.

[rkangel]

I was lucky to work with a great and experienced SW engineer early in my career. Among other things we were working on a Bluetooth stack of approximately 1 million lines of C.

I had assumed in my naivety that as I got more experienced was that I would get better at doing things right 'first time' and wouldn't need to keep going back and fiddling with code I'd already written because it now wasn't quite right. What I learned instead was that he spent at least 50% of his time re-working existing code.

There are two important things. The right design changes as you add more code. You learn more about what the right design should be as your work on the code.

You're never going to get it right first time. So instead concentrate on continuously making it better.