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

The best advice on the profession that I was ever given was simply, "Learn to learn."

The vast majority of this profession is just being interested in figuring out how to solve different problems. Sometimes that means it's all you and sometimes it means learning new things or doing research.

You know that you are not a good programmer when you don't see any problems that need to be solved.

The first is the “rockstar” developer type who is great at prototyping, hitting deadlines no matter what and delivering functionality, albeit full of bugs. They will write 80% of the code and will drive the support team up the wall by breaking the build, causing customer issues in production, security holes and basically seriously degrading the code base. But their boss will love them because they deliver the shiny when required.

The second type are the ones who can sort out the mess created by the first type without making things even worse. They tend to be less visible, less well paid and less in demand but every company needs them.

The whizz kids and the grown-ups basically. Companies who only have the first will burn bright but not be able to scale. Companies who have only the second type tend to move too slowly to get to market or pivot.

So ideally there is a symbiotic relationship between the two types and someone who is a combination of the two is very rare indeed, because the first either needs an ability to place limitations on awareness of the big picture (and it’s very difficult to create a blind spot on demand once you have experience) or they need to be incredible at both analysis and full stack execution. Those people are few and far between so a process that gets the best out of the two types is, in my experience, the way that most companies work.

You don't have to be "good". You have to solve the right problem efficiently. Find the right problem and be the solution. If you need to write a program, make an easy one. Easy to use and easy to maintain. You'll get what that means after a few years of maintaining. Nobody ever cares if you're a "good programmer" or how you feel about yourself.

Ideally you walk the line between them both. Personally, I'm in the former camp, but I'm more a business owner than a coder, so deliverables are more important than the best programming methodologies. It depends on what the priority of the business/department/team is.

A problem is not only defined by stuff like the core routines of the program, but also everything surrounding it, like the structure of the code and of the program as a whole, the environment the program is supposed to be running in, and how to collaborate or manage the other people who are working on the program. Though at this point it's probably better to use a broader term like "software engineer".

A programmer who has enough experience across the whole stack for a certain problem is going to be able to deliver good, readable and efficient code in a timely fashion.

Likewise, they also tend to produce more desirable side effects - things that maybe weren't described in the spec but are a noticeable improvement (e.g., responsive UI behavior)

In security and high-availability related environments – where I've spent most of my time – it is important that you validate all ins and outs, system and function returns, check if writes succeed, in short, not unlike a chess player, to be able to fit all possible moves and scenarios that could go wrong inside your head. You probably need to naturally possess a mind that is precise and can find all loopholes.

Another way is to see efficiency through layers of algorithms and realities of real-life systems. Universities focus too much on mathematical formulas in my opinion; real systems are not clean and simple like a math function with few variabes. To understand by experience where complex systems with remote databases, shared disks and network can go wrong and write code that foresees, prevents or deals with unexpected complications is an important skill that sadly enough is hard to quantify on a resume. A lot depends on experience and knowledge, but you need to have interest and curiosity to get there.

And finally, you have those programmers that can create a more-or-less working mock-up in mere hours. In my experience, those are not always the people that want to spend a year ironing out all the bugs, but it is a valuable skill to be able to adapt and churn out something fast and iterate on it. Dare I say, the Javascript mindset. You probably need to be pretty enthusiastic about new technologies and quick on your feet.

To find not only a motivated person but the right "type" for a job position is probably not an easy task, just as it is hard for a programmer to find the right job that fits your own particular strengths and way you like to work. You might be a good programmer, but end up in the wrong environment. If you are a thorough and perfectionistic person, you're probably not going to be happy in a mockup-a-day start-up.

Along the way, you'll develop a curiosity about solutions other people developed, so you'll read code more. Simultaneously, you'll develop curiosity about different tools, e.g. programming languages. This will lead you to explore them more.

It's all enjoyment feeding curiosity and lots of practice.

I'm watching my daughter's friend become a great basketball player. She's not inherently great at the game. She loves it and practices several hours daily in a disciplined manner. When it rains she puts on rain gear to practice. When it snows she shovels the driveway to keep practicing. She carries a notebook everywhere to diagram plays when she thinks of them.

Great programmers practice even when no computer is in front of them.

Being a good coder is different from being a rock star coder. In fact, rock star coders can be terrible coders and yet have large followings. Most rock star coders became popular through blogging, tweeting, hacking and/or writing trivial software modules that are widely used. Coders who work on difficult problems don't usually become rock stars.

The one and only metric is: how quick do you ship. I know what you think: this leads to unmaintainable code. That is wrong because a programmer who produce unmaintainable code doesn't ship quickly, by definition. Thats because programming works by iteration, and then it doesn't matter you can ship one iteration quickly, what matters is that you ship iterations quickly, over and over again.

Now, the game is simple, you can do two kind of mistakes: you can ship too "quickly" by writing rushed code, or you can ship too "slowly", by writing over-engineered code, for a given iteration. If you rush one iteration, you will have technical debt for the next iterations, and if you over-engineer one iteration, you are wasting time AND you are piling supposedly well written code which has no value and gonna stand in your way on later iterations (it always do, thats what level 2 programmers dont get). Of course, and thats the best part, programmers in practice tend to do both mistakes, which confuses them squared: they have a fair amount of technical debt in an over-engineered codebase.

Programmers in their career though tend to first do mostly rushed code (level 1 programmers) and then they do over-engineered code for the rest of their life (level 2 programmers). So you know you are a good programmer when you know what over-engineered code is.

Is the code readable?

Sorry this is just way to subjective. What you want is a code that's easy-to-learn. The difference? Easy-to-learn is really powerful while "readable" is not. That's because programming doesn't happen on your screen, programming happens between your ears. But first, a spectrum again, at one end you don't know anything about the code you have in front of you which means you cant do nothing; at the other end, you know the whole source code in which case you can do everything: fix, rewrite, extend, debug, run, anything.

A code that's absolutely obfuscated by all standard isnt easy-to-learn, so dont worry, yes "readability" matters of some sort. But a super readable code can be crap too, because it can just be as obfuscated as the former, it's just another form of obfuscation: flood.

A code written to be easy-to-learn means it has been written to help you getting closer to "you can do anything in the code" as quickly as possible. And guess what, the closer and quicker you are from being able to do anything in the code, the faster you ship. Rinse and repeat.

Back to programming, I feel that web development gets more credit, and as a web developer I can say that most of the development is just boilerplate configuration, made complicated by layers upon layers of unwanted but unavoidable complexity. On the other hand system programmers and game developers do more hardcore programming stuff, but may not be as much recognised outside their closed community.

So in other words depending upon the domain, a good programmer might mean a person who can figure out the configuration better and keep things nice and tidy (read 'standard') while at some other domains it might mean hardcore analytical capability and number crunching..

Coding is not enough. Is your code maintainable, interoperable? Did you ship?

What are the priorities of the project? Is your code formally verified not to have bugs? ETH just had such a bug. Has it been tested at scale? Twitter used to have fail whales.

Does your product have a community? Do you manage teammates well?

People live lives, companies build products. Ask yourself, "is my company building a good product?"

To me, someone who is "good" is just someone who has learned the language and main paradigms / tools for it, and can pick up new stuff fast. It's like a native speaker of English who can understand what you're saying and write a book on a new topic that goes over well.

Good means less bugs, maintainable code and playing well with others.

But you can know if you're bad at it. It's kind of like testing and other forms of QA in software -- usually they can attest to the presence of bugs, but not their absence.

If you find yourself not falling into the pitfalls of a bad programmer... odds are you're not programming enough but if you are doing it and avoiding those pitfalls, you have a chance at being considered good. If you have enough self-awareness to watch out for pitfalls you might fall into and avoid them in the future, you will become better than you are now. And that's really all I can promise you.

That can be difficult on the Web.

When learning electronics searching the Web for help quickly showed how useless it is. There were many explanations but no teaching and often the explanation begun at a level too far past the level of the question asked.

My guess is well over 95% of explanations I saw were just people posturing to show off their knowledge. Wordy explanations that went on for paragraphs never teaching just saying things.

I craved brief answers that taught not explained. I know 2+2 = 4 but how do you know that how do I learn to know that!

Meanwhile, there are countless grateful, happy customers who think the kid who slapped together some PHP templates hosted on a slow, insecure $2/mo shared WordPress host is a genius rockstar. This is a more defensible position; it's just also a landmine if the business grows a lot, because any mass of PHP has a limit of how much complexity it can absorb before breaking.

Enterprise customers are particularly hard to generalize over, because each enterprise's software is like a factory, where all the equipment is totally custom made, with all kinds of quirky weirdness that may be part of the secret sauce that makes things work, and no-one really knows if it is, but just keep things working. (Actually it may be larger than a factory, including multiple factories and some supporting supply chains a la Shenzhen).

If some % of changes you make to your code are towards a simplification, I believe you are on the right track.

Not so good programmers fix their assumptions (because they need some ground to stand on) and then let a project ossify - these become legacy systems, burden, technical debt, and so on.

Another angle: A good programmer will save you from problems you didn't even know you are going to have (and you will probably never noticy it, because she or he will have your back).

Yet another take: A good programmer will find a solution to a program which is either perfect or not perfect but so clear, that another person can use it as a basis for a better solution. A good programmer shortens the way to the things you want to achieve, in any way (perfect solution, good solution and clear problem picture, communication, better documentation, explanation, more performance, rethinking, disruption, calm night shifts, and so on).

Besides: Programming and development is actually very hard, many brilliant and curious minds haven't searched for another occuption after they started programming.

Did you get a computer science degree? Did you land a job at a good company to write code after an extensive interview? Have you been able to keep that job for a few years? Have you written code other people find valuable? Do other engineers you respect commend you on your contributions?

If you've answered yes to all of the above or at least some then congratulations you're a good enough programmer. If not then there's room to grow and you can become one. Either way I laud you in your choice of career. It's a good one, and there's no reason to be handwringing about where you fit in the spectrum of engineering skills.

Just always be learning.

Who cares about good code ? good code doesn't mean anything, the only thing that is important is working code. If your program works but the code is not "good" people will still use it.

A good programmer is someone who is able to write code that works

> Is the code readable?

Readable code may not be good code. More readable code almost always means less efficient code. Readability is a trade off.

> Is it easy to extend?

Changing requirements are a thing for sure. But in almost every cases I came across, planning for shifting requirements always misses the point. It is much better to stick to your current requirements and keep your code simple, than introduce things that complicate your code for requirements that may or may not happen. Extending simple code is simpler than undoing code and replace.

> Is your code efficient?

It's very hard to self determine whether one own's code is efficient. Almost every one will think their code is efficient.

> can you write it quickly?

Again people tend to think that they are fast at writing code whatever their actual speed.

-- the reality is that it's really hard to qualify good or bad code. Self assession is particularly useless.

A programmer who thinks that they are bad at programming is almost certainly correct.

On a team, one of these people is more dangerous than the other. Knowing which is the greatest wisdom.

If the problem is a common one and nobody else is able to solve it people will use your code... even if the code isn't good.

If you want to generalize, follow the 80/20 rule - 20% of the effort results in 80% of the benefit. Think like a business owner. Identify what the one or two key metrics are and come up with ways to efficiently ship ideas to test to improve them. Write code that is easy to test. Add high value tests. Avoid perfectionism.

I've observed that especially correctness is the main line that separates a master programmer from a mediocre one.

If you are constantly making errors and not testing properly, not checking the integrity of your data, etc. You are just mediocre and are probably being held at your position against your will.

Software development is hard. Unlike many other building tasks that humans run into, software is rarely "done". Launch of software for most of us means the code we've written has just been promoted to a point where now it's important, and will likely be what we work on for the near term future.

So, what makes a good software developer? Generally, programming's the smallest part of that puzzle. Working effectively with others ranks up there. Business acumen. Communication skills, both written and verbally. Understanding release cycles, revision methods, standards, etc. All the things that developers don't want to care about because they aren't writing code, those are the things that make good software developers.

What.

There is one rule I try to go back to, especially when work starts to pile up and things fall by the wayside. YAGNI.

First, it is far too broad. What does "good" mean? Good enough? The opposite of bad? Compared to whom? And even "programming" is a ridiculously vague thing-- everyone who has worked even a year in the SW development profession will know that programming is only part of the job and that there are many different roles, many different kinds of skills.

Next, what is the intent of even asking that question? What can one do with "the answer"?

Also learning from someone better than you will help you get better at least 10x more than practicing yourself.

Computer science is a branch of mathematics and it is all about solving problems on whiteboard in front of peers.

- It keeps workings

- It's not hard to explain to a new team member how

Then you are an excellent programmer.