I have found that the biggest obstacle I face when adopting a new
language, technology, or framework is using something I don't fully
understand how to implement myself. I read hundreds of blog posts every
week talking about language extensions to JavaScript, cool new iOS
application frameworks, and brand-new SaaS offerings on top of Windows
Azure -- just as a small sample. Obviously, just using some piece of
technology or adapting a sample to my needs is usually not that hard.
The thing is, I can't bring myself to adding code to my arsenal if I
don't understand how it works and how it has been implemented. It's
somewhat akin to the Not Invented Here syndrome, except I don't actually
write all my own frameworks; I just want to be able to write them. Here are a few recent examples.

In late 2011 I started getting my feet wet with Node.js, and in 2012
implemented several personal and commercial projects on top of Node,
Express, and many other Node modules. I was very reluctant to start
working with Node until I grasped the fundamental concepts -- the event
loop and the asynchronous nature of everything -- which gave me the
foundation to implement "something like Node" should I want to. There
was even a time when I was considering to implement a Node-like HTTP
framework with the new C# support for async/await, but gave up because
there are many like it, ASP.NET MVC async controllers notwithstanding.

Next, I always was -- and to some extent, still am -- quite "afraid" of
WPF. I can't say that I love client development in general, but nearly
everything feels, on a purely psychological level, like a more appealing
target for me than XAML-based frameworks. It's not that WPF is very
hard for me to use: I understand the fundamental concepts such as data
binding, styles, resources, and data templates, enough to implement
simple desktop applications or sample Windows 8 and Windows Phone apps.
It's the depth and breadth of WPF that always keeps me wondering: Is
there a better way to do what I just did? How is this XAML expression
working under the hood with this data context and that dependency
property? Should I have moved this entire chunk of code into a behavior
or a separate control?... I can't say I haven't tried: I read at least
three books on WPF, with a total of more than 1500 pages, and they had
had zero effect on my state of mind. The result, at least for me, is
that on a subconscious level I steer clear of XAML-based frameworks,
because I am not sure how to implement my own. The funny thing is that
I'm fairly comfortable with several "thick" client technologies,
including MFC, Windows Forms, Android, and iOS -- but it's as though
XAML, with all its objective advantages, had developed a conditional gag
reflex in my mind.

Moving on to something I am very comfortable with, I always felt at home
with Reflection-based approaches to virtually anything, from
serialization through validation all the way to code generation.
Attributes and Reflection have somehow grown very strong roots in my
mind ten years ago, when I was first working on a large .NET
application, and have been a very powerful tool for me ever since. I
attribute this mostly to the fact that I understand how managed types
are laid out in memory, how .NET metadata is organized, and thus how
Reflection can provide access, at runtime, to this information. In fact,
I immediately feel at home with Reflection in other languages and
frameworks as well: for instance, my first instinct when working on the
Windows Azure Mobile Services unofficial Android SDK was to write my own
JSON serializer in Java instead of relying on a third party library.
After the fact, it might not have been the best decision, but it took me
less than 2 hours to have a working serializer that supports most of
the types WAMS requires.

As a final example, I have a very big problem adopting new languages,
especially if they're not merely compiled to another language. In other
words, I wouldn't mind using something like TypeScript or CoffeeScript,
where I can easily see how the source is compiled down to JavaScript,
and how a new piece of syntax is merely a mapping or syntactic sugar on
top of existing syntax. But a "brand new" language, such as Objective C,
poses huge problems for my mind. It's not the brackety syntax I have
trouble with; it's the "how" of the language. How are Objective C
objects laid out in memory? How are methods dispatched, considering that
you can override them and even dispatch them dynamically by name? How
does the compiler manage memory automatically (yes, reference counting
-- but that's just a buzzword)? The same applies to a language like
Python: I can use Python to write scripts, create modules, and even
interact with C-style DLLs, but I don't have a clear picture of where
attributes are stored and how typing works in a dynamically-typed
language.

To conclude, I wish that every tutorial in the world were followed by a
"how it works" section that would tell me how I can implement that
language, technology, or framework -- on my own. Until such time, I hope
this post explains why I tend to over-analyze how stuff works, to the
extend of implementing it myself. The root cause of this might be that
I'm used to systems, frameworks, and languages that I fully understand;
it might have something to do with debugging or performance concerns;
but at the end of the day, I need to know how it works: otherwise, I face a psychological barrier that gets more and more painful to overcome every day.