[rramadass]

Not to be snarky, but this is just a oft-repeated platitude by the "Management" types who do not understand the psychology behind programming. Given the synergy between language and thought expression, mastery of a language is what will help you solve a problem and add value. If you just have a cursory knowledge of the language you will never get anything done.

[gregjor]

I've been programming professionally for 40 years. Sometimes I'm in a manager or hiring position, but mostly (as a solo freelancer) I'm working directly with customers and solving business problems, using programming skills.

I'm very familiar with the psychology of programming. Read the classics: Weinberg's The Psychology of Computer Programming, Tom DeMarco's Peopleware, Brooks' The Mythical Man-Month. Notice that those books are all about programming but not about languages. Alistair Cockburn studied programming success and failures and concluded that team dynamics -- "soft" people skills -- are a first-order driver of project success. Brooks came to a similar conclusion.

Mastering several languages well enough to produce working code and (more important) participating in a team and business organization is a necessary precondition to calling yourself a programmer. But language mastery is not sufficient for long-term success (many of the languages and all of the tools and platforms I worked with in the 1970s and 80s are extinct today), nor is it sufficient to contribute at a senior level. By analogy a person can get through life just knowing how to hammer a nail, but they aren't going to work their way up to architect doing that, and eventually they'll get replaced by a nail gun.

[rramadass]

>Sometimes I'm in a manager or hiring position, but mostly (as a solo freelancer) I'm working directly with customers and solving business problems, using programming skills.

I think this explains why we seem to be a little at cross purposes :-) Your job requires Programming but you are not "just" a Programmer (you are a one-person company). As i interpret it, "Programmer" is a specific role within an organization which demands more of technical skills and less of others. Their focus is to design/implement a module within a larger system and not bother about Customer Relationship, Sales etc. which are no doubt, important facets for a company but it is not their role to play (Brooks says the same thing with his "Surgical Team" metaphor). Most "average" people have enough innate "Soft Skills" to function in a team working towards a common objective which is usually sufficient for a programming role.

[gregjor]

I have solo freelanced for a little over a decade. The prior almost 30 years of my career was mostly spent in cubicle farms with other programmers. I started programming professionally (meaning I got paid to do it) in 1977, to give some context. I started programming for free, on my own and in school, in 1974.

One thing I learned early on, thanks to some good mentors and managers, was that expanding my interests and skills out of programming would improve my chances of surviving a layoff or getting made obsolete. The most recent incident, at my last full-time job at an educational software company, illustrates that. Most of the programmers I worked with limited themselves to a couple of programming languages, hated meetings, did not interact with marketing or sales or management except under duress. When the company's fortunes turned and they started laying people off, I survived. I actually asked the CEO (my two direct managers had been laid off) why more senior people had lost their jobs but I hadn't. He told me that I was the only programmer who had taken an interest in the business, could work with marketing people, and had expanded my skills when needed (I had to learn enough Lisp in a hurry to deal with a product the company bought and had to integrate, no one else volunteered).

I've had similar experiences in my career, and I attribute it to being that one person, or one of a small number of programmers, who took the opportunity to learn the business domain and contribute in ways beyond just writing code. I survived at another company that replaced a lot of in-house code with a Salesforce-like product, probably because I was one of the only people in the programming group who didn't crap all over and moan about the management decision (I actually pointed out that our backlog of technical debt evaporated when the company moved to a third-party solution).

I still write code most of the time, but my customers (most of whom I've had for 3 years or more, a couple for a decade) tell me they appreciate that I take an interest in their business and help them solve business problems, rather than just telling them that rewriting in Rust or whatever will solve everything, which most managers have heard (or tried to do) enough times by now to show some caution.