Are you a Good Programmer?
It's natural to wonder if you are good at what you do. And if you write computer programs you wonder if you are a good programmer. Well let's find out.
Before we can get too far answering that question we must ask ourselves: what does it mean to be a good programmer? It could mean that when you write a program it is always in an ideal state when finished. But we all live in a society with limited resources with limited lifespans so the ideal state is unlikely to be realized. Instead we aren't just coders, but programmers. We have to make decisions on where to allocate our resources. So if you allocate your programming related resources efficiently are you a good programmer?
The Idealized State
What does an ideal program look like? An ideal program has no bugs, has all the features needed, is easy and intuitive to use, the code is clean and easy to read, it performs well enough to meet its goals, and the code can be modified easily and without introducing unexpected bugs. There are certainly more facets to a perfect program but this should be a good enough starting point for figuring out if you are a good programmer.
So let's say you wrote the ideal program, are you now a good programmer? Given an unlimited lifespan without resource constraints, definitely. Or given an open-ended project that nobody cares how long it takes to build, then again, definitely. But the rest of the programs we write are constrained by time and/or other resources. So to find out if we are a good programmer we must analyze our allocation of resources, and that's where things get tricky.
You can write the perfect program but if you take longer than necessary or use up too much of the budget you might not be a good programmer anymore. A good programmer knows how to navigate and make decisions based on resource limits, human interactions, and the human disposition. So being a good programmer means writing the best program you can given the constraints you are under and knowing when and how to push back or extend those constraints.
So a more concrete and useful question we can ask ourselves is: how close are we to the idealized state and what can we do to get closer to it? Maybe that means refactoring the code or slowing down and being more careful or maybe we have fantastic code but we will never implement the required features in time. Wherever we are it's important to always be mindful of it and be thinking about how to improve upon it.
And it's critical to remember that being good at writing code is not the same as being a good programmer and that most of us writing code also need to be a good programmer.
It's natural to want to compare ourselves to others. So does it make sense to compare our programming ability to others? Possibly. Maybe it doesn't matter to you and I'm sure that's fine but maybe it does matter to you because you want to use it as a metric to know how you can improve or maybe you work in an environment where your programming ability  will be compared to others. This is fine but again it is important to keep resource constraints in mind. And that resource this time is yourself.
Everyone is different and has different capabilities. So while it might make sense to compare yourself to say a co-worker it is important to keep in mind your differences otherwise you may start grasping at straws you can't reach. Maybe they just have a more analytical mind which helps them develop better engineered programs than yours but that's ok. As a bettering programmer you will ask yourself "how do I get closer to that idealized state?" When you do that you could answer: "I need to get a more analytical mind" or probably better "I should consult them when designing the architecture." There are probably areas related to achieving the idealized state in which you are stronger than them as well and it's important you know what those are and exploit them. But like most comparisons in life it's probably healthiest to compare within your own capabilities. It's possible that you just don't have as much capability as them, maybe you struggle with a physical or mental illness, or your brain is developed with other strengths so instead we direct our focus on improving oneself regardless of where others are at.
If we are trying to reach the idealized state it likely means one needs to continually develop their coding skills. But having well developed coding skills does not by itself make you a good programmer. A good programmer also develops the other skills needed for reaching the idealized state. Many of these are soft skills that just take time and experience.
It makes sense to develop your skills by, at times, focusing on different things, like to help yourself know what good code is one needs to study it and write it. We can't always write the best code but we need to know what to aim for.
Since our goal is to get as close to the idealized state as we can, and we likely won't ever reach it, we are never really as good of programmers as we could be. And that's the most important point. We are all varying degrees of good and there's always areas in which we can get better. So how does one become a better programmer?
The first step is in figuring out what the idealized state is and where you are in relation to it. If you had unlimited resources what would the program look like? How would the code look? How would people use it? Then we must assess our options given the constraints we have.
Often a resource is set to minimize, like time. We are told to get something done quickly or in a small amount of time since there are so many other things to do. And again looking at our idealized state is critical because rarely does that mean that time (or money) is truly to be minimized. What people are really saying is that given some assumptions about the future use and development of the project get it done as quickly as possible while still reaching some level of the idealized state. So the trick here is to figure out what level of the idealized state they are really asking for.
To become a good programmer one must practice and improve their skill of sussing out the level of idealized state someone, or yourself, is asking for and the skills for reaching that state.
Are you a good programmer? Are you good at figuring out the required level of idealized state? Are you good at exercising the skills required to reach that level given the resource constraints? If so you are probably a good programmer. If not, you're just like the rest of us: getting better at it.