Over a million developers have joined DZone.

Using Something You Can't Implement Yourself

DZone's Guide to

Using Something You Can't Implement Yourself

· Performance Zone ·
Free Resource

Built by operators for operators, the Sensu monitoring event pipeline empowers businesses to automate their monitoring workflows and gain deep visibility into their multi-cloud environments. Get started for free today.

 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.

Download our guide to mitigating alert fatigue, with real-world tips on automating remediation and triage from an IT veteran.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}