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.
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.
I am posting short links and updates on Twitter as well as on this blog. You can follow me: @goldshtn