One year as a software developer


This past week marked my first anniversary as a full-time software developer. I thought it would be important to stop and reflect on these last 12 months so this is my “Year 1 retro”. You can read more about my background in the ‘About’ page but here’s the TL;DR: I am a self-taught software developer.

Things I learned this year

thing 1: The value of keeping a record

I opened a Google Docs on my first day of work and since then I have been taking notes about what I am learning, what I am struggling with, how my colleagues are helping me, how to troubleshoot a specific issue, how to solve a problem, my first commit to the code base, etc This has been extremely valuable for a few reasons:

  1. it’s a prime reference material for my bi-weekly 1-on-1’s with my manager

2. I have a reference on how I have troubleshot and solved similar issues in the past (and I have used this doc for this purpose countless times!)

3. I can see my milestones (my first commit, that time when I helped a senior coworker, etc) and celebrate them

4. I can look back to what I was struggling with at some point in the past and realize that that issue/concept is not that difficult anymore

5. give peer feedback

I leave this document open at all times so it’s easily accessible and I can write things down *when* they happen, so there’s no risk of forgetting anything. I also found that even though I might have spent several days troubleshooting and learning about a specific topic, after a few weeks have passed I will not remember that information anymore, unless I go back to my notes. So, future me, keep taking notes!

thing 2: New technology concepts and tools

The number of technical (day-to-day related) stuff I learned this year is quite high. In fact, I can say I learn something new every day! Here are some of the cool things I got to work on this past year (either at work or on side projects): GIT, Docker, shell script, IPv4 and IPv6, websockets, tcp-servers, testing frameworks, REST APIs, product analytics, and some more. Some I had to learn from scratch (shell script!), some I built upon some previous knowledge (GIT) and some I’m still fuzzy about (tcp-servers). Nevertheless, there was no end to learning and this was great!

thing 3: It doesn’t get easier

Being a developer never gets easier. You learn some things and those things are not a mystery anymore but then you have another long list of mysteries to dig through. I thought that everybody but me fully understood everything that was going on all the time so I would “give up” on an issue and request my co-workers’ help, fully expecting them to come to my desk and solve the issue in a minute or two. That never happened. In fact, every time we would end up both (sometimes even 3 or 4 of us) staring at my screen together for some time…. So here’s the lesson: there will always be something that I will be struggling with. The specifics will change as I learn more but it’s the nature of the job to NOT know stuff. Nobody knows everything, that’s impossible. And we all have to be ok with that.

thing 4: Ask for help

Everybody needs help, specially when starting out. I learned to do my research and explore as much as I could on my on and not be embarrassed of asking for help or even raising my hand in a meeting to say that I didn’t understand something, for example. One key thing though is how to ask for help. I might write more about this in the future but there’s a wrong way (“my thing doesn’t work”) and a right way (“I need to do x. So far I tried w, y and z and got these errors/responses. Is there anyone available to help me, please?”). So, it’s ok to ask for help.

thing 5: Time is a limited resource; be smart on how you spend yours

Bugs need to be fixed, features need to be written, tests need to be tested and oh, don’t forget to check that new article on flashy-new-thingy that just got released. It can be overwhelming. Early on this year I struggled with finding enough time to do everything I thought I should be doing until I finally realized that I had to prioritize. I think there’s still some room for improvement here though.

thing 6: Everything seems too hard until you start working on it

Real story: we had one fairly long list of bugs to tackle and the unspoken rule of the land is “you always pick the bug on the top of the list to work on”. I would read the bug descriptions and think that no way, uh-uh, I had no idea what that issue was about and it would be too hard for me to solve it, maybe someone more senior would be a better fit. That happened every.single.time. The reality is that I had no option (plus, every issue seemed equally complicated!) and once I started troubleshooting, reading the code and doing research, things started to click and eventually I was able to fix the problem. However, moving to the next issue brought me back to the “can’t do it” mindset. The lesson I learned is that everything we don’t know is hard but once we start exploring, thinks will start making sense.

Here’s to another year! ?

The post One year as a software developer was originally published on