Do good code readers write bad code?

Question

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?

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.

Answer 5

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.

Answer 6

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.)

Answer 7

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.