When reading others code do you usually have any troubles understanding it, Or its more usually that you question the others code about it being wrong/non-efficient/bad-formatted(etc)?

Someone reading what you coded on your first job

  • You become assimilated. You become part of the One. Commented Sep 26, 2012 at 16:46
  • 1
    I have to say that in a professional setting, you are generally going to be fixing the broken parts which tend to be the worst parts of the code. My experience is that it's almost always like your cartoon. If you are fortunate enough to work somewhere that software quality is critical to business success - and the company appreciates that - then your experience will be much better. But fixing bugs and extending things inevitably leads you through the worst parts of any code base. Commented Sep 26, 2012 at 16:53

3 Answers 3


These days I don't have much problems reading other people's code. I've seen so much bad code, that I can even diagnose what sort of evolution led to any I find.

More often than not, professionally bad code is code that started out okay, but best practices, requirements, or skillsets moved out from underneath it. Sometimes it is just someone who is bad or new to the language, but that's pretty apparent too (and uncommon in a professional setting). The more I understand why code rots, the less I question the competence of other programmers.

  • 9
    +100 for "the less I question the competence of other programmers". I think the sometimes present "clearly an idiot wrote this" attitude creates an environment where newbies are scared to ask questions (or "non-idiots" don't question their own practices enough), which in turn leads to bad code. Commented Sep 26, 2012 at 4:10
  • 1
    @TimothyJones You realise that it is actually possible to award +100, by way of the bounty mechanism? Commented Sep 26, 2012 at 4:46
  • 1
    @DavidWallace I'd forgotten, thanks. However, then I won't be able to comment any more. Perhaps I will come back and do it when it's not all my rep. Commented Sep 26, 2012 at 4:54
  • 3
    The worst is when you say, "Clearly an idiot wrote this" just before you realize that you are looking at your own code! Commented Sep 26, 2012 at 16:45
  • 1
    @GlenPeterson, No, I'd say the worst is when the one who wrote it stands right next to you...
    – Svish
    Commented Oct 16, 2012 at 9:04

This may be the result of this development process.

In the last 2 years I have working with other people code. I have debugged it, fixed bugs and made improvements. In my experience I usually think that the code is bad, full of bugs, slow, consumes much more memory than needed, used programming concepts inappropriately, really bad formatted (this is hard to live with), not commented and the logic flow is a mess. What if I tell you that I found one function with 5k lines of code?

So in my experience I usually question the quality of code. If something is hard to understand, because it is complex, it make sense after you understand it. But if it is just bad it will always be bad.


Short Answer: Mostly we don't like it or get very critical on why coding is done this way, and not the other way around. However, more you read other's bad code, faster you appreciate well written code :)

Although it may sound obvious but the best way to get better at reading people's code is: by reading people's code. The problem is that when people typically read other people's code they don't try to "grok" it, i.e. become intimately familiar with it; they do the equivalent of speed-reading poetry.

To grok someone else's code you may try the following:

  • Refactoring the code.
  • Choosing a feature to add that requires going into the depths of the code.
  • Writing comprehensive unit tests for the code.

All of these steps will force you to read the code in greater depth.

There are also some tips how to maximize the understanding of a code-base, that you have been introduce for maintenance and support:

Once you have a basic idea of what's going on, you may want to take a good look at the data storage (the persistence layer). That's another great way to get an understanding of what's happening, but make sure the things you are studying are actually in use. I can remember a few times really getting to the bottom of some classes with this approach, thinking I've understood the system - and then realizing later the classes weren't used at all.

It may seem like a daunting task - it does take time and no fancy tools can remove the need for intelligence - but it can also be very rewarding. As you go, you will probably find a lot of bugs in corner/edge cases, and see ways to improve the code. One piece of advice - don't go too heavy on refactoring / changing until you have a good understanding of the code. Often what looks like a mistake or just plain bad code when you first see it, turns out to be subtle genius at work upon later, enlightened investigation. Also, removing unused code is so satisfying, and great for any future maintainers. Of cource, with the assumption that all code base is version controlled.

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