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

51–60 of 101 posts

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

#51
post #31

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…

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

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

#52
post #5

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

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.

I consider myself okayest because I can fix the stuff I break or improve something I did months ago. Believe it or not, a lot of people I have worked with can’t.

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

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

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

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

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

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

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

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

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

#58
post #18

Earlier quoted context omitted.

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

Because you have a working, but ugly, solution to a problem and can't figure out a solution that does look good. Or because it's a trade-off: the thing you think would be better requires more work than you think the feature is worth. Maybe you want to tractor to make it more reusable, but decide it is unlikely to be reused, so not worth the effort.

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

#59

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.

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

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

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

Post reply on HN