8 Things I've Learned in 12 Months on the Job

When I originally began writing this post I was a happily employed developer in a role that I enjoyed on a team that valued communication and mentorship. I struggled to continue writing it when I lost this job unexpectedly a couple weeks shy of 12 months.

Surely, the imposter syndrome reasoned, if I was no longer at the job I had no business writing a whole post intended to help and relate to others in a first role. But this is unproductive, and if being transitioned out of a role involuntarily means someone can’t write about their industry experience then we probably wouldn’t have very many bloggers.

In the last year I’ve experienced every feeling I was warned about while learning and job hunting - the frustration with endless meetings, the brain lag, the burnout, and that feeling you only get from closing 150 browser tabs after finally completing a ticket. Not every day was a good day, but every day presented an opportunity to grow in some way.

Because there’s power in iteration - several of these points appear on my first post 5 Things I’ve learned in 6 Weeks on the Job

1. Embrace your community.

Get to the know the developers around you! This is harder on a remote team, but it isn’t impossible. Make commitments to the meetings and show up for the people around you, the first step is becoming a familiar face.

2. Document, Document, Document.

I could talk about the power of good documentation all day - but this goes beyond documenting the things you need to, or the things you intend to share - document everything you can stand to.

I use Notion religiously, which is a project management and note-taking app (if you haven’t heard of it 👀). I keep a space for work using different templates, like the Journal Template to track individual tasks and larger projects, and calendar views to keep meeting notes in a logical order.

When I start a ticket I pop open a blank journal entry and track my progress from investigation to blocker, resolution, and completion. Having these living documents at my disposal makes it easier for my peers to help me and for me to help myself when I inevitably run into the same problems and blockers further down the road.

Because human memory is such an unreliable thing these notes don’t have to be detailed to be useful later, and mine often include more screenshots than written words. The point is that they help me remember where I left off, where I was going, and what I’ve already tried. As an added bonus this practice has improved the quality of the documentation I write when it matters.

3. Don’t forget the company tooling.

If you’re working for a company of a mid-to-large size they probably have an entire suite of programs and services that they use to obtain metrics and track various data points like employee engagement and happiness. Make sure that you use these tools, even if you hate them, because the company spends (a probably not insignificant amount of) money on them.

I found it useful to bookmark and store these in one folder that I trudged through on Friday mornings.

4. Ask the ‘stupid’ questions.

"Chances are it isn’t a stupid question, and someone else is probably wondering the same thing."

These wise words came from my favorite no nonsense project manager.

5. If you make a mistake, be proactive.

Mistakes happen. Reach out to your community and let them know what happened. Ask questions and learn from it, double points when you can learn from the mistakes of others.

6. Effect the change you want to see.

A few months ago a new engineer joined the frontend team I was working on and she asked that we use the Zoom “raise hand” feature when we wanted to speak during meetings. A couple days of adjusting, and just like that we spent less time interrupting each other, and more time joking about the man who raised his hand for 45 years. Sometimes it really is that easy to effect real change for the people around you. If you have an idea, or know of something that could improve the day-to-day for your team, say something!

7. Find what motivates you to code and seek that out.

This is a piece of advice I got from my first manager, and I’ve kept it close. Your best work is going to be the work you care about doing, so figure out what that is.

For me it was accessibility. I sought that out by creating tickets for the problems I saw, looking out for tasks that touched it, and started a team channel to talk about it. Through this I eventually found myself invited to product design meetings, talking to more people outside of my core team, and learning more than I ever would have on my own. But most importantly - I enjoyed doing it.