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

[dvnguyen]

I always want to be a better version of myself, but it's unclear how to quantify my quality. In sporting, there're many stats about athletes to look at. In academia, you can look at some indirect indexes about your research quality. But as a programmer at work, I often receive feedbacks from 1 or 2 persons at most. It's easy to think that I'm good enough, when the truth may be not.

So, as a programmer, how do you quantify or estimate how good you are?

Thank you,

[bb88]

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.

[hyperpallium]

"Am I an affective programmer?"

    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"?

Of course, these are outcomes/benefits, not the technical role of programming within an organization. But apt if you see yourself, fellow programmers and company members as "users" also.

> I read a study that measured the efficiency of locomotion for various species on the planet. The condor used the least energy to move a kilometer. And, humans came in with a rather unimpressive showing, about a third of the way down the list. It was not too proud a showing for the crown of creation. So, that didn’t look so good. But, then somebody at Scientific American had the insight to test the efficiency of locomotion for a man on a bicycle. And, a man on a bicycle, a human on a bicycle, blew the condor away, completely off the top of the charts. https://www.brainpickings.org/2011/12/21/steve-jobs-bicycle-... https://youtube.com/watch?v=0lvMgMrNDlg

> ... There need be no real danger of it ever becoming a drudge, for any processes that are quite mechanical may be turned over to the machine itself. https://wikiquote.org/wiki/Alan_Turing

[hdkmraf]

Wow, this is such an eye opener. I have always considered myself an ok programmer, but always struggling with trying to be effective.

Your four points on effectiveness happen to me on a daily basis, but I tend to see them as annoyances, mind you, I rarely refuse to help and advice. This gives a whole new light and meaning to all those interruptions.

[zumu]

Aside from the first question (may first 2 questions), the top questions are arguably more qualitative than quantitative.

> Do I solve more problems than I create?

Who judges what constitutes a problem? How do you know when you've created a problem?

> Do I see simple solutions to complex problems?

Define 'simple'.

> Can I refactor terrible code to more easily maintained code?

Define 'terrible'. How does one know what code is more easily maintained?

> Can I avoid terribly written code in the first place?

See above.

> Can I effectively communicate with people in order to get the answers I need without wasting their time with needless questions?

What constitutes "effective" communication? What are "needless" questions?

I generally agree with the questions, but I would imagine most programmers could read them and think, "I must be pretty effective."

[emmelaich]

... and as in everything, don't trust your own instinct on this; work closely with others to get a true sense of where you stand.

[acct1771]

You're compensated better than your peers, and there's no extenuating circumstances surrounding that.

[xfitm3]

The problem with measuring effective is that it is quite subjective. Politics can skew those results.

[camel_gopher]

One of my gotos has been 'Can I avoid writing code in the first place?'

Zero code has zero bugs, and zero maintenance cost.

[Hbthegreat]

This is the correct answer

[gnahckire]

> You're asked for help often.

Could also mean you write unreadable code and, by extension, unmaintainable code.

> You're the go to person by the boss.

Could also mean you write unreadable code.

[smilesnd]

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.

[l0b0]

This. After 15 years as a professional developer I have a fairly good idea where my boundaries are, and that's about it.

Expect to learn new things every day, and from every conceivable source: your fellow developers, junior and senior, of course, but also your PM (for example, prioritization, techniques to organize work), designers (information flow, HCI), business analysts (how the client ticks), etc.. Very likely everyone you ever worked with could teach you something, and you'll never have time to learn it all.

[jakegarelick]

100% agreed. At the risk of sounding dismissive (not my intention) it doesn’t matter whether you’re a “good” programmer or not.

Stop trying to measure yourself or others, get in there and code.

[_hardwaregeek]

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.

[lolc]

Hours of deliberate practice is said to be the deciding factor in how good you are. Or at least, we can't be good without it. So yes, counting the hours we spent writing and analyzing code gives us an idea of how good we might be as programmers.

[scarecrowbob]

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.

[keithnz]

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.

[vi1rus]

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.

[hnruss]

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.

[sizeofchar]

Wow, this competency matrix is very useful. Thanks for sharing!

[rammy1234]

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.

[dintech]

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

What if the recent stuff looks bad too? :)

[ams6110]

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

[finaliteration]

I just purchased a coffee mug that says “World’s Okayest Developer” so I’m right there with you.

In all seriousness, though: I’ve learned that it’s better to just accept that sometimes you’ll do really good or exceptional work, sometimes you’ll do awful work, and most of the time you’ll do work that’s pretty good and gets the job done but isn’t perfect.

[booleandilemma]

Every once in a while you need a signal flare, but most of the time what’s required is a lightbulb.

[myWindoonn]

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

[oceanghost]

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.

[spiralhead]

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.

[stcredzero]

You know you're a good programmer if the things you build "just work."

How do you quantify, "just works?" For a large enough project, perfection, or even just getting pretty close to it, ends up being pretty expensive.

It should be near impossible to find flaws in your solutions.

I had a boss who declared he could find a bug in any page of code, so long as you let him lawyer the specs in great enough detail. Granted, we were working in a pretty complex domain, but as far as I could see, he was always right about that.

As Matt Easton keeps saying: "Context!"

Maybe the company you're working for finds it much more valuable to do lots of iterations so they can tinker with the product and keep refining it. In that case, it might be even better than "perfection" if the things you build mostly work, but that you can respond to change and bugfix requests quickly. (Without introducing regressions.)

[ravenstine]

> It should be near impossible to find flaws in your solutions.

The number of open issues in most OSS repos would make me hold my tongue before saying something so farfetched.

[sanderjd]

I've used, worked on, and depended on an enormous amount of software and I have literally never seen such a thing.

[TamDenholm]

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.

[RantyDave]

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.

[blakesterz]

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.

[octosphere]

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

[alex-]

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.

[sahil-kang]

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.

[sbinthree]

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.

[analog31]

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.