Your Development & Design Resource
5 Common Missteps in Developer Learning
03/31/2015 by Chris Toohey
Learning should be an adventure into undiscovered country, not a source of frustration, resentment, and pain. There are common mistakes made time and again by even the most seasoned and well-disciplined developers. Whether it's a new feature, a new language, or an entirely new application platform, here are five - thankfully avoidable - missteps in developer learning.
1. Skipping the Directions
The only thing more unforgivable than new tech with no documentation is a developer who ignores great documentation.
The first step after you've found a new framework or set of libraries that promises to do exactly what you need to do in your latest project should be to read all supporting documentation. Whatever you do, stay out of your code editor! You need to do research to see if this is even a viable solution before you start cracking open your editor or importing files and resources into your build.
Getting Started guides and Code Examples aside, truly great documentation not only tries to educate but to also show the professionalism and completeness of the tech. If the documentation is poorly written, imagine the code!
In product development, there is a term used to describe a validatable milestone which requires the least amount of work from the development team: Minimum Viable Product. In development terms, the MVP is simple, extendable, and low-effort-investment example using the given tech that you're evaluating. It is, by no means, your finished product. It shouldn't even resemble your finished product.
But how many developers grab a new platform or language with the end product firmly in mind? Worse yet, how many start developing that product after they do their Hello World example.
Really, stop it.
After you've gone through the examples in the documentation (see above), if this tech is still in the running... you need to create a minimum viable product to 1) confirm your assessment and 2) make sure that you don't spend hours trying to get some killer feature working in tech that you don't completely understand yet.
I'm certain - if you're being honest here - you've spent too many hours trying to get some library or framework to do that one thing that ultimately could have been accomplished a different way once you got more time with the tech, re-read the documentation, and walked through all of the build exercises. Version 2.0 is always a better version of the application, but you'll need to write that version much sooner if you didn't realize that you were doing in wrong in the first place.
Managing the scope of your dive into the new tech will help.
3. Non-flexible Thinking
If you've read the documentation and are managing the scope by creating MVPs and milestones that are in tandem with your understanding of the new tech, you're doing well... but I suspect that you're still thinking about how to apply this new tech with the knowledge gained from mastering the old tech.
Huh? -- I'll explain...
I have found that technology functions the way it does due to three factors:
Working as Designed.
The technology was intended to do exactly - and sometimes solely - one thing. Since it only has one objective when it is written by the developer, it was developed with one objective in mind. Anything else is a happy accident.
Working within The Broken.
Sometimes, especially with application platforms, a feature or function is added that runs on top of the existing framework. The developer therefore needs to make that feature or function work within the guidelines of that existing framework... even if the new feature/function is completely alien to the existing framework. Need a non-relational database to store data in a pseudo-relational model? OK, that can happen if Y... because the platform works like X.
The Happy Accident.
I made a career working in this part of enterprise application platforms. Developers working in the Happy Accident zone of technology can achieve some amazing results since - by definition - they're taking feature functionality that was never intended to be available in the platform and using some open edge case loophole to get the job done.
If you're used to working in a non-relational database architecture and creating pseudo-relational data models in your applications, you should not be applying those same tactics when you find yourself working in a true relational data model platform. You would be transitioning from Working within The Broken (or The Happy Accident) to Working as Designed... because that's actually how the platform was designed. You no longer need to employ the same "hacks" to get the job done, nor should you try those same hacks on the platform.
By limiting yourself to what you already know, you are limiting or perhaps even crippling this new technology.
Remember: there's a reason that you're learning something new here - the tech you were already using couldn't get the job done... so why keep yourself stuck in the confines of the tech that couldn't get the job done in the first place?!
4. Learning in a Vacuum
You are not the first person to tread this water. Google is your friend, as is social media, resources like Stack Overflow, but most importantly the discussion forums that are dedicated to the new tech. The exist, trust me. You just have to find them. Most of the online resources can be found in the documentation, and the developers that have mastered the skill that you find yourself struggling with are more than happy to help.
Give yourself an appropriate amount of time to try something new with the tech. If it doesn't work in, let's say, 20 minutes, search Google, Stack Overflow, and any discussion forums or other resources mentioned in the documentation. If you can't find your answer within 10 minutes, put the question out to your friends and network on Facebook, Twitter, LinkedIn, Google+. If you don't get a response, hit Stack Overflow or the aforementioned resources mentioned in the documentation. If all goes well, you'll have an answer - or at least be course corrected towards an answer - within an hour of your first stumbling block.
No one will think your question is dumb. Everyone was new to this once. Just remember to help out new developers once you've mastered the tech.
5. Fear, Uncertainty, and Doubt
We've all been there: You've done everything you know to do. You've searched through Google results with nothing to show. You've been on Stack Overflow, completely wiping away your own code for 5th comment code that kinda shared a keyword with what you're trying to do and it still isn't working.
Via Facebook, you get responses from family and non-developer friends that can best be summed up as "You and that 'puter talk!".
You've been at this for hours, and now the Fear, Uncertainty, and Doubt have set in so bad that you doubt your career as a developer and wonder if the local hardware store is hiring.
You're great with people and you can give people advice like "Righty-tighty, lefty-loosey!"...
First off, relax. Again, you're not the first person that's been frustrated with this tech while also wondering if other developers out there are secretly better than you because they must have totally got this their first try.
Follow these steps and you'll be fine:
Is there an error?
Now, I picked this example specifically for this: the FontAwesome CSS uses QueryString Parameters when loading their Font files, which will read like this:
IBM Domino uses Domino URL Commands, and will throw an error due to the QueryString Parameter (there's no such action as "v"). To fix this, simply change the reference to the following:
Nothing you did here, it was the application platform itself that caused your headache. If you were worried that you did something wrong with an import of the resources or that you were using it wrong, you'd be there for hours banging your head against the screen.
Does the example work outside of the documentation/example website?
Websites like CodePen exist for reason - aside from a great way to share code, it's a simple non-platform-bound way to test a feature within a framework or some downloaded library. If the CSS that you've downloaded works in a barebones MVP (minimum viable product) that you quickly create on CodePen, then it might very well be the environment that's breaking it.
If it doesn't work there, then it might be a case where the documentation is writing checks the actual tech can't cash.
That prefix should actually translate to "it'll work until you actually need it to..."!
Did anyone else manage to get this working?!
Follow the advice from Learning in a Vacuum above: after giving it a try, reach out and ask for help. Any time I've done that I've either gotten confirmation that someone else unsuccessfully tried the same thing, found links to successful uses and examples, or found others interested in the same functionality who were willing to collaborate with me so we could both be successful.
Fear, Uncertainty, and Doubt will kill your creativity and your productivity, but knowing that you're not alone out there and getting over the potential awkwardness of developer community engagement will have you back on the right track in no time!
At the beginning of this article, I said that learning should not be painful. Learning should be fun. It can be tedious. It can be dull. It will always make you a better developer, even if it's authoritatively knowing that the tech that you're learning absolutely can not do the job you thought it could.
People are awesome, and developers who engage the online development community will find that subject matter experts are more than happy to share what they've learned... mostly because the really smart ones realize that they themselves are still learning.
To recap, here's a simple TODO list to follow:
- DO read the directions. Solid documentation will not only give you an understanding of the technology, but a sense of the technology's stability, maintenance, and support.
- DO keep yourself in check by managing the scope of your development while learning the new technology. Don't get in too deep too fast!
- DO follow the constructs of new technology, and be ready to abandon your own subject matter expertise. Getting out of your comfort zone and out of your own way is often the best way to learn new technology.
- DO engage the greater online community. Remember that you're not alone out there and I doubt you're trying to do something that's never been done before. Don't be afraid to look like you don't know what you're doing... right now, you actually don't know what you're doing - and that's OK!
- DO have confidence in yourself. Don't let your current lack of mastery drive you away from learning... otherwise you'll never actually master anything.
Finally, once you've become comfortable with a new technology, please share your experience. You will, without a doubt, help another developer that was in your particular situation prior to you going through the whole process. Wouldn't the Last Week You have greatly benefited from reading about the experience the Week Later You had with the technology, the learning pitfalls, and the ultimate outcome.
Done right, you might save someone time and teeth-gnashing. And the developer who learned about web sockets a week before you did and wrote about it in the documentation wiki or on their own blog might make learning about them completely painless, completely accessible, and completely fun.