Second Try at Coding
One path to success -- keep going!
10 min read
I’m starting #100DaysOfCode today, but this ain’t my first rodeo.
In 2017, I attended a free coding bootcamp through Per Scholas, and was lucky to be hired as a software engineer within a few weeks of graduation. But I quit the job in less than a year. As the only woman on the engineering team, and a bootcamp grad without a four-year computer science degree, I was overwhelmed by imposter syndrome and having daily panic attacks on the job. Since the company was mostly remote, I spent most of the week feeling isolated in the dark as a junior developer, struggling to figure out what I was doing wrong, but not getting enough contact with a senior developer to ask the questions I needed to move forward.
I regret leaving that job without fighting harder to keep it. I wonder how I could have asked for more help, or found a way to keep going.
I went back to the nonprofit sector work I had been doing before the coding bootcamp, but never stopped wishing to be a software engineer. This year, I’m starting over on Feb. 22, 2022, to document my second try.
A Bootcamp Won’t Make You an Engineer
This should be obvious, but I’ll spell it out anyway: completing a coding bootcamp does not mean you will have a successful career as a software engineer. It provides a foundation, but in order to succeed, there’s much more work to do on your own. Many of my classmates at General Assembly struggled to find a job after graduating from our 12-week intensive course, and a few never did find a tech job. The top students became Instructional Associates at the program and continued honing their skills for a few months while teaching newer students. A few attended a second coding bootcamp, to continue deepening their skills, and got a job after their second 12-week intensive bootcamp.
Among the graduates who found a job, many were not able to keep their first job for a full six months or year. Some persevered and applied to a second and a third job, until they found one that would be patient enough to nurture their growth. Others gave up or found a different role, in product management or teaching. Only a fraction of people who graduated my cohort are still working as software developers today. A few are extremely successful now at top companies. A longitudinal study of these numbers beyond the first job would show continued drop-offs over the course of the first two years, with a series hurdles after bootcamp, which are not necessarily reflected in elevator pitches for admissions.
Why were some my classmates successful in becoming software engineers after completing the bootcamp, and why did others struggle? How do I truly cultivate the craft of software engineering, with the degree of rigor and depth that I need to succeed in this field?
Over the next few weeks, I plan on having “coffee chats” with some of my old classmates in the next few posts to find out about their journeys since Bootcamp. Stay tuned.
Troughs of Sorrow...Forever?
At a free online bootcamp over Discord and Twitch called #100Devs, the brilliantly inspirational instructor, Leon Noel, promises hundreds of participants in each cohort of his program that they can become software engineers within a year if they faithfully follow each step in the program, and overcome what he calls the “troughs of sorrow.”
The “troughs of sorrow” are those spiraling feelings of frustration you get when you’re stuck on a problem you can’t solve, which makes you feel hopelessly incompetent, doomed in your career choice, and possibly not cut out for this world.
What few students know at the beginning of their journey is that those troughs of sorrow don’t stop after bootcamp, or after you acquire some mystical level of knowledge. In fact, it never stops. It only intensifies on the job. The job is quintessentially the hourly joyride of banging your head against the wall, backing up, and banging it again; the weekly cup of programmer tears, mellow wine in which to dip your hard-earned daily bread.
They don’t tell you that to make it as a coder, you have to get intimately acquainted with frustration, humbly let it ravage you, and learn to enjoy the process. You have to find genuine joy in difficult problems, and create equanimity for yourself as a reward for resolving each incremental issue, hour by hour, day by day. Or you just won’t make it.
Learning to code is the California gold rush of the 2010s and 2020s. The world is changing fast, and there are so few reliable options. (Who cares about your passion? Passion is so Millenial; Gen Z is getting paid.) Outside of tech, all jobs are getting more precarious. Gig economy means contract labor without benefits. Creator economy means 1% of influencers get 90% of the wealth; there’s no middle class. Algorithmic trading has even automated finance bros, who form the biggest demographic at coding bootcamps. The more of us rush out to pan gold, the more we find blue. In our lifetimes, coding may become a blue-collar job. Instead of working together to fix our crumbling safety net, let’s play cowboys instead, and hope we strike it rich! Let’s be pioneers in the Wild West of internet-native commerce; and bank on the triumph of our personal genius over societal decay.
If that bargain doesn’t sound good to you, should you even learn to code?
Coding As Character-Building
Personally, I'm re-committing to coding because I realize the journey is important for my personal, emotional, and character development.
It’s possible to cultivate the mindset of a persistent coder even if you don’t naturally have it. (I don't!) I believe that developing the kind of patient problem-solving mentality necessary for software development is a character-building exercise that is valuable as an end in itself.
Here are ten virtues that you can cultivate in the journey to becoming a software engineer:
- Goal-setting & Reflection
- Dealing with failure & frustration
- Overcoming fear and anxiety. Cultivating Stoicism.
- Humility. Ego is the enemy.
- Organization skills. Cultivating clarity of thought & action.
- Toil — work ethic!
- Systematic self-improvement (Kaizen — what this blog will focus on.)
- Helping others in the dev community, and realizing that this mutual gift passed down through the community is what makes it all work...
In the process of making a career transition to coding, you take accountability and responsibility for your own life, to make yourself better for the people you love. You take a big risk, and you work hard to be able to meet the demands of that risk.
You give yourself the opportunity to earn trust in yourself.
The trust that you earn through hard work — that real self-confidence and self-respect — is worth more than any salary.
Happiness is in the Chase
According to psychological research conducted at the University of Missouri by Marsha Richins, wanting things makes us happier than having them. Happiness is in the chase.
I felt happier during my time in coding bootcamp than almost at any other point in my life because I had concrete dreams that I was working hard towards every day. Striving within a defined structure that promised big, meritocratic rewards, I was excited to make tangible progress every day. The good pain of shared late nights of hard work with classmates during our short, intense sprints was so much more tolerable, even enjoyable, when compared to the bad pain of imposter syndrome at my first job.
I realized that I was happier during bootcamp, chasing after the dream of becoming a software engineer, than I was at my first job as a software engineer.
In fact, once I attained my job, all I could feel is existential angst, and loneliness, and dread. There was no structure and little comraderie during my first year as a junior developer to help me understand where to go from there: how to improve at my job, what to do when I’m stuck for many days in a row, what kinds of questions are in fact too dumb to ask your boss, who to turn to for the dumbest of dumb questions, and where to find creativity, joy and hope.
Growing up with immigrant parents who demanded perfection of me, any small mistake or less than perfect grade would be punished with a physical beating. I carry their voice within me, and it becomes the voice of the Terminal and the Console. At my first job, I had mini emotional breakdowns every time I ran into an error I could not solve. Banging my head against the wall, I would murmur to myself that I must be the stupidest person in the world if I can’t solve an issue. When I do solve the issue, instead of celebrating, I would berate myself for having made a stupid, careless error. I could barely focus on the problems at hand because my mind would become an echo chamber of accusations, fears and premonitions, warnings of a terrible life of destitution ahead. Every error message in the console would be a crystal ball to my inevitable failures as a human being.
Needless to say, all of this mental chatter slowed down my coding.
What could I have done differently? How can I train myself to deal better with frustration and anxiety? I’m willing to try again, and do it smarter, with more emotional equanimity. I don’t think that every work environment will be the same as the startup I had joined as a junior developer. How can I also make sure to find a workplace with more mentorship and support from senior engineers, especially for women and people of color?
Coding As Healing Practice
Writing clean, DRY code requires maintaining clear mental models. As a survivor of violent assault and complex trauma, there are particular challenges that PTSD and anxiety attacks play in being able to hold the concentration and emotional calm necessary to be successful in software engineering.
These emotional patterns are part of a disability that I have to learn to live with. However, I know the severity of these patterns can be reduced and even overcome. In fact, I believe that the practice of coding, and cultivating my mind with the mental habits of a computer programmer, can actually be healing for the parts of me that overreact to frustration and anxiety. I spent the last few years cultivating a meditation and yoga practice, and I believe there are lessons in meditation that can make you a better programmer.
Thou Shalt Debug Thyself
Most of one’s time as a programmer is spent in debugging code that won’t run as expected. Coding is a systematic process of:
Gracefully dealing with error messages
Persistently chasing down deviations between output value and expected values, and isolating the source of the error
Resourcefully searching the internet for helpful remedy
Optimistically testing out various possible solutions
Pragmatically patching up the problem with duct tape copied from the internet
Conscientiously ripping out the duct tape and refactoring the sticky part so it works invisibly without the ugly parts showing. (and writing helpful comments next to the all stickiness for others on the team.)
Taking a similar approach to my own personal journey and self-development as I would take to finding a bug in a piece of code, I will isolate where the problem might be coming from. I will experiment on different strategies that might make it better. I will write tests that I can apply to my daily life to keep checks on whether I am doing the things that I need to be doing to stay on track. I will keep trying and trying until I can get to where I want to be.
In this new “coding journey” blog, I am committed to documenting my second try at becoming a software engineer, by writing about #100DaysOfCode as a journey of character-building, towards nurturing emotional resilience and mental health.
Because chasing the dream makes me happy.
The date is February 2, 2022. Here’s to my second try at code!