Method parameters

What does the following function do?

updateState(state, true);

Specifically, what does true mean? What would it mean to be false?

Modern IDEs may give the parameter name as a hint, but it’s still cumbersome to read.

updateState(state, silent: true)

A boolean in a method implies that changing the boolean changes the behaviour, so there is a high likelihood of that method containing an if statement. So why not just make two separate methods and keep the methods shorter?

updateStateSilently(State state);
updateStateWithNotification(State state);

Here’s another scenario:

void updateState(State state, bool silent, bool isAdmin);

What happens when we want to make a change to the function signature, such as removing one of the booleans? We need to be very careful that we refactor appropriately - deleting the wrong parameter could incorrectly invoke admin privileges!

Again, ide tools may manage to handle this for you, but it’s not fool proof. What if instead, we used an enum?

void updateState(State state, NotificationMode notificationmode, PrincipalStatus principalStatus);

...

void updateState(state, NotificationMode.SILENT, PrincipalStatus.USER);

Now, if we incorrectly deleted the wrong parameter, we’ll get a compilation error instead!

State

Sometimes, you might have a boolean field in an object.

Consider the following example of an Order in a financial exchange. Sometimes, a user may want to place an order onto the order book, but want it to be cancelled if it would immediately match with an opposite order already on the book (frequently used by market makers). We call this a *post only` order.

NewOrder{
  Symbol symbol,
  Price price,
  Quantity quantity,
  boolean postOnly
}

As a developer, we’ve been tasked with implementing a new behaviour: if a post-only order would match, then instead of cancelling the order, we adjust the price of the order to be as close as possible to the original price without it matching.

We could add a new boolean to the object, or an enum that expresses the behaviour of the post only order, but we’d only set it if the order was post only to begin with. This makes for some unsightly code, with behaviours that aren’t entirely predicatble to a developer reading the code for the first time.

Instead, we could change the postOnly field from a boolean to an enum, with three possible behaviours:

OnMatchBehaviour.EXECUTE
OnmatchBehaviour.CANCEL
OnmatchBehaviour.ADJUST

But because we used a boolean to start with, we now have to change many places from true and false. We may also be making a breaking change to our API. If we had used an enum in the first place, our change would have been much easier to make.

I recommend using Enums as much as you can instead of booleans. The enum can have a boolean isSomething() method to be used in an if statement. If you then need to add a third enum, removing the isSomething() method will then result in a compilation failure, ensuring that you update the code in all the correct places.

Alternatively, you could use a switch() statement without a default case, so that a new Enum also results in a compilation failure.

Here is how I fixed it. I am using Shokz OpenComm2 with the Loop 120 USB A adapter.

• Get the Vendor ID and Product ID. With the device turned on, run lsusb. Look for the following:

  Bus 003 Device 007: ID 3511:2ef2 Shokz Loop120 by Shokz

• Create a file at /etc/udev/rules.d/10-shokz-fix.rules with the following contents. You will need to use sudo to create this file.

  # Rule to prevent Shokz headphones from triggering standby/sleep
  SUBSYSTEM=="usb", ATTRS{idVendor}=="3511", ATTRS{idProduct}=="2ef2", DRIVER=="usbhid", ATTR{authorized}="0"

  Replace the idVendor and idProduct with the corresponding values from lsusb if necessary
• Reload the udev rules

  sudo udevadm control --reload-rules

Unplug and plug-in the adapter to reapply the rules to the active device.

Sinek’s core premise — that understanding your fundamental purpose drives better decision-making and long-term thinking — is both convincing and actionable.

Unfortunately, the book suffers from significant structural issues. The central concept, while valuable, could be effectively communicated in a much shorter format. The text relies heavily on repetitive examples, with Apple’s story appearing so frequently that it becomes distracting rather than illustrative.

While the underlying message has serious merit, the execution doesn’t justify the investment required for the full 200+ page book.

For readers interested in Sinek’s framework, his original TED talk delivers the same essential value in a more concise format.

Developers may get stuck pursuing minor software improvements over adding real value. This could be due to inexperience in estimating effort versus value, and not realising when a task is taking longer than expected. Alternatively, the developer could be choosing a low-value task that feels comfortable; achieving a solo contribution.

When you have the freedom to choose what to work on, consider the priorities for the team and how you can best help. Remember: today’s priority may not be the same as yesterday’s, so you may need to shelve what you are working on. This is okay: the work is not lost.

If you are not sure what the priorities are, ask! This will show initiative and higher-level thinking.

It’s important to note that low business value does not mean low value: maintaining a healthy codebase is important. This is where the skill of prioritisation comes in: technical debt reduction must be balanced alongside the goals of the business.

Think: What is the goal? How do I help us get there?

Respect is a baseline acknowledgement of a person’s dignity, regardless of their views, status or usefulness to us. By initiating with a baseline level of respect, we enable faster formation of relationships and smoother collaboration. It’s something we should offer freely — not hold back as leverage — and be granted to every person we meet for the first time. Nevertheless, while respect should be given, respect can also be lost.

Trust, on the other hand, is a quantity that must be earned. Trust must be earned through consistency, honesty and follow-through. If broken, trust will be far harder to rebuild than it was to construct in the first place.

In this post, I explore how trust and respect work together, why they matter, and how we can be intentional about building both.

What is trust?

In the security world, trust is something that can break your security model. For example, if we give a team member full admin access to the database, we are trusting them to behave correctly, but there are ultimately no safeguards to the integrity or privacy of the data.

We can generalise the idea. Trust is a calculated risk — we allow an entity the potential to cause harm while believing that it won’t. An entity could be anything: a person, some software, a rope. Harm does not need to be intentional — we don’t trust a toddler with a knife not because we think they might try to kill us, but because they do not have the skills to handle the knife safely.

In a professional relationship, trust is placed in people when we believe they will act with integrity and diligence. Risks associated with the installed trust are considered, with appropriate mitigation in place where suitable, such that the benefit of placing trust in someone outweighs the risks associated with it. For example, giving full administrator rights to a user is highly risky. Taking regular back-ups of the database and monitoring data access mitigates the risk of accidental corruption or intentional espionage.

Earning trust

We do not blindly place trust in people. That would be reckless and dangerous. Now of course, if the risks are low we may have a certain level of trust that we assume of people — trust in “the goodness of humanity”, if you will. Nevertheless, those that we trust when the risks are greater have earned that trust.

Trust is accumulated over time through three main avenues: consistency, honesty, and reliability. Trust is also somewhat transitive: if Alice has trust in Bob, and Bob has trust in Cathy, then Alice may also have some level of trust in Cathy through the trust she has in Bob. Naturally, it won’t be as strong, but it gives a head-start.

A significant part of being trustworthy can be boiled down to predictability; if someone can predict how you are going to act, then they can trust in your behaviour. If your behaviour can’t be predicted, then the other person can’t trust that you won’t do them harm.

We can become predictable and build trust in three ways: consistency, honesty and reliability.

Consistency

When you are consistent in your actions you become predictable. When you have shown a stable behaviour in the past, I can predict that your behaviour will be the same in the future. Be consistent in how you show up and interact with people. Be consistent in your decision-making. Be consistent in your processes.

Honesty

Obviously, a liar can’t be trusted. However, in this regard honesty goes further. I can add three more dimensions to what it means to be honest: being open, admitting fault over pushing blame, and being self-reflective.

Being transparent and open means allowing people to understand our thought processes, and allowing them to challenge us when we are wrong. When someone knows why you made a decision, even if they don’t agree with it, they are more likely to engage with us positively and accept the decision. Also, we should not hide when things are going wrong. Informing others when things are going badly is better to be done early so that fixes require less effort by all involved.

Admitting fault is a sign of maturity and leadership. A trustworthy person knows they are not the centre of the universe, and are not infallible.

Being self-critical and reflective is a sign of growth. Learn to analyise and recognise how your actions affected outcomes. You will be more trusted if you can show you are open to change.

Reliability

Our word is our most valuable asset. When we say we will do something, it is important that we follow through on our promises. By having a track record of doing as we say, we can be trusted in the future.

Similarly, we should not gossip. It only signals that you are not a safe person to trust.

Breaking and building trust

When we have built trust, we have demonstrated the qualities of ourselves that make us trustworthy — consistency, honesty, and reliability.

When trust is broken, it means that we have shown that at least one of those qualities was not actually true of us. In order to rebuild trust, we must show not only that we have the quality that was deficit, but that we have actually learned from our experience, grown, and built that quality into who we are now.

This is why I believe it is far harder for someone to regain the trust of another, than to build that trust in the first place.

For the person we have harmed, there is an emotional cost and a fear of being burned again that must be overcome.

This is why it is so important to stick to your word, even in small matters.

Respect: a different kind of currency

We have discussed how trust is earned through demonstrating qualities of consistency, honesty, and reliability. Respect, on the other hand, should be given to all by default as a sign of human dignity. You may build a deeper respect for someone that you know well or who has achieved lots, but every new interaction should begin with a baseline level of respect.

This starting level of respect should assume that the other person is competent and well-meaning, and has value to the wider world. We should give them time to speak and be heard, and not interrupt or talk over them.

However, respect can be lost. No matter what, we should always treat people as we would like to be treated. Nevertheless, if someone displays qualities or behaviours that fall short of the standards we assume all well-meaning and competent people have, the respect we share towards them will similarly fall.

As someone loses our respect, we should not start treating them poorly, of course. Remember the golden rule: “Treat others as you yourself would like to be treated”. However, it would be human to be more avoidant of that person, and not put as much value in their opinions. Should a professional relationship suffer from falling respect, it is important that it is addressed and managed correctly, with discussions with managers, and HR if appropriate.

Respect can be lost through arrogance, incompetence, or the general disregard for others’ boundaries, time, or values. Respect can also be multi-dimensional - you could respect someone’s work ethic, for example, while not respecting their management style.

Interaction of trust and respect

Respect and trust will often move in tandem, but there is no obligation for them to do so.

You may respect someone’s skills, but not trust their motives. You may trust someone emotionally, but not respect their judgement.

That said, in high functioning teams and relationships, mutual trust and respect are present and reinforcing each other.

That is why it is so important to continuously work on the behaviours that strengthen both respect and trust, and make them an integral part of who we are by building good habits.

Building respect

While we should give respect to everybody, we can not control how they give respect to others. Some people may be more open than others. In any case, we may just wish to have a stronger relationship and deepen the mutual respect.

Here are eight ways we can encourage another’s respect of ourselves to grow:

• Listen. Learn to actively listen, not just wait for a gap to say your thing. Especially when there is a disagreement.
• Acknowledge time and effort. No matter the person’s role, their contribution is meaningful.
• Treat everyone with the same level of courtesy, not just those “above” you.
• Don’t interrupt or talk over others — it signals disrespect even if unintentional.
• Be open to feedback without defensiveness.
• Give credit publicly. Critique in private.
• Respect boundaries — personal, professional, and emotional.
• Demonstrate respect towards others, and respect towards you will follow.

Final thoughts

Key takeaways:

• Respect is a starting point; trust is an earned position
• Trust is fragile - harder to regain than to build
• Living with integrity protects both

To build trust:

• Keep your word, even in the small things - people notice
• Admit mistakes early. Honesty in failure builds more trust than hiding the truth
• Be consistent - trust thrives on predictability over time
• Follow through - If you say you’ll do it, do it
• Be transparent - especially when you can’t deliver or something changes
• Don’t gossip or break confidences - it signals you’re not a safe person to trust
• Build trust by proxy - earn trust faster by being vouched for by someone already trusted

To build respect:

• Actively listen
• Acknowledge time and effort
• Treat everyone with the same level of courtesy
• Don’t interrupt or talk over others
• Be open to feedback
• Give credit publicly
• Respect boundaries
• Respect others

Trust and respect aren’t just values to be talked about; they’re behaviours we demonstrate. They’re built (or broken) in the everyday: in how we listen, how we follow through, and how we treat others when it’s inconvenient. You don’t need a title to earn respect, and you don’t need permission to start building trust.

How are you showing up to build trust and earn lasting respect?

It has been said to be a sign of plagiarism using generative AI, because most computer keyboards do not have the em-dash, and so most people wouldn’t type with them naturally. That said, if a text has been written using an editor like Microsoft Word then the em-dash might have been autocorrected into place over a hyphen.

Personally, I quite like the dash. While I was once oblivious to the difference between a hyphen “-” and an em-dash “—”, the recent discussion around AI writing has made me realise that I should be using the em-dash (if we’re approaching syntax prescriptively). The hyphen is for compound words, like em-dash. The em-dash, on the other hand, is used to separate clauses.

Here’s how to type the em-dash (and other special characters) in Linux Mint — specifically version 22.1 Cinnamon — which is the OS I am currently using.

Instructions

1. Open: System Settings → Keyboard → Layouts → Options

2. Expand: “Position of Compose Key”

3. Select a compose key.

I chose ‘Right Ctrl’. Close the window when done.

4. Type an em-dash:

Press <compose key> - - -

(That is, press the compose key, then press the hyphen key three times.)

You do not need to hold the compose key down while typing the hyphens.

To type an en-dash, use: <compose key> - - .

Some other useful compose sequences:

The full list of compose sequences can be found at /usr/share/X11/locale/en_US.UTF-8/Compose

Trunk-based development is a collaborative development approach where all developers commit directly to the main branch (often called “trunk”). Feature branches and pull-requests should be avoided. Instead, teams rely on fast feedback loops, high collaboration, and strong CI practices to maintain code quality and stability.

Why is trunk-based development better than branches?

Feature branches are ineffective for several reasons:

1. Slow feedback loop

The pull request cycle requires waiting for a reviewer. After receiving feedback, you make changes, then wait again. Repeat ad nauseum.

2. Merge conflicts

You wrote the code against a version of the main branch. It may have moved on since then. You now have to spend time fixing merge-conflicts.

3. Quality

Reviewers did not write the code. Reading and understanding code takes time, especially for a pull request for a full feature - otherwise it gets skimmed and rubber-stamped. Either quality suffers, or velocity does.

How do we keep quality high without pull requests?

Pair programming

Pair programming means continuous code review. No waiting. Code quality improves, defects are caught early, and features are developed faster as pairs bounce ideas between themselves, rather than waiting for responses to questions in a team channel.

Pair programming also results in better knowledge sharing and improved developer satisfaction.

Test driven development and responsive CI

Commit early, commit often. Comprehensive test suites should be run for every commit. The test suite should complete quickly - ideally within 10 minutes. If a commit breaks the build, revert immediately. Don’t wait for the next developer to notice. Don’t leave the broken commit while you fix the bug. Revert - push - fix - push.

Trunk should always be releasable.

Feature toggles and incremental commits

Big features often require a lot of work to get working; an acceptance test for a feature may not pass until the end of development. Instead of completing the entire feature before committing, disable the test and commit in small, testable increments.

Use static feature flags to disable compilation or run-time behaviour that shouldn’t be visible to users yet. You can safely commit code with a failing test, as long as it doesn’t cause the tests for existing behaviour to fail, and the failing test is disabled until the feature flag is enabled.

This lets us commit in small, frequent batches. Any merge conflicts will then hopefully be minimal in scope and impact.

Other benefits

Ship more often

The only code that matters is code that is in production. The only code that is in production is code that is in the main branch. Working on trunk means working on what matters.

By having trunk always in a releasable state, we can ship to production at any time. This means we can ship as often as we’d like.

Boosted morale

Developers like to get things into production. Having code sit on a feature branch for a long time damages morale. Big-bang releases are also anxiety inducing. Both of these are avoided with trunk-based development and frequent releases.

Better collaboration

Long-lived branches create knowledge silos; when a developer spends a long time on a feature branch they become the de facto owner of that code. If they are away for any reason, progress stalls.

This is avoided with pair-programming and frequent commits to the main branch which form a log of work done and break the task up into smaller, more manageable tasks.

In summary

For faster delivery, better software quality, and happier teams:

• Pair program
• Write tests first
• Run fast CI
• Commit small, commit often, commit to main

Although the term soon became the butt of some jokes, I believe there is a place for ‘Vibe Coding’ in serious software development.

Andrej Karpathy has been credited with coining the term "Vibe Coding".

Let’s be clear; this is not a replacement for software development. Unchecked, untested code should not make its way to production. I do not believe AI will be a replacement for programmers any time soon, and certainly not in its current state.

What AI can do is improve a developer’s productivity. If I do not know how to build an iOS app, AI can get me started, or if I do not know a particular API, AI can point me in the right direction. This is AI used as a learning aid. All the AI’s output should be read, understood. Anything that is confusing should be clarified and verified. Production code should be tested, and the test cases designed by a human.

If I need to write a suite of similar looking tests, AI can help me generate them. This is AI used as a productivity tool to remove tedious, repetitive tasks. Again, all the AI’s output should be checked.

‘Vibe coding’, at its extreme, involves blindly accepting whatever the LLM has generated. We do not check the output, we do not understand it. We run the program, and if it does something wrong, we tell the AI to fix it. Edge cases are ignored, and the code is not backed by a comprehensive test suite. This is code that is fragile. This is code that is unmaintainable.

This is code that is not fit for production.

But it is fit for a prototype. It is fit for a proof of concept. It is fit for a hackathon.

To build good software fast, we need an engineering mindset. We need to test early and often and get fast feedback. A common issue in commercial software development is that the business doesn’t know what it wants, or isn’t aware of all the issues or edge cases that need business consideration.

A prototype that can be built quickly with vibe coding can be shown to the business team and used to gather feedback. It can be used to explore the problem space. It can be used to explore the solution space. It can be used to explore the user experience. It can be used to explore the technology stack. It can be used to explore the business model.

Once you have your feedback, and you move to writing production quality software, the vibe code may be referenced, but picked from with consideration. Standard software engineering practices should be followed; pair-programming and test-driven-development must not be forgotten about. Ensure those that see the prototype understand that it is an early prototype for gathering feedback, and not production quality code - we all know how sales people can take a prototype and run with it!

I expect that in the future AI will be a competent pair-programmer. I do not think we are at that stage yet. To blindly trust AI code would be a mistake. But we do not need to trust it for it to be useful.

So get vibing! Try it yourself, but remember to set boundaries. Start a dialogue with your teams about how to use AI in your software development process. Finally, share your experiences! The more we share our experiences of using AI, the faster the engineering community can learn and adapt to this rapidly evolving technology.

A pair of Ghosts

Roast dinner in a Yorkshire pudding

Ladybug

River Ouse

Nice place for a nap

I would love to know the story behind this card

High in the sky

York has a cat trail!

York Minster

Hugo is a static site generator that is fast, and has great support for image processing. Posts are written in Markdown as individual text files and converted to HTML as a build step in a CI pipeline. Hugo also supports RSS, a small nerdy feature that I wanted to have.

While I don’t mind paying for hosting, I wanted to keep costs down. I don’t expect a lot of traffic, so for now the free tier of Netlify is perfectly capable of hosting the site.

Posts are committed to a GitHub repository, and Netlify will automatically build the site and deploy it to the web.

The following are the steps I took to set up the blog, including custom HTML and CSS. I use Cloudflare for DNS for my domain, so will also briefly cover the DNS configuration to point the domain to Netlify.

Initial Set Up

1. Install Hugo

While not strictly necessary, I recommend installing Hugo on your local machine so you can preview your changes before pushing them to GitHub. It also makes setting up the skeleton of the site easier.

You can find instructions for installing on your system at

https://gohugo.io/installation/

2. Create a new site and git repository

hugo new site my-blog
cd my-blog
git init

Find hugo.toml in the root directory. There are some basic configuration options that need filling in.

3. Add a theme

Find a theme you like. A list of themes can be found at https://themes.gohugo.io/.

Add it to your website as a git submodule, and reference it in the hugo.toml file.

git submodule add https://github.com/clente/hugo-bearcub themes/hugo-bearcub
echo 'theme = "hugo-bearcub"' >> hugo.toml

4. Run Locally

hugo server -D

This will start a local web server on port 1313. You can view the site at http://localhost:1313. The -D flag means draft posts will be included in the output.

Hugo will automatically re-build the site as you make changes.

5. npm install hugo

In order for Netlify to build the site, you need to install Hugo as a dependency in package.json. We can use npm to do this for us.

npm install hugo-bin --save-dev

6. Create a GitHub repository and push to git

git add .
git remote add origin git@github.com:my-user/my-blog.git
git remote set-url origin git@github.com:my-user/my-blog.git
git push -u origin main

7. Create a Netlify account and set up the site

Netlify is pretty straight-forward to use. Use ‘Import and Existing Project’, choose GitHub, and select the GitHub repository you just created. You should be able to leave most of the settings as they are, but just in case:

Branch to deploy: main
Base directory:
Build command: hugo
Publish directory: public
Function directory: netlify/functions

8. Set up a custom domain

Netlify has instructions for setting up a custom domain to point to the website. They refer to using a ‘flattened CNAME’. In cloudflare, this is a standard CNAME record. Cloudlfare will automatically do the flattening for you.

Ensure you disable Cloudflare’s proxy for the DNS record; Netlify has its own CDN, we do not need to run Cloudflare’s on top. It would only harm performance.

Customising the theme

I liked the look of the hugo-bearblog theme, however there were a few changes I wanted to make.

First, I wanted the home page to be a list of all my blog post titles. As my site evolves and I add more content, I may want to change this, but for the beginning I wanted the site to be extremely simple. Home page -> Blog post.

This meant overriding index.html, and removing the navigation bar by overriding nav.html.

Second, I wanted to modify the layout of the titles as they are listed. In particular, I wanted to add the category of the blog post to the listing.

Finally, I wanted to add a favicon.

We can achieve this with the following files:

layouts/index.html

{{ define "main" }}
<div class="home">
    <div class="posts">
        <ul class="blog-posts">
            {{ range where .Site.RegularPages "Section" "blog" }}
            <li>
                <span class="post-list-item-date">
                    <time datetime='{{ .Date.Format "2006-01-02" }}'>
                        {{ .Date.Format (default "02 Jan, 2006" .Site.Params.dateFormat) }}
                    </time>
                </span>
                <span class="post-list-item-title">
                    <a href="{{ .Permalink }}">{{ .Title }}</a>
                </span>
                <span class="post-list-item-category">
                {{ .Params.category }}
                </span>
            </li>
            {{ else }}
            <p>No posts yet!</p>
            {{ end }}
        </ul>
    </div>
</div>
{{ end }}

layouts/partials/nav.html

<!-- This file is intentionally left blank -->

assets/css/style.css

ul.blog-posts li .post-list-item-category {
    flex-grow: 1;
}

ul.blog-posts li .post-list-item-title {
    flex-grow: 4;
}

layouts/partials/custom_head.html

{{ $style := resources.Get "css/style.css" | minify | fingerprint }}
<link rel="stylesheet" href="{{ $style.RelPermalink }}">
<link rel="icon" href="/favicon.ico" type="image/x-icon" />

Place your favicon icon in static/favicon.ico

Commit and push to GitHub. Netlify will automatically build the site and deploy it.

Congratulations!

• 150g Self-raising Flour
• 55g Caster Sugar
• Pinch of Bicarbonate of Soda
• 1 Egg, Beaten
• 175ml Milk

Steps

1. Mix dry ingredients in bowl.
2. Stir in egg & enough milk until smooth (may not need all milk).
3. Drop spoon of batter into heated pan on medium heat. When bubbles appear, turn over. No need for additional butter in the pan.
4. Keep warm while making remaining pancakes.
5. Serve. Great with butter, bacon and maple syrup.