Unrelated image from pexels.com to make this post look nicer in social media shares and because Pallas Cats are the best.
Unrelated image from pexels.com to make this post look nicer in social media shares and because Pallas Cats are the best.

Even if you just graduated, there are some simple things you can do to make your new team think you’re amazing, and they don’t even involve any code. Ironically, a huge amount of the stuff that makes someone a really good programmer has nothing to do with sitting down with an editor and writing code. Being an exceptional programmer is as much about making your team more effective as it is about just writing good code yourself.

A big thing that can help your team get more done is to write absolutely everything down when you set up your development environment for the first time at a new job. Everybody means to do this but hardly anyone actually does. No judgement, my current job is the first one where I’ve done a good job of documenting environment setup and it’s my fourth job since graduating from college. If you can, it’s even better if you can write a simple script to set up stuff like environment variables. In some offices everyone gets to choose their own OS and scripts are only so useful, but even a script that only works for one OS at least gives other people something to work with.

Why is this important? Because you are far from the last developer your company is ever going to hire and the less time the people who come after you spend setting up their environments the more time they can spend learning the codebase and actually making themselves useful. It seems minor, but the hours it takes to set up an environment really add up over multiple hires. It’s also incredibly helpful if you’re allowed to work from home and need to setup your environment again on your personal computer or if you switch OSs or need to do a full reinstall or your computer dies and you need to setup a new one. Seriously, just documenting environment setup will make your team think you’re amazing and make everyone who comes after you more productive.

But if you want to do even more, it’s also awesome if you can document parts of the codebase as you learn them. No matter how much sense that code makes right now, you will forget it, and again, this is super helpful to everyone who comes after you.

If your team doesn’t have a place to store docs, see if you can start one. At my work we use google apps already, so it was really simple to create a google sites wiki that can only be viewed by people from our organization. If you don’t use google apps, pretty much any tech company is going to have a spare box you could spin up a wiki on. Whatever you do, just make sure there’s some sort of security – if you’re not going to put concrete details about your code in your docs, there’s not much point having them – and that you’re not using a free service that’s going to up and disappear out from under you one day. If nothing else, you can always put some text files on a shared drive and call it good :)

While you’re at it, it never hurts to document processes like how to deploy to staging and prod, how to fix common errors, where all of the log files for different services are, where those different services themselves are. Basically any time you have a question you have as a new developer, write the answer down where other people can find it. If you need to know, so will the next dev.

The less time your team spends re-learning code or hunting down a lot file, the more everyone gets done. That’s something you can help with no matter how new you are.