People love taking shortcuts and are addicted to spotting patterns. These patterns can enable us to get answers in the face of complexity.

To illustrate this I've written a logic puzzle which provides new puzzles every day. After promoting this on my instagram it took two days to reach the same number of views that my blog got over the last three months.

Discovering heuristics is work but it's also fun. You might have noticed, depending on which puzzle is showing today, that once you've spotted a pattern it fills you with a little bit of joy as you move closer to the solution.

Heuristics show up in more places. Loan sharks come-up with guesses that determine if a business should be funded. Startup investors use the latest VC zeitgeist to purchase equity.

Chess

We are taught heuristics. In chess we learn how much each piece is worth; for example a pawn is worth 1, knight 3, rook 5 and queen 9. Using these numbers we can make calculated decisions in order to help analyse trade-offs. These values are made up, but they're an educated guess at the current board state and determine who has the advantage or which move might be favourable.

Chess engines also assign values to pieces. Stockfish assigns pawns 208, knight 781, rook 1276 and the queen 2538. These are probably more in-line with what the pieces are actually worth but we can't get a human to do this maths during a game of blitz chess.

There is another way chess engines assign values to pieces and it can change through-out the game. Using a grid we assign values to the board positions and how much each piece will be worth in that position. As an example, a knight in the centre of the board is worth 3 more points than a knight in the corner. We know this intuitively because the knight will have more attacking opportunities in the centre than in the corner. A chess engine can have more precise numbers for the value of each board position given a large enough set of chess matches.

Other Places

Heuristics show up through-out life as they are synonymous with lessons learnt. However it is important that we assert these rules with some rigor as this is where bias can seep in, as with what might happen in naive underwriting.

We don't have to worry about this with logic puzzles or chess, these are just for the fun of it.

Over 43 years Edsger W. Dijkstra wrote 1318 essay papers. At the rate I am writing blog posts I should overtake him in 37 years. This is if I keep going at 1.5 weeks per blog post.

An aspirational blog is typically one that has 1-4 essays all dated about 3-7 years in the past. We can further identify these blogs when they contain a post that says something along the lines of "Hey this is my blog, I hope to write in here frequently, stay tuned!" and we never hear from them again. So having a blog seems to be something that people wish to have, but not something they ever get around to publish content on.

Then there are blogs that are full of content and insight. When I've come across these you tend to leave with a strong opinion of the writer and you might even think, "damn, I want a blog like this".

So what makes the difference?

Motivate Yourself

A number of people have asked "How do you motivate yourself to keep writing your blog" and after putting thought to the question I've realised that all motivation can be broken down into 3 steps.

The first step is defining your goal, and in this case we can say the goal is "Create a blog, or a blog post." Goal setting is shallow. Often there's nothing unique about anyone's goal, as with aspirational blogs, showing one's thoughts and personality seems to be something everyone wants to do.

The second step is where we attach meaning to our goal. Try to get deeper than the six year old that want's to be president. Why do you want a blog? Why do you want to be president? The six year old might wish to give their class mates chocolate every Friday maybe they want to make a positive difference in people's lives, on these two reasons alone which six year old do you think is most likely to become a president.

So why do you want to write a blog? Some of my reasons include; I want to receive feedback on certain topics. I want to use it to connect with colleagues, friends and others interested in the same thing as me. I want to build credibility and become a source of insight. I want to get better at writing. Now we've defined Why.¹

Throw Away Your Goal

At this point we can get rid of our goal of "Create a blog, or a blog post" because the next step is to figure out "How".

How can I receive feedback? How can I connect with colleagues? We need to make assumptions and list all the possible ways we can get feedback or develop connection. It's important to highlight that we are out to prove or disprove these assumptions. If we write a blog and don't get feedback or we end up without creating connections then we should be happy to throw it away. At the end of the day our goal is not to have a blog, it's to create connection and the blog isn't working.

We can apply this to other goals that people typically have such as "Get a Job". If we aren't able to find work then we need to think about Why we want a job. It might be money, it might be being part of something greater than yourself. Well there are ways of making money and being part of greater things that are not contingent on getting a job. If we are too attached to the goal we might be blind to opportunities which will help us achieve the underlying driver that's causing us to want a job.

Recession Proof

Knowing the Why is an important part of the motivation. If you can't get yourself to sit down and write on a Sunday, one of the easiest ways to get yourself into gear is to reflect on why you want something. I'm doing this to get better, I'm doing this to build credibility. These reasons are often bigger than your current self and bigger than the dilly-dally of your procrastination session.

Where else are your ideas going to go? There's no point in collecting and holding onto your ideas for the slim chance that you get the right moment to apply the nugget of wisdom. You're more likely to get these moments if you are writing about them. Prove you know something by writing it, and avoid forgetting things by having it written. Finally; write for yourself - not for others.

Getting Started

Beyond trying to motivate yourself, you can make writing easier by making small notes of the thoughts you have throughout the day that you think make an interesting tidbit to tell someone else. Having one place to gather these notes is helpful as you have a flock of thoughts you can collate and group into some coherent essay. That way when you sit down you're not starting with the blank page, you've got a jumping-off point.

Once you are in the habit of doing this you'll tend to be eager to find things that bring you inspiration. It is important that we motivate ourselves to seek inspiration and we are not sitting and waiting for things to come to mind. Being active in sparking inspiration will change how you approach how you consume content and the conversations you're having with others.

Through the process of creating my blog I've found that I've started to engage more with others on topics that I wish to find out more about. I'm fleshing out my own ideas through conversation. I'm trying to find books that touch on topics that I'd like to explore and write about. There's now a loop of being eager to write which is making me eager to learn which is making me eager to write. Which is funny, because I've found that the process of writing a blog post is fulfilling my underlying motivations more so than just having the blog.

Giving yourself a deadline helps too.

One of the major driving pillars of culture within an organisation is the way in which we deliver feedback. However; people are quite terrible at providing feedback and in young organisations this can turn into a form of ritualistic hazing.

If most drivers believe that they're better than the average driver, then we can be sure that people assume their feedback is better than the average feedback.

It is not only important that we work on how we provide feedback but equally important to work on how we receive it.

Ease-in

Positive things should be noticed, starting on a positive note clears the ground for a more constructive conversation than coming out the gate with criticism.

Compliment sandwiches don't work, if you're delivering critical feedback surrounding it with fluff is one way to fog up the message you're trying to get across.

If you're reviewing a piece of work, put the focus on yourself when commenting. "This paragraph confuses me because of x". Instead of "You've written a confusing paragraph". With this we can reinforce the separation of the person and the work, we are here to tackle the work not each other.

Provide Solutions

You should probably work out ways that can help someone improve before asking them to work at it. Discuss and provide these as action items, additionally be clear and ensuring they understand the feedback. You don't want them to spend time addressing the wrong problem.

The person receiving the feedback might already be aware that they're not great in a certain area, the only new information they're coming away with from this interaction is that you're now also aware they're not great.

They could feel frustrated because they've been making attempts at improving which hasn't seem to work. If you provide them potential actions or solutions you show them that they're not alone and you care about getting them through these challenges.

The opposite can also be true, telling someone they need to improve on something can feel like you're pushing their boat out without paddles and it can appear like you're trying to sabotage them, or just out to hurt their feelings.

Don't Provide Solutions

Sometimes people don't need you to provide solutions. Often they're just looking for reassurance. They could be trying to improve their confidence in a solution they've worked out.

Providing answers in these situations can make things tougher for the person trying to get feedback, instead we should ask questions. Questions provide you with further context of their issue and provides them with a different frame of reference. Simple questions can spark ideas in their mind and you offer a fresh perspective.

It's unlikely you're going to give them any better solution from the 10mins of context during the start of the conversation, considering they've been mulling over the issue for a much longer period and you might not be the first one they've come to for help.

Their solution might be good enough, throwing them a new solution might just lead them into decision paralysis.

Obviously if they ask "how would you do this" then give your answer.

Metaphors

If you're going to use a metaphor make sure they make sense.

Metaphors should follow the explanation and should be used for emphasis, they shouldn't replace the feedback.

Make it a Habit

Positive feedback with no buts, if you only compliment someone when you're trying to soften a blow eventually the other person is going to catch-on and the positive notes become flavour text.

Provide feedback when you have it. Gathering a list of things over a long period in order to unload on someone during a feedback session can make those sessions feel like a grilling. There's no warming up to those days and the receiver is probably not looking forward to it.¹ Alternatively if your goal is to create a toxic work environment this is how you can do it.

It's often not effective to address situations from a month ago and hitting them with accumulated criticism can make it tougher for them to know what the important thing is for them to focus on.

If you have to have feedback sessions, make sure that one session is focused on either them or you. Doing everything in the same session can cause it to spiral into tit-for-tat. Make sure feedback is provided one-to-one, getting feedback from two people at the same time feels like an ambush.²

Feedback shouldn't come as a surprise and should be provided on an ongoing basis.

Take Feedback Better

If we grow and learn from feedback, don't make it tougher for others to give it to you. Shutting yourself off from a tap of feedback is going to cause you to stagnate.

Sometimes feedback can be hard to give and you should acknowledge that when receiving it. We can all accumulate blind spots of behaviour, having these pointed out can feel embarrassing, but would you rather someone let you know about it or would you want to go the whole day not knowing you're making a bigger fool of yourself.

Avoid jumping to the defensive or starting an argument. Sometimes addressing the feedback is easier than the work of fighting it, so just do it, resolve the comment. If you're "being too combative" and arguing even about the smallest of things, eventually others might actively work to avoid your reviews and opinions.³

You can build social capital and appear more reliable just by agreeing. My sister does this to her own detriment. She'll re-watch an entire 8 hour series pretending she hasn't seen it already just to spend time with others. Being up for things and avoiding friction is bound to make it easier for others to get along with you.

Say no when it matters.

Blanket Feedback

Giving good valuable feedback is tough, if you're actively looking for feedback you're not helping yourself by asking for any feedback they might have. It can be more helpful to get specific; focus in on what you're aiming to achieve and improve on.

One of the easiest ways of gaining feedback is to ask others how they try improve certain areas of their work or their life, it doesn't have to always be about you and what you are doing or not doing.

Don't Forget Feedback

If you've found yourself in a situation where you've received critical feedback. (Like a PIP or you've said something you shouldn't have). Don't let others remind you of it.

You need to make it a point that you've not forgotten, it's even better if you put in active steps to improve or build a visual habit that can reassure others that they don't have to worry, you won't forget.

It's important to show that you take their advise seriously.

Be Genuine

Give feedback about things that really matter, smaller none impactful things should be ignored. Avoid nitpicking.

If you don't have feedback don't make it up, generic feedback and nitpicks aren't helpful. The person on the other end of the feedback might take every word you say as gospel⁴ and they'll put in an active effort to address your concerns.

Generic feedback can be confusing and some people will go to the earth's ends to address a nitpick when you never intended for them to put that amount of effort into the change.

Be genuine, get personable.

A tech stack is more often inherited than it is chosen. On the rare occasion someone gets the chance to decide which tech the company gets to use for the next decade. I've seen this go well and I've seen this go belly up.

If you're in the right club, you know the answer; stick with boring.

The Postgres Paradox

When thinking about how long a technology will last I often use the current age of the software to determine how much longer it will be around. So if it's 2 years old, it might be around 2 more years. Postgres dates back 35 years, so it will probably be around for 35 more years.¹

We can view this in terms of experienced employees; we are more likely to find someone with 20 years of Postgres experience than we are to find someone with 20 years in a tech that's only existed for 2 years.

Taking the age of the tech into consideration allows us to earmark the hiring pool and the likelihood that fixes or workarounds exist for problems we might run into. Diving into newer tech increases the chance we are the first to come across certain problems.

The bleeding edge might appear shiny and new but we aren't here to ship blog posts we are here to ship features and delight customers.

These avoidable issues are hard to solve because of two reasons:

1. They're novel, we're the first to run into them.
2. The people that have faced this issue are expensive, because not many of them exist.

Make a Difference

Starting a business is a risk, picking fancy new tech is a risk. These risks add up. Where you decide to take the risk depends on where you are trying to drive innovation.

In 2015, London, two neobanks were founded; this is the tech they are built on and the tech's age at the time. Revolut is built on Postgres (25yo) and Java (19yo), the other is built on Cassandra (7yo) and Golang (6yo). The former has 50million customers, the later has 10million.

Risks are allowed to be taken, but we should limit the number of unknowns and not make things harder than they need to be. If we pick our entire stack on the principle of shiny and new we are going to be fighting our tech more often that we are solving customer use-cases.

Get excited about delighting users, not the fancy tech.

Don't be First, Be Fast

Early market leaders have much greater long-term success and enter an average of 13 years after pioneers.

Golder and Tellis (1993)

People make the assumption that if they're not using the latest technology they're not staying competitive, when they are instead just becoming a case-study for the industry.²

The study by Golder and Tellis tells us that first movers have a failure rate that is 6 times higher than fast followers.

If the tech stack mattered, you'd see it in advertising, but you don't, because the customer doesn't care. Your tech stack doesn't determine your product market fit³

Your investors might care (🤷).

If I had to choose between customers and investors I'd pick customers.⁴

The Right Tool for The Job

Ask a graduate what tool or language they would use for their next project and they'll give you a political answer: "I would pick the best tool for the job". Here's a list of programming languages. There are 50 that start with the letter A. Let me know when you've found the one that's best suited for the job.

Perhaps we should define what "best for the job", means. If we are in a team of 12 engineers that are maintaining 2 Postgres databases; introducing a MySQL database on the basis that it addresses a specific use-case better than postgres is not a good idea.

If we hire a DB expert in the future are we going to ensure they're versed in both Postgres and MySQL? It's niche but we could find them at a price.

We don't have to hire this DB expert, our team has built up experience with Postgres, now they'll need to familiarise themselves with the maintenance process of a new db. Just bumping your database version is now slightly tricker and you're monitoring news and bug fixes for both releases.

We could define "best for the job" as perhaps the one we are most familiar with, and this is often the best choice. If you can skip learning a new language or learning the framework step, you're going to get to market faster than others. Don't let learning the tech be the procrastination for learning the market.

In a startup we are testing our market assumptions, this is the largest risk to the company, we shouldn't slow down the speed we get to market. It's better to know we are wrong sooner rather than later.

Getting Experience

Engineers at startups might use the job as an opportunity to focus on CV driven develop instead of focusing on the needs of the business.

I've seen a graduate write every new project in a new programming language.

Anyone know Elixir? We're trying to fix a bug in production and the developer that wrote this is no longer at the company.

From a slack thread.

Starting every new project in a new language isn't a fast way to learn how to deliver. It's a fast-way to get 3 months of experience 5 times. Learn how to deal with a language's pain points and how to solve issues with a specific framework is what makes you valuable. If you're looking to stretch yourself, then use the same language and framework for larger projects.

If you've only got 3 months of experience in a language and framework you're probably not that hard to replace.

The new thing won’t be better, you just aren’t aware of all of the ways it will be terrible yet

Slide 84

Propaganda

Propaganda doesn't just occur in war or between competing states, corporate propaganda is a well established strategy available to large technical institutions.

Let's say you are working on an internal framework that holds up your billion dollar social media platform, you wish to hire more engineers to maintain and build the project. Training new hires on this framework is time consuming, wouldn't it be great if the engineers we hired were already familiar with the framework?

They can also hire developer advocates, these are the influencers of the software engineering world, corporate mercenaric missonaries that are very good at making the work they're doing exciting.

Ignore the hype, your job is to keep things simple.

Bleeding Edge

One reason you might wish to be in the bleeding edge of tech is to gain the expertise and then build around some of the fundamentals you've learnt. Perhaps your customers are others trying to enter the market, this is perhaps a safety-net for the risk you take, but the market can also flatten out and you're left holding a bag of air.

There are a few parts that make up the blog, the static site generator, the API and the repo that hosts all the HTML. This article provides an overview of these pieces and how they're all brought together to create the website.

Framework

The framework is called Pelican a python based static site generator. Each post is written in markdown which starts with meta tags such as Title and Category. Pelican then uses this and a custom theme template to create HTML. The theme uses jinja templating to construct template HTML pages.

Pelican also provides a config file which I have used for feature flags and to enable extensions. The extensions I've enabled include footnotes and code-highlighting. Additionally Pelican hosts a local version of my blog which it recompiles whenever it detects a change to any of the files.

In the config there's a list which contains all the links rendered in the sidebar. Extending or updating these links is only a matter of making changes to this list.

There are two directories inprogress/ and content/. inprogress/ stores drafts that are half complete, completed or minor thoughts for potential blog posts. When these are ready to be published they are moved over to content/ and when these are pushed to the repo, using a github action, pelican automatically renders the entire blog into HTML. The action then creates a commit for any changes and pushes the changes to a public repo.

The public repo contains the entire rendering of the blog and theme. Relying on Github pages, this is then hosted.

The CV

Within the same repo as the drafts and published content there's a CV written in Latex. This latex file can be rendered to a PDF. I have a bash script which allows me to recompile this PDF whenever changes are made to the Latex script.

The API

There's an API that contains edge functions written in Go. These serve requests for the comment sections that sit below each blog post. There are three endpoints, one fetches the count of comments given a list of article URLs. This is used on index pages.

There's an endpoint to fetch comments given an article URL and an endpoint to post a comment to an article URL. The repo containing these endpoints has an action which deploys updates on each new commit.

Finally the API handles the mailing list. It handles registering new emails, verifying the email is valid and lastly triggers an edge function to look for new posts using the blog's RSS feed in order to send updates to recipients in the mailing list.