At the beginning of this year, I switched my full-time focus in a pretty sizable way. I jumped from an environment where I had at least a bit of expertise and its associated advantages, into one where I had little to no foothold.
Switching roles usually means adjusting to a new environment, new coworkers, and new problems to solve—things you might work through in a matter of weeks. But there I was, two, then three months in, and still feeling unadjusted.
What I hadn’t realized was that jumping into a completely different side of the industry is disorienting. The new environment was similar enough to the old one that it still triggered my muscle memory, which was largely irrelevant for new tasks. There were only a few skills I could rely on during the transition—the basic workflow, programming principles, and methods of collaboration and feedback were all the same, but that didn’t always help with things like deploying applications to devices natively, or making decisions about how best to implement a platform-specific SDK.
One of the biggest advantages of having expertise is understanding and implementing best practices, but they were often the biggest hindrance in learning something new. Applying best practices to a new area of focus from a related-yet-foreign area of expertise was destructive.
This was most noticeable in the software architecture decisions I faced. Coming from the world of programming on the web, both server and client side, my mind defaulted to certain patterns of communication between pieces of an application—specifically notifications and callbacks. When sketching out a plan for a feature build, I would sometimes forget about the delegate pattern, which is a pretty heavily-relied upon pattern in Cocoa. In a lot of cases, that was the best fit for the feature in front of me, but my mind was trained otherwise.
The other reason knowing best practices was destructive when learning something new: I was constantly focused on making sure what I built adhered to those patterns. That forced me to focus on optimizing a system before I’d even built or understood it. I was prematurely applying structure to something that I wasn’t quite sure even worked yet.
I had to get back into beginner mode: make whatever it was I was building actually work, before deliberating on how it should be built. It sounds like an obvious thing, but it takes concentration to restrain yourself like that. The sad irony here is that I should’ve known this from the start. A few months ago I wrote about relying on intelligence rather than knowledge, and that’s how we should operate when learning new skills.
That’s dead on what I’m feeling right now. I am trying to update my way of working and I often get stuck on stuff that doesn’t really matter at the beginning, like performance, best practices and architecture. You train your brain to think a certain way during years, but when it is time to change, you shouldn’t rely on it at all because it is still stuck in your old habits. For me, what works best is to let my intuition take the lead and start coding without thinking too much at first. I can review my code later on and refactor it.
Thanks for your great advice!
new tricks can be learned thru our new experience..bodas originales