I have been iterating on Event Sourcing and CQRS architectures for nearly a decade. When I first started with this pattern around 2016 and 2017, the implementation was considerably more complex — a lot of ceremony, a lot of infrastructure, and a lot of things that could go wrong. Over the years I have stripped it back again and again, and what I have arrived at now is something I'm genuinely happy with: a small, focused TypeScript library backed by DynamoDB that does exactly what it needs to and nothing more.

The code is available at github.com/coderbyheart/aws-dynamodb-es-cqrs.

What ES+CQRS gives you

The core idea is simple: instead of storing the current state of a thing, you store the sequence of events that produced that state. Event Sourcing (ES) is the "store events" part. CQRS (Command Query Responsibility Segregation) is the recognition that writing and reading are fundamentally different concerns that benefit from being handled separately.

In practice this means that when someone publishes a blog post, you don't update a published = true column. You append a BlogPostPublished event to the event log. The current state — the aggregate — is derived by replaying those events. This gives you a full audit trail for free, the ability to rebuild projections, and a natural boundary for business logic.

The anatomy of an event

Every event in the system is an AggregateEvent. The type is intentionally minimal:

export type AggregateEvent = {
  eventId: ULID;
  eventName: string;
  aggregateName: string;
  aggregateId: ULID;
  aggregateVersion: AggregateVersion;
  actorId: string;
};

A few things worth noting here. eventId and aggregateId use ULIDs — universally unique, lexicographically sortable identifiers. This means events stored in DynamoDB are naturally ordered by creation time without needing a separate timestamp index. aggregateVersion is an incrementing integer that starts at 1 and tracks how many events have been applied to a given aggregate. actorId records who or what triggered the event.

Domain events extend this base type and add their own payload fields. A BlogPostCreatedEvent, for example, adds title and whatever else the domain needs.

Reducing events to state

The event sourcing half of the pattern lives in reduceEvents. It takes an applyEvent function and returns a function that folds a list of events into an aggregate:

export const reduceEvents =
  <A extends Record<string, any> & { $meta: AggregateMeta }>(
    applyEvent: ApplyEventFn<A>,
  ): ApplyEventsFn<A> =>
  (events: Array<AggregateEvent>, aggregate?: A) => {
    if (events.length === 0) throw new Error("No events to reduce!");
    return events.reduce<A | undefined>((agg, event) => {
      const result = applyEvent(event, agg);
      if (result === undefined)
        throw new Error(
          `Unhandled event: ${event.eventName} (aggregateVersion: ${event.aggregateVersion})`,
        );
      return result;
    }, aggregate) as A;
  };

The domain-specific reducer wires this together. The blog post reducer handles three events — created, published, and title changed — using typed event guards (isNamedEvent) and assertions (assertAggregateEvent) to make the TypeScript types precise:

export const blogpostReducer = reduceEvents<BlogPostAggregate>(
  (event, aggregate) => {
    if (isBlogPostCreatedEvent(event)) {
      return {
        $meta: fromEvent(event),
        authorId: event.actorId,
        title: event.title,
      };
    }
    if (isBlogPostPublishedEvent(event)) {
      assertAggregateEvent(aggregate, event);
      return {
        ...aggregate,
        $meta: updateFromEvent(aggregate.$meta, event),
        isPublic: true,
      };
    }
    if (isBlogPostTitleChangedEvent(event)) {
      assertAggregateEvent(aggregate, event);
      return {
        ...aggregate,
        $meta: updateFromEvent(aggregate.$meta, event),
        title: event.title,
      };
    }
    return undefined;
  },
);

The assertAggregateEvent call on the update and publish handlers is doing something important: it verifies that an aggregate already exists before trying to apply a state-changing event. You cannot publish a blog post that was never created.

Commands: the write side

Commands live on the write side of the CQRS split. They are plain async functions that take some input and a persistence function, validate preconditions against the current aggregate state, produce an event, apply it through the reducer, persist both the resulting aggregate and the event, and return the updated aggregate.

Here is what creating a blog post looks like:

export const createBlogPostCommand =
  (
    persistBlogPost: PersistBlogPostFn,
    reducer: ApplyEventsFn<BlogPostAggregate>,
  ) =>
  async (
    data: Omit<BlogPostAggregate, "$meta" | "authorId">,
    actorId: string,
  ): Promise<BlogPostAggregate> => {
    const id = ulid() as ULID;
    const event: BlogPostCreatedEvent = {
      eventId: ulid() as ULID,
      eventName: EventNames.BlogPostCreated,
      aggregateName: AggregateNames.BlogPost,
      aggregateId: id,
      aggregateVersion: v1,
      actorId,
      ...data,
    };
    const applied = reducer([event]);
    await persistBlogPost(applied, event);
    return applied;
  };

The reducer is injected alongside the persist function rather than imported directly. This keeps commands decoupled from any specific reducer implementation and makes them straightforward to test in isolation. A command for updating an existing aggregate (like publishBlogPostCommand) follows the same pattern: inject both the persist function and the reducer, load the current state, verify preconditions, produce a new event at the next version. Concurrency conflicts are detected at the persistence layer using optimistic locking, so you get a ConflictError if two commands race on the same aggregate.

Persistence: one transaction, two tables

The most interesting part of this design is the persistence layer. Everything happens in a single DynamoDB TransactWriteItems call that touches two tables atomically:

1. The aggregate table is upserted with an optimistic concurrency check. For a new aggregate, the condition is attribute_not_exists(aggregateId). For an update, it is #version = :prevVersion. If either condition fails, DynamoDB cancels the whole transaction and the application surfaces a conflict error.

2. The events table receives a new Put item containing the full event payload, plus a derived eventTs (an ISO timestamp decoded from the ULID) for convenience.

The error handling checks cancellation reasons across both transaction slots — a DuplicateItem on the events table (index 1) is just as meaningful as a ConditionalCheckFailed on the aggregate (index 0), and both produce an actionable error rather than a raw SDK exception:

await db.send(
  new TransactWriteItemsCommand({
    TransactItems: [
      { Update: toUpdate(aggregate, aggregateTableName) },
      {
        Put: {
          TableName: eventsTableName,
          Item: marshall(
            {
              ...event,
              eventTs: new Date(decodeTime(event.eventId)).toISOString(),
            },
            { removeUndefinedValues: true },
          ),
        },
      },
    ],
  }),
);
// ...
if (err instanceof TransactionCanceledException) {
  if (err.CancellationReasons?.[0]?.Code === "ConditionalCheckFailed") {
    throw new Error(
      `Failed to persist "${aggregate.$meta.id}" due to version conflict!`,
    );
  }
  if (
    err.CancellationReasons?.[0]?.Code === "DuplicateItem" ||
    err.CancellationReasons?.[1]?.Code === "DuplicateItem"
  ) {
    throw new Error(
      `Failed to persist "${aggregate.$meta.id}" due to duplicate item!`,
    );
  }
}

Because the aggregate and the event are written in one transaction, they are always in sync. You never end up in a state where an event was recorded but the aggregate was not updated, or vice versa.

The read side

Queries are entirely separate from commands — that is the whole point of the CQR split. The read side has two shapes:

Current state — fetch the latest aggregate projection directly from the aggregate table. Because persistDynamoDB keeps the aggregate table current on every write, reads are a simple GetItem or Query against a well-known key schema. No event replay needed at query time.

Event stream — use listAggregateEventsDynamoDB to retrieve all events for a given aggregate in order. This is useful for rebuilding projections, feeding downstream consumers, or debugging. DynamoDB Streams integration is also covered: extractEventsFromDynamoDBEvent parses stream records back into typed AggregateEvent objects so they can be forwarded to Lambda functions or other processors.

What makes this simpler than the 2016 version

The earlier versions of this pattern wrote the event to the event store first, then relied on a separate asynchronous step — typically a DynamoDB Stream feeding a Lambda — to update the aggregate projection. This worked, but it created three problems that I kept having to work around.

The first was a window of inconsistency. Between the moment an event was written and the moment the Lambda finished updating the aggregate, the two stores were out of sync. In practice this window was small, but it was real. If the Lambda failed — a cold start timeout, a throttle, a transient DynamoDB error — the aggregate could end up permanently behind the event log. You needed dead-letter queues, retry logic, and monitoring to catch and recover from these failures.

The second was latency on the read side. Because the aggregate projection was updated asynchronously, a caller that wrote an event and immediately read back the aggregate might get stale data. You had to either accept eventual consistency or build compensating logic to handle it.

The third was CDK infrastructure overhead. Every aggregate needed a Stream enabled on its events table, a Lambda to consume it, an event source mapping, IAM roles, a DLQ, and CloudWatch alarms. This was not a huge amount of code, but it added up and it was all load-bearing — getting any of it wrong meant silent data loss.

The current approach sidesteps all of this with a single TransactWriteItems call. The event and the aggregate projection are written atomically. Either both succeed or neither does. There is no async gap, no eventual consistency on the write path, and no extra CDK constructs to manage. The aggregate table is always in sync with the event store by construction.

The tradeoff is that you give up the ability to fan out to multiple projections in the same write path — but in practice I have found that DynamoDB Streams off the events table is still the right mechanism for that, and you can add it when you actually need it rather than building it upfront for every aggregate.

The full source, including a working test suite that runs against DynamoDB Local, is at github.com/coderbyheart/aws-dynamodb-es-cqrs. The package is also published to npm as @coderbyheart/aws-dynamodb-es-cqrs if you want to use it directly.

tl;dr LLMs are excellent at scaffolding code that follows an existing pattern. They are not equipped to design new domain concepts. When you let one do design work, you get code that looks right, tests that pass, and an implementation that quietly misses the point. Worse: you own none of the understanding, so when something breaks, you're debugging a library you didn't write.

When all the tests are green but the implementation is wrong, you have a problem. And you have made that problem yourself.

This week I introduced a new concept into an existing billing system. We currently bill on a per-project basis. The new requirement was to introduce organizations: an organization owns multiple projects, and instead of one invoice per project, the organization owner gets a single consolidated invoice.

Same billing rules. Same pricing logic. Just applied to a higher-level entity.

The existing implementation was well-tested and solid. This looked like a perfect LLM task: the pattern is established, the tests are clear, the scope is bounded. I asked the LLM to introduce the organization concept, told it to look at the existing tests, and make it work for an organization owning multiple projects.

The initial results were promising. New modules, new method names, new test files, good coverage. There was a small bit of hand-holding needed around how we identify organizations—they use a different ID format than projects—but overall it looked like a win.

Then I started wiring the new domain logic into the actual consumers, and the cracks appeared.

The tests were lying

The issues were not dramatic. No obvious failures. They were subtle—quiet mismatches between what the tests assumed and what the business actually required. I went back to the domain implementation to fix something. Then again. Then again. Four times in total.

A concrete example: our billing has a minimum charge rule. If your total monthly usage comes to less than $2.00, you still pay $2.00.

In the per-project billing, this is simple: sum the usage, apply the rate, check against the floor. The LLM ported this rule to the organization level by applying it per project. Three projects using $0.10 each would result in a $6.00 bill instead of $2.00, because each project individually hits the minimum.

The minimum charge belongs on the organization invoice—the thing the customer actually pays—not on each individual project. But the concept of the invoice was implicit in the per-project implementation. It was just the natural unit. At the organization level it becomes a derived concept, only meaningful after summing across all projects. The LLM didn't understand that this rule needed to be lifted to a higher abstraction level. It only saw the mechanics: here is a rule, apply it at each step.

The tests didn't catch this because the generated test data wasn't adversarial. Two projects, charges above the minimum, everything sums correctly—all green. The discrepancy only surfaced when I ran real customer usage data through both the old and new implementations side by side.

Debugging code you didn't write

What I underestimated is the cost of not having written the code yourself.

Every time I hit a bug I was in the position of debugging a third-party library I didn't write and don't fully understand. I'd look at the symptom, form a hypothesis, and ask the LLM for a targeted fix—without truly grasping whether that fix would hold in other situations. This is the console.log debugging mode: poking at the surface, observing behavior, inferring structure. Slow, fragile, and deeply unsatisfying.

A feedback loop makes it worse: each fix feels small. Just change this one thing, then it will work. So you keep delegating back to the LLM. But the LLM can only act on what you describe. It doesn't understand your goal—it understands your instruction. It will dutifully add a parameter, loop over projects, apply the calculation, and miss the point entirely.

Scaffolding vs. design

The mistake was misclassifying the task.

There are things LLMs are excellent at in an existing codebase. Scaffolding a new REST route that follows the same pattern as the 25 others in the project? Perfect. Generate the handler, the CDK construct, wire it into the existing infrastructure. The output is obviously correct by inspection because the pattern is unambiguous.

Introducing a new domain concept that changes how the entire billing model is structured is a design task. It requires understanding intent. It requires knowing which implicit assumptions need to become explicit, which rules belong at which level of abstraction, what the code is for—not just what it does.

LLMs can replicate structure. They cannot reason about intent.

What I should have done

Written it myself.

Not because the LLM couldn't produce working-looking code—it clearly could. But because the process of writing domain logic is how you discover the domain. The resistance you feel when you try to implement a rule at the wrong abstraction level, the moment you realize the minimum charge can't live on the project anymore—those are discoveries that only happen when you are making the decisions.

By outsourcing the implementation, I outsourced the understanding. And understanding is not optional when things go wrong.

The LLM saved me roughly two hours of initial implementation and cost me several times that in confused debugging and rework. The irony is that the task that looked most suited to LLM delegation—structured, well-precedented, bounded— turned out to require exactly the kind of judgment LLMs don't have.

Use an LLM to follow a pattern. Don't use it to design one.

Error messages are the only piece of documentation you can be sure people will read when it is relevant. Write them accordingly.
— Beth Andres-Beck

Use RFC 7807 "Problem Detail" to document API errors.

Bad

class UserManager {
  async createUser(email) {
    const id = await this.userRepo.insert(email);
    await this.upgradeAccount(id, "trial");
    await this.sendConfirmationEmail(email);
    await this.notifySlack(`Woot! ${email} has registered`);
  }
}

The UserManager does too many things and needs to know all these dependencies. There is no clear limit to what could be added there in the future, that needs to be done when a user is created. This can increase the runtime of this one method further and further and couples systems that not need to be coupled.

Good

Instead have all methods that change the state of the system only do exactly on operation and use Events to have other components get notified. This enables to run these secondary operations in a separate process and even in an environment which is better suited for them.

class UserManager {
  async createUser(email) {
    const id = await this.userRepo.insert(email);
    this.eventBus.publish("UserCreatedEvent", { id, email });
  }
}

class TransactionalMailer {
  construct(eventBus) {
    eventBus.on("UserCreated", (name, { email }) =>
      this.sendConfirmationEmail(email),
    );
  }
}

This is enabled by implementing the system using Event Sourcing.

Reviewers might not have an in-depth understanding of how things relate to each other in a project so do not mix conceptually different changes in one PR.

Some examples of what not to do:

• fix a bug AND update all dependencies. If a bug fix requires a new dependency or an update to one, then only add this single dependency change.
• implement a new feature AND fix a small bug on an unrelated file. Those should be two PRs.

Bad

if (condition) {
  doWork();
} else {
  throw Error("Condition not met!");
}

Good

if (!condition) {
  throw Error("Condition not met!");
}
doWork();

Stop nesting promises

Another example:

Bad

getData((a) => {
  getMoreData(a, (b) => {
    getMoreData(b, (c) => {
      getMoreData(c, (d) => {
        getMoreData(d, (e) => {
          console.log(e);
        });
      });
    });
  });
});

Better

getData()
  .then((a) => getMoreData(a))
  .then((b) => getMoreData(b))
  .then((c) => getMoreData(c))
  .then((d) => getMoreData(d))
  .then((e) => console.log(e));

Even better

const a = await getData();
const b = await getMoreData(a);
const c = await getMoreData(b);
const d = await getMoreData(c);
const e = await getMoreData(d);
console.log(e);

While some consider rebasing to be an act of destroying the true history of a software project, I think this is doing actually the opposite.

What matters in terms of history is that we preserve the time when a set of changes became effective for the rest of the team. As long as a change is in an isolated branch on which only one developer works on, it cannot produce bugs for others (developers or users) thus it did not have the chance yet to make history so to speak.

By rebasing a PR against the main branch just before merging it will tell the real story: the changes will appear in this branch in the order they became active and this accurately reflects the time when others were made aware of these changes and also the time from when to entire codebase needed to deal with the changes introduced by them.

Squash merging

Once a PR is done and has been approved, I like to squash all commits into one commit with a good and concise explanation. That one commit should ideally look like the PR itself: a PR on GitHub has a title and a decription, which explains the motivation for the change and lists what needs to be done (simple future). Turning this into a commit means telling the story of what the commit now does (in present tense).

I consider squashing a PR into one commit to main an even better way to contribute changes to the main branch. I often have man small commits in a PR, which add tests, implement features, refactor. Having all these in the main branch does not really help other developers to quickly get the high-level summary of a change.

Cleaning up your commits for a PR

This does not mean that all PRs should only have one commit (although they rarely should have many) it makes reviewing a PR easier if all the commits in a PR are condensed down to a set of distinct commit messages, even if they get squashed when being merged anyway. See this as an opportunity to describe to the reviewer what you did when implementing the change. It also enables a reviewer to view changes in a bigger PR with a context specific to a commit.

Re-tell the story of your PR

Creating a clean set of distinct commits in a PR requires that atomic commits were made in the first place. It's a good habit while developing to commit early and commit often: create many small commits, which you then later can combine into bigger ones. A great helper to achieve this is using git add -p, which will go through all current unstaged changes and let you decide which changed segment in a file to stage. git add -p allows you to create multiple commits from a situation where you have applied different changes while developing (a new feature here, but also a bug fix, and maybe some formatting, or changes to the CI configuration).

Tip: when incorporating PR feedback into these commits, git-absorb can help with that.

What if you have unrelated changes in the same commit

You might encounter a situation where you accidentally combined unrelated changes in one commit. There is a way to split up these commits, but there is no reverse version of squash, it has to be done manually. See the Splitting a commit section in the official Git documentation. Here again, when in rebase, git add -p is your friend.

Resources

• https://git-scm.com/book/en/v2/Git-Tools-Rewriting-History
• https://dev.to/maxwell_dev/the-git-rebase-introduction-i-wish-id-had
• https://gist.github.com/mattlewissf/9958704

Yes, you can solve it also with a well maintained .gitignore file that covers everything in all projects but this can get quite extensive to cover all cases.

I consider it noise if entries are in the .gitignore that have no relation to the specific project: I want a clean .gitignore file.

Maintaining a global .gitignore file for your personal setup also has the advantage that it affects all existing and future projects on your machine, thus eliminating the possibility of accidentally committing those files. Otherwise you would need to remember to add your IDE files to EVERY projects .gitignore.

Additionally, changes to the .gitignore of a project are not free: they trigger CI runs, releases, reviews. Having people constantly add their favourite rules creates noise. I don't want that.

Having a huge catch-all .gitignore is no solution either, it will only cover known files. Additions trigger noise.

Adding files to a git repository is a deliberate action, if developers add files that do not belong to a feature or change they need to be better educated about it. If this is done, an accident-preventing-gitignore is no longer needed.

Good example

dist/
node_modules/

Bad example

.idea
.vscode
.DS_Store

Tip

Have a local folder to put your crap in which won't get accidentally committed

This hides dependencies to configuration values and makes them hard to spot.

Bad

class Foo {
  doSomething() {
    console.log(process.env.MY_ENV);
  }
}

new Foo().doSomething();

Good

class Foo {
  constructor(myEnv) {
    this.myEnv = myEnv;
  }
  doSomething() {
    console.log(this.myEnv);
  }
}

new Foo(process.env.MY_ENV).doSomething();

All code style guides must be enforceable by tools

The best way to handle it is to fix all fixable errors using lint-staged and Prettier. That way developers won't even notice. Good IDEs are able to apply prettier style guides automatically even during editing.

How to change the default git branch

Note: The master terminology in Git is historically tied to the master/slave metaphor and not the master copy one, see https://github.com/github/renaming

myMethod(arg1, arg2, arg3);

Good

myMethod({ arg1, arg2, arg3 });

Reasons

• this removes the Connascence of Position (CoP) because the order of arguments becomes irrelevant
• arguments to methods can easier be created programmatically

Watch out for

• removing support for currying

For developers who come from classic, instance-based architectures, working with serverless is a huge paradigm shift. It's not natural, nor obvious. In this blog post I am sharing the current set of material I give to colleagues who want to learn the idiomatic way of building serverless.

The basics

There are some fundamentals when building scalable web services, which apply both in instance-based and serverless architectures.

REST in practice is a must read.

The Twelve-Factor App provides important design aspects for web services in general, but this applies very well to serverless applications.

In my talk Serverless Architecture for IoT on AWS I explains the benefits of serverless in general in why it is especially suitable for IoT applications. I provide an introduction to serverless in general, and how it is implemented at the different cloud vendors (looking at AWS and Azure, where I have implemented the same application using the respective cloud's idiomatic way), and why it is especially relevant for IoT deployments.

Learning AWS serverless

Of course, always check the official AWS resources on AWS Lambda:

• Best practices for working with AWS Lambda functions
• AWS Lambda blog

For training my colleagues I have used the AWS Dev Hour: Building Modern Applications training, with the added challenge of writing tests for it. My colleague Lena Kråkevik Haraldseid has a talk about her learnings from this exercise: Testing serverless applications.

The recently released book Serverless Development on AWS offers a great way to learn more about the potential of the serverless paradigm and the mindset shift needed to tap its full potential. It’s a must read for every developer that works with AWS because more and more powerful services on AWS are built from the ground up as serverless offering.

Testing

One of the challenges when building serverless applications is testing. You are building on the shoulder of giants, and are using services that no longer run on your (CI) machine. In my talk It does not run on my machine: Integration testing a cloud-native application I take you through the challenge of testing a cloud-native application. I cover the challenges when developing solutions on top of serverless components which you cannot run on your own machine and how I designed a BDD driven approach to run the integration tests.

Here is AWS' best practice on testing Lambda: How to test serverless functions and applications.

Reference projects I have built

It's always best to look at actual code, so these are the open-source projects that are available which I have worked on:

• https://github.com/hello-nrfcloud/backend
• https://github.com/hello-nrfcloud/map-backend
• https://github.com/NordicSemiconductor/asset-tracker-cloud-aws-js
• https://github.com/NordicPlayground/thingy-rocks-cloud-aws-js
• https://github.com/teamstatus/aws-backend

I was first paid to write software in 1997, now 27 years ago, and if there is one skill that had the biggest impact on my career then it’s the ability to deliver working software that doesn’t break. This allows me to take vacation, invest back into my communities and initiatives that I want to support, self-development, and to have time for self-, and family care.

In this talk I want to reinforce your love for software quality by sharing how I helps me in my day to day work where I balance my efforts between too many projects but still manage to be both and innovative software engineer, and deliver solutions that do not break when it matters most through setting up all projects and teams that I work with around one main principle: push-to-deploy.

In order to achieve this, confidence is needed, which can only manifest if we know that our changes will not break the system. And in an environment that becomes more and more uncertain and volatile every day, there is only one solution that has stood the test of time: writing tests first. And its beauty, especially with outside-in-test-driven-development, is that it helps to keep the focus on delivering value to the end-user. Over the last years I have added Behavior-driven development to my quality toolbox because it decouples the implementation of the tests from the implementation of the application. Testing through the public API of a system ensures that there are no unexpected changes for the user.

As I will share, I have a strict focus on user stories when building our products, because it is the only way that ensures that all stakeholders can participate and contribute to a product. Because in the end a successful software is always built in collaboration with people who contribute source-code and those who contribute in other ways.

Enabling the collaboration of all stakeholders is a very important part of my job, and I have been able to achieve this through using a walking skeleton approach: delivering working minimal products from the first day. This way developers like me can make sure to be involved in the discussion with product people and customers early on in a projects' life-cycle. And in my experience only the real product (and not even a click dummy) will truly create shared understanding with all stakeholders. Because time is always short and we know that every prototype ends up in production we have to make sure that even our prototypes are of high quality; which is where using quality in software development to achieve continuous delivery (CD) with confidence - really shine.

The slides are available here.

Video transcript

Thanks for joining me in this talk.

I can be here because software quality is the story of my professional career.

And given this is the 10th edition of New Crafts, I thought it would be time to remind you why we do what we do as crafters.

My story goes back till 2012 when I became a crafter, but now I have colleagues who could be my kids if I had them.

Like they're in their early twenties and they, they study, or they become juniors and they are the next generation of software engineers.

And we as crafters need to think again like, why are we doing this?

And we need to explain this.

And this is, this is what I would like to share with you.

This is a talk that is very personal, so not everything that is in there might apply to you, so keep that in mind.

But I hope you can take away a few things in there.

So, a little bit about me.

I am an R&D research and design engineer from, Nordic.

I work on cloud stuff, at the semiconductor company.

So my company makes money selling chips that connects your smartphone to your headphones, the pencil on this fruity tablet that you have or tracks the medical the pharmaceutical products that you need, and, and allow that to happen.

I work in Norway.

I'm not the only one from Norway.

I hear we have two more speakers from Norway, so I'm pretty proud of that.

You can find all my links on coderbyheart.com/socials.

The slides, I've shared them on my Mastodon profile in case you want to follow the links or whatever, but you can reach me there.

So first let's recap a bit.

What is push to deploy?

Push to deploy means:

when I do a change on the thing that I'm working on and I committed to my versioning system, probably Git in most of the cases, and then I push it, meaning I push it to the, to the server, make it available to, to everybody in the team.

So I push it from my local computer to the source code repository that we use as a company.

But then from there, it should trigger the chain, your pipeline, your flow, that puts it in front of the real customer.

And it's not the test system or it's not your colleagues, it's actually whatever makes you money.

So it can be, if you are software as a service, it could be your website that it shows up there, or, if you're shipping, software to other of your collaborators, your customers, then it arrives there and they can use it.

So this is really important fact that we, we want to optimize for this.

And this is, when I, when I talk about push-to-deploy, this is what I mean. Deploy is not just is it running somewhere, but is it used by the end user?

And there is a fantastic book, I hope all of you have read it.

If not, this is a reminder to read Accelerate because, the first half of this book explains why push-to-deploy is so amazing.

And then the second part is it actually shows the proof how they figured it out.

The scientific background, the methodology they used, is explained.

So A, if you want to convince somebody, you can prove that the numbers in there are correct, and B, you can apply this methodology in your company as well to test and figure out and learn more on how to get code faster into production.

Push-to-deploy is kind of a mantra for me.

There are so many principles out there that we learn as crafters.

We get some of the very outdated ones.

S.O.L.I.D., we get, maybe, I dunno, TDD, is kind of a principle, that we learn or inside-out-testing, outside-in-testing, Domain Driven Design, like all of these are many concepts that are very good.

But for me, I feel that over my experience over the last years, it's really that, focusing on this thing, getting the code out there as fast as possible, applies in any domain that I've worked on.

I now work in IoT, but I've worked in FinTech, I've worked in the gaming industry, I've worked in in advertising, in marketing.

So kind of everywhere this would and will still apply.

So it's a universal thing, principle, and it's really easy to remember what to do, how to get there is the hard part, however.

So why do I want it?

What does it give me?

It's not because I get surprises from it, it's to deal with surprises.

And I think we understand now since like maybe the last five years, this is more or less common, is that we live in a volatile world.

Everybody went through the pandemic.

That was probably the call for the globe that nothing can be predicted anymore.

Until before that we had some financial crisis.

We had 9/11, we had some of these Black Swan events that nobody could predict.

And even if you can predict them, then you don't know what effect they will have.

And that makes them really dangerous.

But the overall learning is that it's completely futile to do any planning, any long-term planning that goes beyond maybe this week we don't know what's gonna happen next week.

You have surprises everywhere.

Like you get surprises if you build a product for your customer.

Your customer last week said, I want this button on the left side.

And then they get the new Chief Marketing Officer and they say, no, I want it on the right side.

Here's money. Make it happen. I don't care.

So, and you can tell, but last week you told us left side, and now you're telling right side, and yes, fine, I'm the customer, I'm paying. Surprise change.

And you can, and we heard here, sometimes you need to push back and say, no, that's not right.

But sometimes it's just like that.

They want it, it makes sense. They change their business.

So we need to follow their decisions or they will pick another vendor.

Surprise success is, is great to have, but can come at a surprise.

You build something which is kind of ahhh ... it's gonna be a cool prototype.

Let's see how that works.

And then like two weeks later you learn oh, this is the main showcase at the trade show that is happening in Barcelona.

That happened to me, more than once.

When nobody tells you oh ... your stuff is gonna be used in that way, but it's just this because it works.

We all got that surprise delays.

I can go on endlessly.

I can't avoid surprises.

But I need my team and my solutions that I work on be ready to deal with these surprises.

And that's were pushed-to-deploy really enables me to do this. Because, anytime I have this cycle,

I make a change, I put it in front of the customer, I put it in front of my team, I put it in front of my stakeholders.

And by the way, over the lifetime of your product, your customer will change.

If you start a new project, in the first day, you are your customer because you want to see that it runs in, in the cloud and that kind of the bootstrapping works and that you have all the pipelines in place, then you are the customer.

Then next week you're showing the product to your product manager and to your team.

Then they are your customers. And then this changes over time.

But the idea is the same.

The people that give you money, that give you power that you need to agree on what you're doing, that basically grant you the freedom to keep working on this project.

These are your customers and you, every time you put it in front of them, you get feedback.

I list some features that I get from these fast feedback cycles.

Really if you've been following Thierry a bit he's here on this conference as well.

He has really, really elaborate and very good ran about why, feature branches are evil.

And if we do push-to-deploy, meaning we all commit to production code and there is, at any given moment in time, we can release our software to the wild.

There are no feature branches.

That also means there are no longstanding conflicts where you have a long living branch and then you, you kind of don't put it in production, but you put it off and then you come back and then you need to merge everything together to get it to work.

Don't do this. It will save you a lot of work.

And, it will also not block others if they depend on your work.

Just finish your work.

"Just" an evil, very evil word.

Just finish your work.

Get it in production then everybody else can depend on what you've done.

Of course, that just finish your work means we need to kind of slice our work smaller and smaller iterations so we can basically drop whatever you're working on.

When I work not on any project, basically on any project, if somebody comes to me and says, Markus, I need this.

I am prepared for this because, again, I can't predict if they say, is this important?

Of course we assume, let's assume just they have a good point why they want me to do this.

Then I'm able to drop what I'm working on maybe within one, two hours.

I don't need it immediate, but I can finish what I'm working on, finish, write my test, put it in, push it, release it, maybe put it behind a feature flag, but it's out there.

I can drop it, I can get my mind off it.

I don't need to remind my colleagues, "Hey, I'm still working on this."

"Please wait. Or please rebase your branch against it."

What, whatever. I push it out, it's done.

I can shift my focus.

And with a lot of surprises,

shifting focus happens constantly.

There's unfortunately, a big learning in my career is: you cannot avoid these surprises.

I tried it many years ago. It didn't work out.

Reiterating it a bit, unfortunately, the surprises also come from many things that you don't like.

There are positive surprises, but very often there are unfortunate surprises.

So we want to be, and we need to be in this constant loop where shit's fucked.

Meaning like you have technical depth that you need to change in order to get this new feature, or there's a new feature that you don't want to do, but you have to do it.

And then yes, we need to change it.

And sometimes this means we need to completely change our architecture.

Alberto said this so good in his previous talk.

If you haven't been here, please watch it.

We can only make decisions based on the knowledge we have now.

But we cannot limit the future capabilities of our systems based on the past knowledge.

We learn new stuff, we learn that there is new value to be created and we need to go where we can create this value.

And that sometimes unfortunately means we need to change everything.

So we need to fuck shit up, so we can find it out.

So we can find it out. This loop.

The faster this loop is, the more we learn, the less painful it becomes.

The pain will never go away.

It will always be painful.

There will always be this phase, "Oh my God, not again."

"It's fucked again." But we can get out of it.

So we get this good end of feelings of okay, customer's happy, we changed something.

My colleague is happy. It is on a trade show.

Oh, there's good, PR about it.

My marketing colleagues are happy. Hmm.

That gives me then the motivation.

The next time when somebody comes to me with, "Hey Markus, can we change this?"

I'm like: "I hate you for it, but yes, of course we can."

What we need in order to be able to push-to-deploy however, that is where the craft comes in.

The plain process of I push code and it goes online.

Well, that's that there's no magic.

Like you pack whatever your artifact is of your source code and put it on a server, and then user does a request and hopefully it works.

And of course we want to eliminate this "hopefully".

We want to be certain that it works.

And the only way to get to this point is to write tests.

There, there is no way to do this manually.

You cannot do manual testing.

If you have a high velocity, if you release, change your production multiple times a day, there is no chance in the world that you get good manual tests.

Well, you can pay for it, but it, it doesn't make sense.

It economically doesn't make sense.

So you need automated tests.

This will give you the certainty that, okay, the change that I'm now making, that's usually where you have a high confidence because this is the, the small part in your code where you just work on, you have all the things in mind.

"Okay? It's touching this database here, this is working."

Where you probably can get away with little tests, to make sure it works because you also just tested it.

The problem is all the other stuff out there in your system that you completely oblivious to that it even exists.

Maybe it's not like you've never touched it, you've never seen it.

If there are no tests there, but you kind of change something here, then this will break the system.

So we need good tests over the entire system to make sure that even small changes, we don't accidentally break something.

We also write, of course tests, for ourselves.

Even I have to drop something, I would, very often then if I'm not finished with the the feature I'm working on, write a failing test or a skipped test that says, okay, I want like this thing to work like this, put it in a test, commit it, it will be there, it will be marked as skipped.

But the next time I pick it up, I can go back to this test because this test, and I design outside-in and this test will tell me: "Hey, this is kind of the thing", "that the user wants to do."

And then, okay, alright, I remember, okay, now I know what to kind of implement under the hood to get it to work.

And of course, like this is the fight we constantly have as crafters, who believe in testing is the people who are not there, yet.

Who kind of know it's good, but it's too much effort.

This is our job to make it easy for them to follow us.

We can't just say: "Oh, let's go there.", "This mountain is not so high as it looks like it's kind of, it's fine." "You will be fine." No, we have to go ahead. We need to lead with good example. We sometimes even need to make the path there.

Because getting started is really, really hard.

The thing at the side here, yes, of course, don't have too many tests. Especially when we start with TDD, we start making, building a lot of tests.

And then at some point we have many tests that cover the same feature or are no longer really useful.

Remember to delete your tests.

Because this will remove cognitive load from everybody who's coming in later and trying to understand what is essentially happening here or have like a giant file that tests all the variants here.

Maybe it's not super useful for them to understand it.

And this is where we come to the vacation part.

I'm now not working, on code.

I'm here on stage and on this conference.

If I have well-tested code, I can even be productive while I'm doing nothing.

So, here's an example from my inbox.

This is like Thursday, Friday, Saturday, Sunday.

So while I'm not working, I'm still producing value respectively, not I, but the code base that I created is covered in a lot of tests that I can deal with the messy state that the JavaScript ecosystem is in, where we get dependency updates every hour.

And if you want your code base to not be outdated, you basically need to deal with this in an automated way.

And having a well tested code base means if a new dependency changes, a test will be run, it will be checked that it works.

And if it works, we bump the dependency and release an new version to production. we get automated security updates.

We get new, not new features because we don't use the new features, but maybe we get performance improvements.

And the best thing is, if I get back from vacation, I did three weeks vacation now, I come back to a code base with basically no new PRs.

Nobody needs to take care of maybe stuff that piles up while I'm away on some of my projects where not more people are working on it.

Again this mindset push-to-deploy, means a bot, AI, hello, a bot can create a commit.

It gets automatically verified. Is it good?

And if yes, then fine.

I talked about this principle where, I can save the work that I'm working on and I save the intended user feature.

That was a hint on, what I think is for me, really the best way to approach this, push-to-deploy and the fast feedback cycle is using outside-in TDD.

Very, very simply explained.

If we talk about writing tests we have a calculator and we have a function that adds two numbers, or we have a calculator, it's the product, I want a calculator.

So I can implement my calculator and the test for it by really starting to implement all the features.

Like I have an add function and I write a test for it.

I have a subtract function, I have a root function.

And then so I build all these small things that a calculator should be doing.

"Oh, let's pull in modulo. What else do I have?"

I need to deal with rendering maybe exponential numbers, how to display floats, whatever.

Like I can spend a lot of time on testing all the components and then I pull these together into bigger components.

But since everything is covered under here, this goes very fast then.

But I can spend a lot of time in the depth of some obscure feature that I might be needing to test it.

Where outside-in TDD is really taking from the beginning the perspective of the user.

It's not deconstructing the calculator into its small components, but it's saying:

"Hey, as a user, I want to add two numbers.

Then you have the calculator and say, given two numbers, I expect the sum.

You have a user story already and you get clarity from your stakeholders.

Okay, this is what we want.

None of your stakeholders said they want to do modulo.

Nobody says they want fractions.

Maybe you will never need it.

So when, when you use outside-in TDD you really focus on the features and you only do that.

And this is really, really helpful to, to make sure that you only implement the necessary stuff.

However, that means there is, there will be some maybe shortcuts or not like super optimizations for any kind of use case that will lead you later to do more refactoring.

But then at least we know that the refactoring is needed.

Like in the beginning, I have a calculator which has the add implemented, just in the main function.

And if I have 20 different operations I probably want to refactor this in into smaller modules, so it's easier to compose, but maybe I never need this.

The ultimate hint for you and what to really look into, I think is, Behavior Driven Design, which really takes this to an extreme that it decouples the testing, the language the tests are written in, from the actual implementation.

And BDD takes a step that it moves your basically description of what the thing does.

There is a user who has a calculator and then they input two numbers and they get a sum out of it.

They put this in like written plain English text.

And now when you have a plain English text, you need something that runs this against your system.

But the cool part is that regardless of what you do here, you can change everything in your implementation.

You can change the language, you can change from Python to JavaScript. You can change from Java to whatever this file here with your test.

That will not change.

And there's a really beauty in it that it preserves your intended behavior of your system in a state that is not affected by any refactoring.

And I've seen this so often that when you start refactoring and removing stuff, you start uncommenting tests and maybe delete them, maybe move them around.

You forget to turn them on or add them back.

And that can happen. Where if you have a BDD feature, it will not.

So that is really an important, way to capture the behavior of a system in a way that's also understood by all stakeholders.

I know that's a myth that with BDD, I can go to my product manager, and say: "Hey, let's write a BDD scenario together."

That's not true.

I don't think many people have managed this, but at least like they can, if I give it to them and say: "Hey, this is what my system does," "it takes two numbers and gives out a sum" they can understand it.

They don't get scared by some syntax, by curly braces.

And they are willing to read this.

And also new people who come in a team, they can start browsing through that without needing to dig through your source code system to figure out what's actually happening in which unit test is relevant.

I can talk forever about BDD.

It's also amazing because it groups together features or or implementation into things that a user would do.

A good example is that, you very often see, you have a, a storage class, a repository implementation that can store stuff.

And often it's really stuff because it's generic, it's not a book storage because you don't need that.

Technically, a database can store anything.

So your database repository adapter will also store anything.

And that's not helpful. Like the user is not using a repository, the user is using your website.

And then they have a list where they can add features.

So, and if you have a feature that connects this part of your source code to this feature, you know exactly when and where it's used.

That was just a glimpse of where like this explodes in complexity of how to test, why to test, what to use, what technology to use, which approaches to use.

And, the unfortunate truth is that, it is extremely hard to get started.

The effort it takes, like when there are no examples in your source code base, is insane.

And it's super frustrating.

And then over time, the more examples you have, it gets easier.

I'd say that at some point, like if you have too many examples, it might even go up, because then your test suit gets too long, the runtime gets too long, whatever.

But that's unfortunately the truth.

And that's what I said before, like, we need to be good at giving examples and be a good example.

So how do we get there? How do we become good?

I know I want to test and I was in, in many times in a situation where I came back from a conference, heard about this testing is cool, and then at work nobody writes tests.

And this has worked for me in my career very well.

The 20% rule, which basically means if I have a new project or I have an existing project, but I want to learn something new where this could work.

So for instance, I want to try out event sourcing. I know I have kind of, we have never done this before to, to make events the main source of truth for our system.

We just use MySQL and do updates.

That's fine, but I really want to try it.

So I would then risk it.

That's the truth.

Like 20% means of the deliverable, like using event sourcing is maybe 20% of the features.

And if I figure out at some point "okay, it won't work" "it is the wrong decision" I still can go back and rip it out and use the old approach.

You can do this for everything you have 20% of your time you can always carve it out because you have, after some point of time, you have enough knowledge on how to build a system, and very often you repeat stuff.

So try to introduce some experiment even in your own code, you might learn with it.

And if it fails, well, you take a weekend and implement it the old way.

And this can even work as a team.

You need a commitment to that, but there is room for it. the next thing is and this is a thing that worked well for me, but the gist in here is that we become good by learning not everything.

We need to find the things that work for you.

And that's, that's okay. You can't know anything.

It's just too much. But learn some of the techniques that serve you well, and go deep on them because the truth is there is not one thing how to implement anything.

There is always another way to do it.

And so the same with testing.

I said outside-in is great.

There are enough people and example that say no inside-out is the only way to go.

And we both are right. We get good systems.

It's just for some of you, it the one way works the other way maybe doesn't.

I talked about end-to-end testing.

Push-to-deploy also depends on one of these ideas here. Reproducible builds. You need to learn how to package software in a way that you can kind of repeat it, repetitive, deploy it.

If you learn this by the way, you go into scalability.

I put RegEx on here because for me, RegEx allows easy refactoring.

I can using RegEx, do a lot of refactoring.

I personally, I don't use refactoring tools in IDEs.

I too often change IDEs.

I was forced to use Vim when I was in my early companies.

So I came from a path where I didn't have IDEs in the beginning.

So I know how to clone hundreds of repositories and do changes across many repositories at the same time using RegEx because I also am not afraid of code duplication.

Another thing here, code duplication is not a bad thing.

It allows you to quickly iterate.

I don't need to make code reusable so I can apply it with all the like, perfectly designed APIs in multiple projects.

There's no value in it.

It only becomes a problem if you have bigger code bases that reuse the same piece of code that has the same bugs, but then well, you still can use RegEx to find it and fix it.

This is where craft really comes in.

One of the ideas is that we have is that, we try to understand the tools that exist, keep an open mind, that's really important.

What is out there? Have a look at it, do these experiments, but really find the tools that work well for you because only then also can you explain it to your team?

Why are you doing this? Why are we doing code duplication here and why not here?

How can I deal with tests when I can't run the system, on my computer and to end testing?

Awesome. So this is, we need to have a discussion with our younger colleagues on really not on a level "This is how I do it.", "So you have to do it!" but I need to enable them to understand why we're doing this also because they might find a better way and then can tell me, Hey, there's a new way to do it.

One thing I would really like to reinforce is that, testing as in test driven development, is a universal skill.

Meaning if you invest in this, this will be useful for your entire career.

Like it works in, in all languages.

It works in embedded, it works in high level languages.

There's no programming language that can work without tests.

So all of them can work without tests, but there is no language that is perfect because tests are not for the language.

Tests are for your assumption.

Tests encode your business knowledge and the requirements that you have.

Yes, you might write some tests that your data is stored correctly in the database or the integration against an API works, but mainly tests serve as a documentation.

That's why I put this blue reminder here.

Don't test your language features.

If you have a feature that calls some functions and you have, for example, TypeScript, like I see this very often in, in lambda functions like a Lambda function pulls in some collaborators and then passes in an event to another collaborator.

I don't write tests for lambda functions, which they are very kind of your, the C and MVC and model view controller.

I don't write tests for the controller.

If I have TypeScript, which then ensures that I can call my collaborators with the right parameters and everything typed, the input is validated.

So there's no point in like doing language tests.

We can only do this fast iteration if we start owning our own infrastructure.

I've never seen it work well with a DevOps or an ops team, which you hand over stuff over the big wall and say: "Hey, please run this for me."

And then you just ship them new features and they are responsible for running it.

They're responsible for performance, for migration, for whatever you need.

Unfortunately, I think that's the truth.

You need to learn more about how to run the things that you're building.

And the way to do it is, of course, going in the cloud, going serverless, or learning about, deploying infrastructure, using Kubernetes or whatever works for you.

For me, serverless worked very well.

But one of the like big, big important decisive, books for me to learn and start learning more about it was, REST in practice.

That's the top one. It is really a fantastic book.

The main idea is like, how can we build systems that work when everybody failed to build these systems?

The only system we know that really works well for billions of people for the last 35 years is the internet.

And the internet is built on very simple principles. HTTP requests, status codes and systems are broken all of the time.

So if you keep that in mind, if that's your mode of, how you design your system, everything fails all the time.

How to deal with that. This book tells you how to use that, as a way to design your architecture, and it leads you natively towards a microservice architecture.

And you can use this and apply this many different contexts.

And if you then go a bit more into the serverless route, then definitely start reading. the new book that just came out a few months ago, serverless Development in AWS fantastic introduction.

I'm such a big fan of serverless also because I work a lot in IoT.

In IoT we have this a problem that is made for serverless where we have millions of devices which connect to your server.

You can't predict it.

It needs to scale.

You can't have one machine that deals with these requests.

There's a long talk, by me about why this is such a great match. many systems have properties where serverless is really a good application.

You should invest a bit of time into it.

Now we are close to the end of my time, so I want to finish with what I said in the beginning.

You need the support system outside of work because very often you're alone in a company, and you're the only one who's pushing this forward.

My journey basically as a crafter was really, really, really supported by the outside support, not within my company,

but it's really, there's a big community out there that can help you.

And by the way, no, there are no certificates, like softwarecrafter certification is a scam.

But you can go to my website and get a certificate.

I give them out for free if you want it, but it's a scam.

So the solution, of course is you are already here.

So you did the first step.

You went to, to a conference, to connect with others.

And this is the, I think the only way that really worked.

And if you start digging a bit into the software crafters community, then you will find there's many resources.

Advocate internally, if you're at the point and you need to grow the others,

I said that before, you need to be an advocate, a good example, but the inspiration for that, and many have the same problem, that you want to push a topic and you don't know how is, to go to external communities.

We have a nice website, software craft communities worldwide, softwarecrafters.org, where we list communities all around the world.

NewCraft is part of this network.

There are other conferences, like I really love the Friends of Good Software conference, was from a testcraftCamp.nl

Now it's, it's more on, software quality, really great communitie, it is virtual, you can participate here virtually.

This is really cool. Organize your own, I organize a few conferences.

I organized Codefreeze in Northern Finland, come there, 80 people, a lot of snow, Aurora, Sauna, and maybe a bit software craft talks.

One thing that really has helped me, and this no longer exists, but I just put it up here as an example

I also created my own peer groups.

I think, some people call these mastermind circles where you just reach out to people from other organizations.

And for me, this was a time where I was a CTO in startups in Frankfurt.

That's why #TechLeadsFFM, that's the region.

And I reached out to other CTOs, from startups, and, we started creating this circle, where meeting as a group, like 15 people.

And then we would have one-on-ones.

And everybody was really thankful that this existed.

It takes really little effort.

So reaching out to a few people, finding a coworking space where you can hang out with a few beers and do this once every two months.

But the important part is that you kind of connect with others and start sharing your things and the problems that you have, because everybody has these problems.

And of course, what I'm doing now is also part of getting better at my craft.

Because when I stand in front of people, this trains your skill to voice what's important for you.

And I really invite all of you.

I don't want to be on this stage, don't want to see more people like me, white English speaking dudes from Norway, or from Europe.

I want to see more diversity on conferences.

And unfortunately, it's a giant problem.

So please take the courage and apply.

And the first thing you need

to do is just write an abstract.

You don't need a presentation.

You just need four sentences and three takeaways, and that's it.

Submit it to a conference like NewCrafts.

And if they take you, then you have to make the presentation.

I made a video about this, like how simple it is.

And if you want to write an abstract, I will help you.

We need to get more.

I've been doing this too long, so there need to be more people who are doing this.

Not so long as I am.

But it's a way, of course, I get to go to the speaker's room, I get to meet amazing other speakers.

I can just chat to them and learn about stuff.

And get the insight that will, again, help me improve my skills.

It's, it's really invaluable.

So I will be closing with

What's the point of this?

I talked about push-to-deploy, we are learning, we need this skill.

And I'd like to reiterate why do we want to be good at what we are doing?

And basically, Alberto said it before in the talk, we can't just put shit in front of our customers.

Everything we do needs to be very good.

If it's a good idea, shitty executed.

If it's the most amazing screen design, but the response time is 15 seconds before the page loads, nobody's gotta see this amazing idea.

They will be gone.

The craft itself it's not an end to itself.

We support business ideas with our craft and through us, we are the conduits that take the business idea.

And, I might not agree with all of them, but I don't have the data to say to them: "Hey, this idea is really shitty."

I need to treat any idea that's coming to me fairly, give it my best to put it in front of the user and let the user decide if this idea is shitty, because they are paying my salary, not I.

So that really is why we need to be good at what we are doing to give any idea that is out there, a good chance to survive and maybe to be the surprise success we have been preparing for.

Thank you very much.

I can fully recommend the book for developers who are starting to work more with serverless but as well for technical managers who want a better understanding of the potential of the serverless paradigm and the mindset shift needed to tap its full potential. It’s a must read for every developer that works with AWS because more and more powerful services on AWS are built from the ground up as serverless offering. Making the most of them will be a skill that takes time to master, and this book will provide you with many well explained shortcuts.

For a more seasoned serverless engineer the book is still valuable, especially since you want it in your bookshelf to give to colleagues. Especially chapter 2 (“Enterprise Readiness for Serverless”) is a great resource that discusses the value of serverless as an innovation and value creation enabler which is supported by a great interview with David Anderson.

This chapter also discusses the serverless mindset, which is a distinctly different approach to architecting solutions compared to instance-based architectures. Adopting this mindset is both hard to achieve and complicated, so this chapter does a great job of highlighting the different aspects that serverless solution designers need to conquer.

The highlight of the book is certainly the third one (“Software Architecture for building serverless microservices”) which does a very good job of explaining how to design efficient serverless architectures and the important role events are playing. If you are familiar with event-based systems this might not surprise you: after all, serverless works well if all services are loosely coupled and all efficient architectures are designed with this in mind. This is a good reminder to check out my reading guide of REST in Practice, which still applies to these kinds of architectures.

The implementation of these architectural concepts is then described in chapter five (“Serverless implementation patterns”) and I really liked that they invested a good portion of it to describe strategies on how to deal with third-party services … because the reality is that not everything runs smoothly within AWS. In my day to day job, nearly every feature deals with some kind of third party API. Dealing with those APIs failing gracefully is an important aspect of any implementation. The chapter provides good examples of how to actually solve this.

In this and the following chapter seven (“Implementing serverless applications”) we find good tips on structuring and deploying applications and how to use the serverless platform as an event flow engine so the code you write can focus on implementing the business domain logic.

It’s an important learning that utilizing flow control features like EventBus and StepFunctions will yield better observability and unlock resilience features like automated retries that otherwise would need to be implemented in software.

Of course, chapter 7 (“Testing serverless applications”) was a must read for me, given that I have spoken extensively about my approach on conferences. The chapter explains very well the compromises that have to be made when testing a serverless architecture. The promoted approach is: unit-test your business logic implementation, and add end-to-end tests for the business-critical paths. This way you ensure that the implementation is correct and the solution once deployed does what it is supposed to do. This aligns very well with my experience, so it was nice to read in the chapter’s interview with Sarah Hamilton how an expert approaches this topic.

Don’t skip chapter 8 (“Operating serverless”) because it provides a good introduction to monitoring serverless solutions and shows that it’s quite easy to get started with building monitoring for your solutions.

Overall I really liked the interviews that conclude every chapter, because they add more flesh to the sometimes very technical concepts discussed in the chapters and help to support what was discussed in the preceding chapters.

You can buy “Serverless Development on AWS” on Amazon.

It uses the Nordic nRF9160 as a habit tracker in a 12 sided enclosure and connects to AWS IoT.

In the talk I speak about:

• design considerations
• how to separate work between three teams
• make sure the project is aligned with the user's goals
• how end-to-end tests support integration between teams

https://www.youtube.com/embed/4dxdToouAI8

https://www.youtube.com/embed/FlTWph4At6o

collect project status updates asynchronously and distributed to speed up your sync meetings

I am happy to announce a side-project that I’ve been working on for a while, and which I have been using daily since its inception.

Use teamstatus.space to track what you are working on, as it happens. It may be small updates, or big releases.

Status updates are associated with projects, which belong to organizations.

You can invite coworkers to the projects you are working on. They then can also add their own status to the project.

Team members can see status, and add reactions. They are an important tool to share praise 🌟, but also prepare the next sync meeting. Status can be marked as significant 🚀, so they will be highlighted in the next sync. Or a status can be marked as a question 🙋 so they can be discussed during the sync.

And when it's time for a sync meeting with your collaborators, you create a new sync which collects all the status updates from the projects your meeting is about, from all the collaborators and a time frame you can specify.

This way you do not have to remember all the big and small things that happened since your last sync with this team; or the other group of stakeholders you only meet every other week.

And since you can share what happened in advance, you can spend your time during the meeting to discuss the highlights and the open question which ensures that everyone's time is used most efficiently.

This project is in an early stage and I am interested to hear your feedback, especially whether this is a tool you would use yourself. As a thank you for your input you’ll be able to keep using the tool without charge with all paid features, if and when this turns into a paid service.

I’ve created a self-guided onboarding flow which will guide you through the features, so just head over to https://teamstatus.space to sign up. I’m happy to receive your feedback on a channel that you prefer, but I want to dog-food it, so please use the $teamstatus#feedback project for your feedback.

In my talk Exploring better ways to write tests that I gave at this year's Nordic Testing Days 2023 in Tallinn, I discussed my journey from feeling dissatisfied with testing tools to creating my own test runner. My goal of this talk was to inspire others to explore and customize their tools rather than settling for the default options available.

For quite some time I have been working on cloud-based software system for IoT devices. Initially, I used Gherkin for writing tests, but I encountered limitations in expressing complex scenarios, dependencies, and handling eventual consistency in cloud-based services. Let me explain how I began using Gherkin and describe its format and keywords (given, when, then).

Facing challenges with Gherkin for my specific needs, I ran into issues with expressing dependencies between features, directly embedding JSON in feature files, managing eventual consistency problems, and dealing with context-dependent scenarios. I also realized that I needed better documentation beyond just tests. To address these issues, I decided to build my own custom test runner, a process that took me three years to develop. The key improvement was adopting Markdown for better formatting, hierarchical structure, code blocks, and comments. I introduced the "soon" keyword to handle eventual consistency in tests. Additionally, I utilized GitHub actions to summarize test results in a more user-friendly format.

I also talked about the struggles I faced with architecture diagrams and their maintenance. Auto-generated diagrams fell short, prompting me to explore the concept of using test traces and observability to dynamically generate architecture diagrams based on test runs. This approach would allow for more focused and informative diagrams linked directly to actual usage.

In conclusion, I encouraged others to create tools tailored to their own needs. I believe that developing personalized solutions can significantly enhance efficiency and understanding in both testing and development workflows.

https://www.youtube.com/embed/dZX7SbGOGn4

The slides are available at bit.ly/better-test-tools.

You can read up about my impression under the hashtag #NTD2023.