It's coming up on my first anniversary of being employed as a developer. It's been a year of a lot of really big changes, but it's tough to winnow down the focus of the year to being just a developer. I can, however, isolate my first month as a developer and that feels both like a really long time ago and really recent.
If you don't know me, you might wonder why I'm reflecting on just my first month at work and not the other eleven months I've been working. It's because in April 2020 I was diagnosed with breast cancer and everything changed. I've already written about having cancer and I really want this to just be about being a developer. Cancer adds another thread to unravel in an already crazy time, so it was only my first month where I could isolate being a developer from the rest.
It was mid-March 2020. The very beginning of the pandemic. It was a weird world and I was changing careers. I had no idea what to expect. I went from working with the public at a library to working from home. My working from home wasn't pandemic-related. It was just a coincidence that my new job happened to be remote.
Work
My entire company is remote. It’s really cool, actually. It’s a distributed team. There are people in different countries and because of time zones everyone works at different times.
This kind of asynchronous work was in stark contrast to my library schedule. I worked with the public and I had to be there when they were there. There was, understandably, a lot less fluidity in my schedule. Having the freedom to choose when I work was a little overwhelming. It might feel a little more natural over time, but it still feels really weird after my first year.
There are a lot of really lovely things about this kind of workflow. Firstly, I am part of a global team and that is really amazing. Since we work asynchronously it doesn’t matter if I’m online at the same time as my colleagues. We find times where we overlap to speak face to face, via Zoom, but most of the time I’m on my own. The downside to this, however, is that sometimes I have to wait to get a question answered. Most of the time there’s someone online that can help me out, but it also forces me be more patient and sometimes by writing out my question and waiting for an answer I can figure it out on my own.
Learning
My first month of being a developer, I felt like I didn’t know anything. I went from being a library professional of 14 years years to being a complete n00b as a developer. I didn’t know the programming language I was writing or the CMS. I didn’t even know what a CMS was. (It’s a Content Manager System. WordPress is the one I work with.) I went from mentor to mentee and it was very humbling.
I was paired with another developer, a very patient wizard of a programmer. When I started I had no idea the file structure of a WordPress project, let alone a WordPress plugin with hundreds of files. I couldn’t even find the file to work with. How was I supposed to fix an issue in the code?
My mentor and I figured out my learning style as we went. Since there is never just one right solution in code, I didn’t want to just be given the answer. I prefer a nudge in the right direction, a link to a doc or a line number. I didn’t want to be sent a block of code to copy and paste or retype to gain the muscle memory. I wanted to figure it out, I just needed a little help getting there.
This method has served me well. Just today I was given an unintentional nudge on an issue. The other developer was just leaving a note about what she thought might be the cause of the issue. She didn’t know that I had been struggling with a similar but different issue. I had spent hours trying and failing to solve it. With the one little nudge, I was able to close out two issues. A year into my career I still feel like an idiot much of the time, but I know a lot more than I did when I started.
Lessons
I thought I would spend a lot more time writing code than I actually have. While it may have been mentioned while I was in school, that certainly wasn’t my experience. Starting out, I thought that to prove my worth to this company I would have to write a lot of code. I have written code, but I have read far more. I have learned a lot more through reviewing other peoples code than I have from writing my own.
I also thought that I would work faster as I learned more, but actually I am getting slower and that’s a good thing. Now that I am feeling a bit more comfortable, I have learned to take my time. Rather than just jump in and throw a band-aid over a problem, I try to look a little deeper. I take time to at least scan the file I am working on, reading the function descriptions if not all of their contents. I search the code and make sure that I’ve found every time that the thing I’m working on is used and try to make sure that I don’t break that as I fix this other thing. Overall, this probably makes things go faster. My coworkers don’t have to spend as much time pointing out little things that I missed and I don’t have to keep going back to fix things.
This last thing I knew already, but I have to reinforce it every so often: take breaks. I use a Pomodoro timer to make myself remember to take breaks, but I am very guilty of putting that off for just “one more thing.” I thought that I would be working at my desk writing code from 9-5. That is not how quality code is written. Everyone knows that taking breaks is a good thing, that it lets you clear your head and come at a problem from a different perspective, but it’s hard to do in practice. It’s something that I think a lot of developers struggle with, but using the reset of a break really does help me get more things done.
I plan to write more about my experiences with WordPress, PHP vs JavaScript and remote work another time but today I want to celebrate how far I’ve come over this year and look forward to my future in development.
Top comments (1)
Congratulations! I hope this was the first of many years