(Previous: One Year Later: Some Thoughts)
I’ve been working in some capacity as a full-time software engineer for about five months now. I’ve noticed some significant differences between programming as a job and programming as a hobbyist:
- I’m not alone. I’m no longer working as fast as I can to get my project up and running, all alone in my basement. I’m a part of a team. That means I have to track what I’m working on, coordinate work on big projects so I don’t overwrite someone else’s changes, and communicate about what I’m working on at all times. It turns out soft skills are just as important here as they were in my previous work as a teacher! Not being alone also means that when I get stuck, I can ask a more experienced engineer to help me problem solve; we are all in this together, so helping each other succeed is important.
- I don’t get to decide what the customer wants. When I was building a portfolio, I made the final call on everything. If the CSS didn’t turn out exactly as planned, it wasn’t a big deal. But now, it’s my job to make everything look and function exactly how it is planned, even when I run into difficult places. Which means that sometimes, the last 10% of a project is the hardest part, whether that is making a webpage that looks the same across a variety of browsers, hunting down obscure authorization bugs in an existing framework, or updating the output of an API from JSON to CSV so that it will render faster.
- I have to get to know legacy code. When I was working by myself, I didn’t have to worry about keeping packages up to date, or what latest-and-greatest frameworks could get added on to something that is several years old. I could just generate a project, get it to work, publish it, and walk away. But a big part of my current job is maintaining and updating legacy code (projects that have been around for a year or more, that I didn’t write), which means building a new skillset. With legacy code, it’s important to learn to find your way around someone else’s work, often with minimal documentation, and be able to update it in a way that is consistent with the way the project is working. It’s also important to know when and how to update existing project frameworks and dependencies to newer versions–if this isn’t done carefully, it can get messy pretty fast.
And one thing is still the same: I’m always learning. My boss encourages me to devote a certain percentage of my work week to tutorials, lectures, classes, or whatever is helpful for me. My team holds brown bag meetings to share the most important information about our projects with each other, and with other teams. When we start a new project, we try to use the latest version of new technologies, which means getting up to speed on new developments quickly. And I usually have a few Stack Overflow pages open so I can see how other people are solving problems similar to mine.
It’s pretty great.
(Next: Problem Solving Strategies: Small Incremental Changes)
Kristen Reinvents Herself... Again 
Were you working a full-time job while teaching yourself how to code? If not, do you think you could have self-taught yourself and be ready to apply for an apprenticeship in, say, 6 months?
thanks!
I was working for the first 3-4 months while I did the basics (Learn Ruby the Hard Way and most of Codecademy). Then I quit and just learned/practiced/built things/worked on interviewing for another 4 months or so (while applying to LEAP, then interviewing). And then I started the LEAP apprenticeship my 5th month after quitting my job. I think I got lucky on the timing, and I don’t think I would have been ready so fast without quitting. But I also have a small child and a husband who works, and I didn’t want to disappear from their lives, so I made choices to take a lot of breaks too. All that to say, everyone is different, but I think for most people learning full-time (bootcamp or otherwise), 6 months to a year is pretty normal to get ready for a job. If you’re also working, I would probably double that estimate.