The more you learn about "coding", the more you realize how much there is you really don't know. I've gone from BASIC and Logo, then BinkleyTerm BBS scripts, then COBOL, VB, Java, VB.NET, PHP, C#, F#, JavaScript, along with HTML, CSS, SQL (raw, but including Hibernate/NHibernate and Entity Framework) and a few specific DSLs (along with enough assembler experience with two different architectures to be grateful I don't have to make a living in assembler).
But am I any good? Good question. :) There is certainly "goodness" to be found in specializing and really learning things deeply (I can make Unisys COBOL or C# do pretty much whatever I want), and the linked article is good when it talks about how to structure code. IMO, it goes deeper than that. Your entire career, you will be encountering things you don't know. How do you take what you do know, and devise a solution for what you don't?
Let's take a practical example (one that I've encountered so many times I've lost count). What would you do if someone asked to you debug code in a system you'd never seen before, using a language you'd never heard of before the question? (because "hey, you're a programmer...") The answer to this reveals how you think. A person who is "good" at programming understands how computers work, understands development paradigms, and isn't afraid of code. Not that you answer the question with false bravado; don't promise something you can't deliver. However, the difference between "no" and "well, I've never worked in that environment before, but I'll take a look" is huge.
Of course, this is based off my experience, as a part-time freelance developer and a full-time developer for nearly 20 years in a "large air-based defense agency". Yes, you need to understand scale, Single Responsibility Principle, why the functional paradigm helps, etc., but what I've described is a deeper understanding of how you can get computers to do what you want them to do. The language is an implementation detail*. :)
* Not that these details are insignificant; as a "good" developer, you'll likely uncover these in your learning of the language.
** This is "good" at programming in general. I wouldn't answer a Swift job posting with "I'm good at Swift!" because I've literally never read a line of it in my life. However, if I were to apply for that position, I would explain my grasp of development principles, similar experience, and my go-get-'em attitude when encountering a new environment.
*** What I'm describing could be described as a "polyglot" programmer, but I think it goes beyond just knowing how to write the same line of code in [x] number of languages.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
The more you learn about "coding", the more you realize how much there is you really don't know. I've gone from BASIC and Logo, then BinkleyTerm BBS scripts, then COBOL, VB, Java, VB.NET, PHP, C#, F#, JavaScript, along with HTML, CSS, SQL (raw, but including Hibernate/NHibernate and Entity Framework) and a few specific DSLs (along with enough assembler experience with two different architectures to be grateful I don't have to make a living in assembler).
But am I any good? Good question. :) There is certainly "goodness" to be found in specializing and really learning things deeply (I can make Unisys COBOL or C# do pretty much whatever I want), and the linked article is good when it talks about how to structure code. IMO, it goes deeper than that. Your entire career, you will be encountering things you don't know. How do you take what you do know, and devise a solution for what you don't?
Let's take a practical example (one that I've encountered so many times I've lost count). What would you do if someone asked to you debug code in a system you'd never seen before, using a language you'd never heard of before the question? (because "hey, you're a programmer...") The answer to this reveals how you think. A person who is "good" at programming understands how computers work, understands development paradigms, and isn't afraid of code. Not that you answer the question with false bravado; don't promise something you can't deliver. However, the difference between "no" and "well, I've never worked in that environment before, but I'll take a look" is huge.
Of course, this is based off my experience, as a part-time freelance developer and a full-time developer for nearly 20 years in a "large air-based defense agency". Yes, you need to understand scale, Single Responsibility Principle, why the functional paradigm helps, etc., but what I've described is a deeper understanding of how you can get computers to do what you want them to do. The language is an implementation detail*. :)
* Not that these details are insignificant; as a "good" developer, you'll likely uncover these in your learning of the language.
** This is "good" at programming in general. I wouldn't answer a Swift job posting with "I'm good at Swift!" because I've literally never read a line of it in my life. However, if I were to apply for that position, I would explain my grasp of development principles, similar experience, and my go-get-'em attitude when encountering a new environment.
*** What I'm describing could be described as a "polyglot" programmer, but I think it goes beyond just knowing how to write the same line of code in [x] number of languages.