What a non-technical product manager learned when she attended a coding bootcamp.
By Bo Ren (Product Manager, Facebook)
For someone coming from a non-CS background who chose words over math and philosophy over physics, the thought of coding is downright scary. I found myself sitting in Facebook’s Engineering Bootcamp. Scared shitless.
I flashbacked to junior year of high school when I resented math after a horrible experience in IB Calculus. Unable to see a 1:1 ratio in my effort to result, I gave up on calculus. Unfortunately, it only takes one bad experience — one bad teacher — in math or science to completely put off someone, especially women, from pursuing the sciences and engineering. I wondered if coding would be the same painful experience as learning calculus.
And so I embarked on a two-week engineering bootcamp to familiarize myself with the Facebook codebase, develop empathy towards engineering colleagues and solve actual bugs. Yes, fix bugs — F’REALZ. This nontechnical mind was going to connect my UNIX terminal to the dev server, debug, create a diff and push to prod. No big deal, right?
Below are lessons learned as a non-technical coder:
1. Have a Growth Mindset. Prime Yourself for Success.
The narrative you tell yourself dictates your actions. In a Harvard study on stereotype priming, female participants primed with the gender stereotype that women are bad at math performed more poorly on a math test than the control group. (In some cases, women performed better to counteract stereotype threat but that was an exception). The very act of believing that you are bad at something becomes a self-fulfilling prophecy. Shifting to a growth mindset counteracts negative priming effects. Believing that you can indeed improve, learn, and persist, and you will, in fact, improve.
Professor Ousterhout’s lecture slide on personal growth.
Having a growth mindset enables you the mental agility to learn fast. People with a fixed mindset believe that their traits are permanent. If they are bad at math then they will always be bad at math, whereas people with growth mindset believe that you can work hard and improve in any area or domain. Having a growth mindset overcomes weaknesses and gives even the most disadvantaged a winning chance.
My favorite Quora answer is about how growth mindset can accelerate your personal growth.
Mihaly Csikszentmihalyi’s flow diagram: optimal flow zone lies between anxiety and boredom.
When faced with challenges, I ask myself, “is this anxiety driven growth or boredom driven growth?” The former is emotionally uncomfortable while the latter risks complacency. Sure, putting yourself out of your comfort zone will induce moderate stress. However, a little stress is good for you because it enhances your performance. I call this “productive discomfort.” Productive discomfort challenges you to work on what is troubling you and develop your weakness. Staying within the optimal flow channel in the above diagram falls into the zone of “productive discomfort”, thereby maximizing your personal growth. So have a growth mindset. Even if you suck now, you’ll suck less over time.
When battling an inferiority complex during engineering bootcamp, I kept reminding myself that you’re not born with confidence, but rather, you build confidence.
The very awareness that you suck at something combined with the growth mindset optimizes for personal growth. The more you know the less you actually think you know.
2. Learning to Code is Emotional Learning. Build the Discipline to Quell your Emotional Reactions.
For someone who feels deeply, thinks a lot, and writes cathartically, coding taught me how to regulate my emotions. Vacillating between peaks of elation to valleys of frustration, I found myself in an emotional battlefield. My amygdala, the part of the brain responsible for emotional reactions, fought with my frontal lobe, which is responsible for decision-making and problem-solving.
My amygdala reacted to the problem whereas my frontal lobe calmly rationalized and troubleshooted. Caught in the push and pull between the two, my frontal lobe tells my histrionic amygdala to “CHILL THE FUCK OUT.” Coding taught me to think first and react second. Know when to discard your emotional reaction and know when to let your emotions drive you. Some degree of frustration and pain will add urgency to solving the problem. However, too much emotional reaction will be draining. Instead, be aware of your emotions and channel your feelings towards a rational debugging path.
3. You Don’t Have to Be an Engineer, Just Learn to Think Like One
It is easy to have an inferiority complex or imposter syndrome and think that you’ll never get those 10,000 hours of coding. Well, you don’t have to. Good news: you don’t need to be an engineer, just to think like one. Product managers, project managers and marketers — or anyone — would benefit to think like an engineer. Thinking like an engineer means focusing on a problem, thinking through it rationally and trying different methods to solve the problem with dogged persistence.
4. It’s Supposed to Be Hard. Struggle is Good for You.
While studying Japanese classrooms, UCLA psychologist Jim Stigler observed that the teachers intentionally designed tasks and curriculum to be slightly beyond the capabilities of their students. Once the students master the task, they point out that the task was accomplished by hard work and struggle. Instead of attributing performance to inherent intelligence, Japanese teachers attributed it to hard work and persistence. As a result, students come out of the classroom with a resilient mindset believing that they should struggle and that learning should be hard. The struggle is real and subsequently, good for you.
So next time, when you find your amygdala duking it out with your frontal lobe over a problem, don’t forget to be kind to yourself. It’s suppose to be hard, so stay gritty. The way I see it, life is just one long debugging triage. After we solve one bug, another more gnarly one will come up. After each bug, we become better-equipped to solve the next one and the next one…until we become one lean, mean, debugging machine.
Happy debugging!
This post originally appeared on Medium.
