Having the US president militarily threaten your kingdom certainly doesn’t make me more enthusiastic about sending my money our my data to the US, so I’m beginning a much more full migration of my digital footprint away from the United States. I’m documenting my journey here to hopefully inspire others on how to do the same¹.

When starting this process I needed to reflect on a few things:

• I use a lot of US services, and often for good reasons. Whether it’s because they have a generous free tier, they’re the best you can get, or just because I’m used to them. Migrating over won’t be something I can accomplish in one day, so I’m dedicating a few hours to the process every Sunday. I hope to dedicate a blog post to each phase.
• This is probably going to cost money for me. I don’t think it’s necessarily going to be a lot of money, but I am willing to put my money where my mouth is and help strengthen the non-US tech scene.
• I might never be able to get away from all US technology. My personal computer still runs Windows (might switch that though), my Smartphone still runs Android, and my credit card is still a Visa. I’ll need to be pragmatic and focus my energy where I can make reasonable choices.

Low Hanging Fruit

I’ve switched my search engine to Ecosia. If you’re already using Chrome, I can recommend switching over to the Ecosia browser. Ecosia is a German-based company that donates all its profit to help combat climate change.
I’ll fully admit I don’t think the search results are as good as Google², particularly for local queries, but you can always prefix your search queries with !g and it’ll redirect to google for the tricky queries.

First Phase

The first phase for me is switching over services that I actively pay for. The services I pay the most for are cloud file storage. I actually pay for both Google and Dropbox³.
I’ve moved them both over to Proton, a privacy focused company from Switzerland. Proton also seems to offer almost a full replacement for all the Google services I actually use.

The process for migrating took a little while but actually wasn’t too complex:

• I signed up for Proton and installed the Proton Drive appliction on my desktop computer
• I exported all of my Google data via Google Takeout, and downloaded the files.
  • For my photos I followed this workflow to get them into proton drive
  • For the rest of the Drive files, I just dropped them into a directory that Proton drive syncs with the cloud.
• For Dropbox I already had the desktop app installed, so synchronizing over was a simple matter of copying the files into a directory that proton drive syncs to.

This process wasn’t particularly difficult, but syncing many hundreds of GBs did mean I had to leave my computer running for a fair amount of time.

After synchronizing, I deleted most of my old / big files from both Dropbox and GDrive, and cancelled my subscriptions.

I was paying around 15£ per month for Dropbox (I was on a subscription much too big for what I needed), and around 4£ per month for Google One.
I’ve managed to move all my files to a 15£ a month subscription to proton, that covers both me and my partner.

After moving these services, the only US tech service I still actively pay for is 6$ I spend on DigitalOcean every month to host a small website.
In the next couple of months, I hope to move that service to Scaleway which I’ve used before and quite like.

Next Phase

I expect the next phase for me to be switching over my email. I’ve started setting up proton so that I can use hi@gustavwengel.dk as my primary email address.
I didn’t get around to migrating over accounts or forwarding emails today, though - hopefully that’s for next time.

This Sunday I didn’t get quite as much done as I had hoped (our dishwasher broke and I had a lot of dishes that needed washing), but I did manage to get further with migrating my email over to proton, and I’ve set it up so that you can now reach me at hi@gustavwengel.dk, instead of my old Gmail.

I spent a bit of time digging through 1Password to see what accounts I wanted to switch over, and oh boy do I have many accounts lying around for services I never use, or haven’t used in years. I decided to switch over a handful of accounts that I’d actually be sad to lose access to, and leave the rest as ghost accounts still tied to my old Gmail.

As for my old email? I’m probably going to keep it around for a while. I’ve set it to redirect to my new one (took like 2 minutes), and proton helpfully offers a wizard to import contacts, calendars and emails from your Gmail to proton.

Changing habits is hard, and I still find myself reaching for my old mail, but hopefully having changed accounts, and replaced the Gmail app on my phone will make the muscle memory stick eventually.

I’ve sent my first outbound email from my new mail, and everything seems to work just dandy!

Next Phase

Next week my plan is to try and move away from the wider Google ecosystem:

• Replace GDocs with Proton Docs. I don’t imagine this will be very hard as I don’t actually use it for anything fancy, but I am uncertain about how I’ll migrate my documents.
• Replace my Google Calendar with the proton calendar
• Figure out what to do as a replacement for Google Keep

Last week I didn’t get to do anything, as I spent all Sunday setting up a self-contained solar panel circuitry with a battery and everything.
I’m pretty sure it’s a hideously large solar cell for running such a small light, but it makes me happy every time I see it light up. Solar cells are super cool!

Taking light from the sun, and turning it into... well more light!

Anyway, enough about solar energy, let’s talk status updates of tech migrations. There’s been some good and bad things.

What Went Well

First off, switching email has been much easier than expected! As emails are forwarded automatically from Gmail to my new proton mail, I’m not really scared of losing an y emails, and then I just start any new conversations from the new proton-based email.

Running inbox zero in both emails is a little annoying, but it’s good motivation for switching stuff over (or perhaps unsubscribing from a few things). A surprising amount of services require you to write them an email to switch your email, but on the other hand, at least you can write them an email. I’m looking at you, horrible AI “support assistant” bots.

Switching over to use Proton Drive and Proton Docs instead of Google Drive & Google Docs has been pretty seamless.
The only hiccup has been that when you export your data via Google Takeout you don’t automatically get shared directories, so you have to download those manually if you need them, so I had to go through my GDrive to determine what I wanted to keep.

I also canceled my Netflix today. A very easy decision that I’ve been putting off for a long time, mostly due to inertia - they almost never have anything I want to watch.

What Went Poorly

I was really hoping that at this time I would have switched my Calendar away from Google, but Proton Calendar doesn’t support reminders (or tasks, as I believe Google calls them these days), which I use extensively. Seems like I’m going to be stuck with Google here a bit longer, until Proton ups their game.

I also wanted to try out Mistral as an LLM, specifically I had a small web scraping task that I figured I would test it out at¹. It’s, not great. It’s doing the thing the frontier models used where it’d say something was “perfect” and “fantastic”, when it doesn’t work at all, which is a tad disappointing.

It is however, much cheaper than e.g. a Claude Max subscription (15€ versus 100$ or 200$ a month), but it seems here you do get what you pay for.

Next Phase

For my next phase I’m hoping to move my hosted services out of DigitalOcean, as that’s the last US service I pay actual money for.

I spend a fair amount of time reviewing code, and I’d like to think I’m both reasonably fast and thorough. Over time, I’ve developed some habits, that I think make this more efficient. Not all of these habits might be relevant for everyone - we’re all wired differently in our brains.

I also recommend checking out Google’s Engineering Practices, which provides a short, pragmatic take on code reviews.

Read the PR Description First

The first thing I do when reviewing a PR is read the description. A good description should explain what is being changed and, more importantly, why. If I don’t understand the intent behind a PR, I can’t judge whether it’s the right change to make.

A test I often use: if I revisit this PR in six months, will the git history tell me what I need to know? I prefer all relevant context to be included directly in the PR description rather than relying on external issue trackers like Linear, Jira, or GitHub issues. Git logs don’t decay over time, but if your company changes issue tracker - good luck finding out why the changes described in JIRA-3481 were made.

If the PR description isn’t clear or doesn’t justify the change, that’s my first point of feedback. I also often check whether the code aligns with the description, and provide feedback on that.

Keep a Notepad

While reviewing, I almost always have somewhere to jot down thoughts and questions—things like:

• “I don’t understand how X works with Y.”
• “This is different from how we normally do X - why?”
• “What happens if the user provides input X?”
• “This looks tricky - how well-tested is it?”

Mostly I keep these as a list in a separate text file. This helps because questions you think of, often aren’t answered until later in the PR. Writing them down means you don’t have to worry you’ll forget them.

Once I finish reviewing, any unresolved notes become comments for the author—ranging from clarifying questions to suggestions for improvement.

Some PRs Are Quick to Review

Not all PRs require deep scrutiny. Some are quick to review, especially if they involve:

• Small refactor-only changes (especially if no tests are modified).
• Renaming things across the codebase, e.g., renaming energy to electricity, streamlining capitalization or similar.
• PRs that only add additional tests or logging.
• Bugfix PRs that involve minimal changes and come with a test.

When a PR is well-scoped and self-contained, it can sometimes be reviewed in minutes.

Some PRs Need to Be Split Up

PR review time scales exponentially with size. If a PR contains multiple unrelated changes, I have to manually untangle their interactions, which takes significantly more time. I often request that PRs be split, especially if they mix refactoring with feature work or if they are difficult to review in a single pass.

Spending the time as an author to split up a PR, can improve the overall time to ship, because the time you spend is often less than the extra time it would take your reviewer to review the larger PR.

Pay Extra Attention to Module Boundaries

Code generally have parts that are public, and parts that are internal. You can consider the public part the “module boundaries”: The parts where the module interacts with the outside world.
The module boundaries could be an end-user-facing HTTP API, or simply the methods your particular module exposes for other code to interact with.
Often, getting the module boundaries right is more important than getting the internal details perfect. If a module boundary is well-designed and its implementation is properly tested at the level of the module boundary, it is often easy to refactor the internals later if needed.

When reviewing module boundaries, I pay particular attention to:

• How easy it is to use from the perspective of other developers or API consumers.
• Whether the type system could enforce constraints that are currently left to developers to uphold manually.

Evaluate the Author & Module Match

The level of scrutiny I apply depends on both who wrote the PR and which module it touches.

• If the author is experienced and has a strong track record, I will probably still comment on many things, but I will be quicker to accept their reasons for the way the code looks.
• For newer developers or those unfamiliar with a codebase or a module, I generally take a little more convincing that their approach is correct, and challenge them a bit more. Both because I can’t take their good judgement for granted yet, and because I see it as a learning experience for them.
• If the author is the primary maintainer of a module, I often frame feedback as suggestions rather than things that must be fixed. They are the primary maintainer, so they often know best what constraints they are operating within.
• If the PR affects a critical or sensitive module, I generally invest more time in reviewing it thoroughly.
• If the module is experimental or still evolving, I’m okay with less than stellar code, since it will likely be refactored several times during development.

Based on the author, I also decide when to insist on cleanup now vs. later:
Some developers follow through on “I’ll clean this up in a later PR,” while others don’t.
For developers that reliably perform the follow-up, I’m generally pretty lenient about when cleanup appears, and for others, I normally insist on cleanup work being done in the same PR.

Finding the Important Changes

Many PRs contain a mix of boilerplate updates and tricky changes. I generally start by skimming over the files and marking the boilerplate or irrelevant files as “viewed” so I can focus on the core modifications. If the author has left comments guiding the review, that’s always helpful.

Then I either start looking at the module boundaries or the tests for the given code, to get an idea of how the feature is used, before jumping into the implementation - but this is very much based on gut-feeling.

For complex PRs, I sometimes pull the code locally to explore it in an editor, but not that often.

Things I Look for When Reviewing Production Code

Some issues are easy to spot with a fresh set of eyes—like leftover debug logs or unclear method names. Others require deeper thought. I generally focus on:

• When first evaluating a PR, I consider whether this code is performance-sensitive. If it isn’t, I generally don’t think too deeply about performance.
• Is there anything that’s un-idiomatic or inconsistent for the codebase or the language? If so, I will generally ask for this to be corrected. I think conventions for how to do and name things are generally helpful, even if there are some I disagree with personally.
  I generally think developers should err on the side of respecting convention, even ones they disagree with. I think having a sub-optimal convention is better than having no convention at all.
• I look at //TODO comments and often add a PR comment asking if we need to track this in an issue somewhere else, but I often leave it up to the developer if they think we need to.
• I try to pay particular attention to stuff that’s not easily reversible, such as security issues, or bugs that would persist invalid data into the database.
• I’m a big fan of type systems, and if there is an invariant that needs to be upheld, I will often recommend relying on the type-system rather than relying on developer skills - we’re only human after all. Examples of this could be using an ordered data structure for data that must be ordered, using a list that cannot be empty, for lists that should not be empty, and so forth.

Things I Look for When Reviewing Test Code

I generally pay less attention to test code than production code. My main checks are:

• Do test names clearly describe what they’re testing?
• Do the tests cover both happy paths and unhappy paths that are either likely, or critical?
• Do they answer the questions in my notebook that I wrote down while reading through the implementation.

If the tests cover the key scenarios I was curious about, I make a point to mention it, so reviews don’t always feel like a list of negatives.

Approve with Suggestions

In many cases, I like to “Approve with suggestions”, or as Google calls it a LGTM with comments.
That essentially means that I trust the author to correct the issues I pointed out. However, this depends on the fixes required, and my trust in the author to get them right without an additional review.

During my time at my current employer, I’ve spent a fair amount of time reflecting on product roadmaps—what they’re good for and what they might not be so good for. I think a shared understanding of priorities and collective ownership is important, and a roadmap can be a valuable tool for achieving that. Roadmaps also seem to be a reasonably standard industry practice, though there are some notable holdouts.

Categories of Roadmaps

Roadmunk provides a solid overview of three overarching types of roadmaps:

1. No-Dates Roadmap: A prioritized list of features or problems agreed upon by the team. Priorities can be defined in many ways (e.g., ROI, urgency/priority matrices), but this type of roadmap deliberately avoids assigning deadlines or timeframes to specific items.
2. Timeline-Based Roadmap: A roadmap where each item has a defined duration or deadline.
3. Hybrid Roadmap: Combines the two approaches, with timeframes for near-term items (e.g., 1-3 months) and a prioritized list for tasks further out.

For my five cents, I think I believe the no-dates roadmap or a hybrid roadmap provides works the best. Let’s explore why.

The Risk of Commitment

The moment you introduce dates or timeframes into your roadmap, people gravitate towards treating them as commitments. The software world is rife with stories about estimates being turned into promises. I often see it recommended to keep dates out of roadmaps shared outside the immediate team:

It is not uncommon for sales reps to share internal roadmaps with customers, as a way of closing a deal, generating interest, and keeping leads warm. Avoid having sales teams committing a product to a specific release date, by excluding release or launch dates in these roadmaps. - ProductPlan

An important note: avoid including hard dates in sales roadmaps to avoid tying internal teams to potentially unrealistic dates. Unless there’s certainty about the product’s availability date, it’s a good habit to avoid including dates in an external-facing roadmap. - Atlassian

Some schools of thought around roadmaps believe that you should keep dates out of the roadmap due to the risk of committing to something that might not be delivered - also Roadmunk

There’s two reasons why you might be hesitant to put deadlines on roadmap items (and by extension, make some sort of commitment):

1. Unrealistic Deadlines: Humans are notoriously bad at estimating software complexity. Unless you build in substantial slack into your timelines or do extensive time-consuming pre-planning, you’ll likely miss deadlines.
2. Building the Wrong Thing: Sometimes you realize that what you’re building doesn’t actually solve the problem you think, or even that you have another problem you’d rather focus your resources on. If you’ve commited to timeframes, you either have to renege on your promise or build the wrong thing.

Product managers rarely know what’s going to happen a year from now (market changes, discovery of new user needs, etc.), so planning for a one-year timeline doesn’t make sense. You only need the details of the who, what and how for the month and quarter, focused on working towards achieving a high-level goal or two (for agile teams and startups, even that time frame can be a stretch!) - Roadmunk

Both of these grow more likely the longer you try to plan your timeline, as delays in earlier tasks cascade. While you might hope to make up the difference with some tasks finishing ahead of schedule, in my experience, that’s exceedingly rare.

Flexible Commitments & Appetite

There’s a natural tension between the fact that often want to communicate timeframes, either internally or externally.

If you do have this desire, here are some strategies to make it work:

1. Limit the accuracy of commitments

“We’ll be working on this in Q2 of next year” is a much weaker promise than “This will be done in April next year, with this functionality…”, often a vague commitment is “good enough”, while still leaving more room to maneuver.

2. Limit the timeframe for your commitments.

Limiting your commitments to X amount of weeks or months in the future is generally wise for two reasons. Planning enough to forecast anything with any amount of accuracy is fairly labour-intensive. I’ve seen people spend days or weeks on planning for the next 6 months, only to figure out later that they’ve been building the wrong thing and need to scrap it all.
Delays also tend to cascade. If you’re only forecasting for a month, you might only be delayed for a week, while if you’re forecasting for a year you could be entire quarters off.

3. Build plenty of slack into the system

Unexpected things crop up, things take longer than expected, people get sick. That’s life. If you expect 100% utilization for the new features or roadmap items you’re planning on, you’re going to be in for either a world of pain when your timetable collides with the real world, or engineers cutting corners aggressively, leading to a product so filled with technical debt it’ll remind you of the 2008 financial crisis.

4. Be extremely flexible in scope

If you do need accuracy in time, you’ll have to be flexible in the scope. Determine a few high priority items that are must-haves, and then a prioritized list further than that, that you’re okay not delivering. Cutting down to must-haves is hard to do well, as there’s a tendency to over-estimate how much can fit in there. The list of must-haves should be so short it makes you a little uncomfortable.

5. Use appetite rather than scope

Work with the concept of appetite rather than scope. Appetite is a concept that acknowledges that whether problems are worth solving depends on how hard they are to solve. Rather than starting with a set of features or scope, you start with a problem, and you dedicate “X weeks” of appetite to solving as much of this problem as you can. That is your appetite for the problem. It is then up to the team to try and do as much of possible to get something released for the given appetite, with whatever scope that fits into the given appetite.
Obviously not all issues lead well to appetite. If you have contractual obligations to keep e.g. your database up-to-date, you cannot simply disregard this task, if it takes longer than your appetite. But I believe for most feature-based work, appetite is a really great framework that allows you to forecast timelines well into the future, at the cost of not being able to forecast scope.

Roadmap as an Internal Alignment Tool

It is important for teams and companies to agree on what problems are important to solve—and which are not. Creating a roadmap can be a catalyst for these discussions, even if the actual roadmap is never used afterward. The process of creating the roadmap creates alignment by encouraging collaboration and shared prioritization across teams.

As an example, sales might care more about shipping quickly to meet customer demands, while engineering often emphasizes reliability and long-term maintainability. By bringing these differing priorities to light, teams can find common ground and focus on achieving shared goals that take different priorities into account.

When Roadmaps Become Adversarial

Sometimes I see roadmaps created in isolation. One team creates the first draft (or even version!) entirely on their own, and then sends it to others for feedback. This has a high risk of the process becoming adversarial, as the teams not part of the initial process will feel like they have to fight for their goals and time. There is a significantly different emotional quality to creating a roadmap together, versus having to fight for your priorities by critiquing an existing roadmap.

As an example, in many companies, sales-driven roadmaps pressure engineering teams into accepting unrealistic deadlines, sacrificing code quality and long-term maintainability.
Situations like this, where the roadmap dictated solely by product teams or executive management can alienate stakeholders and engineers. This lack of buy-in can lead to two common reactions:

1. Indifference: Engineers may disengage, feeling no commitment or ownership over deadlines they had no role in setting. As a result, they might say, “If I didn’t have a say in the deadline, it’s not my problem if it isn’t met.”
2. Stress: Unrealistic deadlines can create intense pressure, leading engineers to cut corners or burn out trying to deliver on time. Over time, this can result in a toxic environment, driving away top performers who seek healthier workplaces.

In the end, roadmaps aren’t just an artifact. The way they’re created matters immensely for their effectiveness. As with so many other things that seem numbers and engineering-based in theory, they often end up being about those squishy humans in the end. I’ll leave you with this last quote which I think underlines this point well.

“Third, there’s the guilt. Yeah, guilt. Have you ever looked at a long list of things you said were you going to do but haven’t gotten around to yet? How does that list make you feel? The realities of life and uncertainty show us that 100% of the things on the roadmap are not going to happen on time the way we imagine.” - Basecamp

The test, with irrelevant details omitted, looked like this:

it(() => {
    // Setup
    someOtherSetupCode();
    createUser({id: "TEST_ID"});
    
    // Actual test code

    // Cleanup
    someOtherTeardownCode();
    deleteUser({id: "TEST_ID"});
})

This approach to organizing your test with some setup, some test code, and some cleanup at the end might seem logical.
However, there’s a significant flaw: The cleanup code might never run.
When we put the cleanup code at the end of the test, it means it won’t run if the test fails.

In this case, that meant we ended up in a particularly problematic loop: if the test failed once, it could never pass without human intervention. This was because createUser would throw a unique constraint error if the id had already been used, which meant the test would not proceed, preventing the cleanup code from ever running.

First Alternative: beforeEach and afterEach

A better alternative, if your testing framework supports it, is to use hooks for running code before and after each test, such as beforeEach and afterEach. This would make the test code look like this:

beforeEach(() => {
    someOtherSetupCode();
    createUser({id: "TEST_ID"});
})

it(() => {
    // Actual test code
})

afterEach(() => {
    someOtherTeardownCode();
    deleteUser({id: "TEST_ID"});
})

However, this still isn’t quite optimal for a few reasons:

• The deleteUser call is still not guaranteed to run. It might not run if, for example, someOtherTeardownCode fails, or if the programmer manually interrupts the test run. This is still better than the initial example because most test frameworks run afterEach even if the test fails, so we avoid a scenario where the test never succeeds—eventually, the user model will be cleaned up.
• Debugging database state is challenging when you always delete models at the end. If the test fails and you suspect an issue with a database interaction, you can’t inspect the database state after the test has failed because you’ve already deleted all the relevant data.
• Using beforeEach and afterEach requires that all of your tests share the same state. This may be fine in many cases, but if your tests have very different setup needs, it can become cumbersome.

Best Alternative: Clean Up First

The best approach, in my opinion, is for each test to ensure that any data that should not exist is deleted at the start of the test, leaving it in the database at the end. The code would look like this:

it(() => {
    // Clean up any potential leftover state from previous test runs
    someOtherTeardownCode();
    deleteUser({id: "TEST_ID"});
    
    // Ensure consistent state
    someOtherSetupCode();
    createUser({id: "TEST_ID"});
    
    // Actual test code
})

This way, you guarantee that the cleanup always runs before the test, and if you need to debug anything in the database after a test failure, all relevant data is still available for inspection.
The only caveat is that your teardown code must handle both cases: when there is something to clean up and when there isn’t.

Serde is a powerful Rust library for serializing and deserializing data structures efficiently and generically. One of the cooler features is itssupport for untagged enums, which allow us to specify a list of structs in an enum, and Serde will parse the first one that matches. Here’s an example demonstrating this:

#[derive(Deserialize)]
#[serde(deny_unknown_fields)]
pub struct Fruits {
    fruit_count: i32,
}

#[derive(Deserialize)]
pub struct Burgers {
    burger_count: i32,
}

#[derive(Deserialize)]
#[serde(untagged)]
pub enum MyFood {
    Fruits(Fruits),
    Burgers(Burgers),
}

Parsing JSON¹ with either fruit_count or burger_count automatically parses the corresponding enum variant:

let json = json!(
    {
        "fruit_count": 5
    }
)
.to_string();

let my_food: MyFood = serde_json::from_str(&json).unwrap();
// my_food is now the MyFood::Fruit variant

While this feature is quite attractive and the happy path works great, it has an unfriendly downside. The error messages when failing to parse are often unclear, stating only that “data did not match any variant of your untagged enum”. Examples of problematic code are as follows:

let json = json!(
    {
        "tacos": 5
    }
)
.to_string();

let my_food: MyFood = serde_json::from_str(&json).unwrap();
// Does not work because no enum variant matches "tacos"
// Error returned is: Error("data did not match any variant of untagged enum MyFood")c

let json = json!(
    {
        "fruit_count": 5,
        "foo": 3
    }
)
.to_string();

let my_food: MyFood = serde_json::from_str(&json).unwrap();
// Does not work because Fruits has `deny_unknown_fields` and we have a field too much
// Error returned is: Error("data did not match any variant of untagged enum MyFood")c

let json = json!(
    {
        "fruit_count": "5",
    }
)
.to_string();

let my_food: MyFood = serde_json::from_str(&json).unwrap();
// Does not work because "fruit_count" is supposed to be an int, but found string
// Error returned is: Error("data did not match any variant of untagged enum MyFood")c

These errors are not very informative for developers, and certainly can’t be forwarded to end-users. To mitigate this, we’ve adopted a workaround pattern that involves a custom MaybeValid untagged enum²:

#[derive(Debug, Clone, Serialize, Deserialize)]
#[serde(untagged)]
pub enum MaybeValid<U> {
    Valid(U),
    Invalid(serde_json::Value),
}

// First parse it to something that's either valid or not valid.
// This is simplified for the sake of brevity - in production code you wouldn't unwrap here
let maybe_valid = MaybeValid<MyFood> = serde_json::from_str(my_string).unwrap();

match maybe_valid {
    MaybeValid::Valid(valid) => {
        // Yay! We can move on.
    }
    MaybeValid::Invalid(json_value) => {
        // Parse the string to JSON ourselves, and then attempt to build a sensible error message
    }
}

This pattern, while not ideal, gives us the ability to construct somewhat useful error messages. We have thousands of lines doing this parsing and error construction.

There’s a better way though. We could aggregate errors for all enum variants tried during parsing, resulting in more informative errors:

let json = json!(
    {
        "fruit_count": "5",
    }
)
.to_string();

let my_food: MyFood = serde_json::from_str(&json).unwrap();
// Does not work because "fruit_count" is supposed to be an int, but found string.
// It could return something like: 
// Error("data did not match any variant of untagged enum MyFood.
// Did not match Fruit because `fruit_count` was string but expected integer.
// Did not match burger because required property `burger_count` was missing.")

This isn’t a new problem, and has several issues ranging from 2019 to 2022. There’s even a Pull Request from 2019 with one person who’s been maintaining his own up-to-date fork of serde that aggregates untagged enum errors. The last conflicts with the main serde branch were fixed two weeks ago. The PR has over 50 like reactions.

This PR is an excellent contribution, and I want to take this opportunity to bring it to attention. Merging this could greatly enhance the experience of using untagged enums in Serde.

You can view it below, or here on YouTube:

Carbon Aware Computing: A Quick Overview

The overarching principle of carbon-aware computing is that you should do more when the electricity is greener, and less when it is not. This is most often accomplished in three ways:

• Location shifting: You switch your servers around to where the grid is greener.
• Time-shifting: You run your time-insensitive jobs, such as machine learning model training or batch processing, when the percentage of renewable electricity in the grid is the highest.
• Demand-shaping: Your software performs less tasks when it can tell that the electricity powering it is dirtier.

While if your infrastructure provider allows you to do these things easily, such as Cloudflare’s Green Compute, you should absolutely take advantage of it.
However, if you don’t have such tools available, you can still achieve a fair chunk of these benefits by going through your infrastructure once without needing to make your software carbon-aware. Let’s take a look.

Location-shifting

While the composition of power grids do vary quite a bit between the worst and the best (Wyoming and Sweden have approximately a 10x difference in CO2 per kWh), the day-to-day or month-to-month differences are much smaller than that.

The variance in CO2 per month in Denmark, one of the grids in the world with the highest percentage of renewables. Courtesy of electricitymap.org

And per day. Also courtesy of electricitymap.org

That means picking a region with a good renewable-heavy grid gets you a long way without needing to shift around location of your compute jobs. Some cloud providers such as GCP even has tools to help you find the best regions based on the carbon emissions.

Time-shifting

Time-shifting is an interesting concept. It makes sense because the grid production of renewables compared to the general demand for electricity varies from hour to hour. Many grids however have a daily pattern that can take on the following shapes:

• The daytime has more green electricity available, apart from the mornings and afternoons which are (often) when people are doing their cooking. Grids with higher percentage of green energy in the day often contain a high percentage of solar in the mix.
• The nighttime has more green electricity available. This is often the case for grids where wind is a high percentage of energy in the mix.

You can look at electricitymap.org to spot the trends that are relevant to your grid. If you do that, you should be able to get most of the advantage of time-shifting by scheduling your jobs during the time when your grid composition is more favourable, rather than needing to schedule it dynamically.

The Importance of Hardware Utilization

Some of you might be looking at the grid pictures above and (correctly) noticing that there’s a 2x difference between some of my graphs, and wonder what I’m smoking. Reducing your carbon emissions by 50% seems like a huge win.

That wouldn’t be an accurate number though, because actual cloud emissions don’t come from the electricity usage - they come from embodied emissions. Embodied emissions refer to the emissions associated with the production and disposal of servers.
For consumer laptops, embodied emissions make up 75-85% of total emissions, and the general pattern is the same for servers.

Renting out a VM on Azure. The embodied estimates make up around 65% of the total carbon estimate.
Calculations courtesy of climatiq.io

Carbon-aware computing only focuses on the electricity use of your servers, and not the production, lifetime and disposal, where a majority of the emissions come from.

This means that in most cases, looking at optimizing how well we use the physical hardware before we have to replace it, is a better use of our time than trying to switch load around.

Cloud data centers typically replace servers every 4-5 years, making it essential to use them as efficiently as possible. Reducing the number of physical servers and utilizing rented servers at as close 100% capacity can significantly lower the environmental impact. Plus it often leads to better use of resources, resulting in cost savings.

CPU usage in particularly also doesn't scale linearly with electricity as even a CPU at 0% utilization uses power. This means that the power difference between a CPU running at half versus full utilization is only around 30%.
Calculations courtesy of climatiq.io

So what is the right thing to focus on? If you’re not actively building infrastructure for others to run jobs on, here’s where I think you’ll get the most bang for your buck, in regards to optimizing your computing carbon emissions:

1. Don’t spend excessive time on building software that reacts dynamically to the electricity grid, the benefits are marginal.
2. Go through your software and choose regions with a more green grid. Often cloud providers give you this information - otherwise you can try using Climatiq’s cloud computing functionality to get a feel for the different regions. If you are not using one of the big three, electricitymap.org is also a good bet to get grid emissions, if you know the location of your datacenter.
3. Research if your cloud provider offers ways to switch locations and shift work around to lead to fewer emissions - and use them if they do.
4. Consider running time-insensitive jobs on spot instances for both carbon and cost savings.
5. If you’re renting virtual machines, try to utilize them as close to 100% as possible, both in regard to CPU usage, but also the amount of memory allocated vs what you actually use. Some things such as serverless or managed platforms might allow your cloud providers to utilize the underlying machines more efficiently than you could yourself.

Code is a Specification

Code is a specification for what the machine should do. To write a specification thorough enough for a developer to implement it exactly, you’re essentially writing the entire program. Historically, programming was viewed as a manufacturing activity - take in some specifications and spit out code. However coding is actually primarily a design activity.

This means you can’t craft a specification and just toss it over the fence. What you can do is give the developers the best possible conditions for performing this design activity.
You do that by ensuring they understand the problem. That leads me to my next point.

Focus on the Problem, Not the Solution

The most crucial aspect of handing over a project to developers is providing them with the necessary context, such as how the project fits into existing products, who the users are, and what they’re trying to accomplish. Communicate this information using user stories or another method that clearly conveys the user’s needs and limitations.

Instead of prescribing exactly what something should do, you should first explain why it is necessary. By doing so, developers can act independently, removing many rounds of feedback loops and making the questions they ask more well-informed.

Prototype

Though the solution isn’t the most important part of the handover, you should share any thoughts you have on it. One great way to do this is by sharing a prototype that demonstrates your proposed solution. Prototypes can range in fidelity from sketches and bullet points to interactive user interface prototypes or Excel-based prototypes demonstrating the functionality.

Prototyping also helps you refine your thinking about the solution. If you struggle to express your logic, it could be because you haven’t considered all the edge cases.

Remember not to go overboard with the prototype. If you’re working with higher fidelity materials, you might not need to complete more than 50-60% of it. Use the prototype as a tool for discussion and further collaboration, not necessarily as the final blueprint for developers to replicate.

Identify Rabbit Holes and Risks

Before you hand over a project, think about any risks and “rabbit holes.” Rabbit holes refer to situations where there are technical unknowns or unsolved design problems that can significantly extend the project’s completion time. By being upfront about these uncertainties, you can initiate a discussion about how to handle them early on.

Be prepared for developers to have their own assessments of risks and rabbit holes, based on the underlying program architecture or challenges they haven’t faced before.

Clarify What’s Not Being Done

Outline what you are not tackling in the project proposal to set boundaries and prevent developers from spending time on unrelated tasks. This clarity will help developers understand where their focus should be and where rough edges are acceptable.

Create an Artifact

A good handover should result in one or more artifacts that capture relevant information at a high level. A prototype you’ve developed or collaborated on is one such artifact.

Whether you have a prototype, you should also create a document explaining the high-level problem and solution proposal. You can create this document yourself or in collaboration with an engineer while discussing the problem. Producing a document during the conversation helps clear up any potential misunderstandings, as you’ll need to agree on what’s written on the page.

The purpose of these artifacts is to serve as a reference for both you and the developers, allowing you to make adjustments and corrections when necessary. A shared, collaborative document is ideal, as it enables developers to ask questions and you can edit the document to provide answers.

When working with software developers, the key to success isn’t writing detailed specifications. Instead, it’s about empowering the engineering team to understand the problem and the proposed solution well enough that they can work independently and only need to clarify major questions with you. The more developers can work independently, the less time you need to spend in back-and-forth communication, and the higher the effective work absorption rate of the project will be. Communication is important, but focusing on the problem is much more critical than dwelling on the exact solution.