When I went to the Atlanta Silverlight Meetup Group this past Thursday, I met several people whose college degree (or lack thereof) was completely unrelated to software development. As someone who is trying to become a “professional” software developer and is beginning the tedious process of learning several new technologies, this discovery was very heartening and caused me to reflect on my own background in philosophy and a connection I made to learning new development technologies.
Learning software development technologies can be difficult. It’s as much about culture, language, and the greater community ecosystem as it is about making a bunch of lines of text do cool stuff. Sometimes it can be really difficult to understand the importance of technology without having an appreciation for where it fits in to the big picture. The following is a thought experiment to try to help you understand what I mean.
I took a minute to think of all of the different technologies related to software development that I’ve come across in the past month. Take a look at the following list at see if you recognize the technology and concepts on this list (in no particular order):
- ASP
- ASP.NET
- .NET
- ASP.NET MVC
- MVVM
- Ruby
- Ruby on Rails
- Mono
- MonoTouch
- Moonlight
- Silverlight
- JavaScript
- HTML
- DHTML
- Java
- JQuery
- XAML
- XML
- XAP
- MEF
- OSLO
- AJAX
- DSL
- C#
- VB.NET
- RIA Services
- Entity Framework
- WCF
- CLR
- OOP
- Spark
- Prism
When looking at that list, how much did you recognize? How many of the pieces can you fit together? If you are an experienced developer, you were probably able to recognize the terms and automatically recognize how they exist in relation to one another. For example, you might automatically recognize that “a XAP file is really just a zip file for Silverlight applications” or “JQuery is a library for JavaScript, which is not really related to Java.” Sure, it’s a diverse list of technology, but you probably have at least a general idea of how the pieces fit together.
Now try to imagine (or remember) what it is like not to recognize these technologies and how they fit together. Try, for a moment, to abandon your understanding of what you already know and put yourself in the shoes of someone for whom the term .NET is just another group of letters in a malaise of technological alphabet soup. Think about what it might feel like to write your next Silverlight application without having a clue of why you would even want to use MVVM.
In this experiment, you may have found it quite difficult to forget things you have found important and to abandon your understanding of key technologies related to your field. Besides, you might ask, what’s the point of trying to forget things you’ve already learned?
That’s a great question, and to get at the answer, bear with me as we take a very brief look at ancient Greek philosophy. In Plato’s analogy of the cave (from the Republic), the majority of humanity is described as being in a dark, barely lit cave, trying to understand the world by the dim shadows cast on the walls of the cave. It’s hard to understand the world when all you have to go on is the shadows on the wall.
Some people, however, find their way out of the cave and “see the light.” No longer seeing just the shadows, with the light outside of the cave, they get to see the world as it “really is” and now have a better understanding of the world. This is great! Now what?
Let’s stop here for a second and make a connection to the world of software development. The people inside the cave represent people like me. Some of us are content with where we are and what we know, and some of us are trying to “see the light” so we can understand software better. Either way, we’re the ones who don’t know why we should go through the trouble of using class modules and objects in our VBA Excel applications. We don’t know why MVVM will save us time in Silverlight development, and the phrase “separating business logic from the UI” either means nothing or doesn’t seem applicable.
On the other hand, the people outside the cave know exactly what “ORM” means, have their personal favorite, and know how to use it correctly. Not only do they know why to use MVVM, but they contribute open source code to an MVVM framework. Whether in their specialized discipline or in a wide range of products, these developers “get it.”
Some devs “see the light” while others are still in the cave adding button controls to their boss’s excel report (guilty). Is that all there is to it? This is where we return to our thought experiment of trying to forget what we know about software development.
This is where the value of the analogy of the cave really shines. The philosopher (or developer, I suppose) who is outside of the cave could simply bask in the glory of their own understanding, but to be a true philosopher (errr…developer…), he must go back into the cave and try to convince the great unwashed that they should want to get out of the cave. He must try to get others to “see the light.”
The philosopher-developer must not only tell me where to download the latest bits for their technology of choice, they must tell me why I should want these bits in the first place. The philosopher-developer cannot only give a cool talk at MIX that demonstrates their favorite new tool, they ought to bring me to an understanding of why I should need that tool in the first place.
The hardest part about helping others to understand why to use such-and-such technology is trying to put yourself in their place, forgetting your assumptions and trying to remember what it feels like not to know. It’s easy to geek out and get excited with our peers, but it’s exceptionally difficult to remember what is was like to not even know why we would want to be geeking out in the first place. A person who has donated his or herself to bringing others into the light by meeting them at their level is truly embracing the essence of what it means to be a teacher.
Here’s an example of what I mean. I’ve read a few posts trying to explain MVVM. Almost always, these posts will describe the different pieces of MVVM and how they work together. That’s great, but what I need to see, as someone who is “inside the cave”, is why MVVM is even important. Try to forget about the greatness of MVVM for a second and walk me through an example of how I might build a simple application without it. Get on my level and try to imagine what I would do as I try to solve the problems of building the app. After you show me how to build an app “the traditional way,” show me how MVVM will actually help me when my boss wants to add a new text block to that data form we just built. Show me how I would have spent 2 hours making the change my way, and then show me how I would have spent 5 minutes making the change your way.
I might be kicking and screaming as I spend 8 hours trying to implement your new framework for the first time, but I’ll be grateful for your work after it’s saved my butt for the 50th time because management doesn’t know what they want in the UX of their product. More importantly, I’ll have actually tried your technology because you took the time to show me why it was important. In sum, you can yell and scream all you want about how great “the light” is outside of the cave, but until you come into the cave, get on my level, and then drag me out, I’ll never understand why I should want to join you.
Lastly, I’ll grant that every last blog post and conference talk does not need to be directed at the unenlightened few. Sometimes you just need to preach to the choir or demo some tools to your community. I understand that. However, there are still far too many “Introduction-to-Some-Technology” blog posts that show tools and bits without showing why they are even necessary. As frequently as new technology is introduced, you can’t always assume that everyone listening to your talk or reading your blog post about the next-big-thing is up to speed on why it is even important.
The best way to learn is by being taught by someone who wants to get on your level and guide you to a better understanding of the topic at hand. Any volunteers?
: 
