Like most people, I think of myself as being a bit above average in my field. I get paid well, I've gotten promotions, and I've never had a real problem getting good references or getting a job.

But I've been around enough to notice that many of the worst programmers I've worked with thought they were some of the best. Bad programmers who are surrounded by other bad programmers seem to be the most self-deluded.

I'm certainly not perfect. I do make mistakes. I do miss deadlines. But I think I make about the same number of bonehead moves that "other good programmers" do. The problem is that I define "other good programmers" to mean "people who are like me."

So, I wonder, is there any way a programmer can make some sort of reasonable self-evaluation? How do we know whether we are good or bad at our jobs?

Or, if terms like good and bad are too ill-defined, how can programmers honestly identify their own strengths and weaknesses, so that they can take advantage of the former and work to improve the latter?

199 accepted

A good programmer understands that that they have to continue to learn and grow. They strive to do their best at every effort, admit to failures and learn from them.

They are extraordinarily communicative. Not only are they able to explain complex technical terms to a layperson, but they go out of their way to act as devil's advocate to their own idea to make sure they're giving the best options to their client.

The best programmers know and accept that there is more than one way to do things, that not every problem is a nail, and that because there is always a better way to do something than how they were planning on they constantly seek to learn new techniques, technologies, and understanding.

A good programmer loves to program, and would do so in their spare time even if they already spend 80+ hours a week programming.

A good programmer knows that she/he is not a great programmer. Truly great programmers do not exist, there are only those who claim to be great, and those who know they are not great.


As Paul Graham points out eloquently in this pod cast, you can't. Only your coworkers can tell you.


I've always found that it's easiest to judge your performance by doing two things.

  1. Surround yourself with other good programmers
  2. See how much they complain about the code you write.

The issue of course is finding good programmers, and then being a good programmer also isn't just about coding. You need to be able to work well in groups, yet also work well by yourself.

Now for the sake of going off topic, I will quote Robert A. Heinlein and his view on the subject:

"[A kick-ass programmer] should be able to change a diaper, plan an invasion, butcher a hog, conn a ship, design a building, write a sonnet, balance accounts, build a wall, set a bone, comfort the dying, take orders, give orders, cooperate, act alone, solve equations, analyze a new problem, pitch manure, program a computer, cook a tasty meal, fight efficiently, and die gallantly. Specialization is for insects."
- from The Notebook of Lazarus Long.


Jeff has one of my favorite blog posts on this topic...Why I'm The Best Programmer In The World

"...it's not our job to be better than anyone else; we just need to be better than we were a year ago."


I think the fact that you are asking the question proves you are not a bad programmer, so, in my opinion, you are half way there. :)

Bad programmers always think they are great programmers, in my experience.


This is the Programmer Competency Matrix just for you: http://www.indiangeek.net/wp-content/uploads/Programmer%20competency%20matrix.htm


@Nick's statement "Bad programmers always think they are great programmers..." is explained by the Dunning Kruger Effect, which generalises that people who know a little about a subject often over estimate how much they actually know.

Being a bit facetious... the less you think you know the more you probably do.... unless of course you are a really self aware idiot.

Answering the original question, though i tend to think that the more influence (not control) you have generally is a good indicator. If you see other's following your lead, or picking up your practises then you are on the right path.


You could try competing in the TopCoder algorithm contests.


The answer that got the most plus votes is really distressing. Basically it says that you have no life outside of programming. What about family? Community? Hobbies? What kind of a profession are we in where you have to be preoccupied to the point of obsession just to be considered "good"? I really think we need to get some perspective here.


I'm not perfect. I make mistakes. I miss deadlines. But I think I make about the same number of bonehead moves that "other good programmers" do.

That realization alone makes you a better programmer than most of the bad programmers out there.

A lot of the worst programmers tend to think that they already know everything there is to know and are not aware of their limitations. As a result, they never improve their skills.


If you look at your code from let's say a year ago, and think, jeez, I could have done that a lot better, you're probably good :).


Allow other developers who you respect to work with or see your code.

Have people actually use what you like and see what they think.

-- Kevin Fairchild


There are a few things you could try, to get a better gauge of how you stack up.

  • Compare code reviews. See whose review revealed more problems.
  • Ask when was the last time they read books that were peripheral to their normal course of study. Then ask yourself the same thing.
  • Ask yourself who brings in new ideas to the company (and how well they work).
  • Last (and least), is there some form of company recognition?

(I put that one last because at my last company, one programmer received "developer of the year" twice in three years. After he left, we found at least 20 TDWTF-worthy code snippets. He developed code fast, but not necessarily well. Management just didn't know the difference.)


To me the very best programmers are never looking for work. They have standing offers for new positions just based on their reputation. So a good programmer may have offers from previous employers to return, if they desired. Or a good programmer would have had inquiries from former coworkers about coming to work for them at a new company.

In terms of strengths/weaknesses, you probably already know them. If not, ask a more senior person on your team. It doesn't even have to be a developer. A good project manager knows the strengths/weaknesses of programmers. Besides, the traits that define a good programmer are not just limited to code. Understanding the business, communication skills, judgement, etc. are all performed outside of your IDE.


Just the mere thought that you need to self-evaluate makes you a cut above the rest.

One way I always judge myself is listening to what my co-workers have to say about me. Trick is in finding the right people.


It's always subjective who is a good programmer. I agree with Nick that simply asking the question is a step in the right direction. I think the constant desire to learn more and improve is what makes a good programmer.


I think this is about like wondering how you can know if you're a nice person.

I think, unfortunately, the answer is that only other credible people can tell you that. I don't think it's something you can accurately determine for yourself (at least it's very difficult - but I think it might be impossible).


Here are some real life examples of bad programming. Of course, similar code was all over the place copy/pasted in 100 places. Guy got fired, but I've heard that he got a nice job again. Enjoy:


if (! TableObject.loadList("sql condition").isEmpty()) {  
    List<TableObject> myList = TableObject.loadList("sql condition");  


public static Type getInstance() {  
    if (instance == null) {  
        return new Type();  
    return instance;  


getForeignKeyObjectProperty1() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty1();  

getForeignKeyObjectProperty2() {  
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getProperty2();  


getForeignKeyObjectPropertyN() {
    return ForeignKeyObject.loadByPrimaryKey(foreignId).getPropertyN();


public boolean isHasImage() throws SQLException {
    StringBuilder query = new StringBuilder();
    query.append("select user_name");
    query.append(" from user");
    query.append(" where has_image = 1");
    query.append(" and user_name ='"+getUserName()+"' and user_image is not null");
    Connection c = Database.getInstance().getConnection();
    Statement st = c.createStatement();

    try {
        ResultSet rs = st.executeQuery(query.toString());
        if (rs.hasNext()) {
            return true;
        } else {
            return false;
    } finally {

If you make this kind of code, stop programming. If you don't see anything strange in this code, stop programming. Otherwise you aren't bad, so you even might be good :)

EDIT: To answer comments: I got job before graduating, and this guy already had few years of programming experience. He got fired few months after I got employed so I wasn't in position to tutor anyone. Examples above were just from top of my head - every peace of code he touched was flawed in various and imaginative ways. Most of the stuff started to creep out after he went from the company, because only then other people saw some parts of the code. He is generally a nice guy, pleasant to talk with etc. but he will NEVER be a good programmer, just as I will never be a good painter or a writer or whatever.

To contrast this with another example, guy who came to replace him was also undergrad at the time. He studied college more famous for management then programming. He isn't too geeky in a sense that he programmed anything for fun or would sit home and read about java or programming, yet he is doing just fine. He adjusted quickly and started producing useful and maintainable code. Some people can do that, other can't - just ask dailywtf.


i would simply say: if you're passionate (i mean REALLY passionate) about what you do, if you're flexible (another language, new technology, complete remake of an old project - let's do it!), if you keep learning and improving your skills and never, never think you're good enough to stop - then you're a good programmer!


I think it's more a matter of what you do with your programming skills. Being a great programmer is fine, but what does it matter if you're coding bank software all day (no offense). It just doesn't add up.

To really prove to yourself that you're a good programmer, take on an interesting a difficult side project. This shows a few things: you're interested in programming on your own free time and genuinely enjoy the subject -- this is essential to being a good programmer. It shows versatility in that you can extend your skills beyond what you do in your work environment. It shows motivation and creativity as well: you've defined a problem on your own and are taking steps to solving it.

All of these aspects define a good programmer to me.


It's very hard to self-assess. Incompetent people tend to have wildly inflated assessments of their own abilities.

A good metric is whether other people whom you respect as programmers themselves want to work on/with code that you've written. Given the chance to work directly with you, or to inherit code that you've written, will then turn it down? Agree grudgingly? Or jump at the chance to learn from your work? This technique works even better if it's a peer, not an underling or someone who thinks there may be any benefit to them from making you feel good.


95% of all programmers think they are among the top 5% programmers, the other 5% are managers. So if you are a manager, you are probably not a good programmer, otherwise you probably are.


imho you are a good programmer if

-you have a sound theoric background. reinventing the wheel as well as an algorithm or a framework is a waste of time, most of the times.

-you can see things and problems from a skewed perspective sometimes. this may bring you to find innovative solutions.

-you spend time money and efforts to have the best tools and the best skills updated.

-your code is easy to modify. if you design clean, elegant and understandable code, modyfing it will not be painful.

-if your code/bugs rate is reasonably high. I know this may seem trivial, but I know many creative and skilled developers that nonetheless are very prone to do trivial bugs. this impairs greately their effectiveness and usefulness.

-people around you know that you can help deciding what choices to do

-you can solve problems using different tools. bad programmers keep using the same tool (be it a language or a technology or an architecture and so on) for whatever problem they get

-you keep learning, you are curious.

-you have fun programming, after all these years


For balance I'll throw in the Three Virtues of a Programmer, namely laziness, impatience, and hubris.

Laziness is all about getting the most out of your effort. It's a reminder to spend your time wisely, where it will do the most good. As a programmer it's very easy to get distracted by things that will have little impact on the success of the project, a good programmer can ruthlessly deal with these distractions.

Impatience is a nice one because it's quite specific to software. Basically when it comes to software the earlier the failure the better. A good programmer is not afraid to try out ideas and re-evalute if things don't seem to be making progress.

Hubris is about having the belief that what you are producing has some real value. If you don't believe this then a good programmer will pick something up off the shelf and move on to the next task. It's a good cure to the not-invented-here syndrome.

Just some things to think about for your next performance review :)


"Sir, I have been through it from Alpha to Omaha, and I tell you that the less a man knows the bigger the noise he makes and the higher the salary he commands." Mark Twain

... my conclusion is that good programmers command a low salary and make little noise... :)


Best Programmer: Complete the task with lowest number of code statements on time.


Is your company or organization successful? Can you find a direct, measurable correlation between its success and your contributions. If you were gone, would they stumble a little? Can you prove that?

If you answered yes to all the questions above, you're probably a good programmer, maybe even great. It has nothing to do with your coding skills, how much you like what you do, if you know such and such, if others are worse than you, etc. You were hired for one reason and one reason only - to make your company or organization more successful than it was before you came along. Find that coorelation - the business one - and you'll know whether or not you are great.

One typical measure is the amount you know about things that are not programming, but related to what you are programming. For example, if you are developing a charting component for a dashboard, how much do you know about business analytics? How much do you know about the companies that use these and what they need them for? How do your charting components make your customers successful (I'm not talking about the "Pillars" and "Value Propositions" that your Product Marketing team spits out - I'm talking about you making this assessment yourself). How much do you know about your customer's industries (for example, banking or manufacturing). Why are your competitors successful? If you're not excited by all of these things, you're probably not a good programmer. This will all influence your decision-making ability as a programmer, beyond coding, for your customers. Ultimately they are the ones that decide if you are a good programmer.


How many bugs does your code have per some metric? (i.e. bugs per line) How much of your code has to be recoded when new features need to be added? Do your coworkers have issues modifying your code?

Ultimately, the question is next to impossible to answer given that the question of "what is quality code" is still a hotly debated topic after all these years.


I really like what Adam V said above.

In addition to what others have said, look at the maintainability and support history of your work. If your code has heavy maintenance requirements and is constantly being fixed, or is difficult to change, those can be indicators of its quality. But these can also be indicators of poor requirements.


Can you understand this?

if(rp->p_flag&SSWAP) {
 rp->p_flag =& ~SSWAP;



If you really want to find out, submit some code to your peers, and ask for a (constructive) code review. In the worst case, you learn something. The mere fact that you're here on this site seeking enlightenment already sets you apart from the unwashed masses. (unless you're just here for ego stroking. :-)


How about you actually create software that people like to use? And yes, the software people like to use: works/does what you said it would do, is maintainable, better yet-does what you were asked to make it do. People also enjoy being able to talk to a developer who isn't an arrogant ass.

  • At 2:00AM when the "S" hits the fan does your code make sense?
  • Do you and anyone else for that matter understand your code six months after it is written?
  • Do you get more calls from the "inner circle" than you make to the "inner circle"?
  • When is the last time someone had to line-up your code so they could read it?

The list goes on and on and...


To know what is good, I'd see what is bad and then just invert that. For me, the worst programmer is the one who doesn't give a damn. Ignorance is the worst show stopper IMHO. Those people never learn, never listen, never improve. To my observation ignorance walks hand in hand with arrogance, but I could be wrong on that. So, if you inverse this quality you might end up with a good programmer. Well.., not necessarily a genius, but at least someone with a chance to create something great and be useful to others. Someone said, "it doesn't really matter what I am, what matters is the direction in which I am moving along" :)


Good programmers get paid!


IMO the ultimate test is whether or not your programs are still useful and maintainable in 5 years, 10 years or more.


I think this question can't be answered in the way you would like to here. I think you can't compare the difficulty of a programming task, when your are involved.

Perhaps somebody outstanding can do this, if he has alot of experience.


If you want to see how you compare to other programmers around the globe, just try out www.topcoder.com and see how you fare.