How do I know if I’m good at programming?

I don't think there's any good reductionist way to measure how good you are at programming. There are a number of good programming principles that you can consciously choose to practice, and if you practice all of them, you are probably good at programming (not necessarily amazing, but at least good). SOLID architecture is a decent place to start.

If you need a quick self-check, though, one of my favorite questions is: "Do I understand why this code works?" or "Do I understand why this code doesn't work?" Anyone can write working code by accident (or by trial and error) but good programmers write working code intentionally. These questions are especially powerful when you're reading code written by someone who is much more experienced than you are. You may not know if you're a good programmer, but you probably know if someone is significantly better at it than you are. If you can understand how they got from A to B, you're one step closer to being as good as they are.

These are all good points, but when I think of what it takes to be a good programmer, I usually think about how your abilities relate to the tasks your trying to accomplish. Nobody is good in a vacuum. Not that the article doesn't make that point, but I'd like to go further with that.

I think being good at programming is an ability to understand the problem at hand and take the appropriate steps to solve the problem. More novice programmers don't quite have the ability to understand the current and future problems, and might not come up with the right solution, even if it is technically correct on some level.

Part of solving the problem has to do with the team's makeup. If you're on a solo project, your role and plan of execution is a lot different than if you are on a team of 20 working together on something. Understanding your own strengths and weaknesses, communicating them with the team and finding ways to be productive are all part of it.

Beyond writing extensible code in and of itself, being good at programming is about having developed the toolset to be able to take on a problem with your full creativity, and not be hampered by the basic "how do I even start to approach this?" questions you might have at an earlier level. When you are good, you can see a problem and develop a coherent path to appropriate solution, then execute on it.

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.

I think one of the best way to know if you are good or not, is to simply ask other developers if you are good or not. I would also like to point out that the article is really talking about construction of code, it doesn't really speak about being a good developer, software engineer, programmer, or whatever title you like to use. Code construction is only one aspect of a developer. One more thing, I think if you don't know if you're good, then you might not know enough. That's okay. It just means you should keep learning and absorbing as much as you can from different sources. You will reach a point where you can compare your work with others and know you have reached a level of competency you are looking for. Wishing you the best and keep learning!

I believe the mark of a good developer is four-fold:

(a) LEARNING: When you stop learning, you stop growing. No programmer will ever reach a point at which they no longer need to learn just as much as they did as a beginner. There are always new languages, patterns, paradigms, practices, interfaces, abstractions, and goals.

(b) TRANSLATION: The easy part is deciding what you want to do (i.e. "scrape all tweets with the word 'programming' in them). The hard part is deciding HOW to approach that problem. This can be thought of us "translation" - converting human thought into computer logic. The human brain and the CPU are inherently incompatible devices. The coder translates between the two by thinking like both.

I would say that TRANSLATION is the "coder's instinct" that is so important to what we do.

(c) CODING: The best code in the world is worth very little if no one can maintain it. The article you linked to summarizes good code very well for this purpose, I think.

Side note, CODING is why I have very little respect for certain people implicitly considered coding "idols" - reading their code is an exercise in futility. They're the only ones who can ever hope to really understand their own code, which is a mark of a poor coder.

(d) COMMUNICATION: It was Joel Spolsky who said that the ability to communicate is the single most important skill a coder can have, even more important than technical skills! I've found this to be true time and again.

A good communicator can engage in exchanges with other people that allow them to LEARN (a). They can understand human user needs, ask questions, and explain limitations as part of TRANSLATION (b). They can write, comment, and document god CODE (c).

A Word Of Caution: I have met coders who, while inexperienced and tripping along with shaky legs, aim for all four of these points. I would consider them GOOD CODERS, even in their inexperienced state. Indeed, one of these coders will accomplish far more than even a 20+ year veteran coder who lacks these skills.

Asking if you are good at programming is like asking: "Am I good at writing a book?"

There are many ways to write books. Some books are short and to the point, and might be considered well written. Others are long and considered epic and full of details and intricacies that make the story fun to read.

I would first ask: Does my code work? If yes, then that's good.

Then I would ask: How can I improve my development process?
If the tools you are using enable you to get your job done, then how can you make them help you with the little annoying things you do every day. How can you test your code to help keep yourself from going insane during a large code refactoring.

Then I would ask: Am I good at communicating my ideas?
Do people understand you when you try to speak technically about a topic? Do you know enough to talk the talk? If you don't, then you need to brush up on basics or read up tech blogs about your specific area of emphasis. Become an expert.

Always keep learning.

1) Do other developers read your code and not want to punch you?

2) CAN other developers read your code at all?

3) Do you look back at previous code and improve it if time/resources allow?

4) Do you feel like you're kicking [insert platform]'s butt?

If you answered yes to most of these, you're killing it ;)

Also agree with some of the other points listed here - it's hard to measure how "good" you are, but if you're comfortable in the environment, and your code doesn't feel like walking through the jungle with a machete, I'd say you're doing just fine.

A lot of things go into being a good programmer. But I will say that an enjoyment of solving problems with a technical bent is the primary ingredient to being a good programmer. Learning patterns is the (relatively) easy part, like buying tools for your tool bag. Knowing the proper place to apply those patterns is the hard part and comes with experience. In the process you may often observe others (or yourself) getting a shiny new hammer (pattern) and all problems start to look like nails, as the adage goes. It is part of the learning process. It helps you figure out quickly where that pattern doesn't work. :)

A good gut check for me - step into someone else's code outside your codebase but related to your domain. For example, step into the logic in an HTTP Client library, or an in-house framework that drives your code, written by teams of people. Just start in your code, but follow your IDE debugger into the unknown. Do you understand what the code is doing? Do you understand why it was implemented that way? I find that if I'm content in my piece of the product, and if I can't grasp the outside unknown, that I need to study, read, learn and seek mentorship from good people with good experience in that domain. It helps to travel outside your part of the ecosystem for a while. 🙌🏼

If you are competent your code will explain how it solves the problem space

If you are a good programmer your code will explain what the problem space is

This

$can_get_part_time_job = $age > 14;
if ($can_get_part_time_job) {
  ...
}

Over this:

if ($age > 14) {
  ...
}