At the start of this year, 2023, I set out the goal to write 100 blog posts by the end of the year. I knew this was an ambitious goal but it seemed vaguely achievable. One hundred seems a large enough number but twice per week shouldn’t take up too much of my time. It allows enough slack that some weeks can be less while others the volume increases to meet the goal.

However things have not gone according to plan to say the least. It’s now the end of January and I’ve completed a grand total of 3 posts. If I’m keeping up with my goal I should have about 8 completed by now so I’ve fallen well short. This piece is my January retro to try dig into why I’ve fallen short and what I can try do going forward to attempt to salvage the original and increasingly ambitious goal.

Initially I wanted this blog to be something where I could write out my thoughts on programming and learn along the way. It was going to be a place where as I came across cool new tech or concepts I could write about them. They say to truly show you understand something you should teach it to someone so that’s what this was going to be about. I was focusing on software engineering because that’s where I spend most of my time anyway at my day job. Writing about this would allow me to think out loud on topics that I may only touch on so

Kubernetes itself is great for scheduling within a single cluster but if we have many clusters, spread across geographies, we start to need something above the cluster level. This is where Kubernetes Multi-Cluster comes in in allowing us to manage apps across clusters.

Ask nearly anyone who uses kubernetes what they prefer between treating applications like cattle or pets nearly all will say cattle. Pets require special individual attention but cattle are managed within herds, at least that’s what the metaphor explains. In kubernetes land it means using a deployment or daemonset to create your pods and let kubernetes take care of the rest with things like scheduling and restarting.

This is easy to manage for a single cluster but becomes increasingly difficult as the number of clusters scales up. Creating the same deployment on each cluster becomes tedious and error prone.

In this post I’m going to give the situation where an internal platform team creates and manages clusters with some base level of services in it, for example logging, metrics and ingress along with a few others. We then allow other teams to deploy their apps to this cluster.

For our own services and a low number of clusters the most straightforward way would be to hook up some CICD system like jenkins to be able to deploy to each cluster. There may be some unique config per cluster so each app would get templated out and then we could use something like helm to generate the config as we deploy. However this process becomes unwieldy as the

When is a task done? Every team has a different definition depending on, amongst other things, their release process and what happens after a piece of code gets completed. Even members of the team have different ideas of what makes a task done, that’s why it’s important to have a team agreement of what is their “definition of done”. Here however I want to focus on the part before the task gets marked as done and look at the actual code itself. When can we be happy to say this piece of code is ready for review or has been reviewed.

Code that works is the minimum expected of a software engineer. There’s a host of aspects surrounding the code that we should be expected to do such as testing, formatting, that the code is understandable and maintainable. But how far do we need to go before submitting that PR? Do we need to cover all expected edge cases including possible ones in the future? Do we need to add tests for every single line of code and test all variants of each input?

The answer to all these, in my opinion, is no. We don’t need to cover all edge cases, especially not future ones and we don’t need to test every line and input variant. We should, however, consider them all and make a conscious decision to include or exclude them. Ideally the task, when it’s being written, should call out the edge cases that need to be covered by the code.

It is difficult to draw

What I’m calling a “never-ending PR” here is a PR that is attracting lots of discussion and comments from different people. Once one comment gets resolved another one opens up. Eventually it gets to a point where we just want to do whatever we can to resolve all comments and merge the PR, even if we don’t agree with what has been suggested.

PRs should have limited but concrete scope. That is the task should be well understood and be manageable in size. Well understood means the general solution is known to all team members before someone starts working on it. This is not always easy, especially if the PR involves multiple teams or unknown systems. Concrete scope means the resulting PR won’t be huge. Having enormous PRs is another bad sign as they are rarely easy to review to an acceptable degree.

So what should we do about never-ending PRs. There’s two general types of discussions that happen on these PRs which lead to different solutions. The first are ones that surround technical details and the second focus on conceptual ideas.

Technical feedback is where the reviewer is focusing on the mechanics of the code. Maybe a function named incorrectly or something that could be refactored out somewhere else. Usually it is because they have a different understanding of the code. I think the best way to solve this sort of technical feedback is for the reviewer to pair with the person who opened the PR to get their ideas across instead of scattering them across comments on

Very early on in your career when you start out as a software engineer the path ahead is fairly straightforward. Everything hinges on your technical ability. You must get a good technical understanding of the code and be able to solve problems. Your aim is to become an independent contributor where people can rely on you to get a specific task done.

This can only take you so far however. Eventually you will start being evaluated based on your impact to the business. While technical tasks do have an impact, it is what the job of a software engineer is all about, they don’t do much on their own.

So how do you increase your impact on the org. The best way is to take ownership of a project or feature. You become the leader and subject matter expert for this single thing. If anyone has a question, be it product looking for status updates or another engineer looking for technical guidance, they know to come to you. It will be up to you to lead it to completion and offer status updates to others.

It does not mean you must do it on your own. It is all about coordinating other engineers, product managers and whatever other business function

What is a good project to take ownership of? The best ones are medium sized ones. Too small and the impact is limited but too large and the project risks becoming bogged down or cancelled. I’ve been part of ones that span multiple quarters and, while the eventual impact was

This is a list of books I’ve read or attempted to read. It is ordered from most to least recent. The further back it goes the less I remember about them.

I’ve but an asterick (*) beside the ones I thought were good

• The Alchemy of Air * - great book about a technology that’s not thought about but crucual to the modern world (fertiliser)
• Happy City * - interesting read about what makes cities great
• Boom, Bust, Boom - about copper and mining industries and the real world impacts of the mines
• A Philosophy of Software Design
• The Hard Thing About Hard Things * - good but more suited for those starting a business, though I still took something away from it and his biography at the start is good
• The Millionaire Fastlane - kindof a clickbait book but it’s an easy read and I like keeping finances on my mind
• The Software Craftsman - I liked this as a reminder to take pride in your work
• The Prize: Oil industry * - good book, almost a history of the modern world as oil has been so apart of it
• Sam Walton: Made in America - good but obviously bias as is an autobiography
• Exactly: How Precision Engineers Created the world * - a book for the engineer in us all
• The World for Sale * - good book on commodity traders and how they operate
• The Hobbit
• How To Win Friends And Influence People
• American Prometheus (Oppenheimer) - read the introduction but found it

An accomplishment journal, win diary or whatever title you want to put on it all means the same thing - somewhere you write down all your accomplishments through your career. It’s one of those high leverage things which is low effort but provides high reward once you stick at it. Tracking achievements is useful early in your career too as you move up from the entry level position.

There’s a bunch of places where having a quick and easy list of your achievements can come in handy. For example when you’re brushing up your resume while looking for a new job or an internal promotion, you want to be able to focus on telling the story rather than trying to remember what you did a few months ago. It’s even just useful to glance over while preparing for a job interview to remind you of some little details and keep you focused on what you’ve done. It can also come in handy when you’re in a rough point feeling like you’re making little or no progress in your day to day - being able to look back and see all the things you’ve accomplished can be a powerful motivational factor.

There’s not really any requirements to keeping record but keep it simple. There’s two pieces of advice I would recommend following. First, it has to be somewhere that you take with as you move across jobs or devices. You don’t want to have to start fresh if something happens your computer. Second, it has to be something easy

How to write better for software engineers.

https://eugeneyan.com/writing/writing-docs-why-what-how/ There’s three questions any document you’re writing should answer - why it is important; what a good outcome is and how to measure it; and how to achieve the why and what. There’s examples of the three types of documents the author wrote while working at Amazon - one pagers; design docs; after action reviews.

2021-10-30 Weekly Summary

This week I finally started this blog and posted a few things. For now it is a collection of random posts that are not very good quality but everyone has got to start somewhere so I may as well try start here. Below are a bunch of links I came across the last week or so I thought were interesting or notable.

financial innovation is actually happening

An argument that financial innovation is happening right now, contrary to many who look at the financial infrastructure and see an archaic backwards system creaking along. It makes the case that things are becoming faster and cheaper, with examples of faster cheaper transfers and remittances. (link)

Thoughts: Fintech is huge and an immensely complicated arena. There’s things in this post I don’t fully grasp.

Kubernetes pods are ephemeral, meaning they can be destroyed at any time or moved to another location in the cluster. This means the IP of the pod changes without notice creating problems on how other applications and external traffic can reach the pod.

This is where services come into the picture. A service has a stable IP that clients can reliably use to contact a set of pods. There may be one or more pods in the set and the service provides load balancing over this set, taking care of which replica pod gets a particular request.

How Services Work

Services use labels to target pods. Each pod you want to target with the service should have a label on it. There is a corresponding label on the Service. In the example below the label on the service is app: blog which is also on the pod.

Discovering services can be done through environment variables or through DNS. DNS is the recommended method where a DNS server is added to the cluster and all pods should be able to resolve services through their DNS name.

Types of Services

There are three main types of services we can use.

Cluster IP: this is used to expose services within the cluster

Node Port: this allows services to be exposed externally to the cluster

Load Balancer: this is used when an external load balancer should be used, for example in GKE in the cloud

Example Service

Below is a sample yaml file for the config of a service of the default Cluster IP type:

apiVersion: v1
kind: Service
metadata: