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