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.

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?

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.