[joha4270]

Could you expand on what

> conversationally fluent in the theory behind writing code

means?

It might be my insufficient command of the English language, or I might be outing myself as being outside said group, but I'm unsure what that means. Is this just referring to a vocabulary for discussing the structure and creation of software, or is there a deeper mystery I have not yet grasped?

[ajkjk]

I mean that if someone asks you questions about code, you can respond intelligently and "think on the fly" about the subject in question. For instance you haven't just memorized something like e.g. the big-O time to access a hash table, but you have reasoning behind it: you know how it works in a few cases, your knowledge about it comes from an understanding of the implementation, and you can extrapolate that knowledge to new cases or variations of the problem, etc. Maybe your knowledge ends at some point but you could keep going if you had to: like maybe you don't know how hash tables interact with page tables or CPU caches but if that starts to matter you would be able to understand it and keep going.

The same way of thinking applies to design patterns (single responsibility principle->but why, and when is it okay to break?) or to architectures (OOP / dependency management -> yes but why? can you make a version yourself? can you work around problems with it?) or to libraries (React components->what are they trying to do? how do you keep that contract simple?) or to languages (JS->what are the tradeoffs? what features do you need? how important is upgrading or polyfilling?) etc.

All beyond-basic intelligence takes this form: not memorization but having a working understanding of how something operates that you can use and apply to new situations and investigate and drill into and wieldy flexible. I would call that "fluency". To be conversationally fluent in a subject is not necessarily to be an expert but to be able to "think" in terms of the concepts, and usually it means you could become an expert if the situation demanded it.

[darkerside]

This is much more basic than what I thought you meant. What you're outlining are critical thinking skills. And I agree, lacking them makes a programmer far less valuable.

But there's a whole other level of fluency around the theory of software development, and it comes from experience with different architectural patterns, and being able to see into the different futures of each architectural pathway,and being able to converse with other people who understand software at this level.

Although, calling it a level really undersells it. Multiply the potential capacity for this talent by every dimension of software building, and you start to see how people having even a little of this skill, but being able to work with others who have a bit of it in a related dimension can form a team that is more than the sum of its parts.

[TheHegemon]

Yes, the ability to have critical thinking skills is the key differentiator between the two types of developers mentioned.

I think that is what a lot of these discussions seem to be miss: the issue is not really the hard tech skills/knowledge. It is more about the softer critical thinking abilities or personalities that allow someone to become skilled at something or solve a problem easier/better.

[ajkjk]

I agree, I was quantifying with some examples off the top of my head, but I do mean 'this skill, but for everything'. Architecture is certainly a big part of it.