Today’s skill is the first one: my papercuts coding skill.

The skill is based on the scenario that I’ve just had a discussion about some small coding task that needs doing, either in chat or in real life. In the past, the result would likely have been “let’s raise a ticket in the backlog to address this later”, followed by a single line, non-descript ticket somewhere in the team’s backlog.

The papercuts skill

Now, I head to my harness of choice in the codebase of choice and tell it: “We discussed this problem, and we decided that the solution was to do X, read this link to a thread for context (if there is one available).”

Then the papercuts skill does this:

1. Raises a new ticket in the backlog with the correct details in it

2. Performs my git workflow for new tasks (a new worktree prefixed with the backlog reference)

3. Fixes the issue in code

4. Raises a draft change for me to review

Now there is no context or history lost, work is tracked and done at the same time for these small papercuts.

Note that this only works for tasks that are small enough to be contained in a manually written prompt (one or two sentences at most). Larger tasks that require some form of system design or architectural guard rails aren’t suitable for this skill.

It’s not ground breaking but the biggest value I get from this is that context is no longer lost, work is tracked properly without the extra admin overhead that a papercut sometimes does not deserve.

The prompt

Here’s a prompt you use to get my harness to write its own version of this skill. Make sure to adjust the bits of information to match your own workflow:

• where the backlog lives

• git workflow

• code review

Write me a skill called “papercuts” that takes a prompt about a task and does the following:

1. Create a ticket in the backlog with the description, the solution, and the thread link <ADJUST THIS>

2. Create a fresh git worktree prefixed with the ticket reference (Point this at any existing skill or workflow you have for starting a new coding task) <ADJUST THIS>

3. Implement the fix in the worktree

4. Run a code review with four subagents in parallel, apply the good suggestions, and run the tests (Note this is also a seperate skill that I have) <ADJUST THIS>

5. Raise a draft pull request that references the ticket and thread

Leadership

I have watched a leader’s empathy change a team’s trajectory. Everyone works from a different situation with a different set of motivators, people are different and that get energy from different things.

Some engineers thrive when given tough problems and the time to solve them. Others may want frequent check-ins and small wins. Treat them the same and you will get the average of both.

Understanding your people is how you get the best outcome without burning anyone out.

Practice opportunity: Next time you have to ask someone to do something, first find out what they spend their energy on, both inside and outside of work, then see if you can transform the ask into something similar. For example, if you know someone who jumps at the chance to join a customer interview or spends a lot of their time on understanding the customer, try to help link your ask to the customer need, help them connect the dots if they don’t ask you directly.

Product engineering

Product engineering is where I have watched that skill pay off. It requires understanding your customer: who they are, what they want, how they work, etc.

You can only build what a customer wants if you actually know what they want. Most importantly, someone with a strong empathy muscle is able to bypass a lot of their own biases to discover the real customer problems that need solving, our biases often hide things from us without us even realising it. Empathy helps you overcome that. For those platform engineers out there, the skill still applies. Your customers are other engineers, in fact empathy is more important and much harder to apply because you have a lot more biases as an engineer.

Practice Opportunity: Next time you’re building a feature of your platform, don’t assume what you know about development is what other developers want, go out and ask them. For example, if you are building a visualiser for git commits, your workflow tells you that you only really need to see the latest 5 that you have committed, reject this assumption, instead go out and ask one of your fellow engineers on another team and see what they say. They might say the last 10, they might say the most recent one or they might even tell you that they don’t need a visual, each of these is worth finding out before you even go and start building it.

Just plain getting stuff done

The best outcomes I have seen are created by teams.

I don’t mean teams on an org chart. I mean groups of people from across the organisation coming together to build something, often across teams and functions. You need empathy here as well.

You are negotiating a system design with a team you have never worked with. Understanding what they know, what they don’t, and what spurs them on gets you to a point where you start truly working on a solution together. You’ll start talking the same language, there’ll be less surprises and more trust. Only then can you zig and zag together.

Working apart

Empathy is harder for me to keep up when we work apart. My team is spread across time zones, and it’s much harder to gain empathy when you don’t have the opportunity to strike up a casual conversation. But in a digitally distributed and AI automated world, empathy is increasingly important. Understanding why someone else does something means you can more easily predict what they will do, less surprises in a world where course correction moments are increasingly rare and it’s the only way we can get things done together.

Establishing empathy in this world means being intentional. Writing things down, asking questions and triple checking assumptions before they harden.

Subscribe now

It’s true that AI can solve problems that could not be solved before, or could only be solved at enormous cost. Some processes were too messy to script or had just enough variance to make to make deterministic automation expensive.

But I think there is a misconception that can AI can do this trivially.

The setup

Setting up an agent to actually solve a problem on its own takes deliberate design. Before any of this can run, I’ve had to answer questions like these:

• What knowledge does it need to handle your particular task?

• Which skills does it require, and who writes and edits them?

• Which parts need deterministic scripts instead of intelligence?

• What does the detailed flow of the automation look like?

• What can the agent not do, and where do the safeguards sit?

• What systems does the runtime get access to? The ones it needs and importantly, none of the ones it doesn’t need?

Each of these is a topic in itself. Get one wrong and the automation either stops working or causes damage.

Say your team builds an agent that triages incoming support tickets. Getting it working on ten tickets probably takes an hour. Making it trustworthy on ten thousand tickets means feeding it your product docs, authoring skills for the edge cases, wrapping risky steps in deterministic scripts, and locking its access down to exactly one service.

So the answer to “Can AI Solve this?” is probably yes but it comes loaded with the same questions that always come with automating a process: how much will it cost?

Setup time comes first

You have to put time into using AI before you can use AI.

A prompt alone will not get you a working system. The prompt plus knowledge, skills, deterministic scripts, boundaries, and scoped access: that’s what you need to think about and write down first.

That setup is the price. And for some problems, it’s absolutely worth paying, for others it still might not be.

What to ask for

Next time somebody asks you this, give them an estimate of how long it will take to set it up, the reaction to that will tell you if the problem is worth solving.

Subscribe now

But I quickly realised that writing about that would be missing a far more important point that I don’t hear about as much.

The change is real. In the years since my children were born, I have changed. Most of the time I don’t even notice it until I stop and reflect.

I’ve personally become more energised by social interaction. More craving social connection, less wishing I could be by myself. More engaged in my local communities. I feel it at work, in how I show up. These are not small shifts and they are the kind of changes I would have sworn were impossible for me ten years ago.

For the fathers out there: the change is real. Our brains transform as we become parents. It’s a biological change.

It can feel like failing

Sometimes that change is jarring.

Things you used to do without thinking now come to you differently. Interests fade, what used to give you energy might drain you and what used to drain you might supercharge you. Your priorities reorder themselves. Maybe what was important to you before is no longer important to you now, and more importantly maybe you see that others don’t share your priorities and where you used to try and align, you can’t now.

When that happens, it can feel like failure, as if something is wrong with you.

But you’re not failing. You’re simply changing.

There’s a big difference. Failing means you’re falling behind where you should be. Changing means you’re moving somewhere new. Both can feel the same, because both can

You’re actually doing remarkably well

This is what I wish others could tell me more often: parenting is a second and a third full-time job on top of the one you already have and you are probably doing a remarkable job at balancing them.

Once children enter the picture, there’s more to carry: laundry, school runs, homework, sleep, keeping another human being (or two) alive. The endless scheduling of a small person’s existence. You are juggling all of that on top of the physiological change happening in your body and mind (and by the way, your career too)

So when you’re having a bad day, maybe a work deadline looming, kids refusing to cooperate, a dinner plan that still hasn’t been made, don’t forget what you actually did today. You read that book. You helped build that Lego castle. You got your kids to school on time. Maybe you managed one or two of the many other things that only you can do.

Bad days don’t count against you, nobody is keeping score but you. The best thing you can do for yourself and others is to give yourselves a little bit of latitude. You’re killing it.

After more than a decade observing some of the best software leaders in Australia and spending the last 4 years practicing as one myself, I’ve picked the top 3 skills I think all great leaders need and all aspiring leaders should cultivate.

Filtering Noise

The best leaders I have seen are the ones that somehow know the difference between the noise and signal within their domain and organisation. Both sides of the equation are critically important when it comes to focusing teams. Why? Because humans are inherently limited in the capacity they have for cognitive load and there is far more noise out there than there is signal. As a leader it’s critical to know what your people are not doing so that they can focus on what they are doing.

Let’s use a hypothetical situation. A senior engineer has come to you with an escalation, two team members disagree on the boundaries of a system they are building, one engineer believes 2 microservices are needed while the other believes there are 3. You know that the team is building the first version of this product feature to be launched to 100 customers and that there is a deadline that is looming in 2 months that is business critical. You also know that microservices are cheap to spin up in this organisation. That already makes this decision noise, it doesn’t make a material difference to the functionality how the microservices are structured and the proposed initial scale means that any architecture will be fine, it would be pointless to spin up days of discussion over this to go through technical specs and the pros and cons of each approach. So what can you do as the arbiter of this decision? Your options are:

1. Look at each option, assess the pros and cons of each together with the engineers and pick one based on the best weighted components

2. Introduce a third option for a single microservice and explain why it’s the best option, convince both engineers that this is the way.

3. Pick one option, convince the opposing engineer.

Hopefully at this point, The 3rd approach is the obvious answer; it’s the one that eliminates the noise the quickest and brings the team back to focus.

While completely contrived. I hope this illustrates how a leader uses constraints and context to eliminate noise for the team. Imagine instead if you had decided this was a decision worth diving into and understanding in full depth. You could have possibly wasted weeks deciding something that is non-consequential for the intended scale. Noise often comes in the form of decisions or questions asked, if you’re an effective leader you will know that when they show up, you will either need to make the decision swiftly or if a question, put it to the side and answer it later (if at all).

Decisiveness

Decisiveness follows on from Signal vs Noise. The best leaders I know are able to make decisions quickly with incomplete information and stick to them when challenged by noise.

What does this look like concretely?

Let’s say you’ve made that decision to build 2 microservices instead of 3. An engineer outside your team finds the decision record and brings up that this means the module that would have been the 3rd microservice can no longer be seperately scaled horizontally. The theoretical maximum scale for this service is only 100,000 customers due to this scaling limitation. While factually true, this should not change the decision as we already know that the feature will not need to scale passed 100 customers for the first launch. An indecisive leader would re-open the decision and re-consider the architecture, a decisive leader knows that a comment like that is likely lacking context and stands their ground, protecting the team from the noise; the likely action there is a nicely worded comment detailing the constraints that have already been considered. This of course is balanced by signal, if the comment instead raised an issue with scaling passed 50 customers, you know this is something you have to address properly because it impacts the launch.

Humility

Leaders are people and they can be wrong too, when this happens the worst thing you can do is to pretend you are still right. Though counter intuitive, owning mistakes is one of the best ways to earn trust, trying to pull the wool over everyone’s eyes is the best way to lose it, being overly defensive is probably the worst thing you can do.

It’s launch day in 1 week, you’ve done some performance testing and at simulation of the 99th customer, your services fall over. It is the 3rd module and having that module separated out would have allowed you to scale it out without making the other modules significantly more expensive. Your response options are:

• 2 services is the golden architecture, keep this and scale out the second one so that it can take the load. We can pay the money.

• 3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Let’s scale out for launch and re-architect afterwards.

• 3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Delay the launch until we have the perfect architecture.

• 3 services is the way to go, we made an assumption in the beginning that turned out not to be true after testing. Let’s launch to 50 customers instead.

The way you own mistakes matter too. I hope it is obvious which of these example responses is best. The first is the obviously wrong one (which I have placed there almost as a plant). You are likely to be deciding between the last three options and each of them de-prioritises one of scope, cost and velocity. Which one you choose is contextual and depends on which one of the three is more acceptable, but each one of those three admits the mistake made and proposes an action plan. These two components are critical to owning a mistake, you need an action plan to be taken seriously.

These three skills, filtering noise, deciding decisively, and owning mistakes, don’t exist in isolation. They reinforce each other. Noise filtering gives you the clarity to decide quickly. Decisiveness gives your team the stability to execute. And humility gives them the trust to follow you when things go wrong, because they know you’ll course-correct rather than double down. If you cultivate nothing else, cultivate these.

While I’ve written about these skills in the context of software engineering teams, I believe they are broadly applicable to leadership in contexts outside of the technical. I hope they serve you well if you are in or are pursuing a leadership role at any level.

Here are the four places AI has become indispensable in my workflow.

Data analysis

I write a lot of throwaway SQL. Not the kind that gets shipped and reviewed, but the kind that I use to answer a question I have at a point in time. AI writes this for me far faster than I can handcraft it. Give it the schema, describe the question, and it produces a query I’d otherwise spend twenty minutes getting right.

More importantly, it understands the data. It can read a table’s structure and a data set faster than I can, spot the shape of things, and point me at what matters. And when it comes to logs or large files of text - the stuff that would take me hours to scroll through - AI reads them in seconds, gives me the insights I need and if I need to dig deeper or see the data for myself, I can with relative easy. This has probably saved me hours every time I need to do some analysis.

Project status data gathering

Recalling what I actually did over the past week used to mean scrolling through chat messages, pages I’d written, and calendar events, trying to reconstruct what I did and what happened. AI can gather all of that in moments and collate it into something coherent. What took me an hour of mental archaeology now takes me a few minutes of verification and editing.

First draft writing

I regularly write technical strategies, high-level explainers, and other documents that require real writing. I often hit the blank canvas problem. Staring at an empty page hard and it can take me a while to get into the swing of things. Sometimes hours if I get pulled into other things in the interim. AI gets me past it instantly. I give it a prompt with the points I want to make, it writes, and I edit heavily. I often do heavy editing, sometimes re-writing entire sections in my own words or deleting large parts of a document that was just too hyperbolic or sycophantic. I still end up with a document that is mine but I get there much faster without having to start from scratch.

Summarising chats and tracking work

Ever had the retro item “we need to write better ticket descriptions”? AI solves that retro item once and for all. It can read a chat thread and summarise it, and it can read the code too and write a spec out of both. We are talking here about ad-hoc ticketing, help threads, queries or operational work needed for maintenance. These things used to get lost in history, a lot of the times if a ticket was raised it would have next to no context

Most importantly, none of these things replace our craft. They make us better as engineers because they allow us to focus on the important technical things instead.

Subscribe now

My feeds are full of grand statements about the rate of AI adoption - how you’re already behind if you’re not managing a swarm of 10,000 agents.

This is hyperbole at best, and straight-up lying in most cases. Nobody knows where this is going, so how does anyone know if you are behind? What are you behind in?

Engineering fundamentals still matter. Proper coding still matters. As software engineers, our job isn’t just to build something that works - it’s to build something that lasts.

You are not behind. Wherever you are on your journey with AI in software engineering, that’s the right place to be. The entire world is still learning how to use this technology and how to use it effectively. Some have found improvements; others are still searching.

I’m currently on my third iteration of my own personal workflow.

My first vibe-coding setup built something that worked. But it quickly reached the point where not understanding the code myself, having to rely on the AI to read, debug, and maintain it, became untenable. I was spending the same amount of time, or sometimes more, going back and forth with prompts as I would doing my own bugfixes in a codebase I wrote and understood myself.

My second iteration took a more guarded, spec-driven approach: applying architectural guidelines before starting implementation, and setting up an automated system of spec writing and spec implementation with fully integrated context in a greenfields repo. The result was closer to what I’d consider a robust codebase. But after a while, I realised I’d spent about the same amount of time in setup as I usually would — and even after some weeks, with an acceptable codebase, I wasn’t significantly closer to shipping something. In that case, AI probably gave me about a 30% speed boost. Useful, but not astounding.

I’m now trying a different approach. Paying more attention to the context I give my agent about who or what I am, and the principles I use when writing code, storing that in context and trying out spec driven development with these principles as a foundation.

What matters is that I’m still trying. I don’t have the answer - and neither does anyone else. Because software engineering isn’t really a question that has an answer, it’s a field of many quirks with many different answers. Anyone who says it does doesn’t really understand what software engineering is, or how it works.

Do you need to learn how to use AI? Yes I think so.

Do you need to be scared of falling behind? I don’t think so, not if you are still trying and learning things. The fundamental principle of growth mindset still applies, if you are trying and failing, you’re progressing.

That’s why I’m starting No Shortcuts.

Who I am

I’m a software engineer with over a decade of experience building software. I’ve watched Atlassian grow through several stages of its journey, and along the way I’ve operated in teams as small as two people up through departments as large as five hundred.

Being part of several stages of growth has taught me one thing: the fundamentals remain the same throughout. Whether you’re two engineers in a room or a department of five hundred, the core of the craft - clarity, trade-offs, ownership and judgement are all the same. The scale changes a lot of things but those fundamentals remain and actually become more important as you go.

I’m also a father of two, and balance is critical to me. Software is a marathon, not a sprint, and nothing has taught me that more clearly than trying to be a good engineer and a good dad at the same time. I’ll write about that side of the craft too - doing your best work and having a life worth living shouldn’t be mutually exclusive, we don’t talk about it enough, I hope to be able to do that.

What this newsletter is

No Shortcuts is my attempt to write down what I’ve learned about software engineering as a craft. You can expect three kinds of posts:

• Leadership and the non-technical side of the craft - the skills that aren’t in the code, but essential to software engineering which is at it’s core a team game.

• AI and our craft - how AI is enhancing (and changing) the way we build software, and how to think clearly about it using what we already know about software engineering.

• Occasional technical posts - deep dives into the how and why, when a topic deserves the full treatment. Expect these to be centered around building.

Why “No Shortcuts”?

There are no shortcuts to mastery. There never have been and AI doesn’t change that. If anything, it makes the opposite true. The power of software automation is powerful, I truly believe that, but it can only be harnessed effectively through applying what we know about the craft. The ones who can reason about trade-offs, systems and people will be the ones that will be leveraging this technology to its fullest.

I want this newsletter to be for the people who are in it for the long game and building what the world looks like tomorrow. If that sounds like you, welcome!