This seems like sage advice, especially in a time where people have become so focused on the developer experience and the software lifecycle. But for the sake of conversation, can I fish for an area of disagreement?

I notice that the WGID principle often gets hijacked into the strong version - let's call it the "Software is Just A Craft" conjecture. This version says that we've basically got software all figured out, and from here on out, everything is just different flavors of the same process. C for this, Python for that - it's just up to the craftsman to choose his tools wisely. To me, this kind of fatalism seems like the death of programming as a technology field. I don't know if it's a lack of imagination, or just getting too comfortable as a practitioner of "the craft", but some people seem to relish the idea that there can be no progress, only practice.

As a concrete example, consider Python's inability to use native threads. I see some people talk about this as a tradeoff, as if you're trading the performance of C for the convenience of Python in a zero-sum game. But that's just an approximation. Python _could_ have native support for threads if it was designed better. You could leave everything about its syntax alone, but just allow threading, if only the time was put into engineer it that way. Of course now, it's too late - we have too many legacy systems and too much code relying on how it was already built. But this is not the same as it being in a fundamental trade space. Python is just missing a feature, and now we know better.

It strikes me, then, that the level-headed "choose the right tool for the job" advice is really more just a way to be pragmatic in the here-and-now of writing software. You're not going to write a new operating system, language and ecosystem by the end of this week, so you have to realistically assess your options and grade them on their strengths and weaknesses. I just want to make the point that this is not core to the nature of programming languages and paradigms, just from wanting to build useful things on a schedule. But it has to be possible to make things strictly more expressive, strictly more performant, strictly easier to debug, strictly more portable, strictly... better?

That's pretty miserable, really. At least it pays reasonably well.

I've been programming since I was maybe 13, and being 34 today I find this to be more and more true. Programming IS JUST A TOOL to get something done. When I say "just a tool", I do not mean to ~undermine OR overexcite~ the concept of a tool. The real power to seek as a programmer is knowing lots of programming platforms and paradigms, as then you have the knowledge to select the best tool or technique to accomplish solving a specific problem within a domain at hand.

Sometimes that 'best tool' really just happens to be the one I have X years of experience in, because I'm here, right now, in front of the project, and have solved the same problem Y times before with acceptable results (systems running, people getting value as expected). That doesn't automatically justify being a stick-in-the-mud and never adopting any new technology ever.

But it also means that jumping to new tools on a semi-annual basis, you'll have a hard time having justified confidence you can deliver something of value. I have to qualify with "justified" because... I've seen too many folks who have confidence and... really shouldn't. And I recognize that because I can see how I was once there.

I had a call from someone in 2017 asking about something I'd built for them in 2002. System was still running. Someone had been doing basic system upgrades every so often, but they'd hit some logical issues and needed more insight, and pinged me. Last year I noticed a previous client project started in 2000 was still up. I've no doubt they've updated some of the back end stuff, but some of the stuff I put in place I can still see (html comment, semi-unusual url structure, etc).

Understanding that what you build might actually be in place, working for people for 15-20 years is hard to get your head around until you've actually done this for 20 years. When I was 20 I could not understand the ramifications of decisions impacting people or companies for 20 years - I just didn't have that life experience - no one at 20 does. We're often fed magical press releases about acquisitions and exits and we read stories of things shutting down, getting sunset, etc. Those aren't the norms though, I don't think.

With that in mind, my criteria for choosing the 'right tool' has shifted some in the last few years, and I'm always a bit more hesitant to jump on latest shiny trends, as... I do get somewhat concerned about the long term viability. That has to be a factor in 'best tool' calculations, no? (sorry for long ramble)...

The problem is it takes years to learn one tool, and it take years to see one case as screws, another as nails, etc.

EDIT: OTOH, as you gain more experience, you can classify problem better and look or even develop tools that solve that particular problem. Which is why angular / react / vue is developed and popular.

Somewhat. You can't become an expert in a matter of months, but by the same token, my PHP and Java skills didn't get demonstrably better between years 8 and years 9 of experience.

Other things outside the language got better. One was my ability to understand problems and potential solutions (from both technical and business/operations perspectives). Another was the ecosystems around those languages. Best practices, documentation and tooling all evolved to deal with new needs, new hardware, etc. The ability to adapt to those changes and understand the role of the core language/tech in addressing problems is key. Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself - you'll never know every single aspect of everything, so learn to accept that.

> Figuring out which new tools (or language features, perhaps) will bring the most value to you and your projects is as much as a skill as learning the language itself

Exactly in my view, programming language such as PHP and Java isn't tool, they are a set of tools. However the toolset are different between each programming language, let's say that in PHP the hammer has larger head than Java.

Let's say that programming features such as iteration (for / while loop) and conditional expression (if) are tools, that can be used to solve specific problems.

Well sorry if the analogy or metaphor isn't really accurate...

That helps for 'solo' stuff. Trying to introduce those ideas and techniques in existing teams is almost always more difficult than it should be.