Live data from Hacker News

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

news.ycombinator.com

11–20 of 101 posts

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

#11
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.

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

#12
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.

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

#15

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…

I agree on the other points. Can you elaborate on how "Deeply aware of the powerful and superior features of your favorite languages" makes one a bad programmer? Not trying to be sardonic, just want to know how to improve my programming skills.

It is generally accepted that "right tool for the job" is a desirable philosophy.

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

#16
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.

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

#17
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.

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

#18

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…

> 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? :)

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

#19

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.

> 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.

Post reply on HN