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.

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:
 

As a sofware engineer, no matter how experienced, there’s always things we can learn from others. Some have more expertise in specific technologies, others have more experience in the “soft skills”. I’d like to think we can learn from the more experienced among us by learning what worked from them and adapting it for our own careers.

On that thought I’ve put together an incomplete list of blog posts that I’ve come across that may be useful. I hope to keep this updated with more as I go along

Software Engineering

Being Glue

https://noidea.dog/glue

How to be a Tech Influencer

https://lethain.com/tech-influencer/

How to ask Good Questions

https://jvns.ca/blog/good-questions/

Salary Negotiation

https://www.kalzumeus.com/2012/01/23/salary-negotiation/

You are not Google

https://blog.bradfieldcs.com/you-are-not-google-84912cf44afb

Code Review Pyramid

https://www.morling.dev/blog/the-code-review-pyramid/?utm_source=programmingdigest&utm_medium=email&utm_campaign=471

Refactoring

https://refactoring.guru/design-patterns

Don’t Call Yourself a Programmer

https://www.kalzumeus.com/2011/10/28/dont-call-yourself-a-programmer/

Developers mentoring other developers

https://blog.pragmaticengineer.com/developers-mentoring-other-developers/

Equity 101 for Software Engineers at Big Tech and Startups

https://blog.pragmaticengineer.com/equity-for-software-engineers/

Technical

Indexes in PostgreSQl

https://blog.mastermind.dev/indexes-in-postgresql

How to find more (Blog List)

Here’s a bunch of blogs that are worth reading

https://jvns.ca/blog/

https://www.kalzumeus.com/

https://www.joelonsoftware.com/

Bonus: Blog Search Engine

If you know what topic you’re after or you want to just browse a long list of blogs then this site is really helpful

https://blogsurf.io/

I’ve started this short blog after trying and failing to start a writing “habit” many times before. The reason I want to write at all in the first place is to actually learn about anything you need to put your knowledge into good use. Its all well and good reading countless books and articles but you really need to write to take anything away from those. Writing also improves how you communicate, an invaluable skill in our remote asynchronous world.

My goal is to learn and explore a wide range of topics. I, like many people, have no real idea what my true interests or passions are. Fair enough I kind of am interested in a few things like finance, sports and business on top of my day job as a software engineer. However none of these things I can truly point to and say that is the thing I love learning about. This blog will be an exploration of all of those things plus more, going wherever my interests take me week to week.

There won’t be any formal process to selecting what I should research each week, rather it will be whatever I have learned or come across recently that I think I can write something about.

I hope as the weeks go on my writing will improve and I learn a great deal about the topics I research.

So here I’m going to go through backing up etcd on a kubernetes cluster.

The reason I’ve done this before is for the Kubernetes Certified Administrator (CKA) exam where you would need to know how to do this. In managed clusters like GKE then you probably will never need to interact with etcd.

There’s a few steps involved in Backup:

1. save the snapshot Restore:
2. stop all cluster components
3. restore the snapshot
4. restart all cluster components

Setup

The first thing you’ll want to do before all this is ssh onto the master node of the cluster. The master node is where things like etcd are configured.

We’re going to be using etcdctl to back up etcd in this tutorial. You can make sure it’s installed by running etcdctl version. This will return the etcdctl version and the API version which should be the same. If this command does not work then you can either install etcdctl or even see if etcd is even running on the cluster by seeing if there’s any etcd pods running

Authentication

Another thing you may need to do before continuing on is you may need to authenticate with the cluster. If you find the etcdctl commands hanging or not completing then this is probably the reason. One way of authenticating is by passing in the certs used for etcd. These are usually stored on the master node and you can find the location by looking at the etcd.yaml file. So for example

> cat /etc/kubernetes/manifests/etcd.yaml

...
spec:
  containers:
  - command:
    - etcd