> Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology. It probably also indicates a lot as far as what your colleagues would be like and how much you'd learn from them.

Not everyone is looking for the same thing. Over interest in new technologies cautions me that a candidate may be more interested in hype than finding suitable technology for a problem, it's a continuum, but sometimes you see a pattern of hit and run, trying new tech and then leaving projects behind (not even them knowing what happened to them, if it turned out to be a good decision long term)... that's not attractive from a business perspective where stability is valued.

At the other end you get people who are not comfortable stepping out of the box they've made for themselves. You want a bit of both, it's good to be interested in new things and even consider them for use in production - but it must be accompanied with a healthy amount of scepticism and keeping your evangelism in check, because technology can be subjective.

> the tech stack of a company you're interviewing with matters

Yes, this blog belongs to a (fairly large) class of "career advice the way the author wishes the world was rather than the way it actually is" blogs.

> Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology. It probably also indicates a lot as far as what your colleagues would be like and how much you'd learn from them.

Similarly, using a bleeding edge stack indicates the engineers are getting away with resume stacking and you can be pretty sure the product will be late, over budget and developers leave after a year because it turns out using any particular tech stack in and of itself doesn't mean you can create something useful.

You don’t get it. The point of the author is that you want to be in the position where a company is hiring you, as a consulting business, to solve a particular problem they’re having. That means having very large freedom in your implementation, as long as the problem is solved.

What you’re describing is basically being an employee. When you’re an employee you typically aren’t hired to solve a problem, you’re there to fill a role. To fill the role you will need to fit whatever mold the employer wants, including tech stack.

OK, but what I quoted was specifically advice on being an employee:

>Many asked how to know what programming language or stack to study. It doesn’t matter. There you go

And I'm saying the language/stack absolutely does matter when it comes to advice for new developers.

Note the blog post is from 2011. It mattered less then.

This isn’t true. I have folders with emails each time I’ve been looking for a job since 2008 (2008,2012, 2014, 2016, 2018, 2020). I stayed at my second job from 1999-2008.

A sample of the email from 2008:

> Company in … is looking for a full time .NET developer to start as soon as possible. M leading edge technologies. This is a great opportunity for someone with strong VB.NET skills to come aboard a fabulous company.

Standard developer - minimum 2 years transactional website development experience on the Microsoft platform (don't need content/marketing web developers) Senior developer - minimum 4 years transactional website development experience on the Microsoft platform Experience with .NET 2.0/3.5 platform Experience with VB.NET and ASP.NET Experience with the AJAX framework Experience with writing SQL (Oracle experience preferred) Experience with data access through ADO.NET Must be willing to follow client's code standards and participate in code reviews Java script skills (basic

Nice to have experience

Telerik controls and other 3rd party software experience Database experience with SQL Server and DB2 databases Web farm experience (deployment and troubleshooting)

For new greenfield projects, ok. Sure if you're at an agency cranking out brand new projects for a new customer every few months, you probably should be using stuff that's fairly up-to-date (but tried and mature, not bleeding edge).

However, if you're maintaining and developing a product that has been successfully growing its customer base for over a decade, then you don't want to be just spinning your wheels rewriting it over and over in the latest hot new fad. That wastes time and money, adds bugs, and annoys the customers.

Integrate new tech as you can, along the way to providing new value or getting new customers, but don't throw the baby out with the bathwater. It's perfectly fine to still have 'older/unfashionable' tech in the system that's still providing value and helping the sales team to close deals.

Right, it really doesn't matter—until you are interviewed by a shortsighted manager in a hurry, which is all too often.

And isn’t it a good thing that that manager helped you realize not to waste your time with that company?

I see programmers are as good at judging whole-ass companies as hiring managers are good at judging whole-ass peoples

Which is to say, they are awful at it and will act like one observation of one characteristic is more than enough data to evaluate complex machineries

You tend to work for or around your hiring manager and that managers culture rather than the whole company.

> Using some older/unfashionable languages or maintenance-only frameworks indicates a lack of investment or interest in technology.

Not necessarily. Although many would consider C an older language, it's often the right language for the right job (e.g. network packet processing).

I perceive this as:

- There is always a need for low-level programming, and there is not as much development of new languages, abstractions, frameworks, and libraries in the low-level space. Indeed, most of the time you don't want any abstraction, framework or library between you and the low level thing you want to do.

- In the high-level programming space, there is a never ending race to climb higher and higher in the software stack. As such, all frameworks tend to be obsolete faster. Either it is replaced by the new high level hotness, or it gets stuck as a middle-level somewhere, below the new hotness.

Because of that, low level things don't become outdated as fast.

It could also just be that the population of Web developers is more prone to fads and churning framework after framework passing each off as serious technological innovation when they are typically just re-arrangements based on shifting opinions. So while, in this space, perhaps, “technology is changing all the time” but really it us just feverishly dog-paddling in place.

I see your point, but Facebook had large collection of code written in php(still is?), and they are far from having "lack of investment or interest in technology."

They are definitely the outlier and the version of php that fb uses can barely be called php when they more or less rewrote how it works under the hood.

But this isn't a dig at php, just stating chosen languages/frameworks matter a lot. I think it speaks volumes about a company's tech philosophy if they still mainly use php and jquery for web development.

What about if they use Java or C++ or Erlang for production code, rather than, say, Go or Rust?

The state of thr deployment pipeline and tests matters a whole lot more than the specific language.

To be fair back in the early 2000’s PHP was one of the best options.

And for many purposes, still is.

To your point they also, like, wrote their own PHP interpreter. If you asked your Facebook interviewer about PHP you'd probably get an interesting answer!

compiler

twice

The problem with this is that each person's definition of older/unfashionable differs. Some people think of java that way! And I would say they're wrong. Cobol on the other hand...

Yeah but when you are first starting out it really doesn't matter - what matters more is keeping interested enough to keep learning and growing from wherever you start.

It will affect who you become though - 'a java shop' vs. a Ruby-on-Rails start-up, say - what people think of you, or where you're hireable.

I at least glance over all the recruiter spam I get, and not much of it takes the 'language experience doesn't matter, transferable comprehension of fundamentals does' line.

It's not so much that there's a best one as a bottom five. There are in any given year a certain number that you should probably just avoid.

it's not about what language you're using

it's about what you accomplish.

that's in isolation of pretty much everything, even computers in general.

I might not be defined by Java but after programming in it since it came out in 1995, I certainly identify with it.