Apprenticeship: The Unexpected Journey
11 May 2017

Apprenticeship: The Unexpected Journey

I’d been working on my first real programming job for two months when I heard back from Gaslight with this offer: move away from friends and family in Chicago for a temp position with a worse title and less pay. After five months here, I think accepting was one of the best decisions I’ve ever made.

A more deliberate mindset

Though I dabbled in JavaScript and shudder VBA for Excel at odd jobs in college, I didn’t aspire to code professionally until a bit more than a year ago. I went online and followed what seemed to be the standard curriculum for self-taught web developers: build apps that do a, b, and c by following tutorials x, y, and z. It’s amazing how easy and rewarding it is to do this at the moment, and it got me in the door; but as with self-teaching any skill, by the time I had a few accomplishments under my belt I had ingrained a lot of bad habits.

In the context of only working on tutorials or projects that aren’t expected to have a long shelf life, you get some funny ideas about how to make progress. During the great tutorial wars, my only conscious metric of productivity was how many stories I could knock out in a day. Programming to me consisted entirely of taking a list of features and banging my head against my desk until they worked. It was in that state of mind I accepted an offer with a local Chicago company coding an e-commerce site. It won’t be news to any programmer reading this that I started to run into scaling issues with this approach at my first job. I made some perfectly functional horrific tangles of Sass and jQuery. Then they asked me to change them and the work got slowly more… tragic. I didn’t know how I should be writing code, but I knew that whatever was happening wasn’t sound or fun.

Somewhere in the back of my mind, I knew that my cowboy coding would get punished, but nothing about my college classes or fooling around with tutorials ever incentivized me to stop and work on that habit. All of the work I did and all the instruction I got learning to code encouraged me to spend my focus on trying to understand new languages and performance and puzzling out algorithms rather than clarity or reusability. Though I was vaguely aware of some of those issues, I wasn’t in a context that made me prioritize giving them attention. I’ve heard from plenty of people for whom it took years of professional programming to internalize a more deliberative mindset. I can easily imagine a world in which that became true of me. One of the top reasons I know I made a right decision coming here is that the code culture at Gaslight is structured in such a way that inevitably made meaningful progress on this front.

We code as a community

We code as a community. I would guess I spend something like 90% of my time coding at work with a pair. In the beginning, I thought that the value in pairing would be mostly technical. Two brains would be able to figure out how to get a feature done that would have been much more challenging with one, or one could supplement holes in the other’s knowledge. I wasn’t exactly wrong about that. From the beginning of the project I’ve had to lean on my pairs a lot for everything from embarrassingly basic Ruby syntax on up. It’s also deeply rewarding when every once in awhile I get to share some of what I learned in teaching myself JavaScript with my pair. I imagine it’s also true from time to time that we solve problems with a pair parsing more efficiently together than two working independently. Despite that, I’ve found the most valuable feature of pairing to be more about psychology than brainpower.

Clarity of code is part of culture

Pairing gives you a constant reminder of the community to keep in mind when writing. Your audience is your team, and you desperately don’t want to confuse your team. When you’re inevitably tempted to skip tests while pairing, at least one of you will usually feel sufficiently guilty not testing a feature adequately. When two of us can’t figure out how to write something clearly or practice good TDD, we’ll happily call over a third knowing that we all benefit from that use of time. When someone has to understand what you’re writing as it’s written, avoiding simplifying an overly complicated method is a lot harder because only one of you is likely to understand it! How is the person who reads it alone for the first time tomorrow going to fare? When I joined the project, I had a very minimal understanding of anything Rails or Ruby. Somehow I was able to commit code the first day. I think that’s a pretty incredible testament to the clarity of the code this culture encourages. And though I probably haven’t exactly had a net positive impact on the readability of the codebase yet, I’m a lot more proud of the code I write today than the code I was writing in Chicago, and I’m having a lot more fun writing it.

What I didn’t expect to learn

What I didn’t expect to learn at Gaslight is how valuable office culture is to me. Whenever people ask me about my weekend, my answer generally takes the form of “Oh, I cooked X on Saturday, I went and did Y too. But by the time Sunday evening rolled around I was kinda bored and just looking forward to work Monday.” and somehow I mean it every week. I didn’t know that people could have that attitude toward work before Gaslight, and somehow I still feel that way five months in.

When I signed on for the apprenticeship, I expected to be in a constant struggle trying to compensate for my inexperience. I’d heard a whole lot of stories about the difficulties of being novice dev and being judged a hindrance. That just never happened here. I’ve never felt looked down on by more senior devs, and I’ve never been afraid to ask a question or admit a failure. And I don’t get the impression that it’s because they’re handling me with kid gloves; everyone on up from me through the team leaders seems genuinely comfortable admitting their mistakes or ignorance, just as quickly to clients as to teammates as to management. It makes being the novice a lot easier.

Even if you take away all of the code, Gaslighters are still just pretty awesome people. We bring in people from the coding community a couple of times a week for tech talks or just to hang out with coffee and doughnuts on Friday mornings. I play cello with Chris and Bailey on random weekdays after work. People bring in dogs, and somehow their dogs are weirdly awesome too. They let me put a piano in the office. There’s always good coffee and Twizzlers. It’s pretty bizarrely idyllic. I didn’t know to expect or look for anything like the community here in a job before I came. Thanks for the leg up Gaslight!

Heads up! This article may make reference to the Gaslight team—that's still us! We go by Launch Scout now, this article was just written before we re-introduced ourselves. Find out more here.

Related Posts

Want to learn more about the work we do?

Explore our work

Ready to start your software journey with us?

Contact Us