Grant Isom — Blog

Vampire: Keep Your MacBook Awake

Tue, 01 Sep 2026 18:00:00 GMT

I close my MacBook a lot while it's still doing something. Long build, big download, whatever. Lid down, walk away. macOS sleeps on lid close, and the fix is one command:

sudo pmset -a disablesleep 1

That's the whole feature. I've been typing it for years.

So I built Vampire, a menu bar app that runs it, and then spent basically all of the effort on the other command.

The two ways I kept failing

The first is just typing it. Works instantly, and nothing tracks it. Then I forget, because the machine looks completely normal, and three days later I close the lid, drop the laptop in a bag, and now it's a space heater with a zipper. The setting is global, sticky, and survives reboots. Nothing on screen tells you it's on.

The second is wrapping it. An alias, a Shortcut, an AppleScript with a privilege prompt. Now I get an admin password dialog every single time I want to flip a boolean, which is enough friction that I go right back to the terminal.

Worth saying since I checked first: Caffeine, Amphetamine, and Lungo don't do this. They take I/O Kit power assertions, which stop idle sleep and display sleep. Lid close is a separate mechanism, and caffeinate doesn't touch it either. Lungo is great at what it actually does, and Vampire isn't trying to replace it.

The feature is the toggle, the product is the undo

Once you decide an app is going to hold this setting for you, the real question is what happens when the app isn't there anymore. Every one of those paths has to land back at disablesleep 0.

What happened	Who restores Off	How
Normal quit	The app	Requests Off, waits for the helper to acknowledge, exits only then
Crash or Force Quit	The helper	XPC invalidation fires, and if the marker exists it restores Off
Helper crash	The helper	Every helper launch normalizes to Off before the listener accepts a connection
Mac restart	The helper	Same startup path, run by launchd
Restore fails	Nobody, yet	The marker stays, state stays Error, and recovery retries on every future start

That last row is the one I care about most. The tempting move when a restore fails is to drop the marker anyway and show Off, because error states are ugly. But then the app is asserting something about your hardware that isn't true. Vampire never claims Off while recovery is unresolved. It would rather show you a warning triangle it can actually back up.

Write the intent before you change the world

The recovery marker is a root-owned plist at /Library/Application Support/Insomnia/active.plist, and the ordering around it is the load-bearing part:

On: create the marker, then run pmset.
Off: run pmset, then remove the marker.

Both directions record the risky state first. If you flip the setting and crash before writing anything down, nothing knows there's something to undo, and the next boot leaves you with a laptop that quietly can't sleep. Erring toward a stale marker is cheap, since a stale marker just means the next startup runs a disablesleep 0 that was already 0. Erring the other way means a silently broken machine.

Never show a checkmark you can't defend

pmset exiting 0 doesn't mean the setting took. So the helper writes, then reads back pmset -g custom and requires every reported power profile to equal what it asked for. Disagreement between profiles is a failure, not a tiebreaker.

disablesleep is undocumented, though, and macOS sometimes just omits the key. In that case the successful write is accepted only on hardware that should support it, and the release checklist covers the rest with a physical lid close.

The menu item sits downstream of all of that. Clicking it doesn't check the box. The box gets checked when the helper says the change happened and verification passed.

The privileged part stays boring

The helper runs as root, so the interesting work is in how little it's allowed to do.

It executes exactly three commands, all with fixed arguments, none of which come from the caller:

/usr/bin/pmset -a disablesleep 1
/usr/bin/pmset -a disablesleep 0
/usr/bin/pmset -g custom

There's no shell anywhere in that path (Process straight to the executable URL, never /bin/sh), and the XPC interface has no generic execute method to abuse. It exposes three operations: status, on, off.

Before the listener activates, the helper reads its own Team ID out of the Security framework and builds a code signing requirement from that verified runtime identity, then hands it to setConnectionCodeSigningRequirement. A caller has to be bundle ID co.groundwork-ai.insomnia, signed by the same team. macOS rejects everything else before my delegate ever runs, which is my favorite kind of security code, the kind you don't write.

And because "the helper must never invoke a shell" is a sentence in a doc, and sentences don't fail builds, CI greps for it:

rg -n '/bin/(sh|bash|zsh)|system\(|popen\(' InsomniaHelper/Sources

A hit fails the build. The same script fails on URLSession, Sparkle, Telemetry, or Analytics in runtime source, which is how "no network, no updater, no telemetry" stays true instead of staying aspirational.

Small things I liked

Hardware support without a whitelist. Model whitelists rot. Vampire supports anything whose model identifier starts with MacBook, plus anything starting with Mac where I/O Kit reports an internal battery. Covers old and new naming, excludes desktops, and doesn't get fooled by a UPS.

The repo says vampire, the code says Insomnia. Bundle ID, helper label, Mach service, and recovery path all kept their original names on purpose. Renaming the bundle ID would invalidate the helper approval the user already granted, and the signed XPC contract with it. A rename there is a user-visible change, not a cosmetic one.

A target whose job is to fail. InsomniaWrongIdentifierClient is a binary whose entire source is exit(EXIT_SUCCESS). It exists so an integration test can point the real signing requirement at a wrong-team binary and assert it gets rejected.

76 tests, and about as many lines of test as source (1,547 to 1,549, which I promise wasn't on purpose). They all use a fake command runner and a temporary marker store, so scripts/ci.sh never touches the real power settings of the machine running it. Anything involving real pmset, real registration, or a real lid close is a checklist item with an explicit ask, and it always restores afterward.

What it isn't

Vampire changes lid-close sleep only. It doesn't prevent idle sleep, display sleep, or screen lock. No timers, schedules, shortcuts, or automatic activation. No network, analytics, updater, Dock icon, or window. MacBooks with a built-in lid, macOS 13 Ventura or newer.

The honest limitation: verification leans on an undocumented pmset key. When macOS reports it, Vampire is strict about it. When macOS doesn't, the best it can do is trust exit status on hardware that should support the setting. That gap is a big part of why it never enables itself at login, and why quitting always restores.

Try it

Grab Vampire.dmg from Releases and check it:

shasum -a 256 -c Vampire.dmg.sha256

Drag it to Applications, launch it, approve the helper once. After that, On and Off never ask for a password again.

Building from source needs Xcode 26 and XcodeGen:

xcodegen generate
scripts/ci.sh

Signed, notarized, MIT, and no runtime dependencies outside Apple's own frameworks. Code's on GitHub. If it saves your laptop from cooking in a backpack even once, that's the whole return on investment!

skill-thief: Steal the Ideas, Not the Install

Tue, 01 Sep 2026 12:00:00 GMT

I read a lot of other people's agent setups. Skills repos, plugins, conference talks, that one blog post everybody links. There are almost always good ideas in there. What I kept getting wrong was what to do next.

So I built skill-thief, a Claude Code plugin that runs the in-between step.

The two ways I kept failing

The first one is installing the whole thing. It feels like the fast path! Add the marketplace, enable the plugin, move on. Except now every skill in it loads into every session from then on, and all those descriptions compete for routing with everything I already had. I paid that cost forever, and the actual insight was three paragraphs.

The second one is doing it by hand. I skim the source, grab the two ideas I like, apply them, and lose the reasoning behind everything else. Six months later I read the same repo from scratch and re-derive the same conclusions. Worse, I re-propose the ideas I already looked at and deliberately passed on, because nothing wrote down that I passed on them or why.

skill-thief is the repeatable thing in the middle.

Every idea gets exactly one verdict

The whole plugin is built around a four-item ladder. Each mechanism it pulls out of a source lands in exactly one box:

Verdict	Applies when	Lands in
Absorb as a rule (default)	No independent trigger. Nobody would ever invoke this by name.	An existing skill body, your agent instruction file, or a conventions doc
Mint a new skill	It has its own trigger. Someone would ask for this at a moment when nothing else would fire.	A new skill directory
Harden a gate	It's a check, not prose. The value is that it fails a build.	A validation script or test tier
Reject	There's a durable, concept-level reason not to adopt it.	The rejection record

The important part is that "absorb as a rule" is the default, not the neutral middle. Minting a skill is the expensive verdict. It spends description budget in every future session and competes for routing with everything already installed. Two overlapping triggers don't average out into good coverage, they just make the router's job harder for both. So a mechanism has to earn "new skill" by showing its own trigger, not by being useful.

Reject has two guardrails I care about a lot. A deferral is not a rejection ("we're busy this quarter" changes with the calendar, so it doesn't go in the permanent record). And you never file an already-implemented idea as rejected, because a future reader will conclude you tried it and it failed, and miss that it's live and working.

Mechanisms, not features

The other rule that does real work: pull out the mechanism, not the feature.

Say a source ships something called AutoReviewGPT that scores a PR against a five-item checklist and blocks the merge under a threshold. The feature name is AutoReviewGPT. The mechanism is "a weighted rubric gate that blocks on a numeric pass threshold before merge." You write down the second one.

The litmus test is simple: strip the source's name and product out entirely. Does what you wrote still tell you what to build? If not, you copied a feature. A mechanism carried over under someone else's marketing name shows up with their assumptions attached, and those get a lot harder to spot once the name sticks.

How a run goes

Six phases, and only one place where anything gets written.

It starts by inventorying your repo and building a map of where each of the four verdicts would even land here. That map gets shown before it reads the source, so a bad guess is cheap to fix. Then it pins the exact version it's reading (a commit SHA, a publish date, a URL), scouts the source for mechanisms, and greps your repo for prior art.

That prior-art phase is my favorite bit, honestly. Evidence of absence has to be actual evidence: the literal command and its actual output, including the empty result. "I didn't see it" and "I searched these six paths with these three patterns and got nothing" are different claims, and only the second one holds up a verdict.

Then everything lands in one ranked table, at one approval gate, once. Not a finding-by-finding approval loop, because that defeats the point of ranking them. Nothing is written before that gate and everything is written after it.

Re-run it later against the same source and it goes into diff mode. It reads the findings doc from last time, resolves the current version, and reports only what changed.

It's not an installer

Worth being loud about: skill-thief never adds a marketplace, enables someone else's plugin, or vendors their code. The only output is changes to your own config. It also doesn't write feature code, and it isn't an auditor for what you already have installed (different question, different cadence).

One real limitation. A thin host repo weakens the prior-art check. If there's not much of your own tooling to find, every mechanism looks like a gap and it will over-recommend. Verdict quality tracks how much of your conventions actually live in files instead of in people's heads.

I ran it against obra/superpowers as a dry run and it's checked into the repo under docs/examples/. Eight mechanisms scouted, three made the gate table (one of each verdict, as it happens). Three of the other five got filed as "you already do this better," and two as "doesn't apply at your size yet."

That last bucket is there because of the dry run. In the first pass those two got labeled Reject, and an independent review caught that both reasons were really about how small the repo is, not about the mechanisms. That's a deferral wearing a rejection's clothes, which the guardrail was supposed to catch and didn't. So the ladder got a new category out of it. Pretty good outcome for a dry run!

Try it

/plugin marketplace add glisom/skill-thief
/plugin install skill-thief

Then point it somewhere:

Use skill-thief on https://github.com/example/agent-skills and tell me
what's worth taking.

Not on Claude Code? The skill body is written harness-neutral on purpose, so copying skills/skill-thief/ into your agent's skills directory works the same way. There's no second copy to keep in sync.

Zero dependencies, MIT, Node 20+. Code's on GitHub. If you run it against something interesting, I'd love to hear what it told you to steal.

Bringing ListWithMe Back to Life

Tue, 24 Feb 2026 12:00:00 GMT

Back in 2019, I built ListWithMe—a simple iMessage app for creating shared shopping lists. My wife and I used it constantly for grocery runs and weekend errands. It was nothing fancy, but it solved a real problem: quickly creating a list that both of us could see and edit in real-time, right inside our conversation.

Then life happened. The app sat untouched as iOS evolved, and eventually Apple removed it from the App Store. I always meant to update it, but between work and other projects, it kept getting pushed to "someday."

Well, someday finally arrived.

A Complete Rebuild

Rather than patch the old UIKit codebase, I decided to rebuild ListWithMe from scratch using SwiftUI. The original app was functional but minimal—just lists and items. The new version keeps that simplicity while adding features I've wanted for years:

Smart Input — Type "3 apples" or "milk x2" and the app automatically parses the quantity. It sounds small, but it makes adding items so much faster.

Priorities & Due Dates — Not everything on a shopping list is equal. Now you can mark items as high priority or set a due date for time-sensitive errands.

Categories — Group items by aisle or type. When you're navigating a store, having items organized by Produce, Dairy, and Frozen makes the trip faster.

Activity Feed — See who added or completed items. When you're shopping together but apart, it's helpful to know what your partner just grabbed.

Batch Actions — Select multiple items to complete or delete at once. Clear all completed items with a single tap.

Search & Sort — Find items quickly in long lists. Sort by name, category, priority, due date, or drag to reorder manually.

The Technical Side

The rebuild gave me a chance to work with some iOS technologies I hadn't used in personal projects:

SwiftUI with the new @Observable macro (iOS 17+)
Core Data with CloudKit sync for seamless multi-device support
Modern Swift patterns and concurrency

The codebase is open source on GitHub if you want to poke around. It's a good example of a relatively simple but complete SwiftUI app with persistence.

Why iMessage Apps Still Matter

When I first released ListWithMe, the biggest complaint was discoverability. Users would download it, then struggle to find where it went—because iMessage apps don't appear on your home screen. That's still true today, and it's still the biggest friction point.

But I think there's something valuable about apps that live inside your conversations. You don't need to context-switch. You don't need to share links or coordinate which app to use. If you're already texting someone, the list is right there.

For my wife and me, it's become invisible infrastructure. We don't think about it—we just have a shared list that updates as we shop.

What's Next

ListWithMe 2.0 is available now on the App Store. I'm planning to keep iterating based on feedback. A few things I'm considering:

Recurring lists (weekly grocery templates)
Siri integration
Widgets for quick access

If you try it out, I'd love to hear what you think. You can find me on GitHub.

Here's to shared lists and fewer forgotten items.

HealthQL Now Supports React Native

Sat, 07 Feb 2026 20:00:00 GMT

HealthQL v1.1.0 adds full React Native and Expo support. You can now query Apple HealthKit using the same SQL syntax from JavaScript/TypeScript apps.

GitHub | Documentation | npm

Quick Example

import { HealthQL } from 'react-native-healthql';

// Request authorization
await HealthQL.requestAuthorization({
  read: ['heart_rate', 'steps', 'sleep_analysis'],
});

// Query with SQL
const results = await HealthQL.query(`
  SELECT avg(value) FROM heart_rate
  WHERE date > today() - 7d
  GROUP BY day
`);

Same SQL syntax as the Swift version—the React Native package wraps the native Swift implementation, so you get real HealthKit queries, not mock data.

Installation

npm install react-native-healthql

Add the Expo config plugin to your app.json:

{
  "expo": {
    "plugins": [
      ["react-native-healthql", {
        "healthShareUsageDescription": "Read health data to display insights"
      }]
    ]
  }
}

Then rebuild:

npx expo prebuild --clean
npx expo run:ios

What's Included

Full TypeScript types
All 18 quantity types (heart rate, steps, calories, etc.)
Category types (sleep analysis, headache, fatigue)
Workouts and sleep sessions
Schema introspection for building dynamic UIs
Structured error handling with suggestions

Also New: CocoaPods Support

The Swift library is now available via CocoaPods in addition to SPM:

pod 'HealthQL', '~> 1.1.0'

Platform Support

iOS only for now. Android throws a clear PLATFORM_NOT_SUPPORTED error—Health Connect support is on the roadmap.

Check the React Native docs for the full API reference.

HealthQL: SQL for Apple HealthKit

Sun, 01 Feb 2026 20:00:00 GMT

I built a Swift library that lets you query HealthKit data using SQL syntax. Working with HealthKit directly involves a lot of boilerplate—callback-based APIs, type-specific query objects, manual result transformation. HealthQL simplifies this into something more familiar.

GitHub | Documentation

Quick Example

SELECT avg(value), min(value), max(value)
FROM heart_rate
WHERE date > today() - 7d
GROUP BY day

This returns daily heart rate stats for the past week. The library handles all the HealthKit query setup, permissions, and result formatting.

Swift DSL

If you prefer type-safety, there's also a Swift DSL:

let result = try await Health
    .select(.heartRate, aggregates: [.avg, .min, .max])
    .where(.date, .greaterThan, .date(.daysAgo(7)))
    .groupBy(.day)
    .execute()

Both approaches compile down to the same intermediate representation before hitting HealthKit.

Supported Data

The library covers most common health types—steps, heart rate, calories, workouts, sleep sessions, and more. It supports aggregations, grouping by time periods, and the standard comparison operators you'd expect.

Installation

Add it via Swift Package Manager:

https://github.com/glisom/HealthQL.git

The documentation site has the full syntax reference and more examples. Feel free to open an issue if you run into any problems or have suggestions.

Accessibility Testing in Maestro

Wed, 19 Jul 2023 15:33:47 GMT

Recently, our mobile team came across a problem with text sizing in our app when customers had the "Larger Accessibility Sizes" Display Text option on. After updating our app to more fully support dynamic text, we came across a cool solution to automate testing this for future releases.

Using Maestro UI Testing, we could enable these settings for certain tests. We created actions within our flows to enable certain settings prior to running the actual UI tests steps. This pattern can be applied on both Android or iOS as Maestro gives you full access to the simulator even running in their cloud environment. If you have not checked out Maestro for UI testing on either React Native or Native applications, I would highly recommend it, as it solves so many historical issues with similar tools.

Below is an example enabling the "Larger Accessibility Sizes" and then launching the target application in an iOS Simulator.

Example Maestro Flow

appId: <your_bundle_id>
---
- tapOn:
	id: "Settings"
- tapOn:
	id: "ACCESSIBILITY"
- tapOn:
	id: "DISPLAY_AND_TEXT"
- tapOn:
	id: "LARGER_TEXT"
- tapOn: text: "Larger Accessibility Sizes"
	index: 0
- tapOn:
	point: "50%,90%"
- pressKey: "Home"
- launchApp:
	appId: "<your_bundle_id>"

This pattern or strategy can be applied to any of the accessibility settings available on simulators/emulators. This can be a huge help to ensure new UI updates and features are accessible while continuing to release fast.

Using Act to Run Github Actions Locally

Mon, 15 May 2023 22:06:58 GMT

https://github.com/nektos/act

The Act package offers a convenient way to execute your GitHub Action workflows locally. It's a valuable tool when debugging or working on issues that either have a long runtime or are complex, saving you those precious minutes.

Installation

The installation process is quite straightforward. First, ensure Docker Desktop is installed on your computer. Then, for Mac/Linux users, the easiest installation method is via Homebrew.

brew install act

That's all there is to it! Upon executing your workflows for the first time, the required Docker containers should automatically download.

Setup

An essential point to remember is to pass in your personal access token from GitHub when running any workflow dependent on SECRETS or environment variables.

Executing Workflows

With everything set up, running workflows becomes a breeze:

➜ act pull_request --container-architecture linux/amd64

Checkout the README for additional examples and a comprehensive breakdown of all the capabilities this package offers. I believe Act is an indispensable tool for anyone working with GitHub Actions who wants to test or debug their changes swiftly.

Expo App Config Setup for Multiple Environments

Wed, 01 Feb 2023 04:22:25 GMT

Expo is a free and open-source platform for creating and building mobile apps using JavaScript and React Native. It is a popular choice among developers for its ease of use and its ability to quickly set up and run a mobile app without the need for extensive configuration. Expo provides a set of tools and services that allow developers to build, test, and publish their apps to the App Store and Google Play with minimal setup and without the need for Xcode or Android Studio.

One of the most powerful features of Expo is the ability to use a single codebase to create apps for both iOS and Android platforms, which can save a lot of time and effort. Expo also provides a rich set of pre-built components and APIs for common functionality such as push notifications, camera access, and location tracking, which can help developers get their apps up and running quickly.

One of the things you may come across is figuring out how to setup different environments or app variants within an Expo app. If you want to just target one binary on iOS and Android, there is very little to do other than setup some environment variables. If you want to have multiple apps for development, QA/test, production, etc then you’ll need to do a few things to be able to take advantage of all Expo has to offer without having to manage these things yourself.

Converting to app.json to app.config.js for multiple environments.

The first step is to convert the app.json file into an app.config.js file. This allows for dynamic changes for things such as your app’s bundle identifier/package name. Below is an example of a basic conversion. Somethings to note is that you are not able to auto bump build numbers when using the app.config.js but there are other ways to accomplish this.

app.config.js

function getBundleId() {
    switch (process.env.APP_VARIANT) {
        case 'development': {
            return 'com.isom.grant.dev';
        }
        case 'qa': {
            return 'com.isom.grant.qa';
        }
        case 'production': {
            return 'com.isom.grant.prod';
        }
        default: {
            return 'com.isom.grant.dev';
        }
    }
}

export default {
    name: getName(),
    ...
    ios: {
        bundleIdentifier: getBundleId(),
        ...
    },
    android: {
        package: getBundleId(),
        ...
    },
    extra: {
        APP_VARIANT: process.env.APP_VARIANT || 'development',
    },
};

eas.json

{
    "build": {
        "development": {
            "distribution": "internal",
            "developmentClient": true,
            "autoIncrement": false,
            "env": {
                "APP_VARIANT": "development"
            },
            "android": {
                "buildType": "apk"
            }
        },
        ...
    },
    ...
}

Now simply providing the --profile when running an eas build command will set the bundle identifier and package name of your app. You can do this for environment variables as well.

Constants.expoConfig?.extra?.APP_VARIANT

The above snippet will return the value set during build at runtime.

Passing Environment Variables to EAS Update

Environment variables are fairly straightforward for updates. You will need to configure use interactive mode to attach branches to variants. But after that, you will just include the environment variable(s) before the command like any other CLI.

APP_VARIANT='production' eas update -p all --branch prod

To wrap things up, if you're using Expo to build your mobile app, setting up multiple environments or variants can be a big help. By converting your app.json file to a app.config.js file, you'll have more control over your app's settings and can utilize environment variables for native pieces. And if you need to pass on environment variables to the EAS update, it's pretty simple. Just include the variables before you run the update command and you're good to go. All in all, Expo makes it easy for you to build, test, and publish your app to both the App Store and Google Play with a smooth and stress-free experience.

Notion 101 for Software Engineers

Sat, 14 Jan 2023 20:28:58 GMT

As a software engineer, staying organized and on top of your projects can be a challenge. Not only are there many projects going on at times, but how your work is managed can be split between tools. We use Jira, Confluence, and Github at work, I use Todoist to deal with personal tasks and projects, and then Notion sits in between all of those helping to bring the information needed to the front. In this blog post, I will walk through how I use Notion as a software engineer to keep my work running smoothly and streamline how I capture interesting or important information.

The Work Log

Keeping a Daily/Weekly Work Log is a great way to document what you worked on during the day and any questions you want to bring up at Standup the next morning. This can be done in any note-taking tool, but I find that Notion is particularly useful for this purpose. I have a daily template set up that I use to log my work and any questions I may have. This template includes sections for:

Tasks completed
Problems encountered
Questions for the team
Things to follow up on

This has been incredibly helpful in keeping my update concise and to the point while not forgetting something I need help with. The work log has also served as a great utility when trying to track down something I worked on that is not easily found in Jira or Github. I highly recommend every engineer at least try keeping a log for a couple months and see if they get a benefit from it.

Templates

One of the most powerful features of Notion is its ability to create custom templates. These templates can be used for everything from meeting notes to planning sprints, and they can be easily shared with other members of your team. These allow you to spend less time setting things up and more time capturing the important information needed during meetings. For example, I have a template set up for meeting notes that includes sections for:

Agenda
Attendees
Discussions
Action items
Follow-up

This has been extremely helpful in keeping track of what was discussed during meetings and what the next steps are. I also have a template for capturing my achievements and work during the year. This way when it comes time for reviews I have a breakdown of all of the things I was proud of throughout the year. This can be very helpful at companies of all sizes and makes your manager’s life easier when understanding your impact. There are endless ways templates can be used, but I think this is a major reason to use Notion or a similar tool over something like Apple Notes.

Web Clipper

The Notion Web Clipper has fully replaced Instapaper or Chrome/Safari Reading Lists for me. It allows me to capture helpful articles, links, even things like README’s from Github. It works on pretty much any browser and mobile and is an easy way to quickly capture web pages that you want to reference later. It also tries to pull the text into a page so you can search over the content of all of your saved links. The Web Clipper is an extremely helpful tool when you are starting a new project as well since you can gather a massive amount of information and references very quickly without having to keep a million tabs open.

Teamspaces and Notion AI

Notion's recent release of team spaces and Notion AI has made it an even more versatile tool for software engineers. Team spaces allows for easy collaboration and sharing of templates, databases and pages within a team, making it a great tool for managing projects and tasks together. Notion AI, on the other hand, offers a range of features to help you with your workflow such as automated reminders, scheduling, and natural language processing to quickly find information. These features have the potential to greatly improve productivity and collaboration within teams. Additionally, with a growing community and tons of resources online to maximize Notion’s potential, it is an extremely versatile tool that can help software engineers stay organized and get work done faster.

9 Must-Read Books for Software Engineers in 2023

Mon, 02 Jan 2023 23:43:56 GMT

As a software engineer, staying up-to-date with the latest developments and best practices is essential for growth. One of my favorite (and what I feel is overlooked) methods for growth is reading books. We spend a large part of our day reading Stack Overflow and blog posts, but books have really helped me see things in a different light or understand something I do not come across on a daily basis.

In 2022, I read a number of books that were extremely valuable to my career as a software engineer. Here are nine that I highly recommend for software engineers at all stages of their careers to consider adding to their reading lists for 2023:

"Build: An Unorthodox Guide to Making Things Worth Making" by Tony Fadell is a must-read for anyone looking to create things that matter. Fadell shares his unique perspective on how to focus on small, achievable goals and pivot when necessary.

"The Phoenix Project: A Novel about IT, DevOps, and Helping Your Business Win" by Gene Kim, Kevin Behr, and George Spafford is a captivating story about an IT manager who must turn around a failing project. Along the way, he learns about the principles of DevOps and how to apply them to his work.

"The Hard Thing About Hard Things: Building a Business When There Are No Easy Answers" by Ben Horowitz offers candid and practical advice on the challenges of entrepreneurship. Horowitz covers topics such as hiring, firing, and managing through tough times, and provides valuable insights on how to navigate the ups and downs of building a business.

"Structure and Interpretation of Computer Programs," also known as the "Wizard Book," is a classic text that covers the fundamental concepts of computer science and programming using the Lisp language. This book is a must-read for any serious software engineer.

"A Philosophy of Software Design" by John Ousterhout argues that good software design is all about simplicity and clarity. He offers practical advice on how to achieve these qualities in your own code. This is a good one to read even on a yearly basis.

"The Pragmatic Programmer: From Journeyman to Master" by Andrew Hunt and David Thomas is a comprehensive guide to becoming a better software engineer. It covers a wide range of topics, including debugging, testing, and refactoring, and is filled with useful tips and techniques. Make sure to pick up the 20th anniversary edition.

"An Elegant Puzzle: Systems of Engineering Management" by Will Larson discusses the challenges and opportunities of managing software development teams. Larson covers topics such as building effective processes, setting goals, and creating a positive culture.

"Software Engineering at Google: Lessons Learned from Programming Over Time" by Titus Winters, Tom Manshreck, and Hyrum Wright offers a behind-the-scenes look at how Google approaches software development. It covers topics such as code review, testing, and technical debt, and provides valuable insights into how to build reliable and scalable systems.

"INSPIRED: How to Create Tech Products Customers Love" by Marty Cagan is a must-read for anyone looking to create successful tech products. Cagan covers topics such as defining the product vision, building a strong team, and gathering customer feedback, and provides practical advice on how to apply these principles to your own work. Commonly recommended for product managers, I think its a great read for engineers as well as it will help when working cross-functionally with your product team.

These books provided invaluable insights and kept me motivated and inspired throughout the year. "An Elegant Puzzle" was particularly helpful in figuring out how to more effectively handle support issues within my team, while "Software Engineering at Google" offered valuable guidance as we were setting up a new project and repository. I hope this list of recommendations will provide some useful reading options for you in 2023 as you continue to grow and develop in your software engineering career.