Is it okay to not completely understand code functionality? [duplicate]

Question

As I am currently struggling with learning WCF for a project at work, for the past several days I have been looking at online tutorials and examples on the best way to make a WCF client; and today, when I told my boss I was having a hard time finding good tutorials because some of them would not go into details with their examples (for instance showing a piece of code that works but not explaing why exactly, or making an example with just a few lines instead of at a larger scale), he told me that I should not try to understand them completely, because there are times where a code will just do what it does and I should leave it at that (he gave me the example that when doing calculus, for instance, we use formulas that we don't know how they were conceived or how they work, we just know that they do and we use them).

And this bothered me because I have always been told that it's really important to understand your code, and that just copying and pasting without knowing HOW it works is practically a sin; which is why I always take my time in understanding something before moving forward with it. And it's not like I'm trying to understand how a particular class works at an assembly language level, I just want to know why a set of instructions does the trick, and why another one doesn't, or why both do and under what circumstances. But my boss tells me that I will end up wasting time obsessing over these little details, and I should just skip it. So my question is, is he right? Is it okay to understand your code only to a certain extent and keep going, and have I only been obsessing over little things that don't matter?

Answer 1

The sole purpose of software abstractions is to hide functional details. Were it not for those abstractions, it would not be possible to progress beyond a certain point in computing, because systems would simply collapse under the weight of their own complexity. Human brains can only comprehend so much information at once.

Consider what happens when you write a method. When you write a method, what you are doing is hiding some bit of software functionality behind a method call. Once that method is written and proven to work by writing unit tests about that method, you no longer have to think about what's inside that method unless you need to change something about its implementation.

Large software systems are built upon many layers of these abstractions. You have a microcode layer in the processor, machine code, address and data buses, language compilers, object-orientation, data structures, domain-specific languages, and so on. You have libraries built on top of other libraries, which in turn are built on top of an operating system. You don't fully understand how any of that stuff works either, but you're still able to successfully write computer programs that do something useful.

That said...

You can't just copy/paste code without understanding how it works. The person who tries to make his program work by copy pasting code that he doesn't understand is setting himself up to fail. You need to understand the code you write. That doesn't mean that you have to know how WCF works internally, but you do need to know what the purpose of WCF is, how to write code that properly interfaces it, and how the code you write functions in concert with it. Many copy/paste programmers don't even have a decent understanding of the programming language they are copy/pasting, let alone in-depth knowledge of the libraries they are using.

So you need to have some decent skills, and you need to understand the code you write (or paste) that calls WCF. But you don't need to have in-depth knowledge about how WCF works internally.

Similarly, programmers who think they can stitch together a program by randomly wiring up software patterns are missing the point. We call those folks Cargo Cult programmers.

Answer 2

I think the answer is context.

One of the most powerful techniques for managing code complexity—which is the real job of a software engineer, in my mind—is abstraction. An electrical engineer does not have to reprove Maxwell's equations in order to develop a new product, and I do not need to know anything about a car in order to use a steering wheel. Both are important abstractions because they allow us to intuit and use things without understanding them. This in turn allows us to build bigger abstractions.

As an aside, because abstraction is so important I think it is sometimes good to even enforce it with other developers. For example, in my office we sometimes have one developer write the unit tests for a block of code before the block of code is written by a second developer. It enforces the idea of simple interfaces and clear abstractions.

That said, abstraction is no excuse for not understanding how code works when it matters that you know how it works. Refactoring code is an obvious scenario in which the implementation details matter quite a bit. I don't need to know how a car works in order to drive it, but a mechanical engineer and a mechanic should both understand how a car works, arguably in different ways.

As a second aside, one of my first lessons on the job was to never touch code I didn't truly understand. For example, I was once working on a new feature and noticed another line of code in the module that didn't make sense, so I "fixed" it and then released a bug. That taught me a pretty big lesson, which is to admit when I don't readily understand a piece of code and to recognize that good and complex and nontrivial code can be non-obvious. I'm pretty new to software development, but I have found the idea that "good code is easy to read" to be an insidious one that no software developer I know puts into real practice. Sure, don't write obscure or bad code, but hard problems often require complex code. Don't be upset if it takes you time to understand things. My favorite Feynman quote is, "But it is not complicated; there's just a lot of it."

So when do you abstract and when do you take apart the Swiss clock? I suppose it depends on when you're wearing the watch and when you're building it. My own opinion is that the best people in any field are T-shaped, meaning they understand their work in a larger context—something that is only achieved through abstraction—but also know what they need to know deeply.

Answer 3

There are three different parts to understanding software:

1. First is understanding why a piece of software (as big as an application or as small as a single function) exists. You need to know the point of it, why it was written.
2. Next I think is understanding what a piece of code does.
3. Finally is knowing how a piece of code works, what it's internals look like and do.

Which of these you need to have a grip on in order to understand a piece of software differs depending on what you need to do with that code.

For example, take .NET's String.ToUpper() method. I know what this method does, and why you would want to use it, but I don't know how it's written (that's an implementation detail) and I don't really care - as long as I can use properly. I won't ever need to modify this method, so my understanding of the internals isn't necessary.

If I was copying code off the Internet, I need to make entirely sure of what the code does and why. If I was just copying it and never modifying it (unlikely) then I don't feel any need to understand how it works. But if I was going to be modifying it (likely) then I'll need to know how it works - otherwise I'm just using guesswork to modify the code, and that's probably not going to end well.

Answer 4

Not that I disagree with the other answers, but let me respond to what I read between the lines. If your boss is advising you that you don't need to understand how something works, it could be some feedback that you are taking too long to get something done. Some people easily get distracted by unimportant details and for them it is advisable to work on staying on track.

On the other hand, if programming is your chosen profession and you do have the intellectual curiosity to dig deeper into some technology that is important to what you do, then I would encourage you to take some extra time to follow your interests when possible. The insights that you gain, though not immediately rewarding, will pay dividends in the long run. It will help you make sense of the technology, put you in a position to extend it in many cases, and will prepare you for an even deeper understanding in the future. Over time, this is what differentiates an expert from a casual user.

Answer 5

In the great book pragmatic programmer this is called "programing by coincidence" (http://pragprog.com/the-pragmatic-programmer/extracts/coincidence)

The bigger problem with this is, if you don't know why a piece of code works when this piece of code fails for whatever reason, you don't know why fails and you can't fix it.

Answer 6

I don't completely agree with the statement: "You can't just copy/paste code without understanding how it works."

Forgive my stupidity, but from a programatic viewpoint, isn't including a library of methods/functions which I don't know they work essentially the same as copying/pasting that code into my own?

I.e., if I'm programming using jQuery, I include the jQuery library and then use it. Using Robert Harvey's answer, this is fine since jQuery has abstracted out all of the things I need to use without having to write the code myself or even understand it completely. Do I really need to know exactly how jQuery works behind-the-scenes before I can use it?

Having said that, I agree with the principle behind the statement, but wanted to point out that the concept of "copying/pasting" code (without complete comprehension) is actually more common than one might think and not as onerous as this statement would make it seem.

Answer 7

As most of the time, it all depends. At the extreme end, there is the use of a library. You are not supposed to know or care how it works. You are supposed to know what to put in and what comes out, what it can and what it cannot do.

At the other end, you don't know how to do some task because you haven't done it before. You find ten lines of code on the internet, which seems easier than finding the right information in your documentation (and often is). At that point I'd strongly suggest that now is the right time to learn how to do that task. So take the code, understand it, make it your own. Realise that lots of code on the internet isn't necessarily written by the cleverest of people, so there may be weaknesses and misunderstanding, so by learning now you can make sure that the code works. And at the point where you include those ten lines in your project, they are your responsibility. If the code doesn't work, it's your fault. So you have to understand it, as if you had written it.

So what's the difference to the library? Isn't that your responsibility as well? The code of the library isn't. The choice of library and the usage of the library is. If the library crashes your application ten times a day, that's because you picked a library that is unreliable. You don't have to understand the code of the library, but you have to understand its reliability issues and act.

Answer 8

Your boss' advice might work fine, but it is risky. There is a danger that in the long term you will get into bigger problems, which could be averted by taking the time to understand things in the first place. If this is a one-time thing, the risk is relatively small. If you build an entire software system this way, you have a ticking time bomb on your hands. What you don't understand, you don't have any hope of fixing or changing without causing bugs.

On the other hand, if you disobey your boss, your own job may be at risk. If you like your job, then in the future, try to resolve technical issues yourself before he has to get involved. I had a boss once who would mess things up whenever he got involved in technical decisions (though he was stellar at sales and customer relations). Most of the technical staff learned to listen to what he would say, then turn around and do something different. As long as the software worked, he would never follow up and check whether his technical advice was actually implemented. The job paid well, but I'm glad I'm not there any more.

If this attitude is pervasive at your place of work, I would at least consider other work options.