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

21–30 of 101 posts

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

#21
post #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? :)

Then why are you writing it?

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

#22

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.

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

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

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

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

#24

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.

If you are "Deeply aware of the powerful and superior features of your favorite languages", then you probably are too deeply caught up in language fanboy-ism to actually understand the merits and disadvantages of your favorite languages compared to the alternatives. (You're probably also being a jerk to people who aren't fans of your languages.)

They're tools. They're not rock bands. Don't get caught up in fanboy-ism.

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

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

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

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

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

#29

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.

Yeah I agree with this, finding balance between risk and productivity. Although doing something beautiful is the exception.

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

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

Post reply on HN