a companion discussion area for blog.codinghorror.com

Why I'm The Best Programmer In The World*


#1

It's because I'm so humble, obviously. Allow me to illustrate with an excerpt from the personal character chapter of McConnell's Code Complete 2.0:


This is a companion discussion topic for the original blog entry at: http://www.codinghorror.com/blog/2004/08/why-im-the-best-programmer-in-the-world.html

#2

I couldn’t agree with you more, and reading what was on your homepage has definitely “evoked the feeling of suprized recognition” for me, by showing me what I knew, but didnt know that I knew…and here is how.

I’ve had the pleasure of working with two “can do anything, I know everything, my dad was a hell’s angel, I know kung foo, plus I started programming kernels when I was 6” kinda guys who say they are going to do this and that but never actually get anything done, and when they do finish something, all they have really done is create a maintenence knightmare for everyone else because by the time they finish whatever it was they were working on, they are fired because our boss finally figures them out.

On the other hand, I’ve also had the pleasure of working with 1 guy who is on the other side of the spectrum…and now I realize what exactly it was about him that made him special…he was humble! Of course he was also a good programmer, but it was his personallity I think that made people trust him, and look up to him. The reason you trusted him was because he never failed to do something he said he could do…this is because, I believe that he never said he could do something unless he was absolutely sure that he could. But dont get me wrong, it wasnt that he wasnt confident in his abilities…I believe it was that he was aware of his limitations at the time, and was completely comfortable admitting when they had been reached. To sum it up, with a humble person, you essentially have a guarantee…you can feel confident that if they say something can be done, or can be done in a certain amound of time, it can and will be done, in that amount of time. People that can’t admit when they are not qualified for a certain project, or just aren’t sure about something, are people who create faulty programs badly, and become so tangled up in their if then else statements that they are finally forced to throw their hands up in despair and blame the clients or the programming language for them not being able to finish the project they said they could do in their sleep.

Although humbleness does not mean kick ass programmer, it does at least assure you that the person is probably reliable. So when giving interviews, don’t be fooled by a person who adamently claims they are not an “expert” in java. After all, one the smartest people ever claimed that he didnt really know anything, and therefore in a way was one of the most humble people ever.

Thanks for the insight,

Mike


#3

did not get this humble guy a job


#4

did not get this humble guy a job

Believe me, you’re better off not taking that job if they can’t accept an occasional “I don’t know”. I suppose if you were looking for a very narrow, specialized field of knowledge in a candidate, but that’s rare.


#5

This is really enlighting as most companies don’t like to hear “I don’t know”. There is a difference between “can do” attitude and “i know i can do”. Some people are just so arrogant that they will never admit that they “cannot do it” and “can do” is something which comes out of them without thinking.

Everyone has to deal with such people but “I don’t know” are much better because they at-least give you an opportunity to decide what you need to do! In the end, you cannot force anyone to do something which they cannot do or they don’t want to do. Best to stick with people who are honest about it rather than the ones who drag you into trouble like the first kind descripbed by mike.


#6

I wish I could communicate to people that humility is a good primary motivator for improving your skills.

The reason that people get into Design Patterns, and iterators, and dynamic functions, and languages with macros … the reason you do this is because you simply don’t trust yourself to be able to – or instance – MANAGE and MAINTAIN duplicate code, in the same projects or across projects.

And I hate when people misapply this Humble Programmer principle! It’s arguing that it’s arrogance to rely on your own brain, instead of a powerful abstraction that allows you to think about the problem in much simpler terms. Many people actually try to use the essay to argue against advanced coding techniques! That’s not “humble”, it’s some kind of prima-donna, look-down-on-other-coders thing, right?

How do you get THROUGH to these people?!?

Whereas many a “can-do”, “80’s guy” programmer will gleefully blast through reams of duplication-heavy code, copy-paste at the ready, producing hundreds of files and folders and tables, very productive, look at that tangible output … I feel, I KNOW, that I would be unable to keep my code from devolving into chaos. For one thing, I know I suck at keeping track of changes and making them in more than one place; it kicks my ass. In fact, I am less able to maintain non-orthogonal code than almost anyone else I know. I can’t manage several hundred different but similar stored procedures for a variety of domain objects, even using tools like code generation. It kicks my ass and I know it, and that’s why I went the extra mile, learned how to address the bigger problem, and now use a capable ORM library like Hibernate, and write only a small amount of specialized SQL – like Nested Sets insert triggers, etc, which is just to support specific data structures.

A program is going to change. Since I don’t trust myself to be able to redo all of this code later – or even to remember what it was about – I put a ton of effort into ensuring that my programs are very loosely coupled.

In so many industries, it would be difficult for me to succeed, because I have a terrible memory and a low ability to store much in my head at a time. Don’t get me wrong, the stuff I do can be pretty powerful, but I HAVE to keep the programs and interfaces simple and elegant. Otherwise, I’m doomed.

In so many industries, the fact that the quality of my output varies drastically would bar me from working. In programming, if I just think about a problem for slightly longer than the time it takes to copy googled code and paste/adapt it to my needs, I know that I can always work with my best thoughts. And so the quality of my output can be consistently high.


#7

you see, programming is not just writing anything, it’s about writing lines of codes that looks good to not just you but to so many people out there. You are not a good programmer because of the number of lines you wrote but because of the creative manner you wrote it. I just dont know what one can use in measuring how good a programmer is but all i know is that all programmers are GOOD irrespective of what language that use.


#8

You really have a point here. My switch to get a humble programmer lasted years. Starting by lying to yourself and somewhat ending by not telling the “subtle untruth” about projects I wanted to have (no, I did not actually lie). And in a way I wrote about humbleness without knowing it of my own on my page (comparing programmer levels).

Keep on supplying us with that kind of blog entries! :wink:

Georgi


#9

But what is “humility”? It’s tricky because always saying “No, I don’t know, I can’t do that” isn’t humility, it’s false modesty. I see the following basic concrete instantiations of humility, some mentioned, some not. Please feel free to add more.

  • The already-mentioned ability to say “I don’t know” without it being a crushing blow to your ego.

  • The recognition that there is code beyond your ability to manage, so you learn how to write code that isn’t that complicated, as mr luc talked about.

  • The ability to accept feedback from anybody. You may be the Senior Architect for your company, but programming being the tricky, hard thing that it is, the lowliest intern may have valuable feedback about your design. (I find the best feedback comes in the “customer is always right” sense, where the intern is a “customer” of your design. If they feel like something is more complicated than it ought to be, there’s a reasonable chance they are right, even though their identification of the “root problem” may be laughably wrong. And even if they are completely wrong and it really does have to be that complex, a humble designer should not immediately resort to “Because I said so”, but should at least try to explain why. (“Because I said so” does sometimes end up the final answer in our hierarchial work environments, I just don’t think it should be the first resort.))

  • Accepting that you can’t do everything, and that others are capable of producing good code.


#10

I have said this for years, and it feels good to be agreed with. Programmers who can’t admit to their mistakes will suck forever and make the same mistakes forever. Programmers who can’t let someone else rip their code to shreds without getting defensive will suck forever and cause problems for their team.

One of the reasons I love TDD so much is that it supports humility. How do I write this feature? I don’t know yet, but the tests will prove my hunches right or wrong.

The scary thing is realising how poorly I understood object oriented design until unit tests showed me the way.


#11

Hey, If you don’t know anything, should you say I don’t know or I will try to do this.


#12

The full E. W. Dijkstra archives are here:

http://www.cs.utexas.edu/users/EWD/welcome.html


#13

I don’t see why you compare “I don’t know” with “can do”… For me, both are true. I am the type who says “I don’t know yet, but I am sure I can do it” and I find this a very contructive attitude. This is what got me this far and what will probably get me further. I think that I can do anything if I try (and this is not true just for me).
I think it’s wrong to say “I know”, but I see only good in “can do”.


#14

I totally agree with you. It’s better to know that you know nothing and question what you don’t know in order to understand it rather than believe you know everything and learn nothing.


#15

Awesome entry, will probably help me when I’m out for a job after the university. Keep up the good work!


#16

very interesting forums, for my self, if i’m facing problem or something that I don’t know yet, I will just say I don’t know, but I will try to find out. I believe wherever there’s will we can do ‘almost’ everything.


#17

I agree wholeheartedly with the original article, and what was said about this argument being misused to justify simplifying languages. I think languages should be complicated so I can write shorter code. Write one complicated compiler, and millions of smaller programs rather than the other way round.

It really pains me to have to read Java code because it can be so much more unneccasarily verbose (and therefore harder to maintain) than more powerful languages like C++, Smalltalk or Lisp.

I really wish someone would give me a language with all of C++'s power but adding “modern” features such as (a natively supported) garbage collector, (intrinsic) delegates, (possibly) a “managed” environment, modules instead of headers, and a larger standard library. D doesn’t seem quite mature enough, or rigourous enough to stand the test of time. C# is proprietry, and moving in the wrong direction. C++ development itself seems glacial and suffers from too much historic cruft.


#18

I entirely support your argument. Many of my friends who consider themselves to be great programmer “because they have been writing code since they were 8” never wrote code which could be maintained by others. And as a result never built a maintainable software or an extensible software. And even if they did … (only once !!) that could not be understood by anyone themselves included.
I am not as great as them though I earn my humble bread by writing clear easy to understand code.


#19

Personally, idont know what it takes to be a good programmer coz am a fresher in that field.But i would like to thank you for giving me an eye
openner


#20

programming is all about knowing when to boil the orange sponge donkey across the phillipines with an orangutang gorilla crossed with a ham sandwich to the fourth power of twelve across the nile with an awful headache from the previous night when all of alfred’s naughty jalapeno peppers frog-marched the nordic elves across the loom-lined geronimo induced swamp donkey over and above the fortran fortified kilomanjaro fence past the meticulously crafted anti disgusting sponge cake scenario where all the hats doth quoteth the milk which is not unlike the super werewolf from the infinite realm of ninja-step. it’s hard to define, really.