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.