Me and a friend of mine were discussing yesterday about differences between writing a large C++ software and understanding it as a new recruit.

Is it possible that since a software gets done one line at a time and this process resembles how we (humans) learn things and build a thing on top of another one, writing a large software is actually easier than reading it and understanding what it does (stepping through the code helps but you need to remember multiple classes/source files together you don't even know what they've been written for, multithreaded code adds malus points)?

This sounds weird at first but after we thought a bit it seemed reasonable

  • 1
    Brief explanation of the closure: While this is an excellent question, it's also one that simply can't be answered, only discussed (extensively). There are too many factors to consider, code quality and style, the reader's learning skills and familiarity with the project and the language, the project's size and so on. If you are interested in further discussing the closure, there's already a question about it on our Meta site.
    – yannis
    Jun 8, 2013 at 12:36
  • The book "Apprenticeship Patterns" talks about the Journey from Novice to Master Craftsman. It answers many questions of novice, apprentice, journeyman level programmers in their career-growth. It takes some time to use many of the patterns but that is part of the journey. One of the patterns is to write 'Broken Toys' or 'Prototypes' which help one to figure out and compare with production systems. There are many more useful patterns.
    – GuruM
    Apr 14, 2014 at 21:27

8 Answers 8


Based on my experience, I would rank the following activities in order from easiest to hardest.

  1. Reading good code
  2. Writing bad code
  3. Writing good code
  4. Reading bad code

The above ranking leads to 2 conclusions

  1. While it is easier to write code than reading bad code, it is easier to read good code than write your own code
  2. Writing bad code is easier than writing good code, but writing bad code sets you up for reading bad code, which is the hardest thing of all. Especially since bad code is read more than it is written.

Of course, good code and bad code are broad generalizations. I recommend Code Complete and Clean Code for more details about good code.

  • A lot of other things can lead to "bad code" - lack of internal consistency, unifying vision, or planning. A general lack of planning or proper modularization of code. I've seen good code that was pointless because it didn't use built-in language features that would have worked just as well.
    – Ben DeMott
    Jun 7, 2013 at 15:18
  • Also, how to write good code: cdn.thenextweb.com/files/2011/01/65987_700b.jpg
    – CurtisHx
    Jun 7, 2013 at 16:00
  • 2
    In my scale, reading bad code remains easier than writing good code. At worst, you can launch a debugger on bad code that you are trying to read, or edit it with a refactoring tool.
    – mouviciel
    Jun 7, 2013 at 17:13
  • 3
    Writing bad code is only easy up to the point where it has to integrate and work, or change with respect to changing requirements. If you "program yourself into a corner" then it's no longer easy.
    – Kaz
    Jun 7, 2013 at 18:11
  • @mouviciel Reading bad code written by very clever programmers who shouldn't be writing bad code can be hard. Reading bad code written by naive programmers is easy. Just put on your "naive hat" and it becomes obvious what the code is failing at trying to accomplish. :)
    – Kaz
    Jun 7, 2013 at 19:18

This question appeals to a False Consensus. http://en.wikipedia.org/wiki/False-consensus_effect

Different people learn and absorb information differently. It's akin to auditory learners, visual learners and kinestetic learners. For some, reading code is easier, for others, creating code is easier. For me, it is the latter. For others on my team, it is the former. I don't believe finding some kind of consensus or majority is useful. It is better to understand how your brain absorbs and learns information and use that knowledge to make yourself better and to learn to accept others who are different.

  • 2
    Surely asking the question and canvassing opinion is far better than simply believing this (or any other) hypothesis is automatically correct. Recognising how various people approach the same problem can often have a positive effect on how teams perform as well improving social interactions.
    – Robbie Dee
    Jun 7, 2013 at 15:00
  • 7
    You are absolutely correct. Asking is the beginning. And, understanding that there is a False Consensus is beneficial for understanding. That's why I "answered" the question instead of simply ignoring it.
    – mawcsco
    Jun 7, 2013 at 15:03

differences between writing a large C++ software and understanding it as a new recruit

This isn't the same thing as the difference between reading and writing software. When you're new to a project (and especially when you're new to a company) you have a lot more to learn than just what the code does. Understanding why the code does what it does often requires an understanding of how the business works and how the project relates to the rest of the organization. In short, reading code without the benefit of background knowledge is a slower, more difficult task than reading code when you fully understand the context in which the code works.

There is a difference between writing brand new code on a greenfield project and reading and modifying existing code, but I wouldn't say that one is necessarily easier than the other, just different. When you're creating something new, you don't have to worry about how to make your code work with what's already there, but you do have to worry about making your project sufficiently extensible and adaptable that it'll remain useful into the future. When you're working on an existing project, you can often use what's already there as a guide, but you must first understand what's there.

As a "new recruit" it's usually better to work on an existing project specifically because it helps you to learn all the things you don't know: how the business works, how the various projects work together, coding standards and practices, and even (especially) what could be improved.

  • Understanding a 'context' breadth/depth of system and underlying API with experience. What are the logical components of the system? How do these components interact with each other? What mechanisms do they use of the underlying building blocks? How do underlying building blocks behave in different paths? What are the constraints/goals of the system? Why certain path-ways were chosen over other candidates? If you need to add a new component what could you reuse and what do you need to add anew? Can you see from 'inside the system'? A Super book to see Pragmatic Thinking and Learning.
    – GuruM
    Apr 14, 2014 at 21:20
  • Building a 'Prototype' or a 'Broken Toy' (with known deficiencies and only to explore alternatives) would help to "force" oneself to think out the questions above. Adding components and adding features followed by Refactoring would help one get a "feel" for the issues at hand and candidate solutions (via forum search maybe).
    – GuruM
    Apr 14, 2014 at 21:31

It's an interesting question, but I would tend to lean towards the side of it being easier to read and understand than it is to create it.

If you are a veteran, seasoned programmer, then you are likely to read through code and go "Yeah, good choice, check, oh, I might have done X instead of Y", etc. You may modify or tweak, but that would save immense time over writing from scratch (Unless there are reasons for doing so).

If you are a newer programmer, then "you don't know what you don't know", and so you are going to have to invent/learn all the little things, and very likely you are going to have some inefficiencies in the code. You will likely develop a greater understanding of the language, however.

But in both of those cases, it's going to be easier to read the code and go from there than it is to write it completely from scratch.


Most programmers find it easier to understand code they wrote themselves compared to code other people wrote. This is due both to the line-by-line learning you mentioned, as well as just a matter of individual style and talent. That's why so much wheel reinvention happens.

However, that's the view of the trees. The forest view is that it's much easier to read code than to write it from scratch. For example, is it easier to write a new word processor from scratch, or to learn an existing code base well enough to make improvements?

When you start reading the code, you can think of a bazillion ways to make the code easier for yourself to read. You spend the first while just tracing code around, trying to figure out the lay of the land, sometimes in an architecture completely anathema to how you would like to do it. But even in really large code bases, you'll spend maybe 40-80 hours spinning your wheels, compared to the hundreds of thousands of man hours already invested in creating that application.

  • Can you write code and not understand it? Copy maybe.
    – JeffO
    Jun 7, 2013 at 16:56
  • @JeffO All the time - lol...
    – Robbie Dee
    Jun 10, 2013 at 8:54

The person writing the piece of software will almost always have the best understanding of the program simply due knowing the logic and his/her thinking process while writing it.

I don't think that writing code can at all be compared to reading code in terms of ease of understanding. On one hand, simply writing software provides greater understanding of that specific piece of software due to knowledge of the context associated with each section of code, library used, etc. However, reading code that others have written can be difficult to understand in terms of the actual piece of software, but in terms of understanding the language it can provide insight into new ways of doing things or uses of a library that you might not have considered using, which can lead to making your life writing code easier.

In terms of build knowledge, I think reading code and writing code are very connected and in many ways build on each other. Experience writing code provides ease of understanding others code, and reading code allows you to have an easier time writing code (through new logic concepts, library use, etc).


This is something that I've personally felt to be self-evident, but I've never been entirely sure that it holds for the programming populace as a whole. For example, I've known some very talented coders who rather than read documentation, can happily pick through other people's code and comprehend it as if it were their own.

This leads to the question: does this matter?

If you're reading the code, then chances are you're making a change rather than rewriting it. Even if you are rewriting it, you're likely to be writing this in a new language/version and so you may not necessarily craft the code in the same way. The point I'm making is that it isn't always necessary to understand all of the code all of the time.

All this being true, newer development methodologies e.g. BDD do recognise that it is important for the business logic to be clear from the code rather than the code simply being a means to drive the machine. This of course is nothing new - the concept has been around since Donald Knuth's seminal work: Literate Programming.


I'm into StMotorSpark's answer, just adding:
It depends on so many factors it can't be a yes or no question, for instance:

  • Is the existing code well documented and well written or does it look like a spaghetti without any sense or comments?
  • Is it a tiny app with very rare situations that cost you endless time to find out how to solution, or a larger but simple app?
  • etc.
  • 1
    Very good points; however, I would argue that it is more dependent on the person. For instance even if there is some code that has almost no documentation, it can still provide insight in the form of "That's weird I wonder what that is". If someone really wants to learn, they will find anything helpful regardless of size of the program or documentation. With that in mind though, good documentation and code that isn't over the top in size help substantially. Jun 7, 2013 at 14:55
  • 1
    Fully agree, it depends also a lot on the person. Just notice that due to owr job requirements some of us do a lot of development from scratch while others do a lot of maintenance. This will inevitably perfect two different expertises, no matter if they started both with the same well organised way of thinking, same level of logics and language specifics understanding, ... Jun 7, 2013 at 15:02

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