Structured Learning
A few months ago, I found myself stuck:
- To become a better leader for my team at Zipline, I need to learn to work with larger organization scale, to hire and coach engineering managers.
- To get closer to my dream of a quiet life of an indie developer and a solo founder, I want to learn more about building iOS apps.
- To build up my career security and career compensation, on top of learning to manage larger orgs, I need to build up experience working with more robust, reliable systems at scale, and do more infrastructure work.
These are three distinct directions. Leading a team (or teams) and having a 2 year old kid doesn't leave a lot of time to invest in learning. If you're anything like me, the monkey brain will happily jump to any new exciting engineering topic, not leaving enough space for the new knowledge to crystalize in your head.
Bringing structure to your learning means to make trade offs about what to tinker with first, and consequently what to put away for now. With some structure in place, you should be able to see what your new skills and knowledge would shape into in a few months from now.
Learning one thing means not learning another (for now)
What would you say to someone else struggling to fit 20 hobby projects into their schedule? This topic often comes up in 1:1 conversations with my team, and the advice is usually something like this:
- Figure out what you want to do, and why you're interested in doing it.
- Think about how much time you want to spend on it. Timebox it, but make an estimate of how much time you need to spend for a meaningful outcome.
- Think about what other areas you're interested in — how much resources and time do they need?
- Now you can reason about the trade offs: if you're committing time to work on project X, what are the projects you're committing to not doing?
The big lesson of looking at your learning from this angle is that you only have enough time for a few topics each year. Making the right choice will bring you lots of fun, and can change your career trajectory dramatically.
You only have 5 months left in 2022. Each new skill you want will take at least 2 months to develop. What are the skills you want most, and what's the type of work that you need to do to acquire them?
This approach might look clean and nice in theory, but in practice it means that now you have a new problem: instead of working on a project right now, you have a new meta-project of exploring time commitments and trade offs. It's up to you to decide how much time is reasonable to spend on this.
To me, it's proportional to the size of the commitment: if I'm about to take on a year-long project, I would spend a couple weeks to make sure I'm ok with not doing other things for a year, and in what situations I can drop the ball. But if I'm committing for a few weeks, a couple hours session with a notebook is fine.
Learning SwiftUI in July
Which brought me to what I did in July! I've spent my nights tinkering with SwiftUI, inching closer to two toy projects that I want to build.
- Why: I wanted something hands-on, something I can build and see the results of it. Something applicable to my current work: spiking on using SwiftUI to build simple forms and flows gives me deeper understanding of what part of my team is working on. Engineering managers write code, a lot, but not to build features. We code to learn the trade offs our teams are facing.
- What: started with wrapping up a course on SwiftUI that I've started previously. I love having things done done, and this one was hanging in the air for a year. I've picked up a couple of courses as a result of this month-long exploration, though.
Tinkering with Swift is on hold for August. I miss it, a whole lot, but it's time to read up on building reliable and robust platforms, and on leading larger, more diverse teams.