[Philosophical] Is there a 'Best Programmer' and what makes him (or her) so?

I code relatively slowly, but I hope, thoroughly. One of my colleagues codes incredibly quickly, and quite well, but I cannot help wonder if his work is not suffering therefore...

So, what makes one programmer better than the other? It may be that one coder sticks on bells and whistles (you know, cute code that does this, handles that and provides the user with a smooth interface). Another coder, on the other hand, just 'gets it done'. His user interface is acceptable (not brilliant, but certainly not bad) but all user requirements are fulfilled and the work output is very high.

Which of these foregoing is the better programmer? Or even, do you have your own ideas on this?

The real question here is better than what?

Both are getting the job done. So, to me, they are equal.

"Better" is relative to the project and person.

I know some who can code very quickly including myself sometimes (I've written two games, on in C++ with SDL and the other with C# and XNA the night before each were due in two different college courses without any experience in the frameworks and they turned out decent (they both got me an A :D)). Sometimes I code slower as well to try and think through complex problems.

I think it depends on the project, what kind of logic is required, the language, the programmer's mindset and experience and more to determine if they're doing well going fast or slow.

Okay. To answer the question, 'better than what?', let's suppose that ProgrammerA and ProgrammerB attend an interview. A is known to be slower than B, but his final product is polished. B is much quicker than A, but although his final product is not quite as polished as A's, it still acceptable.

Who would you choose?

---------------------------------------------

An A for work done in one night in a rush? Do we have another Bill Gates on our hands? ;)

Quote:

---

Originally Posted by bigMeUp

An A for work done in one night in a rush? Do we have another Bill Gates on our hands? ;)

---

Ha! One can dream

Quote:

---

Originally Posted by bigMeUp

Okay. To answer the question, 'better than what?', let's suppose that ProgrammerA and ProgrammerB attend an interview. A is known to be slower than B, but his final product is polished. B is much quicker than A, but although his final product is not quite as polished as A's, it still acceptable.

Who would you choose?

---------------------------------------------

An A for work done in one night in a rush? Do we have another Bill Gates on our hands? ;)

---

Candidate C....

Seriously.

It's a bad comparison... You're trying to equate speed with being good, and that's not true. Neither is the other assumption. You have to look at the why.... Why is coder A slower? Is it because he has to look things up every 5 minutes? Is it because they ask a lot of questions?

We have both kinds here... the quicker developers... and slower developers... and people in between. I myself flip back and forth depending on what I'm working on. Is coder B faster because he's been doing it for 20 years? Is coder B faster because he's been around the block more often.

So it's a bad comparison, which is why I'd hire Candidate C.

-tg

Unfortunately, candidate C was passed out after combining a batch of mushrooms with his typical 10 AM fifth of Jim Beam, so TG's wisdom was called into question and he had to try to find work as a hobo getting chased by railroad bulls.

I agree with TG that the question is invalid, though (despite his dubious affinity for that drunken wastrel C). Different people will have different levels of experience, but they will also have different perspectives, and even different aptitudes. Consider painters. There are some very effective painters, and there are some spectacularly creative painters who end up making gobs of money. Does it really matter how fast the latter are, and by extension, does it matter how fast the former are? I don't believe coding speed, code quality, and creativity (three items you touched on in the question) are necessarily related in any way. Suppose you have the highly creative prima dona who can't be encouraged to actually work, but when he does, the code he creates is brilliant. Alternatively, you have somebody who tosses together good code fast, but has no particular vision, so all his programs are fairly predictable. A third alternative would be the person who thinks things over incessantly, eventually ends up with something brilliant, but takes bloody forever to get there. And on and on. Those traits of speed, quality, and creativity, are all facets of a gem. You may get them all, you may get only one, you may get none, but they aren't mutually exclusive.

I haven't heard anybody mention business knowledge. Business knowledge harder to learn than a programming language by far, because you can't google it, and no one at microsoft is doing web casts about it. It just takes years of projects under your belt. So if somebody is coding really fast it may because they haven't thought of all the requirements for their program.

Quote:

---

Originally Posted by wild_bill

I haven't heard anybody mention business knowledge. Business knowledge harder to learn than a programming language by far, because you can't google it, and no one at microsoft is doing web casts about it. It just takes years of projects under your belt. So if somebody is coding really fast it may because they haven't thought of all the requirements for their program.

---

On the other hand, business knowledge is often not the least bit necessary.

I have worked as a contractor/consultant in the following industries:

Insurance
Banking
Adversting
Automotive
Education
Casino

I did not have then, nor do I have now, the least bit of understanding of how any of these business operate and what their business rules are.

I worked with a staff member who wrote up specs for me. My instructions were to make screens that do thus and so, and that is exactly what I did. More often than not I had no idea what any of what I was doing meant, but it worked, and pleased my clients, so I got paid, and therefore, was happy!

As it is now, I'm working in the Health Care industry and about 75 to 80% of the time, I'm completely lost with respect to business rules, but, I know how to write code, and I'm working with a very good B.A.

Quite frankly, the business side of things bores me to beyond tears and any day I can avoid learning anything whosoever business related about the industry I'm working in is a good day. :D

I don't know how business people do it. If I actually had to learn the business side of the house, I honestly believe I would look for a nice, tall bridge from which to fling myself.

If this is business we are talking about it's all about ROI - return on investment.

The bottom line is all that matters - you propose a project to a customer - agree on $$'s and now have to deliver.

You want them happy (few bugs - nice interface - easy to understand)

You want to be happy (didn't lose your shirt because it took 3 times longer to code then you expected).

I've had very slow programmers in house here - but they produced clean code that the users were very happy with.

I've had very fast / sloppy programmers - I still curse them when I come upon something they wrote.

If your colleague codes quick and well - as you stated - then what do you find suffering in his work? He sounds like the ideal candidate.

Lots of interesting responses!

szlamany: The user's experience will suffer. Although business rules are adhered to, tabbing in his documents is not intuitive; things like having the cursor turn into a Wait during long operations don't occur, and grids overrun forms (although, to be fair, that was in the specs, so yar boo sucks to the b.a.!) Also, I detect a lot of cut-and-paste from god-knows-where; when I asked, 'how did you come across this abstruse class bla?' he said, 'why, what does it do?' On the other hand, I feel, so what, the code works?!

I guess I feel fragile because even though I've been doing this for years, I still look things up 'every 5 minutes' (techgnome). What's that sql command for getting the identity in the current context...? Used it last month, but can't remember for the life of me is it ident_current or dbcc checkident? What's the freakin' Microsoft.Practices sql exception again, or can I use SqlException? Or System.Data.dbException, or something in the Microsoft.Practices.Enterpriselibrary.Exceptionhandling namespace? (Ended up using System.Data.dbException). And then there is remoting (those bloody configuration files!), xml, xslt, asp.net, vb legacy, html, javascript and trying to make sense out of examples written in c#! Yeah - I look things up every five minutes!

wild_bill: The b.a. on this project has driven me nuts! The 'technical' specs are arranged by business infrastructure, not by objects or classes. So if I am looking up a class I am working on, it might be in docA, B, C or - get this - obsolete docD. And then countless revisions which have not yet been commited in the Word document means that there are red lines through everything, and 'refer to page 161' is meaningless, because page 161 is now page 210! All through this contract, which ends on Friday 21st December, thank goodness, I have felt all at sea, because it is the first time I have worked on a project that I didn't understand at all. And six months later, I still don't understand! Which is why Hack's remarks:

Quote:

---

I did not have then, nor do I have now, the least bit of understanding of how any of these business operate and what their business rules are.

---

have put such a wide smile on my face.

I feel a lot better now, so thanks to all of you who wrote in. :)

Yes, there is a best programmer.

I am he.

chem

Quote:

---

Originally Posted by bigMeUp

...tabbing in his documents is not intuitive; things like having the cursor turn into a Wait during long operations don't occur...

---

Now you have made it clear - he is fast and sloppy - that's far from a good programmer.

A consistent clean experience for the user is a primary goal of any application.

A best programmer is one who can code in such a way that he gets everything right the first time (robot). He needs no debugging or unit tests (robot). He understands client requirements exactly the first time he hears them (mind reader).

Therefore the best programmer is a mind reading robot.

Darn - now you've blown my cover :eek2:

Back to 17 years ago when I did the Sofware Engineering degree, I was taught that
"Your boss will check your production by counting how many lines you can code a day."
That made me laugh when I saw a guy who coded an If statement like this:

Code:

---

If a = 1 Then
  b = 10
ElseIf a = 2 Then
  b = 20
ElseIf a = 3 Then
  b = 30
ElseIf a = 4 Then
  b = 40
ElseIf a = 5 Then
  b = 50
... ...
  ... ...
ElseIf a = 200 Then
  b = 2000
End If

---

How many lines for that If...End If ? You guess? 401 lines.
I was a stupid one when I coded it like this:

Code:

---

If a >= 1 And a <= 200 Then b = a * 10

---

That was only one line.
So his production was 401 times more than mine !!! !!! !!! :ehh: :sick: :ehh:
That means he was the best programmer.

Let's hope the relativity of productivity wasn't reflected in your salaries. ;)

Quote:

---

Originally Posted by anhn

Back to 17 years ago when I did the Sofware Engineering degree, I was taught that
"Your boss will check your production by counting how many lines you can code a day."
That made me laugh when I saw a guy who coded an If statement like this:

Code:

---

If a = 1 Then
  b = 10
ElseIf a = 2 Then
  b = 20
ElseIf a = 3 Then
  b = 30
ElseIf a = 4 Then
  b = 40
ElseIf a = 5 Then
  b = 50
... ...
  ... ...
ElseIf a = 200 Then
  b = 2000
End If

---

How many lines for that If...End If ? You guess? 401 lines.
I was a stupid one when I coded it like this:

Code:

---

If a >= 1 And a <= 200 Then b = a * 10

---

That was only one line.
So his production was 401 times more than mine !!! !!! !!! :ehh: :sick: :ehh:
That means he was the best programmer.

---

Either way,
you had a BIG issue when a > 200!
What would happen then?

In my vision it is very hard to become 'the best programmer'. A professional programmer should know some programming languages (e.g. Visual Basic, Java, C# etc.), a database management system (e.g. Microsoft SQL Server, MySQL etc.) and of course the essentials of UNIX. The state of being 'the best' means to know these tools and systems at perfection.

Therefore, 'the best programmer' should also be creative and have a mathematical and physical foundation to build effective algorithms. One can write code and even doesn't know what this code does, repeating the same parts more and more. The other one codes slowly, but creates a strict algorithm, a structured code and a better application.

A professional who has an aim to be 'the best' must understand how computer systems work, how they interact with the others, not just 'it works because my programs work'. 'The best' means to be a unique person, who knows every little aspect of a system, who can explain and even change the way the system works.

In my vision, 'the best' programmer is a person who can build reliable applications and effective code by using minimum of the effort and maximum of the creativity and knowledge.

Well. Theres many aspects of being better in programming.

You could set 2 people the same task and ...

One could do the task quicker
The other could have neater coding
The first could of made his project easier to edit
The other could of made his task better visually.

etc. Theres too many aspects. If there was a way to have somebody better than the other. There would be a Best programmer in the world. When their isnt really.

Quote:

---

Originally Posted by DelyProg

...and of course the essentials of UNIX.

---

Where the heck that come from!

I've never touched a UNIX box - nor have a reason to touch a UNIX box.

(I really cannot say that though - in using DCL (Digital Command Language) on DEC mini/mainframes we had to use lower-case unix syntax when using FTP).

It's not whether someone is faster or slower that's the issue, it's why they're faster or slower.

If someone gets his work done quickly by cutting corners and putting out a product that's just barely acceptable but not very user-friendly and runs slowly and another works slower because he makes the application more intuitive to use and takes the time to write cleaner code, then the second would be better.

If in another pair, one works quickly because he has more experience and has gone through the trouble of building and debugging similar code in the past, so he can draw upon what he's learnt previously and pound out efficient code in a timely manner and another works slowly because he's on google and MSDN every fifteen minutes trying to figure out how loops work and what this "object-oriented" thing he's been hearing of is all about, then the first is clearly better.

It all depends on a number of factors - unless, of course, one of the people is chemicalNova, in which case he appears to be the best, since no one would say that if they weren't.

We've been over this.. its me.

The End.

chem

Best programmer is a wide scope. Could be taken as many things. The old saying "Use the best tool for each job" would apply here as you would have the best programmer under each language or project type, least bugs, fastest or most efficient etc.

So you have to categorize what you are wanting to cover for this thread.

I believe that is why most commercial products are team developed.

It takes all types working together as a team to really produce good results.

Collaboration has been a key in our success here - even having good customers and users makes a huge difference!

Quote:

---

Originally Posted by DelyProg

One can write code and even doesn't know what this code does, repeating the same parts more and more.

---

Ha! Sounds a bit like Shlemiel the Painter.

Quote:

---

Who is Shlemiel? He's the guy in this joke:

Shlemiel gets a job as a street painter, painting the dotted lines down the middle of the road. On the first day he takes a can of paint out to the road and finishes 300 yards of the road. "That's pretty good!" says his boss, "you're a fast worker!" and pays him a kopeck.

The next day Shlemiel only gets 150 yards done. "Well, that's not nearly as good as yesterday, but you're still a fast worker. 150 yards is respectable," and pays him a kopeck.

The next day Shlemiel paints 30 yards of the road. "Only 30!" shouts his boss. "That's unacceptable! On the first day you did ten times that much work! What's going on?"

"I can't help it," says Shlemiel. "Every day I get farther and farther away from the paint can!"

---

I think the best programmer is not necessarily the person who is best at any particular task, but who can accurately identify the right way to tackle that task, by applying the right tool or combination of tools, and solving the problem in as simple and sensible a manner as possible. Given an hour to complete a job, he or she may spend 30 minutes of it on Google, or MSDN, or in a library, researching the best approach—rather than wasting time jumping head-first into the code and then not understanding why it fails later.


Of course, the debate is moot. Clearly, chemicalNova is the best programmer. :afrog:

Quote:

---

Originally Posted by szlamany

Where the heck that come from!

I've never touched a UNIX box - nor have a reason to touch a UNIX box.

(I really cannot say that though - in using DCL (Digital Command Language) on DEC mini/mainframes we had to use lower-case unix syntax when using FTP).

---

Yeah... once you start mentioning specific tools, it becomes less of a "who's good at it" discussion, and more "who's done this before".

Quote:

---

even having good customers and users makes a huge difference!

---

I'll second that!

Actually, one of the best skills a programmer can have IMO is the ability to second guess a customers business processes. The number of times I've had a conversation with a clients techy guy that went something like:-
>The system does this and it's wrong.
>OK, I'm looking at the code and you're right but have you considered that it might be doing it for a reason.
>Nope, it definitely shouldn't be doing it
>Well maybe it's doing because then you have the option to do xyz on the other form which you haven't bothered considering yet.
>Oh, errm, yeah, we do still need to be able to that, errm, hang on I'll check with the boss...

some time later:-
>Yeah, actually we think we'll want to keep that functionality for now... you know... as a fallback... until we can come with a better practice.

It's amazing how many customers don't know their own business processes. Of course, I've spent most of my career picking up other peoples systems after they've left the company so I'm second guessing the previous developer as well as the customer. Strangely, I usually find the developer was right first time but it does go both ways:rolleyes: