Development devices for software engineers I like, in 2024
What would I use everyday for software development?
The devices you use everyday become an extension of you1. Familiarity with your devices can drive your productivity levels up way higher, so choosing the right one can be difficult. These are my personal recommendations for development machines in 2024, based on my experiences with a small range of hardware.
My development flow
Since personal workflows are person-dependent, and this article is my own personal recommendations, I thought I’d cover my own workflow — so those with similar workflows value it more, and those with different ones know to ignore me.
I value portable devices, since I do things from home, offices, or trains a lot. Portable means smaller in size, longer in battery life, and lighter in weight. I don’t really use external monitors much these days, though I used to use 3 of them. I prefer to work from comfy seats rather than awkward desks. I value screen real estate, so tend to hide everything beyond the currently opened window. I think that touchscreens are not really valuable on laptops, unless you have a very different workflow from me.
I’m also a strong believer in using devices for development which are as close as possible to what the end user actually will use, since then you’ll discover more of their pain points. Browsers are pretty similar across the desktop OSs these days, so you can get away with running Linux to support users on Windows, if you’re in frontend development. The exception are browsers that are OS specific, like Safari.
I tend to prefer keyboard driven workflows, where I don’t have to press the trackpad or mouse much. I’ve been a Linux2 user for about 16 years, with xmonad being my default window manager for quite a few of those, coupled with dmenu. Tiling window management, or a good-enough approximation, is a must for me.
I typically code backend/frontend/ops type stuff, though I do lean into mobile app development on occasion. I don’t really need any local files except for code, and I typically only install browsers, an editor (VSCode and Obsidian these days), and a terminal. I usually have several tabs open, but not more than 10 or so. I don’t use any extensions, except for uBlock, or ones I’ve built myself. I configure VSCode to automatically close old tabs when I have more than 8. I prefer to search for my apps or type their names, rather than to click through menus or bars.
Outside of coding, I end up writing a lot. Obsidian is my main writing tool, though I use Google Docs a bunch too. I never use Github Copilot, and occasionally use ChatGPT when I have a question Google can’t answer. I’m also an avid reader of news, both societal and tech.
I prefer not to use desktop apps for chat (e.g Slack, Teams), because I can end up getting distracted or doom-scrolling. I use the web-based interfaces instead, opening when I get a notification on my phone or when I want to check something. I also never allow notifications for anything on my desktop3, other than low battery.
With all that clarified, let’s get on to my recommendations!
Chromebooks
Recommendation: Use as your main development device
Price: 💸 to 💸💸
Ease: 🌟🌟🌟
Keyboard-driven or mouse-driven: keyboard, trackpad, touchscreen
The Chromebooks I’ve used have been my favourite machines I’ve ever used. I’ve had the cheapest and more expensive ones, and both have been great for my needs. The earlier models I owned, I would just wipe and put Arch Linux on. There was an option for doing Linux-y stuff from ChromeOS, but at the time it didn’t fit my needs.
Nowdays though, ChromeOS is fantastic and probably the best stable Linux experience out there. While many of the configuration options you’d typically get in Linux are out of reach, moving from xmonad to ChromeOS has been very smooth. My recommended settings are:
Hide the shelf (dock/taskbar) and move it to the right
Disable the Android VM unless you want offline streaming, games, or some VPNs
Enable the Linux container (I’d size it to 50gb, but it’s easily resized later)
Switch Search and Alt in keyboard shortcuts (better for keyboard-driven workflows)
Use Desks as you would in xmonad (Desk 1 is terminal, 2 is browser, 3 is editor, etc)
Turn off battery / memory saving options4
Avoid installing extensions (one of the few attack surfaces remaining on ChromeOS)
Disable Google Assistant
In terms of hardware, my favourite machine for the price point was a Lenovo 5i with 8GB of RAM and an i5 processor. Sadly it’s not being sold any more and finding replacement parts is hard. Google announced a new program for high-powered Chromebooks, known as Chromebook Plus. This is not to be confused with the old Chromebook Plus line from Samsung. Chromebook Plus comes with a minimum amount of RAM, disk space, CPU power, battery life, screen size, and camera quality. They will also get a bunch of features that regular Chromebooks do not get, such as Steam without using the Linux container, built-in camera controls and AI features. I’d recommend anyone using a Chromebook for coding to get one from the Plus line. Touchscreens are common in Chromebooks, but personally I find them annoying, and turn them off5. A Chromebook which is USB-C powered, with USB-C ports on both sides, will help make charging easier.
8GB of RAM is pretty much the minimum you’d need to be able to run the Linux container and have a bunch of tabs open at the same time. The Linux container reserves half of your RAM, so if you have a 4GB machine, your Linux container could only access 2GB of that. Fine for some workflows, but it may make it difficult to run some codebases6. Other than that, most things will run fine in the Linux container. Firefox, VSCode, and Obsidian all work well. The Linux container by default is Debian, but can be switched over to Ubuntu. Linux apps don’t have access to some of the Chromebook’s hardware, though, such as cameras or microphones.
ChromeOS doesn’t allow for installing apps directly to the main OS, other than those few in the ChromeOS store. This is awesome for security, but can be limiting. The Linux container is separated from the main OS, as is the Android VM. But despite that, they don’t feel like an old style VM — apps are handled well by the window manager. Updates to the browser and OS are done quickly and frequently, with little nagging.
Aside from being pretty secure and easily maintained, there’s a big hidden benefit to Chromebooks: if your users are using low powered devices, then a Chromebook is more likely to replicate their specs than a top end Macbook. Linux isn’t the same as Windows though, but Chrome, Firefox, and other browsers can be installed on ChromeOS easily. A Macbook would still be required for doing iOS or Safari development.
If you’re used to a trackpad-driven workflow, then ChromeOS will fit right in for you. Lots of shortcuts, though I never use them. The window manager also supports snapping. Taking partial screen screenshots and screen recordings has never been so easy on a Linux-based desktop OS, compared with my old scripts and LiceCap through wine. This is a general pattern in ChromeOS: things just work as you’d expect them to.
Any future device I get will likely be a Chromebook, where possible.
Macbooks
Recommendation: Someone on your team should have one, at least
Price: 💸💸💸
Ease: 🌟🌟
Keyboard-driven or mouse-driven: trackpad
Macbooks are basically the default development machine in many European and North America, so I would assume most readers are familiar with them. So to avoid boring you, I’ll just focus specifically on the parts I find interesting.
The move to ARM has been amazing, and left x86_64 based machines playing serious catch-up when it comes to performance per power usage. To get near 20 hours of continuous usage is incredible, something that many phones fail to do. The compatibility layer (Rosetta) to run x86_64 programs is very compelling. If you’ve used an ARM build of Linux, you’ll be familiar with the difficulty of running into binaries only compiled for a different architectures, and Rosetta removes a large part of that limitation.
Apple devices are a requirement to make iOS apps, and debugging Safari bugs is much easier if you have one. Safari’s behaviour has been one of the biggest causes of weird browser-specific bugs I’ve encountered in recent years, and figuring out what is wrong without a Mac is pretty tricky. I’ve previously used Mac Minis to be able to make iOS apps, but I think that developers should be consistent users of whatever platform they develop for. Lots of muscle memory builds up if you use a Macbook as your daily driver which you wouldn’t get if you use it only when it’s time to release your iOS app.
With the newer releases, Apple has realized the world is not ready for a USB-C-only world, and added back a bunch of ports. I’ve heard the built-in keyboard continues to be problematic, though. Some limitations exist on external display support, so make sure to check if the machine you’re buying supports enough displays for your preference.
I would not personally want to use a Mac as my own machine, but that’s mostly down to the window manager, the price, and Apple’s ecosystem. But if you’re not used to a tiling window manager, and the company is paying, and your work directly involves making Apple software, then it’s a no-brainer.
Phones
If you’re a frontend developer, I recommend having access to both Android and iOS devices. While mobile views in dev tools and virtual phones have become a major upgrade over deploying something and hoping it looked right, there’s still going to be bugs that you can’t really fix without a real device. You don’t need to own both, but your team should probably have at least one person using an Android device, and another using an iOS device. They’ll be familiar with the normal and expected behaviours and patterns of their devices. Better yet, a device lab in your office will help you grab a device to check how things work for yourself.
I always carry a charged power bank, with at least one USB-A to USB-C, USB-C to USB-C, and USB-A to micro USB cable each. Very handy when you’re travelling a lot, or if you just leave the house without remembering to charge your phone. I’ve also started carrying a USB-C => HDMI converter, because there’s enough people out there without a HDMI port that it comes up frequently during meetings or events.
Other devices I’ve used
I have used machines from Thinkpad T series for running Linux, and most things work out of the box. When they switched from their custom charger port to USB-C, it was a huge upgrade. They’ve got generally great specs, though I will say the screens really suffer in sunlight, the camera and audio are not great, and their cases are pretty fragile. They continue to be my pick for pure Linux (excluding ChromeOS) machines, though.
I also have a Remarkable 2, which I used consistently for art drawing. I find my notes are generally better when they’re written using a keyboard, but for the ability to have a low power device that you can take on long trips to do some drawing, they’re pretty good. I do wish that they had not pay-walled cloud storage, and charging the device when it’s completely flat is a bit weird. You have to have the right cable, and it has to be a low-power one, so it takes forever. Still, to have a device where there’s no notifications or any other kind of distractions, it’s pretty great.
Devices that interest me
I’m very interested in the Framework laptop, particularly the ChromeOS version. Reducing e-waste is pretty awesome, though I’ve heard they have pretty average battery life. I probably would’ve bought one as my main device by now, but they don’t sell to Norway.
Final words
Finding a device that works for you is pretty important, and doing plenty of research before getting one can be very helpful. It’s also pretty important to have access to a wide range of platforms, if you’re a developer. Find people who have similar workflows to you, and ask them about the devices they use.
This article is one in a series, all about recommendations I’d make in 2024 for software engineers. The previous post was all about software engineering practices. The upcoming entries will be about specific programming languages, libraries, and frameworks. See everything in the series here.
There’s a lot of interesting studies out there showing that tools people use are treated as physical extensions of their body.
I’ve used quite a few distros, with the main ones being Arch, Ubuntu, and Fedora. Now I use Ubuntu and ChromeOS, if you count that. This year the Linux desktop share hit 4%, 6% if you include ChromeOS!
If there was a way to auto-reject websites asking “Do you want to enable desktop notifications for this site?”, I’d do it right away. I have never wanted to have them for any site I actually frequently use, and it always seems to end up some ad-laden small news websites that ask you if you want to give permission on your very first visit. Like, no, I just wanted to read about the cheese run.
There’s options to turn off energy and memory saving modes in the browser, but to turn off ChromeOS’s battery saving mode you’ll need to change some flags (chrome-flags://#cros-battery-saver).
I had to add support for splitting up a test suite into smaller chunks so that I could run the full Derw test suite on a 4GB machine.