A checklist for when you change your development job

If you’re a developer who’s moving onto pastures new, there are a few things you need to check before you go.

More, now than ever, developers are changing their jobs. Whether it’s to take advantage of higher pay, or more options when it comes to remote/hybrid working, it’s very likely that you, as a developer, will be changing jobs at some point in the future.

The hard work is obviously securing that new position — you’ve found an opening, you’ve applied, made it through the interview(s), and been offered it.

Congratulations!

Now you’ve just got your notice period to finish at your current job, and tie up any loose ends. You’ll be excited to start your new job, but you need to make sure you leave your current place in as good a state as possible.

This article will try and give you a few pointers to consider, to make sure you leave things in the best way possible.

Your development machine

As a developer, you’ll have spent the majority of your time working on your development machine, whether that’s a PC or laptop or a virtual machine somewhere.

It’s worth spending a bit of time reviewing what’s on this machine.

1. Check your local repositories

Most developers will be working with some kind of source control (e.g., Git), so it’s a good idea to check each repository and make sure you’ve committed all the changes that might be needed by the rest of your team.

If you’ve got any local branches that haven’t been pushed, now’s a good time to check if anyone else needs the work in those branches, and if so, get them pushed.

2. Check your throw-away projects

It’s pretty common for developers to create new solutions to try things out, run experiments, or even try to automate those mundane tasks you usually have to run manually.

If you’re using something like Visual Studio on Windows, these projects by default get saved in C:\Users\[user]\source\repos, so they could easily get missed if your main projects are saved elsewhere (e.g., in C:\git).

Have a quick review of any projects you’ve created here. If they are all just projects to test things, then you’re probably fine to leave (or delete) them. However, if you find something that might actually be of some use to the rest of your team, let them know and see if they want it sharing with them (or committing into a repository somewhere).

3. Deactivate any licensed software

Depending on what you use, you might have software installed that’s been licensed. It’s common now for licensing to be based upon user accounts, but there are still some applications that make use of a volume-limited serial number, which allows for a maximum number of activations.

If you take the assumption that your development machine will be wiped once you leave (which may or may not be the case, depending on your company’s procedures), it’s a good idea to make it known to your team what licenses you’ve currently got. For volume-based licenses you might need to deactivate your licence so that the licence can be used by someone else once you’ve gone.

4. Delete personal data from your browsers

As developers we spend a lot of time on the internet, and as such, we’re likely to have countless accounts, passwords, cookies, etc. stored in our browser.

It’s important to remember to clear these when you’re handing a machine over. Whilst it may be that your machine is going to be wiped once you’ve gone, a lot of times the machine will be kept for a little while just in case there’s anything on there that you’ve forgotten to hand over before you went, and during those times, someone may log back into your machine using your domain account. If that happens, you don’t want them to have access to any personal accounts you might still be logged into in your browser.

So, before you go, make sure you log out of any browser accounts (e.g., your Chrome profile), remove any saved passwords for non-work accounts (e.g., for Stack Overflow), and remove all cookies to prevent previous sessions from being used by someone else.

5. Check all your files in My Documents, Downloads, Desktop, etc.

Review all the files you might have created or downloaded that are still on your machine, and delete anything that’s either irrelevant or personal. It’s always good practice to only use company machines for company business, but if you’ve been using the same machine for many years, it’s possible the odd file might have made it on there, so it’s a good idea to quickly review this.

If you also find any files that would be useful to the rest of your team, such as documentation on how things work, raise this with your team and see if these files need to be shared with them somewhere.

Your team

It’s not just about your machine you need to care about, you also need to consider what else your team might need from you before you go.

A lot of this should (hopefully) be covered by any handover work that’s already been agreed with you, but try to think of anything that you do or know that the rest of your team might need to know about.

Are there any manual tasks that only you do, that someone needs to take over?

Is there any functionality that only you know about, that you need to get someone else up to speed with?

Are there any projects that you’ve worked on that you need to pass on to someone else?

This is all obviously very specific to your actual role and your team, and hopefully already considered, but there’s nothing worse for a team to have someone leave, and then they’re faced with a problem that they know only you could have fixed.

Summary

There’s a lot to consider when you’re moving development jobs, and it’s tempting to think it’s your old team’s responsibility to handle what happens during your departure.

However, there are some things that you’ll want to do for your own benefit (such as protecting any personal data you might have left around), and there are things you’ll want to do to help the rest of your team. Remember that even though you’re leaving, you hopefully want to leave on good terms and not burn any bridges, in case your career paths cross again in the future.

Finally, good luck in your new role. It might be scary, but you’re going to be awesome at it.