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?

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.
