Your first morning at a new company usually involves a courier, a sealed envelope containing a password, and a laptop that still smells faintly of cardboard. By lunchtime, someone expects you to be productive. Setting up a development machine properly is not glamorous work, but it is the difference between a laptop you trust for three years and one you argue with every morning. Work through this checklist where you can on day one, and finish the rest during your first week.
Identity, ownership and encryption come first
Three things are genuinely painful to fix later: whose account the machine is tied to, whether the disk is encrypted, and whether the recovery keys exist anywhere other than your head. Sort them out before you install a single tool.
- Sign in with your work account rather than a personal Apple, Google or Microsoft account. Mixing the two causes awkward conversations later.
- Confirm full-disk encryption is switched on: FileVault on macOS, BitLocker on Windows, LUKS on Linux. Check that the recovery key is escrowed somewhere your employer can retrieve it. A key that only exists on the encrypted disk is not a backup.
- Set a firmware or UEFI password if the hardware supports it, so nobody can boot from a USB stick and reset your admin account.
- Turn on automatic updates and set the screen to lock after five minutes or less.
- Check whether you have a standard account plus a separate admin account. Many organisations do this deliberately. Use the admin account for setup work, then step back down.
Worth saying plainly: if the laptop belongs to your employer, assume anything stored on it can be read by them, including browser history and local files. Keep personal projects on your own hardware.
Close the obvious doors before opening new ones
Install the company's endpoint protection agent if IT has not already, and leave the host firewall switched on. Both are boring. Both are also the first thing anyone asks about during an incident.
Browsers deserve a moment of thought. Use a dedicated work profile, or a separate browser entirely, so personal logins never land in a corporate profile that syncs to a managed account. Then be strict about extensions: any extension can read every page you visit, including the internal tools you are about to log into. If you cannot explain what it does and why you need it, uninstall it.
While you are there, check your free disk space. A large monorepo, a few container images, a language toolchain and an IDE will eat tens of gigabytes faster than you expect, and a full disk is a miserable thing to discover at four o'clock on a Friday.
Accounts, keys and access requests
Ask for everything you need in one message rather than five. Being blocked on access is the most common reason a new hire has a slow first fortnight.
- Single sign-on and the company password manager. Work credentials belong in the password manager, not in a notes app or a spreadsheet.
- Multi-factor authentication. Register a hardware key if you are offered one, and register a second factor so a lost phone does not lock you out of everything.
- Git host, CI, cloud console, ticketing, monitoring, internal wiki and VPN.
- A fresh SSH key pair generated on this machine, using ed25519 with a passphrase. Do not copy a private key over from your personal laptop, however tempting.
Request the narrowest role that lets you do the job, and be patient if someone has to approve it. Least privilege is not a lack of trust; it is how a mistaken command stays a mistake instead of becoming an incident.
If your work touches personal data, follow your employer's data protection policy about what may be stored locally. A local spreadsheet of customer records is a problem waiting to happen, and data protection rules are not something to guess at — ask your data protection lead or manager how the policy applies to your day-to-day work.
Build a toolchain you can rebuild
The goal is a machine you could recreate from scratch in an hour, because one day you will have to. That means a package manager, a way to pin language versions, and configuration kept somewhere other than the laptop itself.
- Package manager: Homebrew on macOS, winget or Chocolatey on Windows, apt or dnf on Linux.
- Version manager: asdf, mise, nvm or pyenv. Pin the runtime per project so that "works on my machine" has an actual answer.
- Containers: Docker, Podman or colima, plus a compose file for the services your team runs locally.
- Terminal and shell: Windows Terminal, iTerm2 or whatever you prefer, with a prompt you can read at a glance.
- Dotfiles in a private repository: git config, shell aliases, editor settings. Keep secrets out of it, always.
Write a bootstrap script as you go, even a scrappy one. It does not need to be elegant. It needs to install your tools and symlink your dotfiles so the next rebuild takes twenty minutes rather than a lost afternoon.
Make the thing comfortable
A laptop that is unpleasant to use costs you attention every single day. Start with the keyboard layout. A UK layout puts the pound sign above the 3, the hash beside Enter, and the backslash somewhere that surprises anyone used to a US keyboard. Check that the operating system layout matches the printed legends, or you will spend months typing the wrong symbols.
Then look at the physical setup. An external monitor, a stand to bring the screen up to eye level, and a keyboard and mouse you actually like will do more for your output than any editor plugin. Many UK employers provide a display screen equipment assessment, so ask your manager or HR before spending your own money on a chair. If you have a budget, the usual order of return is chair, monitor, keyboard, everything else.
Finally, adjust the software you stare at all day: larger fonts, a theme that does not glare under office lighting, keybindings that match your muscle memory. Twenty minutes here pays for itself within the week.
Backups, recovery and the boring paperwork
Find out what happens if the laptop dies, then make sure you are not relying on a single copy of anything.
- Push your work to a remote repository at least daily, and at the end of every significant chunk of work.
- Confirm what is backed up automatically and what is not. Build caches and container volumes usually are not.
- Store recovery keys, the serial number, the asset tag and the support contact in the password manager, so you can find them while panicking.
- Test restoring one file. A backup you have never restored is a hope, not a backup.
- Know the lost or stolen device process. Report it immediately — assumed delays are how credentials stay live when they should be revoked.
Your first week on the new machine
Spend the first morning on encryption, accounts and the password manager. Spend the afternoon on your toolchain, and do not chase perfection; a working build beats a beautiful one. At the end of the week, write down every step you had to improvise and fold it into your bootstrap script. In a fortnight you will have forgotten how you fixed the proxy certificate issue, and that note is the only thing standing between you and solving it twice. Then tell your manager which access is still missing, and get back to the interesting part.
Photo: freephotocc / Pixabay
