Is it more important to get the problem done or to write programs that are easy to follow?

Question

A guy I work with is outstanding at programming. He gets the job done quick and always has an answer to any question you may have. However, I was recently going through some of his code and found it to be really sloppy. He uses variable names like ulc and td, and he mixes instance variable declarations between method declarations.

I asked him about his coding style, and he said, "I just power through a problem then move on once it's working". (That explains his mixture of instance variable and method declarations) He apologized and said he was hoping to break the habit one day.

So, I was wondering, is a programmer good because he can get the problem done in a small amount of time, or is a programmer good because his programs are easy to follow? My guess is that the answer to this question is somewhere in-between the two extremes, but I would like to hear from others on this subject.

Similar questions:

How do you define a “good” programmer?

How to recognize a good programmer?

How Can I Know Whether I Am a Good Programmer?

Answer 1

A good programmer writes good code. It helps if he can write it quickly, but I don't see much value in being able to write bad code quickly.

Sooner or later, someone is going to have to read that code. If you've saved yourself one hour, but cost someone else three hours trying to figure out what the heck it was doing, wouldn't it have been better to just spend two hours writing the code properly in the first place?

As the C2 wiki page "Code For The Maintainer" says:

Always code as if the person who ends up maintaining your code is a violent psychopath who knows where you live.

If the code is never going to be used again, you can get away with doing it "quick and dirty." Most code doesn't end up that way though - even if it was originally meant to. "Quick hacks" live on for years and years, often because they're so dirty that no-one wants to touch them for fear they'll break something.

Obviously you don't want to go too far in the other direction and never produce anything - but I prefer quality over quantity in almost every case.

Answer 2

You are right: it's somewhere in between.

On the one hand, I've worked with brilliant developers who knew code inside and out, but couldn't get any work done because they were too busy building a space shuttle just to cross the street.

On the other hand, I've worked with developers who didn't know what loops were for.

After fifteen years in the business, I think a "good developer" is one who gets his work done and meets the expectations of the project. Code quality is a subjective (but important) metric therein.

Answer 3

Ask the programmer who has to maintain the code and you'll get one answer... ask the manager who sees his targets being met and you'll get different answer.

Answer 4

Well fast is not alsways good.
If you're a lonly developer coding your own tools.. than i think quick an dirty is good.

The Importance lies in maintainable code.If your code isn't maintainable ... no one can work with it.

Answer 5

Someone who can solve problems quickly (and correctly) is typically more valued by a company than someone who solves problems elegantly.

I just recently had someone on my team who I had to let go, even though he wrote extremely elegant code. He tested everything, he followed all the best practices, he knew his stuff. But as a result, he was SLOW. It took him 2-4X longer to finish something vs. his peers.

My advice - if your organization needs something quick and dirty (i.e. intranet portal, non-critical app, etc.), don't spend a lot of extra time doing things the "correct" way. Follow the path of least resistance.

Answer 6

This basically comes down to quality versus quantity issue for me.

I've been around a lot of developers that can "sling" code with the best of them. With these developer types, I often find their code to be fragile and hard to follow. Yes, they get it done quickly, but it requires an awful lot of maintenance and back-and-forth with the test team.

I've also worked with very methodical developers that take a more disciplined approach to programming. They can write short sequences of code just as fast as their code-slinging brethren, but they are constantly re-evaluating the design and double-checking that things work correctly. Their code typically has a simplistic elegance to it and is straightforward to follow.

Given a choice between the two, I prefer disciplined programmers to the code-slingers.

Answer 7

A good programmer writes clean, understandable, maintainable and efficient code and also gets the job done.

But for high management sometimes getting the job done faster is what counts.

Answer 8

A good programmer is someone who can solve problems quickly and produces code that is easy to maintain.

There is no point in writing the perfect code, if it took you several more days to write it, and on the flipside, there is no point to writing code quickly if it's a nightmare to maintain it.

Answer 9

A good programmer is someone who is always questioning his own work and always looking for ways he can improve his code.

We can talk about hundreds of good things you can do in your code, but above all it's about recognizing your own weaknesses and having the drive and passion to invest in your own skillset.

If you can do that, there's no limit to how far you can go.

Answer 10

Other answers have addressed your main question pretty well. I'd just add that, personally, I don't care so much about the quality of the code as the quality of the comments. Descriptive, consistent variable names are always nice, but I don't have a lot of difficulty following code that uses one-letter variables, provided the author has left behind some description of what they are.

Also, a lot of code that you have to read is just a stepping-stone on the way to some final block of code that actually has a problem. Good comments let you avoid having to read that code at all, which saves an order of magnitude more time than just making the code clean.

Answer 11

It needs to be a balance between the two. At one end, the fastest code to write will be the hardest to maintain and cost more in the long run, however if you follow all the principles, do everything exactly by the book, you'll never get anything done. Sometimes you need to remember your purpose is to make your company money, not write the prettiest code.

Answer 12

In my mind, a good programmer is an Agile Programmer in that they iteratively improve themselves, one small step at a time. They also unit test their skills through self-reflection and seeking out constructive critiques from others.

Answer 13

I think an important measure of a good programmer is knowing when not to write code. My heart always sinks a little when I see a bunch of code heading off re-implementing something that already exists and has been tested and proven by the community.

For me, a little questionable code gluing together solid, dependable libraries is much better than awesomely well written code that's totally unnecessary.

I guess that needs your programmer to be on top of the developments in their chosen technologies, too.

Answer 14

I assert that a good programmer is like a good writer: the programmer is able to write succinctly and clearly to a broad audience.

Programmers and writers have many things in common. Among them:

1. Both are tasked with putting abstract ideas into words.
2. Both can produce output that is deemed beautiful.

Anybody can get a piece of code to work and perform its original task, but the adept programmer is able to write code so that anybody else can understand the code and modify the code should there be defects.

Answer 15

I agree with good code, and all the good answer prior to this one BUT a good coder/programmer is also starved for knowledge and always looks for ways of learning new skills, techniques and languages.

Answer 16

A good programmer meets requirements.

I'll let that settle in a bit...

The real problem is that most people don't know what their requirements are.

If you expect a program to run well and have few bugs, that's a requirement. A good programmer will use reasonable testing and QA methods.

If you expect a program to be used and maintained for 3 or 4 years, that's a requirement. A good programmer will write clear, readable code because maybe somebody else will have to maintain it.

If you expect an audit trail and accountability, that's a requirement. A good programmer will probably produce alot of models and use cases before writing any code.

but.. If you expect a program to be delivered next week and only perform a specific task once. A good programmer better not waste any time at all on the processes mentioned above. A good programmer in that case could be the guy mentioned in the starting question.

Answer 17

If it's a simple program then if he can get the job done fast that's just perfect.

But if the program is even a bit more advanced it is very important for the code to be clear even if it takes longer to write.

Answer 18

I was just working with some code and realized something.

I am completely incapable of dealing with complex code. I'm not good at guessing, and if I can't get an entire block of functionality in my head, I'm totally useless.

That said, I'm really good at simplifying code! I can isolate a block, snip the wires that tie it to all the other code, break it down into small, understandable classes and repeat.

I just took a really annoying class that had an array and did its own stack implementation with the stack logic and business logic tied up together.

When I was done, I had replaced it with three tiny classes (only the original class is public, it's API hasn't changed), and each is understandable by a first-year student.

If I'm stuck in code that I can't refactor--I'm done. I think the the biggest thing I can bring to a code base is my ability to simplify it.

I think this is why I disliked my year-long stint in ruby so much. The inability to see all the "wires" that tie the code together drove me nuts. Java (more accurately, it's static typing and the fact that reflection is hard enough to be rare) is constrained enough that I can know 100% of the effect of any change I make, regardless of how poor or "Tricky" the original code was.

That said, I work well with "Good Guessers". People who don't have to understand all the code and can just dive in and fix stuff. I can't do it, but I appreciate the talent!

So I can't tell you what's good, or even if I'm good, but I've never regretted coming back to my own code and I've met very few other programmers who can say that.

Answer 19

Without seeing the code, it's hard to tell if it's truly sloppy or if it simply fails to live up to a set of standards that may not be appropriate for the circumstances. The two critiques you mentioned don't sound too terrible to me.

But I do think that coding style matters in equal portions to coding speed. (But coding speed is often a good indicator of good style in my experience.)

Answer 20

Someone that uses there head and is not dogmatic is a good start

Answer 21

If you search, you can find 1010011010 on the scalp.

Answer 22

This has been touched on by others, but it bears reiterating: being able to knock out code fast is not the sign of a good programmer.

Don't get me wrong - speed is important. I've worked with several people who could crank out systems like you wouldn't believe, but they did it by sitting down, and just banging out code until it was "done."

For small projects, that's fine. But these guys would do this with multi-million line mission critical apps that were developed over the course of several years. So when the specs change (and they always change) stuff that should have only taken a few minutes to patch in suddenly took days, as they had to essentially rewrite whole modules from scratch.

This is just a back of the envelope style guess, but I'd be willing to bet that on more than one project, an extra day or so of actual design work up front would have cut the total hours on that project by a third.

To wrap this back around to the actual question: a good programmer knows when to spend the extra time getting the design in place, and when to just crank out a script that no one will ever look at again.

Answer 23

Easy, a good programmer is somebody that starts counting from 0... :D

Answer 24

A lot of the answers say that a good programmer should know to throw his principles over board when faced with an impossible deadline. I disagree. I think, a good programmer is one that can perform under pressure. A quarterback who can only throw when he is not attacked is not a good a quarterback. A musician who can only play when noone's listening is not a good musician. A soldier who loses his head as soon as someone shoots at him is not a good soldier. And what would have happened to the passengers of US Airways 1549 if Captain Sullenberger had thrown all good principles of airmanship over board, just because he was in a stressful situation?

And a programmer that resorts to spaghetti code when the deadline looms is not a good programmer.

In one of the answers, someone wrote that when the deadline nears one should take the path of least resistance. So, we have to make sure that following XP practices, doing TDD, following the SOLID principles, writing clean code and all that goes along with it, become the path of least resistance.

The question is: how do we do that? Well, how do these other guys, athletes, soldiers, musicians, pilots do that? The answer is: practice and training. Soldiers spend 40 hours a week training for stress events that they hope will never happen. Before the successful ditching of Flight 1549, it was widely believed to be impossible to safely waterland a large commercial passenger aircraft, and yet, simulator training for this event is mandatory. Programmers OTOH usually do not train at all, even though they know that they will have to code under a deadline.

One idea that for example Micah Martin has tossed around, comes from martial arts: Kata. Kata are a ritualized performance of a strictly defined sequence of strictly defined, usually pretty basic, moves. These moves are usually not technically difficult, nor physically demanding. Kata are also very short, typically just a few minutes. What's most important about a Kata is not just that you perform the prescribed moves, but how you do it. Another important aspect is that Kata are actually performed, together with others, in front of an audience, your fellow students, your master and sometimes judges.

A Kata should be a simple coding project that takes no longer than 10 minutes to complete. You should do this over and over again, practice daily, and more importantly perform regularly in front of your co-workers, your local usergroup, or at a conference. And you should ask them to judge you.

If you want to see what something like that looks like, Micah Martin has publicly performed his Kata a couple of times, for example during his talk at RubyConf 2008.

Ask yourself: when was the last time you completely threw higher-level control flow constructs out the window and used only GOTO? We are so intimately familiar with for, foreach, while, until, repeat, loop, map, reduce, filter and friends that we would never even dream of GOTO. And I believe that with enough practice, the same can be achieved for testing, factoring, DDD, TDD, SOLID, and everything else.

Answer 25

There are two measures by which to judge a great programmer and to me they are of equal importance:

1) The code must be correct. Simply stated, that given a set of inputs, the code generates the expected set of outputs.

2) The code must have a aesthetic aspect. There must be a simple elegance and an "inner" beauty to the code. Simplicity and generality are valued (not necessarily conciseness). From this all good things flow: the code is easy naturally easy to understand by others, the code is easy to test, and the programmer gains a strong sense of satisfaction from job they have done.

Check out this slide slow on beauty in Mathematics: http://www.medialism.net/mathematik. Listen to chapter five and replace "Mathematics" with "Programming" and you will get the idea.

Answer 26

Short answer

Getting the problem done is critical. Beautiful code that doesn't work is of no value to the customer.

Long answer

"It depends" ;-)

Going strictly from your description of the "issues":

• terse/poor variable names
• instance variable declarations in between methods

From a management perspective:

• is the code unreadable, or just not quite as good as it could be?
• is it cheaper to pay a code monkey to group declarations and rename variables?

From a developer perspective:

• how much would it "slow him/her down" to develop better habits?
• how valuable would it be to the team for him/her to do so?

Obviously, the "best thing" would be for the developer in question to develop better habits, because good habits will not slow him/her down significantly. But working code is far more important.

1. Make it work
2. Make it fast
3. Make it pretty

Step 2 can be skipped if performance is satisfactory. Step 3 can be skipped if time is a factor. Yes, this incurs some "technical debt", but it is cosmetic, not mechanical, so you can carry a lot of it for quite a while.

If you have unit tests, have an intern/code monkey go back and make the uber-developer's code pretty. Then show him/her the difference and ask if it would be too much trouble to conform to the company standards a bit better (you are talking about company standards, right, not just your personal preferences?).

Answer 27

In order of priority: 1. Make it work right 2. Finish it 3. Refactor as time allows

Answer 28

The question is really a comparison of two extremes. A good programmer is somebody who can get something done reasonably well in a reasonable amount of time.

Answer 29

There's been an idea called "technical debt" floating around, and this is a good place to use it.

Your colleague is running into debt on the code. Today's fix is quick and easy. Keep it up and a fix next year is going to be difficult and uncertain.

It's like using a credit card. You run into a problem, and you deal with it by charging more on the card than you can pay back immediately. This isn't necessarily a problem, but if you keep doing that you'll find that you're losing money on interest payments, you're losing morale from looking at the amount due, and you can eventually reach either the credit limit or a minimum payment you just can't afford.

Sometimes it's worth it. You may have to fix X right now, or you may expect good things if you get Y out of the door by the next trade show. Similarly, the company might go into financial debt either to correct a problem (a lawsuit or recall), or to make more money later (investing in a new facility). The financial people at your company are aware of this in great detail. They will also have plans for how much debt is acceptable, and what to do about it if it starts growing out of hand.

Similarly, a good software manager will have a clear idea of how much technical debt (i.e., messy code) to tolerate. (A bad software manager is much like a bad money manager.)

That being said, it sounds like you've got a good opportunity to work with this developer and help him write better code.