How to understand the why/reason behind programming?

Question

As a beginner programmer, I often look at code and wonder why it was done a certain way or the reason why someone chose to implement a method one way over the other. Usually my lack of expertise or knowledge sometimes makes me feel frustrated. What are ways to not only know what someone did, but the reason why they did it, so if you ever got into debate, you would know what you are talking about?

Answer 1

One way is to go directly to the source -- ask the person who wrote the code, and ask for reasons why the code was written in a certain way.

If the original author is not available, then ask someone who knows more than you on the subject you are having difficulty with and ask questions.

Don't miss out on an excellent learning opportunity!

Answer 2

Do you think that is possible. Unless you specify in comments why or what you are doing, the person reading it for the first time will not understand.

Reading the code for sometime will make you understand how it works. But you cannot say why it was written like unless its documented somewhere.

Answer 3

Your best bet is to find somebody who knows more than you and is good at explaining it, and ask questions. Your second best bet is to read some books on the language you're using, and see if they explain why. Some languages have books dedicated to explaining how to write in that language and why.

Answer 4

I wouldn't worry to much about this. I often look at code that I've written myself and wonder why I did things a certain way.

It's probably only investigating if someone has done something that seems strange in some way or is something that you would have never done, as this may indicate a gap in your knowledge (or a bug in the code). If one approach seems peculiar to you, you should be able to ask anyone why the chosen approach is valid and not just the original coder.

How often you encounter this will vary on the language you're using and environment you're in. If I was being glib I would say all languages are on a scale with Perl - "There's more than one way to do it" - at one end and Python - "there should be one - and preferably only one - obvious way to do it" - at the other.

Answer 5

Normally comments should help you but it's all about how that subject is obvious based on your expertise and the original author's expertise.

I do try to comment a lot if I'm doing something which I'm haven't done before or I do rarely, unless you are lucky to have some good comments I don't think it's possible to figure out why.

Answer 6

Probably the easiest way, if possible, is to ask the author of the piece of code.

You can also search for comments in the code. Some authors will explain why they chose their approach.

As a new dev (and really devs at any level), participate in code reviews. That is a time to ask questions and see people defend their decisions.

For me, it was a combination of reading some great books (like effective c++), and working with experienced developers. As you get more comfortable, it becomes second nature.

Answer 7

As a programmer with 25 years of professional experience, I "often look at code and wonder why it was done a certain way ..."

Often, the original programmer didn't know any better. Unfortunately, you can't depend on that --- you really have to go to the original programmer and ask "wouldn't this work better?"

But those case are usually obvious. More confusing are the times that the code is there is handle some exceptional case, or perhaps some special user requirement, that no one bothered to document. (Often, these are no longer valid, but the workaround to deal with them remain)

Answer 8

I don't want to duplicate the great answers suggesting going to the source, so won't but do want to add that while reading other peoples code and having it explained is a great learning tool, don't get too caught up in the why. We're all human and on any given day our moods, experiences, etc, affect the code we write.

Over time you'll find yourself able to read code more easily, so it's just a practice thing, the more you write the more it'll read naturally for you. However, as others have indicated, you may still be unclear as to why you wrote something in a particular way let alone the thought processes behind another's code.

Programming is a creative art and although there are models and methods and architectures out there, how you implement them will always be down to the moment you lay finger(s) to keyboard. If you ever work out how to write it the same way every time and for it to be perfect please tell me how :)

Answer 9

Sometimes, things are implemented in a certain way because it's an easy or common way of tackling a problem. A lot of problems fit into a few distinct patterns, known as 'design patterns'. Of course these don't describe how to implement a single function point, but as an architectural aid they make some sense.

Answer 10

Very often the code you're looking at was changed few dozen of times. So it's not actually possible to understand why, without knowing how it was done before. Especially true for heavily optimized code.

So I agree with Coobird, asking the author may be the best option.

Answer 11

I don't think it's that cut and dry. Sometimes if you look at code and wonder why it was done a certain way, the answer might be "management is forcing me to do 2 weeks of work in 2 days, so I'm going to make it work the fastest, dirtiest, and ugliest way I need to". The more you know about design patterns and the generally agreed upon "best practices" of the language and environment you're programming in, the more it'll make sense though. But honestly, you can't always tell.

The real lesson to learn is to pay it forward and always remember to comment your code. I often put comments above my method that have a conversational tone so that the next person who has to pick it up really gets where I'm coming from (beyond just explaining the functionality in technical terms). I'll even be honest and put things like "This is ugly as sin, but we're pressed for time. Feel free to refactor...".

Answer 12

I think one of the more interesting things about this job is diving into some strange code and figuring out how it works. You learn a lot about the code, the environment and the programmer. It's the modern day equivalent of exploring, or taking something apart to see how it works.

Answer 13

This is exactly why comments exist. You can't assume that the person who wrote the code is available (It's interesting how many posts here assume he is...)

I often want to know why someone did something--sometimes I see cryptic, piece of code. My first thought is that the guy didn't know what he was doing and I should re-write it. Sometimes I've realized that he was implementing some strange hack and that code couldn't easily be replaced.

I often just want to see comments just so I can figure out the level of competence of the author. Without comments, I often have to assume that his level is "in".

Answer 14

This is a skill that can't really be shortcut, it has to be learned through experience and - critically - reading a lot of code. Nonetheless, you can usually get a good idea of the mindset a programmer had when they wrote the code by looking at whatever comments there might be, and then the naming of variables, functions, classes, files etc, which if chosen well (or even half-well) will tell you something about how the original programmer thought about the problem.

Think about what metrics of success they were using - is concise code better, for example, versus verbose code? If so, why? Does speed of execution or consumption of memory matter in this context? If so, you should be looking to see if the algorithms are efficient. I think being able to figure out the context in which some code was written is key in understanding the original author's mindset if you don't have access to them.

As you read more code you'll start to spot patterns than mark out particular philosophies, schools of thought, competence levels etc. I don't just mean Design Patterns and common algorithms - I also mean ways of dividing up code into modules or objects; ways of parcelling up work into functions; neat or concise ways of expressing particular problems (for example, use of the ternary operator ? in C# versus writing if...else. Not that everyone agrees that this is a good thing of course <g>). You'll also, sadly, learn that there's an awful lot of really bad code out there :-(

Taking this particular journey is one of the most fun, and most frustrating, things about doing this job. I both love and hate it in equal measures. Hopefully you will too.

Answer 15

I always start with the interface to the code, whether it was rigorously defined or more ad-hoc. That should hopefully give you a good idea of what it's supposed to do.

When you're trying to figure out how it does what it does, you read the code--which is really akin to executing the code in your head. You can get an even better sense of what's happening if you execute the code in the debugger. Watch local variables change, watch the flow etc. This is practical and easy if there are unit tests for the code.

As to why things are done a certain way--if you don't have access to the source (the original author), that comes from experience. You can quickly gain this experience by writing lots of code yourself and analyzing code from others.

Answer 16

The only real way to find out why the code was written the way it was is, as already noted, to either ask the person who wrote it (if they're available) or read the comments in the code (if they're available).

If neither author nor comments are available, the best you can do is to examine what the code does and how it does it, then ask yourself what benefits or drawbacks there might be to doing it that way. Even if you have the author and comments available, this is an excellent exercise for learning new techniques and honing your skills.

One other point to keep in mind though, which none of the other answers have explicitly pointed out so far: Just because the code you're looking at does things a certain way, don't assume that it's necessarily done the best (or even a good...) way. The person who wrote it may have been distracted, tired, drunk, in a bad mood, trying to meet an impossible deadline, or just plain not very good at it. Learn what you can from the code, but don't assume that. just because you're a beginner, you should emulate what you see.

Answer 17

I believe it's good to make your comments describe your assumptions and intents. Unfortunately that isn't the way most of them are.

The best thing is to talk to those you can about why they do something. If you have friends/acquaintances that are experienced, ask to read some of their good and bad code and then talk to them about why they did things a certain way.

For the long haul I believe it's best to expose yourself to as much as you can, experiment, ask questions, and come to your own conclusions.

Answer 18

The practice of programming also brings patterns. The code repeats itself very often, you will notice that.

Improve your skills in programming and software design and you will see the reason behind each line of code. As well as seeing no reason at all and changing it.