[jandrewrogers]

It is important to recognize that even if knowledge becomes untrue because some assumption or fundamental has changed, knowing the history of these changes and why they occurred is still extraordinarily valuable knowledge.

Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the past frequently encourages developers to reinvent an old thing poorly without understanding that not only is it not new but that we stopped doing it in many contexts for good and nuanced reasons.

I think this sense of history is one of the most important aspects of "experience" when hiring. It is easy to train someone on an arbitrary tech stack but difficult to train someone on the history and path dependencies. Many developers are not interested in that history because it doesn't feel relevant to doing a job now. We tend to gain this sense of history by being in the industry long enough that we were part of that history.

[JohnFen]

This is one of my pet issues. I'm absolutely of the opinion that you need to at least be familiar and understand what has come before in a technical field in order to have real mastery in the same field today.

Practically speaking, knowing the hows and whys of obsolete technologies makes it much easier to learn new the new stuff that is coming tomorrow as well. Everything is built on what has come before.

I see many "kids these days" who not only don't know the history, but actively think that knowing it is a waste of their time. It's a shame, because that attitude is a handicap. I also take it as an indication that the person doesn't have an interest in the field for its own sake.

[aleph_minus_one]

> It is important to recognize that even if knowledge becomes untrue because some assumption or fundamental has changed, knowing the history of these changes and why they occurred is still extraordinarily valuable knowledge. [...] I think this sense of history is one of the most important aspects of "experience" when hiring.

I can tell you that in my experience employers do not value this kind of knowledge a lot. Quite the opposite: quite some employers hate such employees who ask "too many inconvenient questions" instead of surfing the hype of the "current/next big thing".

[dartos]

While you’re not wrong, just bc employers don’t care about it during interviews doesn’t mean it’s not important.

In my experience, startups with inexperienced technical leadership tend to be the “next big thing” (as far as tech stacks go) focused types of places.

[rightbyte]

I think that is an orthogonal issue.

That is more or less about virtue signalling that you are a "team player" that helps your boss advance his career rather than doing what nominally is your job. Think teenage clothing fashion. You need to show you are in.

Pretending that complex and risky solutions are needed is a key property of this. The boss need headcounts for the complex fancy project.

And so on, with different companies being in different circles of hell on the matter.

Good solutions usually look simple and easy in my experience. Downplaying the skill in doing them.

The author however seems to write about machine learning, which honestly is a really fast moving field right now. Sometimes things just move fast?

[JohnFen]

In a sense, though, that doesn't matter. I mean, it would be nice, but it's not material. That knowledge is of value to the devs directly because it makes them better devs. That is something employers do actually value.

[hn_throwaway_99]

> Too many software developers just know the "current thing" without knowing why it is the current thing and the specific issues that caused us to move on from the old thing. This ignorance of the past frequently encourages developers to reinvent an old thing poorly without understanding that not only is it not new but that we stopped doing it in many contexts for good and nuanced reasons.

I agree with this, but I also have real frustration that so often, as an industry, I see big pendulum swings along the lines of "that old thing is bad, let's do this new thing that solves many of the problems of the old thing." Except that engineering is usually about balancing tradeoffs, and oftentimes that new thing leaves you with a different set of problems that the old thing fixed in response to the old-older thing.

Microservices were probably my best example of this, where companies were frustrated by the issues with monoliths so they said "Aha, microservices solve all those monolith problems", except microservices come with a whole slew of difficulties of their own, which in my opinion are often more difficult to manage than the problems with monoliths.

The industry's love for a hot minute when all these NoSql DBs first came out (i.e. around when Mongo came out), only to later find out "Hey, the ACID guarantees in RDBMS transactions are actually pretty essential a lot of the time" is another good example.

One bright spot is that I feel like the industry has matured somewhat when it comes to searching for these silver bullets. All frameworks and tech have pros and cons, and when you solve one problem, don't be unaware of the new problems that will create. E.g. sometimes you still see some "Do it all in the cloud!!" vs. "No, you lose control when you do it in the cloud, you should own it all", but I think more commonly you see reasoned responses along the lines of "it depends".

[flyinghamster]

Not only that, but the old knowledge can still be useful. Newtonian physics won't explain semiconductors, but it's still useful for slinging space probes around the Solar System or winning bets at a billiard table.