M2M Day 209: It’s never what you think (and why it’s important to know that)
This post is part of Month to Master, a 12-month accelerated learning project. For May, my goal is to build the software part of a self-driving car.
I’m currently visiting a friend in Seattle, who’s giving me a hard time about the post I wrote two days ago:
In that post, I explain that I was able to leverage the collective knowledge and work of many others to greatly accelerate my self-driving car efforts. In particular, I didn’t need to build the machine learning model from scratch, but instead, I could integrate an already-built model into my system.
As a result, I’m hearing a lot of “If you didn’t actually need to build the core self-driving car model, how was this month’s challenge actually a challenge?”.
In Friday’s post, I do agree that the perceived challenge (of creating a self-driving car mechanism) wasn’t actually the challenge, but that doesn’t mean there was no challenge at all.
In fact, I’d argue that the perceived challenge is never actually the real challenge.
For example, back in November, when I was trying to become a grandmaster of memory by memorizing the order of a shuffled deck of cards, the hard part wasn’t actually remembering. Instead, it was forgetting what I had memorized during previous attempts (so as not to confuse myself).
Back in February, when I was learning to backflip, the hard part had nothing to do with anything physical or athletic, but instead, had to do with the mental blocks and fear associated with self-preservation.
This month, the challenge wasn’t creating the self-driving car model, but instead, it was integrating this model into my system so it would actually work.
This isn’t surprising — most of software engineering isn’t necessarily building completely new components. Usually, it’s figuring out how to take a bunch of pre-existing components, fit them all together, and have the output function as expected.
In my mind, software engineering is a lot like performing an organ transplant: The trick isn’t finding the replacement organ (although, this can still be a long process). The trick is making the body not reject the new organ.
Similarly, software engineering has two main challenges: 1. Finding the ‘organ’ (i.e. an example of the component you want to build), 2. Integrating this ‘organ’ into the overall body (i.e. ensuring your development environment is properly setup; connecting the component to other components and services so that it properly interacts with the rest of the project; modifying the component so it behaves in the expected/needed way).
And so, while this month’s challenge wasn’t difficult because of the perceived difficulty of getting a car to drive itself, I still did spend a lot of time in the coding pit of despair trying to 1. Find a self-driving car model that I could successfully run, 2. Set up my computer’s environment to support the model, 3. Format data so it could be used by the model, 4. Figure out how to output something interesting from the model, 5. Modify the model to work with different datasets and for modeling different behaviors.
Overall, the perceived challenge wasn’t a challenge, but there was still plenty of friction.
There’s actually an important lesson here: Often times, when people are learning something new, they have a preconceived notion of what’s “going to be hard” or “what they are supposed to be learning”. As a result, when there are other difficulties along the way, people perceive these difficulties as roadblocks, instead of additional parts of the learning process.
In other words, when people struggle on the thing they expect to struggle on, they usually can justify persevering. However, if they are struggling on something that seems to be a distraction, people tend to give up (since they perceive that they’re wasting their time).
But clearly, these distractions are often times the actual meat of the learning challenge, and, if cracked, unlock the most progress towards the goal.
As Ryan Holiday explains: “The obstacle is the way”
Your obstacles aren’t preventing you from pursuing your goal, but, in fact, define the pursuit itself.
So, I stand by calling this month’s challenge a challenge. Not that the semantics matter anyway… But, it reveals any important lesson about learning and perseverance.
Read the next post. Read the previous post.
