Ask HN: As a programmer, how do you know if you're a good one or not?

Do you do any of the following things?

Start a project by "hitting the ground running" and writing code. Fail to write documentation unless under external pressure. Deeply aware of the powerful and superior features of your favorite languages. Have a considered view that long term systems maintenance irrelevant to most software design. Frequently roll performance optimizations in to your code.

If so, you are probably a bad programmer.

1. read others code. think. ask questions. why and how certain code is written in certain way.

2. Read more code.

3. Write more code.

4. If your code which you wrote few years back looks bad to you, then you are on right path.

5. How much you understand the core concepts. New languages and frameworks are more of an glitter.

6. You want to be better version of yourself, then your progess is your stats you need look at. How many books did you read year on year? How much code you read year on year ? How much code you wrote ? How much fun you had :)

7. Adding, if you can think of the future maintainer of your code in mind and code, then you are lot better than many programmers out there in business.

8. Try to be a clean code enthusiast.

Easy, I know I'm a bad one

The more experience I get, the more I realize that I'm pretty average.

I knew I wasn't very good when I worked as a programmer. I based that on watching others, and how often I could figure out problems without asking for help. I could see I was waaaaaayyy behind even the newest people around me. That was a long time ago, I'm still in IT, but not a coder now. I do ok with the basics still, but I ask for help all the time.

Does my code still make sense to me 6 months later?

Did I introduce new bugs?

Are people using my building blocks to add features or working around them/ redoing them?

These are not good metrics. I have researched this and it seems there is no good way to measure coding improvement except subjective measurements.

Depends on how you measure it, if you gave me a programming test that measured how much i knew and if i knew the intricacies of a language and memorised the manual, while also testing me on computer science questions that only get talked about in universities, then i'd probably perform poorly.

However, i'm a get shit done developer, while i've been doing this 14 years and know my area very well, i dont know it nearly as well as someone who has rigorously studied it and has been doing it for only 3-5 years. What i can do is deliver, and thats whats valuable to businesses.

So, is "good" an academic measurement or a business one? Its all context.

If you can manage to stay interested in what you're doing, you're going to learn and improve over time.

If you lose the passion, and get bored with what you do, you're not going to care, and that's a worse fate than even staying still skill-wise. It's a very common fate for those who have to work at this 8 (or likely more) hours a day, nearly every day of the week for years or decades.

So I'd just try to keep the flame alive, focus on always doing what you genuinely enjoy, and not sweat the rest.

How do you define "good" and "quality"? This is the difficulty in measuring skill or productivity in this kind of work. Is it the number of uncaught bugs that have been released? How well what you produced matches with what the askers (product mgrs, customers, etc.) asked for? How much test coverage you have?

As others have suggested, it's useful to look at code that you wrote 3, 6, 12 months ago and ask yourself: do I understand this? Could I write it better now? What would I do differently now? You might try keeping track of these reflections in a journal.

If someone pays you a lot of money to program and are happy with the results.

I put in the work. I once heard a very good fencer say that the way they keep calm during competitions is to tell themselves that they've put in the hours of training and the blood, sweat and tears necessary to win. I spend hours of my days writing code, reading about how to become a better programmer, constantly analyzing my work and finding ways to improve. I'm not going to spend my time worrying about whether I'm a good programmer. I will be a good programmer.

This is a very complicated thing to answer concisely, but I'll take a stab at it from a product development perspective.

You know you're a good programmer if the things you build "just work." It should be near impossible to find flaws in your solutions. This is actually rare. Most developers I've worked with will declare something "done" well before all of the flaws have been worked out.

If people are explaining stuff to you all the time, you're the dumbest guy in the room.

If you're explaining stuff to people, you're the smartest guy in the room, and you should find a place to work where you're the dumbest guy in the room.

My favorite definition of a “good” programmer is someone who ships! Done is better than perfect. Knowing what compromises to make in order to ship without creating a future nightmare.

Try leetcode the hard ones

I find as I get more experience I realize my limitations as a programmer so I can predict much further out where I'll run into trouble. It usually ends up being avoiding bad architectural choices, avoiding bad abstractions, avoiding introducing bugs into code that works. It's easy to spot a bad programmer, I find that a lot of the time a good programmer will be known for their faults in other areas (ie. Bad communicator) but people take their skill for granted. And then there's the rare programmer who can solve things that others can't understand. There's way more bad programmers than star ones, but my guess is a lot of people here fall into the good not great category unless their track record is exceptional. A lot of people try and fail early, much like companies, so if you've been in the game for a while it's a good indication.

Programming is an open ended non competitive (generally) activity. I don't think there is any meaning in trying to quantify "goodness" and in fact might blind you to possibilities.

So, for myself, the thing I pay attention to is my ease of expressing the things I want to create. I also pay attention to my ability to produce things with certain "qualities" correctness, simplicity, and how modular and composable my code is. There is no objective measure of those things and my understanding of those things constantly expands. I learn these things through by my own experience and looking at what other people are doing and having in depth discussions about programming ( and outside of programming ).

So I have no idea how good I am, but I have confidence in what things I can create and confidence in my ability to learn more.

This can only be answered with context.

Someone may or may not be a good programmer depending on a whole bunch of factors, the project being built, their familiarity with the codebase, familiarity with the technologies used, how happy they feel in their job, how happy in their personal life, if they really like the project they are working on, whether they get time/space to concentrate. It goes on and on.

There's no answer to "is person X a good programmer" within context and even then it's purely subjective.

You're asking the wrong question. You should be asking "Am I an efficient or effective programmer?"

  Do I get things in on time / under budget?
  Do I avoid common programming pitfalls?
  Do I solve more problems than I create?
  Do I see simple solutions to complex problems?
  Can I refactor terrible code to more easily maintained code?
  Can I avoid terribly written code in the first place?
  Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?

Then you know you're effective when:

  You're asked for help often.
  You're the go to person by the boss.
  You're often asked for your opinion for engineering decisions.
  Your opinion holds weight with others.

    Does my code make people feel good?
    Does it automate some user task?
    Does it make some user task easier?
    Does it amplify users' powers?
    Does it create value, by my definition of "valuable"?

Check out: https://github.com/mtdvio/every-programmer-should-know

Somewhere I read a measure of intelligence is: the ability to achieve your objectives efficiently. You could say the same about coding. Are you achieving your coding objectives efficiently?

> But as a programmer at work, I often receive feedbacks from 1 or 2 persons at most

Oof, yeah, that's rough. It's hard to say something conclusive with little data, and most of the data is likely biased (yourself). I'd recommend finding opportunities to work with other devs. Open source is a good path forward.

Otherwise, estimating your performance is super hard. Are you right more often than you're wrong? When you're wrong, do you consistently fix your flaws? Are you learning? Are you contributing more and more business value? These are all very opaque questions, and even if you answer all of them you're likely to have gaps.

Get more data!

If your employer is happy with your performance then you are probably "good enough" as you say.

However if you truly do always want to be improving your ability as a software engineer, then you are in luck, this field is so vast and deep that you can easily spend more than a lifetime improving! Finding out how and measuring it is another matter.

Would you hire yourself?

When you maintain a piece of code, that only you have written, for a couple of years, and making changes to it is as easy as the first day, then you're a good programmer.

If every change to the code feels like adding another twist to the maze, then you're not a good programmer.