A Retrospective on Seven Months at Turing
Article Table of Contents
Collection of thoughts on Turing #
It’s the last week of Turing. I went through the backend software engineering program, and it’s been a journey.
In no particular order, I’m throwing down thoughts in three general categories:
- What went well
- What didn’t go well
- What I might have done differently, were I to do it again
I believe there is a narrow window for me to capture this information well. As soon as I get a job, I’ll probably forget everything that didn’t go well, and if I were to never get a job, I’d forget anything that went well.
Went well #
Learning #
I’ve learned a ton, and my pace of learning has steadily climbed through Turing, as I build a more and more robust mental for existing information. It’s easier to add new information when the framework for the old stuff is strong.
I use Anki (a flashcard app) every day, so even on days when I don’t write any code, I’m still getting reps in of practice, and strengthening mental pathways. I’ve used Anki every day since Turing started, and have almost 1000 cards in my programming deck.
Getting in simple exposure to programming #
Quality beats quantity, but at the beginning, I’m simply resigning myself to pursuing quantity.
I’ve committed a lot of code. It’s not good code, but it’s code, so I’m making progress and learning.
I filled up 1.5 large notebooks with notes and code, and many whiteboards.
Cohort #
I bonded with the folks I went through Turing with. I think we’ll be friends for a long time, and will try to meet up every now and again. (I hear there’s a trip to a beach in the works for a year from now.)
Outside of Turing #
While Turing dominated my time these last seven months, I enjoyed still spending lots of time with Kristi, and I managed to sneak in a surprisingly large amount of rock climbing.
I’ve been improving in my climbing, but that’s a topic for a different time.
Didn’t go well #
I’m technically not graduated yet - I’ve started this a few days before the end of Turing.
I feel like the quality of my work on the last two big projects was low. I still have a lot to learn about JavaScript and DOM manipulation, and I’ve not yet gotten enough repetition in with those basics to have simple tasks be effortless and quick to achieve.
So, that’s been a bit stressful. I have generally high standards for my work, and when I can’t meet it, I become convinced that I’m failing everyone else’s standards as well.
Why did these last two projects go poorly?
Tactical reasons they went poorly #
I expand on this concept below, but I have a “slow but thorough” learning style. I struggled to spend the time I needed getting in repetition and depth of learning while managing the high rate of work required at Turing.
If I didn’t have the time to dig deep into something, I’d skip it, and aim to complete the projects.
If I were going to re-do my module three prework, I’d work through this tutorial three times in a row:
Build a RESTful JSON API With Rails 5 - Part One (DigitalOcean Tutorial)
I’d find some node/express/deep dives into JavaScript before module four started. I felt a bit behind there as well.
Strategic reasons they went poorly #
I learn things slowly.
Some folks at Turing have expressed the incorrection assumption that I learn things quickly, and I try to correct their wrong thinking. I always aim to get early exposure to a topic, and to play with it before I have to use it in any sort of production environment.
I did a fair amount of work before Turing to gain exposure to the topics we covered in the first half of the program, and consequently had a good frame of reference for the things we learned.
The topics in the 2nd half of the program I’d gained no prior exposure to, and felt ill-prepared by the recommended pre-work that we did over the intermission weeks.
For the duration of both of the second mods, I felt behind, simply enough.
The good news here, though, is given the world of difference that I experienced based soley on prior exposure to a topic… with repeated exposure, I can feel comfortable with just about anything.
This is encouraging, because I have many years to gain comfort with a range of technologies.
Summary #
I’m thrilled I did Turing. I’m not good at big “summarize this huge thing” write-ups, and much prefer to do small posts on bite-sized topics. So, much more to come on that, down the road.
Would I recommend Turing to someone else? It depends. There are some very important non-Turing-related details that lined up nicely for me. If someone else is in the same position and has the same inclination, I’d say go for it. This was well within my range of comfortable risk, because of the following:
I had my wife’s enthusiastic support #
I cannot overstate how empowering this is. Kristi has been making all of our money this year, on top of managing most of the details of cooking, food prep, etc. Her efforts freed me up to just think about programming, which is a significant advantage. On top of that, she of course provided great emotional support
I’d been planning on something like Turing for over a year before starting, and we’d been saving money appropriately, both for Tuition, and for living expenses while in school #
Kristi ended up changing jobs shortly after Turing started, and it came with a significant pay increase, so that dramatically changed (for the better) our financial situation while I was in school. Also, turns out you can defer most of your tuition for Turing until after it ends. Those two things left us with more margin in our budget than I’d expected.
This wasn’t the first time I tried to learn software development #
I’ve done the self-study thing for a while before Turing started. That made the first half of the program much smoother sailing for me than they might have been otherwise.
I’m not a total stranger to the world of software development #
I’ve worked for two different software companies before doing Turing. I have a bit of the lay of the land, as it were, of how a “standard” software company fits together. I also spent time doing support and sales (and a bunch of other stuff) for technical software products, so I’m comfortable with the common pain points of software development, and I can speak to the value I’ll bring to a development team. This diminishes any pressure I feel around getting my first development job.
The sales experience in particular was helpful - I feel no discomfort cold-emailing people and setting up virtual or in-person informational interviews. Since informational interviews are the best predictor of getting jobs, this feels like a significant advantage.
These four pieces alleviate lots of potential pressure, and make this a much less risky decision than it might be for someone who doesn’t have this same context and environment.
That said, if someone is curious about software development, I’d 100% recommend they kick the tires with Turing and some online tutorials. Or shoot me an email. We can talk about it. I think it’s a great decision, provided someone knows what they’re getting into, and have set up systems and support for themselves as they move through the program.