What Makes a Good Programmer

  • I think you could say the same about just about any career. Doesn't stop it from being true. Sensible stuff!

  • The trouble with this article is that it appears to have been written by a poor programmer - where is the requirements analysis etc?

    Where are the definitions? I mean, which definition of 'Good Programmer' are we discussing? The kind that spend all of their time writing books, giving lectures, and producing nothing? The kind that never make a mistake, and produce 'beautiful' programs? Or the kind that get stuff out on time, are continuously learning, and getting pay increases every year?

    For me 'continuous improvement' is probably the most important phrase in any business.

    Throw away your pocket calculators; visit www.calcResult.com
  • Good Article!

    I think 'Good' depends on your needs. Good depends on what you need for the job.

  • Colin Anderson (7/3/2007)


    I'm going to bea bit pedantic in my opinion by saying that you have to be careful of the terms that you use. The only communication skill a programmer needs is the ability to communicate with a computer. A programmer will not design a system, they will be given a design that they have to program.

    i disagree. if the programmer can't communcate well with at least the person/people supplying him/her with the spec, s/he will quite likely code what s/he THINKS is required, rather than what IS required. i've seen it countless times. on one occasion, a programmer of my acquaintance was told that he should stop an application producing a certain error message: he removed the error message.

    i'd go further: the best programmers give people what they need - and sometimes that's different from what they ask for.

  • I have found this out more recently. Perhaps I have devolved as a programmer. Based on the description, I believe that at least at some point I could have been considered a guru. I still do many of the things that seem to fit into that category, but I have learned something very enlightening over the last few years.

    In the past, I have worked with programmers at the 2nd and 3rd levels and I could definitely see, at that time, the differences between the way I coded and the way that they coded. I enjoyed improving the efficiency of the programs and making the programs relate more easily to the users. I enjoyed problem solving and was pretty good at it. I made plenty of mistakes, but corrected them all quickly. I've learned to prevent a great number of mistakes.

    At one point, I found myself as a lone developer again. Here is what I found. When I was with a team of developers, those 2nd and 3rd level programmers, some of whom really didn't even seem all that interested in programming, were still much faster at coding than I was. I tend to get bogged down in details, and occasionally attempt to solve problems that don't need solving. This was not a problem for these developers. They weren't interested in doing any more work than was actually needed to solve the problem. As a team we worked well together. They did most of the actual programming, and whenever we had a particularly difficult problem, I would step in and either show them how to solve it, or create a solution that could be replicated by them in various places where it was needed. We worked extraordinarily fast. When I became a lone programmer, I found that my development speed had become seriously crippled.

    I feel bad that I devalued some of the other developers that I have worked with. Now that I don't have them, I realize what I have lost. I don't know that it is good to have ratings for developers based on the criteria indicated.

    Instead, I think it is better to consider that there are different people who are particularly good at different types of things and getting the right combination of those people can make all the difference.

    So rather than labeling programmers as basic and guru, it might be better to separate them as coders, specialists, solvers/engineers, etc. Supply and demand may make some of these positions seem more valuable than others, however, without a good combination, I feel like development can severely suffer from being unbalanced in these.

  • Rudolph Davidge (7/3/2007)


    The newbies were impressed by thispost because it was written to impress newbs. Thissaid little that hasn't been said (often) before...and by people who write a lot better than this. As for Gates, Gates is all about marketing. Microsoft does the very thing they decry so much...Push programmers to write for production, not quality. For proof, you need look no further than every single product they ever released. Gates loves to come off as a 'guru' himself, and maybe he is, but certainly not a tech guru. No, Gates strong point has ALWAYS been in marketing, certainly not in innovation. The only innovation M$ has EVER brought to market is that which they first purchased (or simply robbed) from someone else. But I digress.

    A 'guru, from a programming perspective, doesn't, in fact, need ANY interpersonal communication skills...It's ridiculous to assert otherwise. If he has them, well that's just gravy. It makes him (or her) a LOT easier to get along with within a team work environment, but has NOTHING to do with his/her 'guru' status.

    Gurus are NOT, although the label 'guru' would indicate otherwise, in ANY sense a teacher, or a mentor. They don't NEED to teach, because they are more than capable of DOING. If they CHOOSE to teach, again, that's just more gravy.

    Gurus are the ones that not only KNOW five ways from Sunday how to accomplish a particular coding task, in multiple languages and on any platform, they ALSO know (and much more importantly) the OPTIMUM way that said task SHOULD be done.

    They also are ALWAYS thinking 'outside the box'...In fact, they don't even acknowledge the box's existence for the most part.

    The poster also mentioned how humble and unassuming this hypothetical guru is. In my experience (ESPECIALLY during my 4 years at Microsoft), that's simply not true. They are TOTALLY assuming and oftentimes downright prima donnas...and with good reason. They realize their worth to their employer. They know the savings in time and money their presence on the work force represents, and they expect management to recognize it as well....and to compensate them accordingly.

    Merely 'good' programmers on the other hand, are a company's bread and butter. They ARE the ones that simply 'git 'er done'!...And Management loves them for that fact alone.

    I think you may have missed something here. The word "guru" is Nepalese, and very exactly and specifically means "teacher".

    I think the word you are looking for is "maestro", or "expert". Those do not carry the meaning of "teacher", but do carry the meaning of "having a great amount of skill".

    The people you are talking about as "gurus" very definitely are not.

    - Gus "GSquared", RSVP, OODA, MAP, NMVP, FAQ, SAT, SQL, DNA, RNA, UOI, IOU, AM, PM, AD, BC, BCE, USA, UN, CF, ROFL, LOL, ETC
    Property of The Thread

    "Nobody knows the age of the human race, but everyone agrees it's old enough to know better." - Anon

  • sadara (5/15/2008)


    i disagree. if the programmer can't communcate well with at least the person/people supplying him/her with the spec, s/he will quite likely code what s/he THINKS is required, rather than what IS required. i've seen it countless times. on one occasion, a programmer of my acquaintance was told that he should stop an application producing a certain error message: he removed the error message.

    i'd go further: the best programmers give people what they need - and sometimes that's different from what they ask for.

    I completely agree. To say that communication is not important is a cop-out based on preference or fear. Granted, some people aren't gifted in communication, but that doesn't mean that it somehow disappears. Most important of all, though, is proper understanding, which certainly requires good communication. It is too easy to communicate something that could be taken in many different ways. Look at all the implementations of "standards."

    A great programmer--I realize I'm using different terminology than "guru" due to the misunderstanding on the meaning of the word--definitely delivers what is meant, not what is specifically requested.

  • I agree with points stressed in the article but author opinion is useless here.

    Every body creates his attitude to the life and his job base on his personality

    and experience. It is completely stupid to compare yourself with brightest stars.

    Best practice and properly set responsibility doing a job.

  • Ryan Riley (5/15/2008)


    sadara (5/15/2008)


    i disagree. if the programmer can't communcate well with at least the person/people supplying him/her with the spec, s/he will quite likely code what s/he THINKS is required, rather than what IS required. i've seen it countless times. on one occasion, a programmer of my acquaintance was told that he should stop an application producing a certain error message: he removed the error message.

    i'd go further: the best programmers give people what they need - and sometimes that's different from what they ask for.

    I completely agree. To say that communication is not important is a cop-out based on preference or fear. Granted, some people aren't gifted in communication, but that doesn't mean that it somehow disappears. Most important of all, though, is proper understanding, which certainly requires good communication. It is too easy to communicate something that could be taken in many different ways. Look at all the implementations of "standards."

    A great programmer--I realize I'm using different terminology than "guru" due to the misunderstanding on the meaning of the word--definitely delivers what is meant, not what is specifically requested.

    This kind of goes to my point of there not being levels, per se, but rather job roles and functions. An expert may not need to have the same communication skills if there happens to be a good business analyst on the team that can bridge the communications gap. I personally have found that after many years of application development, my ability to relate to the user has declined. I simply can't always think of ways to simplify concepts that have taken me years to learn. Sometimes this can be very confusing to the typical user. It's as if I forgot how to speak English.

    This is likely to happen to any specialist or guru if they've been in the business long enough. Ultimately, having the right mix of people for the job will make the biggest difference. Having a single person with lots of experience may not always be as good as having 2 or more people with less experience, but complimentary skills.

  • I've worked with top notch coders, meaning they write great code that isn't buggy, runs well and fast, tests well.

    And doesn't meet my needs.

    Communication is key, and it's important that you learn to communicate and listen to what is needed without interpreting that too much. Your skill as a code doesn't necessarily predict your skill as a developer/programmer. I think that's the easy part. The hard part is understanding what you need to build.

    Get to know your end users, talk to them, understand their jobs. Only then can you communicate.

  • A good developer/DBA needs to have a passion for the job. Sometimes the job is tedious.

    This is not only true for DBA but also for other profession also. Until and unless you have a passion you cannot succeed in any job though you may have the right degrees.............

    🙂

  • Chris.Strolia-Davis (5/15/2008)


    This kind of goes to my point of there not being levels, per se, but rather job roles and functions. An expert may not need to have the same communication skills if there happens to be a good business analyst on the team that can bridge the communications gap. I personally have found that after many years of application development, my ability to relate to the user has declined. I simply can't always think of ways to simplify concepts that have taken me years to learn. Sometimes this can be very confusing to the typical user. It's as if I forgot how to speak English.

    This is likely to happen to any specialist or guru if they've been in the business long enough. Ultimately, having the right mix of people for the job will make the biggest difference. Having a single person with lots of experience may not always be as good as having 2 or more people with less experience, but complimentary skills.

    I was going to respond to your message earlier but thought you made such a great point, nothing futher was necessary. 🙂 You are certainly correct, and an additional point could be that both experts in one language / environment / skill as well as jack-of-all-trade types complement one another very well. (I tend to fall into the latter category.) Diversity of team members, within reason, generally tends to produce a better result. (I add within reason for the sole purpose to exclude a team consisting of something like one each of Java, Python, SQL, and .NET developers on one team, which would lead to too much confusion and no productivity.)

Viewing 12 posts - 31 through 41 (of 41 total)

You must be logged in to reply to this topic. Login to reply