Go seemingly anywhere in Amsterdam or more widely in the Netherlands and you’ll find it that seemingly everyone cycles. Certainly more than most other western nations. But why is this so?

Weather and landscape play a factor. Having nice weather, basically just not raining, and flat roads to cycle on do play major roles but I think the more important one is that the infrastructure is there. Look around and you see segregated cycle lanes that don’t just end randomly like they do many other cities. They’ve even built an underwater bike shed instead of leaving it up to you to find somewhere to put your bike like many other cities.

Socially too it is accepted or even expected to cycle.

So why is this so. If you went back to the post World War 2 days of the 50s and 60s you’d probably find the popularity of cars rising at the same rate as most other western European nations. Oil was cheap and the car was the ultimate expression of freedom. The continent was rebuilding and the economies were growing rapidly.

This all began to change in the early 1970s with a series of major oil shocks. Over the decade the price of a barrel of oil rose from about 3 dollars to about 12 dollars, a 300% increase. For comparison, today the price of oil sits around 80 dollars. A similar increase would move it to 240 dollars. Nowadays we are somewhat used to oil prices fluctuating daily but back then in the post World War years they

In this article I will walk through how to create page redirects in Cloudflare. The redirect I’m creating here is one to go from one page to another so for example to go from /blog to /posts. In many cases it may be more preferable to set these redirects up in Cloudflare as you can avoid extra requests going to the site which results in lower load and cheaper running costs. Cloudflare also serves these requests closer to wherever the visitor is coming from so it leads to a faster experience for them too.

Cloudflare have recently updated their redirects feature which may cause confusion as most of the posts I’ve found online relate to the old way of doing this through page rules.

Example

The example I’m using here is to redirect the homepage (/) to the /posts page.

1. First navigate to the redirect rules page which is under the rules section in the Cloudflare dashboard
2. The incoming requests should match whatever you choose so in my example it will be “URI Path” equals /. This is represented in the expression preview box as (http.request.uri.path eq "/")
3. As this is a single path we can use a static URL redirect and set the URL to be /posts. I also want to keep the query string (e.g. /?foo=bar) so I will tick that box. Status code can be whatever you like, I’ve a section below with more detail. In the end it will look like the following screenshot:

Testing it works

Here’s an example

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.