Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I've been observing programmers that are great at reading foreign, messy and undocumented code. At the same time they tend to also write messy code without documenting it. Is this common or just a coincidence?

My theory is that since they can understand almost anything, they don't see the need for quality code. While I'm not that good at interpreting foreign code, when I write new I try to show the intent in the code and use plenty of comments, so that I myself could understand it later. Does this make sense?

share|improve this question

closed as primarily opinion-based by MichaelT, durron597, GlenH7, Dan Pichelman, jwenting Jul 29 at 7:52

Many good questions generate some degree of opinion based on expert experience, but answers to this question will tend to be almost entirely based on opinions, rather than facts, references, or specific expertise. If this question can be reworded to fit the rules in the help center, please edit the question.

My experience has taught me that there is no such things as good code and bad code. There is only working code and non-working code. –  Manoj R May 28 '11 at 7:01
@Manoj R: Well, then you've either been lucky enough to never see bad code, or never been lucky enough to see good code ;) –  back2dos Jun 6 '11 at 9:04

7 Answers 7

up vote 1 down vote accepted

I don't believe there is such a correlation. And here is why. Experienced software engineers usually develop a good sense of code smell, that is, even before analyzing the details they can “smell” bad code. That smell works both ways: reading somebody's code and writing own. That's why experienced developers write “clean” (not smelly) code, even they just write a test, a prototype, a demo, etc.

On the other hand, sloppy developers have no sense of code smell. They eagerly take on spaghetti code without any bad feelings and even handling it seemingly with ease. But if you try to analyze what they do, they are skimming on the surface very superficially, making unwarranted assumptions, skipping details -- their analysis is of the same quality as the code. As a result when they tackle other messy code, they add a lot of new errors adding more mess, but they often don't know and/or care that software can be developed any differently. Interesting that many developers don't seem to improve in this respect no matter how many years of experience they accrue.

share|improve this answer
I think your description of the situation is very good. We are skimming on the surface, because it is hard to get a good understanding of the code. Because of this I'm afraid to touch it, but others seem to do better. Maybe they are not that good programmers after all? –  Purple Tentacle Jun 14 '11 at 19:38

No. I do not see any obvious co-relation between the two. Writing clean code comes from a passion of producing quality work. Reading messy code comes out of necessity.

However, I can see a case where if someone has only been exposed to "unmaintainable code" that person will be more prone to writing bad code. If that happens to be the situation here then I recommend you intervene and do some "coaching" and perhaps make him read the book Clean Code.

share|improve this answer

This sounds pretty normal and usual and I'm going to use analogies (oooh, evil) to demonstrate that. For starters and to stick to the reading/writing theme:

A good editor is not necessarily a good author!

Good editors or reviewers will spot mistakes in your grammar and style, and identify the blind spots in your story plot or the quality of your research. From these they are able to make very accurate and educated recommentations. Yet they probably would not be able to write the book for you, either by lack of content or by lack of style; even though they can rate you and assist you with both.

Similarly, nor do all critics of any kind have the ability to create the things they criticize: they simply have the knowledge to appreciate them. Examples include cooks vs gastronomers, directors vs film critics/movie buffs, musicians vs music critics, designers vs fashions critics, etc...

It's all very subjective.

share|improve this answer

I've always thought that my particular strength, as a developer, is dealing with other people's (often poor) code. Maybe it's because I've spent more time in my career doing maintenance than I have doing greenfield work, maybe it's just the natural way my mind works, but I've always felt I stand out from the crowd more due my skill at debugging, fixing and modifying existing code.

So yes, I think I'm pretty damn good at reading foreign, messy and undocumented code. I've done a lot of it, and I've figured out problems that had my co-workers scratching their heads.

And I really would hate to think that anyone looked at my code and thought it was messy or undocumented! As CoolBeans said in his answer, maybe if someone has only been exposed to "unmaintainable code" that person will be more prone to writing bad code. But that's not the case for me. I've worked with fine coders, collaborating on excellent code, and I've maintained the worst of the worst. I know what the difference looks like, I know what I like, and I strive to write code the way I want to see it written - clean, clear and maintainable.

share|improve this answer

I'd think it would be the other way around. I've spent way more of my life figuring out the intricacies of crappy code writing 10 or more years earlier than I care to think about. Over that time, I've developed an excellent understand of what I hate encountering when I'm maintaining code. From that, I think I write much cleaner code than I otherwise would have.

But these things always depend on what you want to get out of it. Some programmers might be somehow impressed with the convoluted cleverness of a piece of code they had to spend 3 days to figure out and take it as a blueprint for their own code. Others might think complicated code equates to job security.

share|improve this answer

I've seen this...

Now that I think of it, a lot of the "rockstar" programmers I've worked with were a little bit like this. They didn't write "bad" code, it just tended to be a very unique and hard to read style for others, and was severely lacking in comments. But they could pick up almost any hacky legacy garbage and get productive with it almost immediately. So I think the theory has some merit.

(I'm the opposite. I have a bad memory and can't even read my own code quickly after two weeks. So I make a very conscious effort to code (and comment) as if the code will be maintained by someone else - someone who is fresh to the codebase.)

share|improve this answer
I tend to notice the opposite effect... Most "rockstar" progammers I've had the privilege of working with might have had "strange" or "weird coding styles, but always produced code that was extremely easy to read (even when considering a difficult context). They are not only fast coders because of their typing ability and their agility to design a good and clean design from scratch, they also tend to have "code style built-in" and produce naturally sensical code. The rest are not rock-star programmers, in my opinion, nor are they hackers. Just skilled coders. –  haylem May 28 '11 at 1:07

Not sure you can write clean code without knowing bad code when you see it. Hard to imagine someone who has alway been capable of only writing good code and was never wrong. It's a learning process. I can go back to old code that I know think is bad and recognize what was wrong and how to make it better.

Maybe the problem is being so hung up on the site of the bad code that your desire to understand it gets clouded. I notice this with handwriting. Someone sees sloppy handwriting and just jumps to the conclusion that no one can read it and they have not make an effort.

share|improve this answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.