Transitioning to a Real Dev Team
It’s still hard to believe sometimes that I pulled this off (though not on my own, certainly) — that less than a year ago I was thinking about Turing, but hadn’t gotten up the guts to apply yet. That I’m now in week 5 of my first job as a Software Developer. I was prepared, and I was not. There are some things that only being in it can actually teach you.
You mean real humans will use this thing I’m building?
Got your schema wrong? Just drop your database and try again. Not sure whether you have your asset pipeline set up properly to render the same way in production as development? Push it up, find out.
Not so, in the real world. Don’t ever, ever impact production. There are so many environments and databases for a reason. We’re currently in the middle of developing a new feature that requires data model changes — we’ve been doing it in tiny pieces over the past few weeks to make sure nothing breaks, to make sure the end user won’t notice anything, deploying as we go.
Also, error handling. If it is doubtful-but-maybe-possible-probably-not for a thing to happen, it will happen. These real-live-users prove to be pretty ingenious in their edge-case creation, whether intentionally or not. No more just-hit-the-likely-scenarios. Making things fail smoothly for the user, and visibly for the developers is key.
With this too, comes pride in your work. We’re building a thing that is making other people’s lives easier. How cool is that?
Feeling like an imposter is still a thing.
This was a thing at Turing, but part of me wondered whether I didn’t feel like a real dev because I wasn’t one. Now I am one, but I don’t always feel it.
There have been parts of every day so far where I’ve felt incompetent, because it’s a new stack and a more complex codebase than I’ve worked with before. This is hard sometimes, but it is also why I changed careers — because I wasn’t challenged, I wasn’t learning. Those things are not true anymore; I’m surrounded by people who have been doing this for so much longer than I have, who know so much more than I do, and I’m so grateful for it.
We worked 60–80 hour weeks at Turing. We worked weekends. Always, we were working. People warned me that the startup life was intense, that it involved long hours too. Every startup is different I’m sure, but I’ve not found this to be the case so far. We work hard; we have deadlines and are expected to meet them. We don’t have the beer-and-ping-pong culture that some startups do (part of why I chose the company I did, though that’s a different conversation), but a lunchtime game of Bananagrams is not uncommon. Quick iteration matters; there is simultaneously an emphasis on doing things well over doing things quickly.
People have made space for me to work with them on things so that I can learn, even if I slow them down (this will pay off in the long term, of course). We have a thorough process of Pull Request reviews, which means changes usually don’t get merged or deployed immediately, but they’ve had several sets of eyes on them and are better for it.
This is one of my favorite things. I no longer have to make decisions about what to work on next or what the feature or bug I’m working on should look like. We have a Product Manager who works with our Customer Success team and the CTO to prioritize and frame the work. When I finish one thing, I go to the “Ready” column of our kanban board and grab the next one. This means I spend all of my time focusing on the parts I like best — the code. It’s great.