Skip to content

Instantly share code, notes, and snippets.

@Jropp
Created March 31, 2022 17:08
Show Gist options
  • Save Jropp/a1001c0b6040d1d8ae71c60ace09f794 to your computer and use it in GitHub Desktop.
Save Jropp/a1001c0b6040d1d8ae71c60ace09f794 to your computer and use it in GitHub Desktop.

Today is my last day. And today might be one of your first. I have been told my time here was successful and helpful, so I thought I would pass on a couple of the things I've learned that might be helpful for you as you work through your first years as a developer. There's not enough time to say everything, so I'll just list a couple.

Turn Yourself In

There is a great temptation to appear smart and confident in any field, in software this temptation is compounded by imposter syndrome, that nagging feeling that you don't actually belong here. The fear is that as soon as you are found out, you will get the boot out the door.

While a small dose of this dread can keep you on your toes, it can quickly become overwhelming and start to kill your enjoyment and productivity. And then the shame of feeling inadequate compounds with the shame of not getting any work done.

My solution to this problem is to continually turn myself in, to find every opportunity I can to own a mistake when I want to hide, say I don't know when it seems like I obviously should, or call out a weakness in myself that should be accounted for on a given project. None of this is a pity party, I'm pretty cut and dried about it. Name it, figure out what you are going to do about it, make sure the people who need to know know, and move on.

Turning yourself in will both alleviate the presure on yourself to put up an act, and will free up others to do so as well. Every neurosis you have, someone else has their own version of it. Extreme honesty about ourselves can inspire others to be honest themselves.

Invest In The Future You

It has been difficult, but in the face of daily urgent pressures I have continued to invest in practices that benefit me and my team 6 months to a year from now.

For example, I often took a large chunk of Fridays to learn things that felt outside of my day to day work:

  • Bash scripting and building my own automations for work
  • Postgres databases (I have never written a line of database code during my time here)
  • CSS (even before average devs on the team were allowed to write a line of CSS)
  • Hotkeys and extensions for Visual Studio Code

In the short run this feels selfish or wasteful or indulgent, especially with some deadline looming. And had I only been around for a year, I might have "got more done" if I would have done just the necessary work and learning. But things that you learn can compound in ways that you wouldn't expect. So for example learning Postgres helped me catch issues in projects where services engineers were making things harder than they needed to be, and helped me communicate with those engineers more thoughtfully and effectively.

Another way of thinking about it is taking time to work on the engine of a car to make it more powerful. You have to stop your progress to do so, but then for the rest of your drive you can go faster. Those small investments compound in big ways over the years.

Especially as an apprentice, be a little bit ridiculous with the amount of time you dedicate to learn above and beyond what is required. You aren't stealing, you are helping build yourself into a better developer that will return that value to the company down the road.

Find Shortcuts That Help Others

Review a LOT of PRs. I found this trick by accident because I was frustrated that flippin nobody was reviewing PRs, especially when it was a continual bottle neck for our team, so I went on a scorched earth campaign and reviewed what averaged out to be 3 PRs per day for a couple months, even reviewing PRs outside of spaces I had worked in before. In some cases I did "shadow reviews" where I tried to understand the code and called out anything explicitly wrong I found, but in cases where I didn't understand or found no issues, no one knew I had been through the code.

The motives were a little wonky, but I'm glad I did it. Other than it helping unclog the team, I got to see how every developer on our team writes code, and gained new understanding for parts of our platform that were pretty siloed at that point.

It was hard, a shortcut up the mountain means climing a steeper path, but it dropped me on to a harder learning curve every day when I could have just been cruising.

There are things out in the open that help others, that no one wants to do, and that make you a better developer. Find as many of these things as you can and volunteer to do them.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment