Hacker News new | ask | show | jobs
by tluyben2 2165 days ago
> Sometimes what works now won't be competitive in the near future.

What do you mean by that? I can understand in terms of hiring devs, this is true, but any other reason I would be curious about. Because I work with/in many companies, I see a lot of different tech and competitive is usually just what the team knows best. So unless you are making a new team, I cannot phantom why you would switch.

Java with Servlets/Spring and C# with asp.net have been competitive for almost 2 decades; maybe some people can shave off a few minutes here and there but in the grand scheme of a serious company with a serious project (500k loc+) it is not going to matter. There are exceptions as for instance machine learning but those gaps close and this was about web frameworks.

1 comments

Perhaps he means that you won’t be able to attract great talent. A lot of extremely talented engineers don’t want to work on code bases and technologies that are 15 years old.
Definitely would like a source for this because I feel like I hear it a lot and I don't believe it's true.

You can be talented and not care what you work on. And if all you care about is what tech is new and shiny, how talented can you be? I don't want you rewriting my product every year so you can use the next framework du jour.

Maybe talent means something else when nothing is at stake, but I'd argue that a talented engineer knows that when a product works and makes money, and the tech stack isn't prohibitive of those goals, it doesn't really matter what it's written in. In fact, I see trend-chasing developers as liabilities, because they're the ones who will replace everything every six months while you bleed money.

The issue is rarely the age of the codebase or the tech stack, but rather the maintainability and quality of the code.

Due to many factors, the age of the codebase is normally inversely proportional to its code quality. Especially codebases in fields where trends change fast, like web technology.

Therefore, if you're a talented engineer able to work in multiple technologies you'll certainly prefer to work on something that has less chances of making you want to tear your hair out.

> the age of the codebase is normally inversely proportional to its code quality.

What??? You are saying that simply because a code base is old, it is of poor quality. There are numerous public examples contradicting this: Linux, many Apache projects such as httpd, etc.

I emphatically disagree and would like to know why you think that.

I said "normally". I don't think anyone considers Linux or httpd "old tech", neither they are "legacy software" that experienced developers are running away from. C might be old as a language, but there are still modern things being built with it. I also said that the issue is not the age itself or the tech stack.
You didn't use the word legacy in your post. You used the word old. Quite different. Something can be old and still maintained (httpd, etc).
> they're the ones who will replace everything every six months while you bleed money.

Yep. I agree. Maybe talent is the wrong word, but my point is that a lot of experienced engineers want to learn new things by working on new things.

There is a difference between talent and wisdom.

My source? Decades of experience in the industry working with hundreds of different engineers. So, anecdotal.

Not everything needs a double-blind research study to be truthful.

both java and .net (core) are evolving and more mature, though