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

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.

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.

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.

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

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.

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.

Programming is a craft once you reach a certain level their is no checklist or metric that can be used to measure you ability. Only experience and battle scars tell how good you might be when solving the next problem.

Only ever measure yourself against yourself. As long as you make sure you are a better programmer today then yesterday then you have nothing to worry about.

Easy, I know I'm a bad one

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.

There are many ways to quantify how good of a programmer you are.

- You can compare yourself to other developers (there are plenty of qualities to compare)

- You can review your statistics (commit frequency, average file size, accuracy of time estimates)

- You can compete in programming competitions

- You can evaluate yourself using the Programmer Competency Matrix: https://sijinjoseph.com/programmer-competency-matrix/

Also, "Good" is subjective. Some programmers are "good" in certain contexts, but "not good" in others.

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

I wouldn't describe myself as a programmer, but I have spent a considerable amount of time and energy thinking about how to become 'better' as a data scientist (as well as how to encourage others to grow their skills and knowledge, and how to measure that growth). So, I can share some tips about learning in general (i.e. metalearning--"learning how to learn") that should apply no matter your field. If you devote yourself to (effective) learning and improvement, you are as 'good' as you can be, and that is what matters.

1. People learn best by a) effortful 'doing'/practice and b) spacing that effort out over time. (Actually, not just people...almost every organism seems to learn more effectively this way.) Generally, the marginal benefit of learning time is greater when you expend effort directly applying knowledge/skill to a difficult and meaningful, rather than ingesting the output of others. An hour spent solving programming puzzles is more effective than reading an hour of others' puzzle solutions. 10 hours spent doing either is better spent if it's spent as [10 x 1hrs] vs. [1 x 10hrs]. Spend more time working on side projects that motivate you, solve book problems, solve coding challenges, practice explaining a technical concept to someone, etc. Spend less time gliding above the vast wilderness of what there is to know, observing the work of others--hit the ground and blaze the trails yourself (but don't rush it).

2. Programming, like data science or research or basketball, is not really a discrete skill you can directly improve at. Each is composed dozens/hundreds of sub-skills, and mastery of the field is a lifelong endeavor of building up these individual skills as well as connections between them. What strengths form the core of your identity as a programmer? What about areas for improvement? (relative to what you want to be, not compared to coworkers/HN folks/world-experts)

3. If you find yourself sharpening the same swords again and again (as I have), then look for an area of both weakness and interest to reallocate effort to. The learning benefit per unit of time is greatest when you spend it on something in your 'zone of proximal development'--not too easy, not too hard, not too irrelevant, but just right. Sometimes, this may mean diving headlong into the difficult thing you believe you "should" know, but have been avoiding. Other times, being "better" at your field means improving at something that seems tangential (communication/presentation, documentation writing (!), time management, domain knowledge, mathematical skill, whatever). Just don't fall into the trap of 'oversharpening'--expand your arsenal.

4. Teach/communicate what you know to others. Interact and network with others both at, above, and below your general level of experience. This not only helps solidify your knowledge into something permanent, but incidentally is one of the best (only?) ways to be perceived (rightly or wrongly) as knowledgeable. You don't even need to do this 'for real' for it to work--I imagine myself explaining code / mathematical concepts to some imaginary audience, whether it happens or not. And if it does, you'll be prepared...(While backpacking in Yosemite recently, I encountered a professor that asked me to explain a ROC curve to him. Another time, I awoke on the train to an elderly lady, seeing the title of book that I fell asleep on, asking me what a stochastic ["stoychistick"] process was.)

5. Beware that the 'better' you become, the more inferior you may feel. Climbing higher gives you an unobstructed view of the yet taller peaks in front of you, and the canyons blocking your way. Remember to take pride in the struggle.

This is a general problem.

In sports, for most people, staistics are meaningless. I climb 5.10 okay... am I good climber? I'm not world class, but I do stuff that I like.

I've been an academic. I know I was a bad one, because in retrospect I had to step away from a lot of my ideas and research... at the end, I didn't see value in the projects I was doing.

As a programmer... who knows. I don't usually have a lot of problems coming back to old projects and building new stuff. I don't have a lot of systems I put together breaking down and requiring work. I know that there are at least 10-20 other folks think I am good, because I've solved things for them and they have told me I am good.

But I just build CRUD apps, admin some linux servers, and put together custom code for WordPress. Some folks would look at that pile of day-to-day tech cruft and say that I am not even a "real" programmer (even if I do know how to implement a buffer with TTL and I've written toy mouse drivers and serial implementations).

All that comes down to this: it really comes down to you and your goals, and what you want to get out of your life. You are the only measure of what you consider to be a good person. Most of us are sane enough to peg that estimation to feedback we get from other people. But fundamentally the metrics are still our own.

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.

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.

There are no such things as good programmers. Humans have no idea how to program computers, and anybody who tells you differently is lying.

The most honest person here is https://news.ycombinator.com/item?id=18538092

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.

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.

Ha! So, so many definitions of good. But, at a basic level, you can boil it down to:

* Does my code work?

* Does my code look after itself and its user when things don't go according to plan?

* Is my code simple?

* Can my code be maintained?

There are very serious sub-plots involving (ie) what does "work" mean? are simple and maintainable the same thing? But if you hit the four points above and don't fart in the office, you're good to go.

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.

Some basic heuristics I use for determining the capability of other programmers and myself:

1.) Does the code have a good bus factor i.e If the maintainer dies tomorrow by being knocked down by a bus, can other people pick up where he/she left off? Further research into the Bus Factor can be found here: https://www.youtube.com/watch?v=0SARbwvhupQ

2.) Is the code well documented? This is so obvious that it is painful to write this comment, but it is a very simple heuristic for determining capability. Documentation can include code comments.

3.) Is the code resilient to weird input? The code should perform well under heavy fuzzing and where possible, sanitize different input. It should be tested against this: https://github.com/minimaxir/big-list-of-naughty-strings

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.

I would recommend contributing code to a well known FOSS project, or at least an existing project that you use or respect. I think hacking on meaningful projects will be clear milestones for yourself, which seems to be what you’re looking for.

To encourage you, here are a couple of contributions I have to Linux and Hadoop:

https://github.com/torvalds/linux/commit/0bef71093d446165964... https://github.com/apache/hadoop/pull/114

If you read through the commit messages and look at the patches, I think you’ll find that reaching these clear milestones doesn’t take an unattainable amount of skill; just a bit of patience and curiosity.

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.

Granted, I'm a lone wolf (mostly) scientific programmer, not a commercial software developer. I look at a few things:

1. Keep an eye on how big or elaborate my programs get before I lose control of them, and have to either stop development, start from scratch, or massively refactor in order to know what the heck is going on. Being able to maintain a larger program, or participate in a larger project, without doing too much damage, seems like a reasonable informal metric.

2. Look at programs that I've written months or years ago and critique my own work. A year-old program should hopefully look better than a decade-old program.

3. Try to stay abreast of improved programming techniques, incorporate them in my work, and have faith that my programs will gradually improve.

I just realized these things are not about how good I am, but about the rate of change of my skills.

Just from pure introspection, you might be able to glean an answer by thinking about these questions:

— Are you capable of distinguishing opinion from fact? Are you capable of distinguishing _your own_ opinion from fact?

— Any project will have easy bits and hard bits. How accurate are your predictions of which bits are easy and which bits are hard, for projects within your domain of expertise?

— When you think about your software, how good an idea do you have of what's "cheap" to achieve, and what's "expensive" (e.g. which endpoints or queries are fast and which are slow)? What's easy, what's hard? Do you understand how the people who consume your software use it? Do you know whether common operations for them are cheap and/or easy? Do you understand why (or why not)?

— Turn the previous question around — do you understand the design behind the software that you consume? Are your own common operations things that are cheap and/or easy to achieve using that software? Do you know why (not)?

— When you think of technical choices, do you tend to think in terms of absolute right and wrong, or do you prefer thinking in terms of tradeoffs? If the latter, how capable are you of articulating why a given tradeoff makes sense in one situation but not another? Are the tradeoffs you consider limited to technical matters, or do you consider "softer" aspects in your analysis (such as recruiting costs, time to market)?

— How well do you know your tech stack of choice? How well do you understand your own limitations within that stack? How does your stack of choice measure up against the alternatives? Where is it better, where is it worse?

— And, finally — why does any of this matter? Do you genuinely want to work on the sort of project that _actually_ requires so-called "rockstar" engineers, or are you happy working on projects where good enough really is good enough? How much effort would it take to actually become a rockstar? What would it cost you? (you might want to go over the bit on tradeoffs above again)

I believe that you get good by getting better. And I think it's easier to tell that you've gotten better than it is to tell that you've gotten good.

Look back 6 months, a year, 2 years. How have you grown? What can you do now that you couldn't do then? Are there things that you'd do differently? Things you wouldn't do at all? That might give you a sense of where you are now.

Repeat the process of getting better many times. Then one day you'll take some call, draw some diagram, write some code and you'll know. For a brief shining moment you will know without a doubt that it is good and you are too. Then the moment will pass and you'll spend a couple of years trying to find the next one.

> 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 code 1) runs the first time with no non-trivial errors or obvious bugs, 2) does at least what you intended it to do, reliably, efficiently, and isn't easily de-railed...

then you're getting close. If 3) you find you can easily and quickly modify it to add features... months later... that's closer still.

Of course if you have to answer to someone about why you did it this way or that way, or who can't comprehend your code, then (in that environment) you may have farther to go.

Longer, bigger, harder projects may test your skills. Be your own best critic, always strive to do more with less.

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.

Do you mean programming as a job, or programming as an activity/art? They seem two very different things; some people are answering one or the other or a combination.

I noticed some refer to programming as a craft - maybe programming as a job is usually a craft. For myself, I am motivated to write a program because I don't know what the output will be - i.e. not a craft, where the end result is known and aimed for. It's like an experiment - it's worth doing because I don't know what will happen.

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.

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.

If you work in a moderately sizeable organisation and manage to delete more lines of code than you add, while still adding features, you may be a good programmer.

It's a question I've asked myself too. I've also wondered how often others are being aggressively pursued by former colleagues to join them at another company. I've seen team strongly believe they hire strong candidates only, but rarely seem to pursue these same people after moving to a new company.

Would you hire yourself?

There is no point in measuring yourself against other people, even in sports.

You should measure yourself against yourself. Your goal should be to become your best self, not the best X in the room/world. X is mostly picked arbitrary.

This means you should always try to become better at what you value.

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.

Late but we don't have stats on world's best plumber/doctor either. It becomes a practice at one point and your results/impact becomes the true measure.

I don't think it makes sense to compare a profession to a sport.

It isn’t about your skills now, but if you are improving. If you look back back in code you created 6 months ago and thinks it is a disgrace, then you are very well becoming a good developer.

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?

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

What’s a programmer?

I’m very good at breaking down old code and making it modern. Does that mean I’m a good programmer? For that task, yes. In general, the jury is still out.

My general rule is that if I look at code from 1 year ago and I'm not disappointed with year-ago-me, I'm not growing as a programmer.

Do you solve the solution to the user's problem or just accept the solution given by the business?

Are you a team player?

Your development speed keeps being a constant even as your software evolves and you add many new features.

Go back and read code you wrote 1, 2, even 5 years ago. If it's still clear and logical, and you don't think "who's the clown that wrote this?" then you're good. If you can hand it to someone else and they don't think "who's the clown that wrote this?" then you're very good.

A common mistake is to judge yourself in a vacuum. You aren't a rockstar because you have achieved a certain number of years employed (this is more common than you would think). The Dunning-Kruger effect is very real.

https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

Objective measures of competence are:

* speed of delivery. Do you deliver faster than your peers?

* extreme problems. Are you able to solve problems nobody else can solve?

* originality. Are you able to demonstrate problems nobody else can see or solve problems in a new way?

* write software everybody wants. Do people frequently consume your software or beg you for certain features?

---

Sometimes a low aggression (aggressive as far as product not angry people) environment can trap you into a tightly contained cocoon of suck from which there is little or no self-improvement potential. Be aware of this.

Good programmers don’t concern themselves with such trivialities.

If you're questioning yourself, then you're alright.

Try leetcode the hard ones

I can answer the specific question for you easily: you are not good enough yet. That answer applies no matter how good you are :-) But to be serious, it's very, very important in this industry to cultivate that attitude because as soon as you think you are "good enough", the industry moves under your feet. This is a job of endless learning and self development. For those that are new to the field, take note. If you are the kind of person that just wants to show up at their job, do what they know how to do and then go home, you are at extreme risk to be unemployed and even unemployable in this field in about 10 years time. There is nothing inherently wrong with wanting a job like that, but a programming job is not that (at least not right now -- maybe come back in 20 or 30 years).

On the other hand, I could also say that no matter how bad you are, where you are today is fine. There are so many roads in this industry it's incredible. It is counter productive to judge yourself harshly. I know many very talented people who I never, ever want to work with. I know very many people who don't have so much talent that I am extremely happy to work with. I'm sure most people can relate. No matter what kind of natural talent you have at programming, try to cultivate the sense that others want to work with you.

I saved the most complicated bit for last. How do I know what I suck at so that I can make sure to improve it? This is really difficult. I've seen many people feel very secure about their abilities in one way or another, when in reality the things they were most proud of were part of their weaknesses, not their strengths. If I'm really, really honest with myself, I've gone through patches of that myself. I think everybody does (although some are much more delusional than others).

The best thing to do is to try to work with a wide variety of people who have different backgrounds. When someone disagrees with you, make a note of it. Even if you end up convincing them that they are wrong, try to understand why they had that idea in the first place. Is there anything you can learn? Look for ways to invalidate your current view point.

The most difficult piece of advice to follow, I think, is to celebrate when you are wrong. It is easy to convince yourself that you are right and to put your head in the sand. It is difficult to understand that you are wrong and to figure out how you came to your mistaken conclusions. More importantly, if you really are right, then there is nothing to learn and nowhere to grow. It's only when you are wrong that you can make substantial progress. Cherish that process.

One more thing: I believe that every good programmer must, at some point in their career, build a system of significant size all by themselves. Thing of it as your master project (the project that journeymen do to be recognised as masters). One of the best things you can do is to build that system and maintain it for many years. With that you can see where your weaknesses lie -- all your assumptions will be laid bare. Be very critical of the result. If it isn't perfect, why isn't it perfect. You only have yourself to blame, and that's a wonderful piece of perspective.