It’s Like a Tough Mudder For Their Brains
Life-long learners, yes. Thrilled with every step of the process? No. Modern developers notice the hard parts of learning just like everyone else. Because of the nature of their work, they have very specific challenges. Fortunately, these are challenges that technology, tool, and framework companies are well-poised to help them overcome. Yes, YOU can help a developer.
Developer Media posed a very simple question on CodeProject.com:
“What are the hardest parts of learning a new technology or framework?”
Almost as many respondents (>40%) said that getting started with new tools, library managers, and build/deploy processes was the hardest part for them as said that the most difficult part was having to understand a new way of completing familiar tasks. Another 35% indicated that not having a good understanding of the functionality that is, or is not, available to them was the hardest part. While the solution to these problems clearly lies in access to high-quality public documentation, a good 38% of respondents indicated the hardest part for them is constantly having to constantly refer to documentation!
|Answer Options||Votes||%||% Error*
|Getting started with new tools, library managers, and build / deploy processes||380||44.81||3.35
|Wrapping your head around a new way of completing old, familiar tasks||357||42.10||3.32
|Potentially learning new languages in order to use the new tech||134||15.80||2.46
|Having to constantly refer to docs instead of having it all in your head||320||37.74||3.26
|Understanding what functionality is — and is not — available to you||299||35.26||3.22
|Learning new design patterns||154||18.16||2.60
|Finding the time to practice||359||42.33||3.33
Respondents were allowed to choose more than one answer; therefore totals may not add up to 100%.
But, the comments…
The comments offer more specific, anecdotal, and often humorous views at the challenges that developers feel they face when learning something new. For example, there is a secret, third option — of learning a new technology only to find you actually should have chosen something completely different.
“we learn technology X .
We work on it for few days/months, spending a lot of time going through docs, samples, & practicing, sometimes getting stuck…
and later while finding solution of problem in X is discovering that alternate better technology Y exists 🙁 “
Or, the oft ignored “missing option”…
“…at all the weird sh^t that some button-clicking, icon dragging moron thinks is a good interface with NO HOT KEYS for anything! …and other reasons that I won’t mention as I just get too angry to type!”
Oh, you won’t want to miss this one…
“…The “Other”, however, has to do with those who are describing/teaching the new technology. All too often, they use jargon that makes sense only if you already knew about it – and if that was the case, I wouldn’t looking at their stuff.
A case in point – the concept in C++ about classes and objects. Sure, makes sense now – but at the time I first tried to got to it from C (out of necessity) it was just so much jargon and gibberish. Adding to the confusion was, at least in this case, that one had native and ‘managed’ versions of the types was used to and the hitherto need for namespaces.
Yeah – it all falls into place rapidly enough – but only when it starts to fall into place.”
And, let’s not forget the people trying to keep it real with a little “new math.”
a(ssumptions)2 + b(ullshit)2 = hyp(e)2
The wrong angle theorem that some deem right
That’s a Wrap
Most of the problems developers encounter when learning a new technology or new framework truly can be solved by high quality public documentation. The kind of documentation that recognizes what a new user may be trying to replicate in a new environment. The kind that is well-organized so the new users can easily find the material they need (even if they hate the fact that they need it).
And, finally, make sure something you are asking developers to learn really is helpful. Don’t be the product that fulfills the wrong angle theorem.