Comment by dkarl | Hacker News Reader

Comment by dkarl | Hacker News Reader

Parent Full thread

The "When touching it is the right call" is the tricky part, because it contains this very subjective exception: "Every new feature costs three times what it should because of the design, and you can show the trend."

I've been in situations where I was sure this was true. I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.

Also subjective: "The business needs a capability the current code was never shaped to grow into." Most of the times I've heard this brought up, it's not that you need a re-write, but you need a re-architecture. Often the existing system can continue to do its job as it always has, but in a new architectural context. Or 90% of the code can stay the same, while the application it runs in is changed, for example from a web service to a Kakfa consumer. (This is why it's so important to avoid languages and frameworks that are tightly bound to an architectural choice.)

Everything about all this has always been subjective, which is what separates good engineers from bad ones. Bad ones do refactorings that add very little value, good ones do it the right way, at the right time.

It’s also why, as you become older, the more senior you are the more you start to appreciate “boring” solutions and avoid fancy abstractions. It almost always serves the business much better.

> I've also been in situations where the person claiming it simply refused to become competent in the language, framework, or persistence technology that the system was built on.

To all managers out there, this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring. Eliminate this type of behavior immediately and if the person wont change then fire them (inability to change is also another red flag).

There is a small chance that there's strong logical reasons for a desire to fundamentally change an underlying technology, but the comment above says they "simply refused to become competent in ....... that the system is built on" and as a ex-google senior engineer of 20 years, I can 100% confidently say that the first step to large scale refactor is to understand and be competent in the existing system!

> this is a strong negative signal in the employees mindset, and a strong positive signal that there was a mistake in hiring

Agree that it's almost certainly a mistake in hiring but strongly disagree that it's a negative signal in the employees mindset

Being specialized in one area is actually a good thing for many people and many roles. It's actually kind of bullshit that software companies expect everyone to be a generalist nowadays

Having strong preferences about the tech you like to use and the way you like to build is fine. Find the employers with projects and teams that match your preferences rather than trying to crowbar yourself into everyone else's preferences

Strong (but polite) disagree. Domain knowledge is now commoditised more than ever, the only valuable employees are intellectually flexible ones with a can-do mindset, ideally more senior ones who will also take responsibility for the final output. Thats all we hire right now.

With the exception of companies so huge that economies of scale make hyperspecialisation the sensible choice, however I ignored these because this is a startup and small-medium business community

Respectfully I remain unconvinced. Especially now with people thinking that AI basically does a baseline "good enough" on many things, specializing more deeply than the AI does is probably a really important thing for people

We already have a massive oversupply of generalists and AI makes that easier than ever, so idk. I think specialists are more valuable

I really like your comment about "re-architecture". I 100% agree with you.

To expand on this, I've found that often, the best way to make a change is in two steps: First, make the change easy (the re-architecture). Second, make the change that is now easy.

My best software development experiences have been in cultures where this way of working was common.

It is a shame that these cultures are not more widely spread; and I mostly blame GitHub: the lack of good support for stacked PRs or patch series or whatever you want to call it makes it harder than it should be to work in this way.

Reply on news.ycombinator.com