Carbon Accounting

For corporate carbon accounting, the standard to read is the Greenhouse Gas Protocol Corporate Standard. This standard explains the different reasons behind doing corporate carbon accounting, and sets out guidelines and requirements for doing so. I would recommend reading (or at least skimming) the entire thing in full. This is the text to read when understanding the carbon accounting space.

Greenhouse Gas Protocol (GHGP) also publishes other standards & guidance documents, like guidance for calculating Scope 2 and 3. I have not read all of these myself, but I’d consider them relevant to skim if you’re doing work that deals with one of those areas in particular. In particular I think the Corporate Value Chain (Scope 3) standard is worth skimming.

Here’s also a few notes of things I thought were particularly interesting or important regarding corporate carbon accounting.

General

• The GHGP starts with a section about why businesses should do carbon accounting, and what outcomes they might be interested in. In my mind, of course companies should care about sustainability, but I think it’s important to remember that in many cases sustainability teams have to fight for budget and demonstrate their work is worth doing.
• In general, carbon accounting is significantly more.. imprecise than I originally thought. There’s a lot of assumptions that goes into carbon accounting, simply because not making a lot of assumptions is going to be very expensive.
  • This is also why you cannot compare the carbon accounting of companies. The GHGP is pretty clear that carbon accounting for a company, is to track reductions for that company only, and should not be compared with other companies.¹
  • In carbon accounting, the concept of “baseline year” exists, which is the year when you start your carbon accounting baseline from. You then compare yourself with your baselines year to track reductions.
  • Surprisingly, the CO2e number from the base year is not set in stone. If you e.g. do a corporate re-structure, or change calculation methodology, you have to do “rebaselining”, which is essentially re-calculating the emissions from your baseline year so they’re still comparable with the current year. This makes sense, but it’s fairly unintuitive if you don’t know about it.

• There’s a distinction between primary data and secondary data. Secondary data is generally emission factors compiled from industry averages, where primary data is when your supplier says how much emissions a product emitted during production.
  • Depending on your supplier, they might be calculating that information primarily from secondary data themselves (hopefully enriched with some data like their own fuel and electricity usage). This means that results calculated primarily from secondary data can become primary data, which seems a bit odd.

• Generally, it seems like carbon accounting is a journey. You often tend to go wide to get an overview of where your emissions are, often with something like spend-based data first, and then you identify hotspots where it’s worth to get more granular data.
  • Spend-based data is where you know how much money you spent on e.g. electronics, and then you multiply that with an extremely rough emission factor, to figure out your emissions. This is extremely inaccurate, but good to get a first picture of where it’s worth looking deeper.
• Then, when you know where to dive deeper, you have to get more data, e.g. litres of fuel consumed, kg of product bought, etc. This is generally talked about as activity-based data, and considered higher accuracy, but also more time-consuming to calculate and acquire the data for.
• In later stages of the journey you might start swapping secondary out for primary data, if you can get your suppliers to give you the primary data. This is often something people struggle with getting out of their suppliers.

Scopes

• Corporate Carbon Accounting it split up into three scopes.
  • Scope 1 (the fuel you burn in stuff you own, or emissions from chemical processes under your control)
  • Scope 2 (emissions from the electricity you purchase)
  • Scope 3 (everything else really).
• Under the GHGP Scope 1 and 2 reporting is mandatory, while Scope 3 is optional.
• The scopes seem primarily designed to avoid double-counting, which is when multiple companies count the same carbon emissions. Scope 1 and 2 are designed so that they cannot be double-counted, while your scope 3 is by nature someone else’s scope 1 & 2.

• Double counting is defined as:
  “Double counting or double claiming occurs when two or more companies claim ownership for a single GHG reduction within the same scope.”
  It makes sense that it’s important to avoid double counting if you e.g. do trading with carbon credits, but if you’re “just” disclosing it probably doesn’t matter all that much.

• Scopes are primarily designed based on company structure - there’s a lot of rules about how you determine if something counts as your scope 1 & 2, especially if your company owns (parts of) other companies.
• Scopes seem very game-able if you want to make your carbon accounting look good. If all your scope 1 comes from burning gasoline in cars your company owns, you can just sell the cars and lease identical cars.
  Now the gasoline suddenly counts as scope 3 emissions instead. And you don’t have to report on those, so your carbon accounting disclosure looks great, with no change in actual emissions anywhere.

Allocations

• It seems to me like Carbon Accounting is kind of like trying to model the physical world. You want to know how much stuff you emit in the end, and you might need to trace the path of your products all the way down across multiple companies, to figure out the final emissions.
• This becomes particularly tricky if you need to do allocation at one point in the journey.
• Allocation means, that if you have a system that produces multiple things in the same process, you’ll need to figure out how to allocate the shared emissions to each part.
• An example: You have a factory that various items. You only have a power meter for the entire factory. This means you only know the overall emissions for the whole factory, which you’ll need to allocate out across the products.
  • The best thing to do, is do no allocation, which means installing e.g. electricity meters on each manufacturing line if possible.
• Often allocation cannot be solved by e.g. adding more monitoring:
• If you raise and slaughter a dairy cow you get many products. Milk during it’s lifetime, and meat and leather after the slaughter. Cows emit carbon from food and methane from the digestion. Should those emissions count towards the milk? The leather? Everything equally?
  • In cases like that you’ll need to do explicit allocation. The GHGP has some different strategies and a “hierarchy” for when different kinds are good to use, but in the end it becomes a question of judgment.

Electricity

• Accounting for electricity when doing scope 2 has more nuances than you might immediately expect.
• You do two types of accounting and report on both of them; location-based and market-based.
  • Location based is the actual emissions of the grid energy you’re using. The emissions will vary depending on what the grid makeup is, the percentage of renewables etc.
  • Then there’s market-based, which exists because you can sell renewable energy certificates. So someone can buy renewable energy certificates to get a certification that their electricity is 100% renewable.
    But in practice the grid mix is what it is, so the certificates essentially means someone gets the green energy and you get to take credit for it.
    The market based approach takes this into account, so if you don’t have any energy certificates, you’re supposed to calculate using the “residual mix”, which is the emission factor of the energy after all the green energy with certificates have been taken out of it. These generally come with fairly high emissions, as most/all of the renewables have been taken out.
• Even though you have to account for electricity in scope 2, this is only part of the picture. There’s parts of the electricity that’s not covered, such as:
  • The transmission & distribution losses when transporting the electricity. These hover between 4 and 20% depending on the country.
  • The extraction of the fuel. The fuel extraction might particularly be relevant for fuels like natural gas, where methane leaks make up more than 30% of the direct CO2e emissions, which wouldn’t go into your Scope 2, which makes Natural gas seem significantly more climate-friendly than it is.
• These additional emissions from electricity consumption go into your scope 3.

Product Carbon Footprints

Corporate Carbon Accounting is one thing, that works at a corporate level. Another area is Product Carbon Footprints (PCF) which tries to calculate the carbon emissions of a single product.

Product Carbon Footprint is governed by multiple different standards that agree on most things but not all things, which is a royal pain in the ass.

• The Greenhouse Gas Protocol Standard, I think is worth reading. It has the advantages of being commonly used, and very easy to read.
• ISO 14067 which is built on top of ISO 14040 and ISO 14044. I don’t think these standards are worth reading, they’re hairy, you have to purchase them, and they’re hard to read. Unless you really know you need these, skip ‘em.
  • Fun side-note: The ISO standards call it “The Carbon Footprint of a Product (CFP)” but the rest of the world seems to call it a “Product Carbon Footprint”.
• The PACT Methodology, which is really more of a project that aims to enable interoperability and easy sharing of PCFs², but comes with methodological guidance as well. This isn’t as widely used and known as the other two standards, but it has the advantage of being pragmatic and very well-written, which means it’s a great introduction to the concept of a PCF, and how those calculations work.

As before, here are a few of my personal notes:

• The standards don’t agree on everything. ISO and GHGP agrees on most things, but e.g. PACT has very different ideas of how data quality works (data quality is qualitative in the other standards, but quantitative in PACT)
• PCFs come in two variants. Cradle-to-gate, which is the production of something, and cradle-to-grave, which also encompasses the use of the product, and the disposal. The disposal generally doesn’t contribute hugely to emissions, but the use-phase might, particularly for products that use electricity.
  • In some cases a use-phase might also be something you don’t expect. E.g. you can include the energy costs to wash a piece of clothing in the use-phase of that clothing. This might make sense if you e.g. are creating odor-resistant clothing that needs less washing.
• Product Carbon Footprints are often not created based on an end-product - they’re calculated based on a “Functional unit”, which is what function the product serves. Examples of functional units:
  • “Washing 5kg of laundry every week for 10 years” ( A laundry machine )
  • “Provide covering for the torso for five years” ( A t-shirt )
  • “Provide color and environmental protection for five years for 50m2” ( A liter of paint )
• The functional units might seem silly at first, but they make sense, as they allow for capturing e.g. upgrades to product durability, and can help compare products, so you don’t accidentally end up comparing paint that lasts 1 year with paint that lasts 15 years.
• Product Carbon Footprints, frustratingly enough, are also not comparable. This is the same as Corporate Carbon Accounting, even though intuitively you’d expect two PCFs for different kinds of screws to be comparable, they’re not.
  • For PCFs to be comparable, they need to make the same assumptions. For some sectors there exists “Sector-specific guidelines”, which is the list of agreed upon assumptions to make. Two PCFs calculated under the same sector-specific guidelines are comparable.
  • For PCFs to be comparable they also need the same functional unit. That way you don’t naively compare a liter of paint that covers 40m2 with one that covers 60m2.

I actually think that explicitly spending time to acquire domain knowledge might be one of the best uses of your time as a software developer for a few reasons:

• It allows you to act with significantly more autonomy. If you lack domain knowledge, it’s hard to evaluate whether user-facing decisions are a good idea, so you’ll have to get feedback from someone who does know.
  If you live in a fairytale where all tasks are perfectly specified up front with no room for ambiguity this might not be a problem you have. For the rest of us, having domain knowledge allows skipping a lot of back and forth because you often already have the knowledge you need to make decisions.

• Domain knowledge is great when scoping new projects or features. Having both domain knowledge so you know what to build and the technical experience to understand how to fit it into the existing product is a good skillset to have when figuring out what an MVP looks like.

• It’s just plain fun. Getting to learn about a new industry and domain is one of the really cool things about building software in my opinion.

Types of Knowledge

In my mind, you can split the knowledge required to be effective at building software into four (extremely coarse) categories:

Foundational Knowledge

The foundational knowledge about how computers and their building blocks work. This could be about how processors work, about complexities of algorithms, client/server infrastructure, when and how to cache, etc.

This kind of knowledge is often something that’s picked up via formal education, but can also be picked up via reading books, or sometimes by learning painful lessons on the job.
This kind of knowledge generally carries over across jobs, and is useful in almost all situations.

Stack-specific Knowledge

Then there’s knowledge that’s specific to your stack. How to make the best use of your programming language, what weird quirks or footguns it has² or how to best make use of the framework on top of your programming language.
This knowledge generally carries over across jobs if you’re using the same stack, but if you’re starting over on a completely new stack you’ll have to re-learn new stack-specific knowledge.

Product Knowledge

Next up is the knowledge about the product or service you’re working on right this moment. This is generally always going to be job-specific and it means that when you switch jobs you’ll always have to re-learn this.
Depending on how many products your company has, you might even have to learn this multiple times in the same job.

Domain Knowledge

Last is the knowledge about the domain your end-users are operating in. Personally I think domain knowledge is so broad that it’s hard to define, but here’s some examples:

• When working with wind turbine software it turned out to be really handy to know a lot about how wind turbines worked even, if I never had to interact with one physically.
  I read the Wind Energy Handbook and actually ended up teaching a “Wind Turbine for Software Developers” course to other companies in the industry.
• When working with carbon emissions estimations at Climatiq reading the relevant standards, like the Greenhouse Gas Protocol Corporate Standard about how carbon accounting works, helped me make lots of decisions much quicker than if I had needed someone to explain the relevant context to me each time.
• When I was doing a startup in the waste management industry we interviewed waste haulers, and actually also got to do a full work-day with one of them, to see what their day-to-day was like.

As you can see, domain knowledge can take many forms. The three example above cover physical/mechanical constraints, industry standards, and end-user behaviour / mindset.

In the end we’re trying to get enough big-picture knowledge, that we can easily put ourselves in our users shoes and therefore make good decisions that takes them into account.

How to learn domain knowledge

I think that we acquire the different types of knowledge differently.

I think it’s fair to say that most of the product knowledge and stack knowledge comes from the day-to-day work.
When starting on a new stack or product, you might do some tutorials and read some guides, but afterward the learning comes naturally as part of the regular workflow.

On the opposite end of the spectrum, I think that both foundational knowledge and domain knowledge requires explicit “learning time”.

This is because they often require stepping back from the task that’s right ahead of us to look at the bigger picture.

While foundational knowledge is often something that you’ve been taught as part of an education, domain knowledge isn’t, as it’s well.. domain-specific.

Some ways to acquire domain knowledge is:

• Reading introductory textbooks in your domain
• Attending introductory courses in your domain
• Talking to end-users that are using your product.

I think many of us might feel we’re too busy to take a step back and schedule time for getting the domain knowledge we need.
But we should take that time. It pays off in the long run.

I used to be able to fairly quickly determine whether an article answered my question, and if the author seemed competent enough to warrant reading.

However, with LLM’s getting better at disguising themselves, I now often spend several minutes figuring out whether an article is worth reading or not (if I wanted to ask an LLM, I would have just done that.)

To avoid people reading this site having to face the same uncertainty, I wanted to clarify the policy on LLM-generated content on this website. It’s none of it. Every word is human-authored by me, and all mistakes and bad takes are mine.

I might use LLMs to do research, and spar with, but I will fact-check, and the final output is authored by my hand alone (and sometimes with corrections from kind people who submit a Pull Request).

The last thing I had left to migrate, was my side project grønpension.nu (it’s in danish!) which is a site I help host, to allow users to easily submit a Power of Attorney to their pension fund, to vote to divest from fossil fuel companies.
This was the last service where I actively paid money to US companies every month.

I moved it from DigitalOcean to Scaleway which is an European cloud that I’ve worked with before, and that I’ve generally been fairly happy with.

The switchover was smooth-ish. I think it could have gone smoother if I had done a straight 1:1 transfer, but as the website is fairly seasonally active, I wanted to switch from an always-on to a serverless setup.

It took a few hours to figure out how to actually deploy it from Github on pushes to main - there are some Github Actions for Scaleway but they’re not necessarily super well maintained. I think that’s probably the cost of moving to an ecosystem that’s not quite as popular, and with a smaller focus on developer experience for small projects than DigitalOcean.

With that said, the whole thing took around half a day, and I was fairly happy with the setup.

After the migration I did get some error reports with iOS-specific "TypeError: Load Failed" errors, that I didn’t have the time to properly debug. However, scaling up the serverless capacity seemed to solve the issues. ¯\(ツ)/¯

This means that during peak season, Scaleway is a few euros more expensive per month than DigitalOcean, but peak season is almost over now, and by that time, I’m thinking I can scale the site down to 0, and save some money and electricity.

Final Status

This is the final stage of my migration away from US-based services for now. I’m not actively paying monthly money to US companies, which is good enough for me. My phone is still an Android, my debit card is still a Visa, and there’s no way to get around that.

But seeing as this is the last step, I figured I’d step back and take stock of how it all went.

• Switching to proton has been really painless. I was never a huge power user of Dropbox or Google’s cloud services, but I did pay for both of them for storage in multiple places - and proton ended up being much cheaper.
• Switching my email, which was the thing I feared the most, was actually fairly simple. The import & forwarding from Gmail worked pretty easily, and I don’t really miss it, apart from Proton botching a search every once in a while. I haven’t logged into my Gmail for weeks.
• Proton Docs is perfectly adequate for all my purposes and I don’t really miss Google Docs.
• I really wanted to switch my calendar over to Proton as well, but unfortunately the lack of tasks & reminders is a dealbreaker to me. If they add that, I’m switching over in a heartbeat.
• Ecosia is actually much better than I thought it would be. Last time I tried it, particularly local queries were kinda bad, but they’re perfectly alright now! For some queries though, a lot of Ecosia results are LLM-generated slop sites, and I really wish there was some way to exclude them. Google is better at filtering those out.
• I really wanted mistral to be as good as Anthropics models for coding, but it just isn’t. Though for chat-based interface for common queries, it’s perfectly adequate. I never use my ChatGPT anymore, and my company has also quit its subscription.

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 application 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.