Code and Climate Change. Blog about software development in ClimateTech
I’ve previously written about that I think having domain knowledge as a software developer is tremendously important, and really helps you be effective in your role.
As I currently work with carbon emissions and carbon accounting at Climatiq, I figured I’d put together a little reading list of what to read in this space if you’re a software developer / software engineer looking to get a little more domain knowledge.
Something that I think is often overlooked by many software developers is the value of domain knowledge, i.e. understanding the industry you're in and the mindset of the end-users of your software 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.
Have you noticed that it’s gotten harder to trust things on the internet nowadays?
I'm moving my digital footprint out of the United States. This is the final part (for now)
I'm moving my digital footprint out of the United States. This is Part 3.
I'm moving my digital footprint out of the United States. This is Part 2.
I'm moving my digital footprint out of the United States.
An unstructured list of things I do while reviewing pull requests
Some of my unstructured thoughts on product roadmaps.
Some developers run cleanup code at the end of their tests or in an "afterEach" block - but there's a better way.
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. Unfortunately the error messages if it fails aren't great.
Following some of my talk on serverless performance and greener cloud computing i was invited to talk at the Serverless Berlin meetup. You can see my title called “Sustainable Serverless: Serving 2million+ requests with a lean team”
The Green Software Foundation (GSF) is a non-profit organization under the Linux Foundation that aims to reduce the climate impact of running software. With multiple projects under its belt, GSF is driving the conversation about sustainable software practices. One of the things I’ve heard most about is Carbon Aware Computing, which entails developing software that understands its carbon emissions and adjusts its behavior according to the electricity grid it’s currently running on.
At Climatiq, we practice a dual-track agile approach, dedicating time to discover and conceptualize parts of our product before implementing them in code. A colleague asked me about the best way to write a specification for the engineering team to effectively implement a conceptual design.
As an individual contributor, particularly in software development, managing multiple projects and tasks is a significant part of the job. The wrong approach can leave you feeling worn down and unproductive, while a better approach might result in excellent productivity and momentum.
I’ve since changed my stance a bit on this. See the AI Policy for my current stance, at least when it comes to content on this website.
Climatiq is an API designed to estimate greenhouse gas emissions for any given activity.
It can be used to batch process large amounts of data, and embedded into other software for informed decision-making, Climatiq aims to provide businesses and developers with a powerful tool to monitor and reduce their carbon footprint.
In this post, we’ll delve into the strategies that help Climatiq achieve ultra-low latencies, consistently under 100ms, and sometimes even as low as 30ms.
Reviewing pull requests can take a short time or a very long time, depending on the size, complexity and how diligently you go about it.
I don’t think all pull requests demand the same level of rigour. If you have a skilled team and a high level of trust, I think you can leave it up to the author to have an idea of how thorough a review needs to be, and communicate that.
Recently I've been spending a lot of time discussing what good API design is. One of the discussions we often have is 'should we implement this logic inside our API or not?'. This post tries to give an overview of what to consider when discussing this.
At Climatiq our core product is an API.
That means we spend a lot of time discussing what good API design is. While APIs are primarily meant to be used by computers and are allowed to be a little cumbersome, you still want the person who has to read the documentation and implement the API to have a good time. That means caring about having understandable documentation where you can find what you’re looking for. It also means designing your API in a way that it’s easily understandable and leads users into the pit of success.
Recently at my company Climatiq we had discussions about time management. Many people seem to feel like they have too many meetings, and too many notifications.
I don’t really feel like I have any of these issues. I’ve dug down a bit and looked into some time-management, or time defence strategies I use, and tried to formulate them.
I've been working with rust at for a little more than a month now. Here's my first impressions, from someone who's never seriously worked with a low-level language before.
BackgroundServices in ASP.NET Core seem simple but can be tricky to get right. Here I'm going to try to write down what I wish I had known when I started, by answering the following questions: "How do I test my BackgroundServices", and "How do I manage scope inside my BackgroundServices"
When I first started learning about ASP.NET Core, the IHostedService and the BackgroundService was a mystery to me.
I wasn’t quite clear on how to use them or what the difference between an IHostedService and a BackgroundService was or when I should use which.
I also didn’t know how to do error handling in them or why my BackgroundService started failing silently.
But pain is a harsh mistress and now I know better. Read on, and you can too.
We’ve had some discussion at SCADA MINDS about what the best size of a pull request is, so I’ve been looking at what the internet thinks. Let’s dive in!
Testing frameworks in C# generally have some built-in way to do assertions. Don't use them - use FluentAssertions instead. Here's why.
You should rarely implement Object.Equals. And you should definitely never do it for testing purposes. Here's why.
I recently became frustrated with the speed of my Continuous Integration pipeline for .NET. I thought it was way slower than it should have been. I spent some hours debugging, and here's how I managed to make my continuous integration pipeline run faster.
Say it to them!
Once at a company dinner someone had to leave early.
He was a new hire at the time and right after he left, everyone started talking about "what a great guy he is" and how "we’re lucky to have him."
I don't think anyone ever told him the nice words we said about him that day. But I think someone should have.
Unfortunately, I've seen quite a few people use Azure Event Hubs when what they really wanted was a queue. Event Hubs are great for large-scale data ingestion, but if you just need to pass messages between your services - use something else. Here's a few reasons why.
Some teams are much, much better at asking questions than others. Here's a few pointers on how to do it right.
Microsoft Teams seems like it’s trying to be the one-stop tool for all your organisational needs. I think it works fine for chat and calls, but for knowledge management it is extremely unimpressive, often making things much harder than they need to be. Here’s four ways Teams is killing your knowledge management.
How being under tight deadlines can actually make you slower in the long run
You’ve made your awesome new Pull Request, but the person who has to review it won’t have time for several hours. While we all strive to review code as fast as possible, there’s always going to be delays. So what do you do while you’re waiting for that review?
It can be frustrating to wait for someone to review your pull request. While everyone is interested in pull requests getting reviewed as fast as possible, reviewing code takes time. Here’s 4 ways to make your pull request as easy to read, and as fast to review as possible.
Describes an efficient way of doing Pull Requests called the two pass pull request
Some tasks are costly to do early. You should do those later.
I’m trying to get a little more structured when it comes to how I publish and syndicate the content I write. These are primarily my notes to myself about my process, but maybe you’ll find them interesting.
Twitter recently announced that they're beginning to change many of the terms they use, to "more inclusive" variants. Is it all just virtue signalling, or are the new words better?
Recently I’ve been thinking a lot about what I call Death Spirals. The name might be a bit much but I like the dramatic flair.
When I was first introduced to Observables in C#, they sounded pretty damn good. “They just model streams of data”, “It’s just data over time” and “It’s just the push equivalent of an IEnumerable”. After working with them for a little while, I don’t think they’re as good as I was told.
At my employer SCADA MINDS we’re currently working on implementing a data pipeline for one of the larger wind companies in the world. Wind turbines have a lot of sensors, that generate a lot of time-series data. For the amount of turbines we need to support, we need to be able to process upwards of 1GB/sec.
New technology often comes along with a lot of promises. All the hard things? They’re easy now. All of your troubles? Shh, they’re all better now.
Recently while pair programming with a colleague, we got into discussing the best way to initialize new objects in C#. I’ve always just implemented constructors and left it at that, while he tended to favour static factory methods. This led to a lot of discussion and back-and-forth about the pros and cons of each type.
Internally at SCADA MINDS, we’ve had to make a decision whether or not to use a Serverless architecture for a large project. I wrote a post earlier on the general pros and cons of Serverless, but like most projects, there are some unique circumstances that we need to consider.
Internally at SCADA MINDS, we’ve had a lot of discussion whether or not to use serverless, Azure functions to be more specific, for a large project. This is my attempt to give a balanced overview of the pros and cons of Serverless, to help us make the right decision.
Or the alternative title, "How Microsoft shot me in one foot, and then gave me a gun so I could shoot my other one"
Many programming languages have automatic formatters. Go has gofmt, Rust has rustfmt, JavaScript has prettier and python has black. Being able to, in an editor-independent way, have your code automatically formatted without having to worry about it, is extremely freeing. It means there's a whole slew of religious wars you don't have to fight, and it means you never have to review a pull request with a bunch of noise, because this particular editor or user thinks the braces belong on some other line than they were. Unfortunately C# doesn't really have an equivalent, but here's my attempt at making one.
We've had issues coordinating across different ASP.NET microservices that lived in different repositories, so we moved them all into one big repository.
Building a docker image of an ASP.Net core application with Azure Pipelines can be surprisingly tricky - here's how you do it
Looking back at our failed startup Reccoon, we made a bunch of technical mistakes, that meant we weren't able to execute as succesfully as we'd like. Here are the three major ones.
The post-mortem of our startup Reccoon. The journey, and the mistakes we made along the way.
This is a very in-depth walkthrough of what the different pieces of Djangos default MiddleWare does, and how it relates to django-rest-framework. Most of this isn’t particularly relevant to know unless you’re debugging a Middleware issue - in that case it’s invaluable information.
Django-auto-prefetching is a library that automatically prefetches data from the database when using the django-rest-framework
In this post we’ll look at what it means to program by voice in 2019 as well as what the future may bring.
Projects using babel can now use TypeScript without having to include the typescript compiler. But should you? We look at the pros and cons of each.
Much of modern development now is searching for the right things. Error messages can be tricky if you're new or working on a new stack. This is a short guide about the anatomy of an error message - what parts there are, which are important and which can be ignored.
TypeScript is great, but it has issues. I outline the four challenges I think are most important to pay attention to, to ensure that TypeScript remains great.
This is the second in a series of blog post that will deal with converting an existing React codebase to Typescript. We’ll end end up with a completely typechecked codebase. This time we’ll be looking adding type annotations to simple React components.
When you add gradual types to an existing project, it can sometimes seem difficult to know where to start. Here I present how to do it bottom-up.
This is the first in a series of blog post that will deal with gradually converting an existing React codebase to Typescript and ending up with a completely typechecked codebase. This part deals with getting the first TypeScript file to compile along with the rest of the application.
We take a look at how Voice Coding looks in 2017, new advances in speech recognition engines and different systems.
About a year ago I started having pain in my left pinky. At the time I was a student, and had just helped start bambuu where I develop software. I figured the pain was temporary so I kept on working, thinking it’d go away by itself. This would be a very short blog post if I was right. After while it had spread to my right pinky as well.
Recently we created a placemat game-controller and a game for a university project. The goal was to help users eat slower in an engaging way. These are the four things I wish I had known before starting.
Here I present a short technique that helps making good decisions easier, e.g. buy healthy, excercise, etc.
I recently read Malcolm Gladwell’s book “David and Goliath – Underdogs, Misfits and the Art of Battling Giants.” Gladwell writes about a phenomenon called relative deprivation – when we are deprived of something, relative to the people around us. I’m going to talk a little about this phenomenon, and how it relates to keeping the big picture of the world in mind.