I was recently tasked with learning Ember for a new project here at Lofty Labs. I'm now shifting my perspective on web development from "backend templating + jquery" to "front-end framework + backend api" (slowpoke.jpg). I'm not through the entirety of Ember's learning curve, but I've been able to get productive with it in a decent timeframe. Here are some approaches I took and things I learned along the way:

Become like water

“Be like water making its way through cracks. Do not be assertive, but adjust to the object, and you shall find a way around or through it. If nothing within you stays rigid, outward things will disclose themselves.

Empty your mind, be formless. Shapeless, like water. If you put water into a cup, it becomes the cup. You put water into a bottle and it becomes the bottle. You put it in a teapot, it becomes the teapot. Now, water can flow or it can crash. Be water, my friend.”

― Bruce Lee

I hail from the land of Python/Django. While there's plenty of 'magic' going on behind the scenes in Django, it still emphasizes a moderate mount of configuration. It follows the adage from the Zen of Python: "Explicit is better than implicit".

Ember and Ruby on Rails work in contrast by assuming a great deal of the workflow and configuration for you. They take the stance of "convention over configuration". It was initially very counterintuitive and disorienting, but I eventually adopted a muscle memory as to where things belong.

You may encounter mind-bending conventions or quirks like this on your foray into a new technology. When this happens, allow your mind to become like water.

Clear your mind of any preconceived notions. If you are to use any of your previous experience or opinions, let it be to draw parallels and augment your understanding. Try not to let it taint how you see this particular technology. Once you have a more holistic perspective of the framework, then you can pass judgement  (as we all so love to do)

Embrace how the framework does things. Try to shift your mindset to accommodate this new perspective. Fighting the established paradigms is a great way to dig yourself into a hole. You'll know when you've done this when every move you make feels wrong. It will feel like you're having to go to extraordinary lengths to make something seemingly simple work. When I encounter this scenario I try to take a step back and ask myself, "What approach seems most in line with how this framework accomplishes things?". Go with the flow. Take time to appreciate how it's different from your initial assumption and use that as a learning opportunity.

Be prepared for frustration and anguish

I find that adopting a new language or framework comes with its own "stages of grief" that you should be prepared to endure.

1. Blissful Ignorance:
   [Following along with the tutorial] "This isn't so bad. This actually makes a lot of sense. Looks pretty easy tbh."
   
2. Realized Incompetence:
   "Alright, I guess I didn't understand this as much as I thought I did.. That's okay though. Back to the drawing board."
   
3. Bewilderment:
   "What the hell? Why won't you work? Whyyyy?"
4. Anger:
   "This is literally the worst thing ever created in the history of the universe. I should take up carpentry."
5. Anticlimactic Epiphany:
   "Ah. I was using that method incorrectly."
6. Hubris:
   "This is amazing.. I am amazing."
   <Go to stage 2>

It's one thing to read documentation or follow along with a quickstart/tutorial. It's another entirely to try to build your own thing. When following a tutorial, you're seeing the scenario in which all of the bugs and speed bumps have already been encountered and paved over. You're also typically not doing anything too complicated in a beginner's tutorial, as that would defeat the purpose. It's jarring to go from an enjoyable, smooth tutorial to your own project.

It's important to note that change is hard. There's a reason that humans get in a routine. It's conducive to our survival. Our existing experience and worldview is comfortable. Oftentimes new frameworks have entirely different ways of breaking a problem down. Try considering how this methodology came about.

RTFM

   Be willing to put in the time to read the documentation. I know that sounds about as exciting as watching paint dry, but it's very important to quickly gain a high level view of what's going on. You don't know what to leverage if you don't even know it exists. When you want to solve a problem you need to know whattools you have and where they are. Having to reinvent the wheel or use the wrong tool is the bane of every engineer with deadlines.

• Example: I helped build a form that used component lifecycle hooks and intricate logic to populate form fields and check for changes in the form fields. If the form data changed in any way from the model data, then we would enable the save button. It turns out that all of that excess code could be replaced with a simple check of model.hasDirtyAttributes. Coming across that section of the documentation would have saved me a great deal of wasted time and convoluted logic.

Join the community

Get a feel for what people are talking about. Find out what they're excited about. Check out the new or popular plugins and related technologies. They can be a great indicator of the shortcomings of the framework and what you can do about them. Learn from the experience and mistakes of others to ensure that you're not chasing down a rabbit hole.

‍