Today marks a full year for me as a software developer. I thought it would be worthwhile to spend a little time reflecting on what I’ve learned and experienced.
Not as much code as I expected. I don’t have hard and fast numbers but I estimate that I’ve spent about 30% of my time doing research about proposed projects. Specifically, the client wants XYZ or we need PQR tool, what hurdles are there likely to be? How difficult will this be? How many hours/days should this take? In a lot of ways this is a great opportunity to get exposure to parts of the video player codebase that I might not otherwise see. It also gives me a chance to deep-dive into technologies that may not be implemented, but it’s worthwhile to understand how those pieces might fit into our system. I do read documentation for code that does enter the codebase, including the HTML5 video spec, Apple’s AirPlay and iOS specifications, and the Android Chrome autoplay specifications.
Communication is vital. I know, it’s not a huge revelation. But, I spend two years completing a master’s in applied history, and twice I completed professional writing certificates. My previous career was writing appeals to medical claim denials. It’s fair to say I have a lot of experience with writing (though I admit I need to work on brevity). Fortunately I have a project manager who appreciates that I will stop the conversation to ask “what is ‘it’ that’s being referred to?” or similar questions. I don’t mean to be pedantic, but when there are four projects that are approaching readiness to ship “this looks good to me” is a statement I’m going to ask for clarity about. Slack has been a great tool for group and individual messaging, and is the primary way we communicate between Bellevue and New York. Our Jira understanding is improving, and we are growing more accustomed to leaving robust requirements and work comments on each ticket.
I’m more independent than I gave myself credit for. We did pair programming and small group projects almost exclusively in my boot camp. This was great for learning but it may have set some unrealistic expectations, at least in my case. Pair programming is nice when my teammate is available to work on part of a ticket with me. But more frequently we exchange messages on Slack, I work on the problem, more messages, more work… until it’s time for a PR to be reviewed. I do quite like proper pair programming, but I am increasingly confident that I can solve problems with minimal input.
I was on my own for two weeks and nothing blew up! Related to the above, last November I spent two weeks as the only person on my team. Yes, 15 weeks into my career as a developer I was left to fix tickets on my own, I had production keys and a mandate to use them to ship code. The good news was that we were in a slow period. It was nerve wracking. I answered a lot of people with “I don’t know but I’ll find out!” and I did.
I’m learning to maximize my commute. Currently I commute about 150 minutes a day. Fortunately: my Kindle’s battery is still going strong; there are a lot of great podcasts available; my 4G connection is stable for most of my trip so I can tether to finish work, read about coding and hobbies; and, of course, there’s napping. Lately I’ve been combining additional research with podcast topics and questions that come up in mailing lists (today’s question: why index a database? Why not?)
Being social is required. Despite as much time as I spend working on projects by myself, there are plenty of opportunities to interact with coworkers. A close-quarters open office layout is no place for being standoffish. I’m frequently grateful for the great folks I work with. We have a lot of laughs while doing a lot with very small teams (2-4 people).
Recruiters are optimistic. They also (apparently) follow LinkedIn. As my year anniversary approached I started to hear from more and more recruiters. Many of them were very eager to fill roles in CA, VA, NJ, TX and other not-Seattle locations for PHP, Python, C#, ASP.NET and other technologies. All of these roles required at least three years of experience and a host of other skills that I don’t yet possess. Maybe some day, folks!
Flexibility is mandatory. We are a smallish shop and we have to be responsive to client requests. A quick story: while I was working on my master’s thesis the absolute worst possible thing that could happen did – I found a recently published answer to the question I was researching. That’s thesis death!* I had four months to come up with a new topic, re-write my proposal, reconvene my thesis board, defend a second topic AND defend why I had to have a second topic, then I had to essentially restart my research. I do have that master’s degree. How is that relevant? When we have a client request (or something breaks) it is all hands on deck, fast pivot over to the new problem, research what the cause is and come up with a solution. It is stressful and we do a good job of not stopping to wring our hands that something went wrong, but we use that time and energy to fix it. *It did confirm to my committee and me that the question I had been asking was relevant to the body of history, but it did sink that project.