Turing by the Numbers & What I Learned Other Than Programming
I graduated from Turing a full 5 days ago and have since moved across the country, started to look for my first web dev job, and made goals around community, tech skills to hone over the coming weeks, and personal projects to focus on. I’m not entirely sure how to digest the experience, so here’s a first attempt at thinking about a few pieces of it.
By the Numbers
- 2,077: Git commits
- 486: Miles biked to and from school
- 1,620: Hours spent programming. (It’s an estimate from 60 hours per week for 27 weeks, but I’m surprised to see that number is lower than my number of commits. I either commit a lot or am underestimating the number of hours I spent! Commits do include issues/waffle cards created, and merging other’s Pull Requests, so that may account for some of it.)
- 2: Number of non-programming books I read (for comparison, I used to read about a book a week). I’m looking forward to bringing some of this back.
- 210: Estimated number of times I walked around the 15th-Blake-16th-Market block around Turing. It became a pomodoro tradition that my classmates teased me about but worked wonders for my mental clarity and emotional state. Sunshine matters, ya’ll!
Things I learned other than Programming
Turing turns people into software developers. That’s what we were all there for, and I accomplished that, certainly, but Turing is also more than that. It’s a community that focuses on turning out developers who are also humans with soft skills.
Turing didn’t actually teach me how to do any of these things for the first time, but they sure made me better at it.
- Public Speaking — We give lightning talks. We teach student led sessions. We lead group retros. We talk to our peers with a microphone in our hands until it feels like no big deal.
- How to say “I don’t know” — There might not be many skills in software development as important. Because if you don’t know something and you pretend you do, you’re likely to a) go down an hours- or days-long rabbit hole that someone could have spared you (and the company), or b) create bigger problems than you solved by leaving something unsavory in the codebase for some future unsuspecting developer (or yourself!) to come across. Reading documentation and figuring things out for yourself is an invaluable skill, so there’s a balance between that and asking for help, but knowing when to ask is key. There’s no shame in it — I’m hungry to learn, and asking questions is a good way to do this.
- How to Communicate & Work in Groups — Sure, I’d done this before. But it’s different in programming than in any of my previous work. Each piece is closely dependent on the next, you have to strike the right balance between pairing and divide & conquer. At the intensity things happen at Turing it requires communicating about everything from your technical strengths and weaknesses to your sleep schedule, and we learned how to do that unabashedly and efficiently.