Andrew Poole
Senior Backend Engineer @ Flagstone, ex-ClearBank
Street, United Kingdom
Actions
Andrew Poole has been writing code for a living for 15+ years, most recently as an L5 Senior Software Engineer at ClearBank since 2020. He loves solving problems, design and architecture, communicating ideas and the incredible creativity of software engineering. He’s interested in event sourcing, immutable architecture and distributed systems. He also enjoy mentoring others and building great team culture. He has previously been a successful team lead, but what really drives him is striving to write elegant, intentional code which is easy to understand and maintain. He absolutely loves C# and only really dabbles in other languages in order to write better C#. Outside of work Andrew is a husband and father of 2 who enjoys playing bass guitar and making things in his shed.
Area of Expertise
Topics
Fluent Method Chaining in C# and creating super clear orchestration code!
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
Keep calm and carry on? Navigating difficult times as a software engineer
I've been a software engineer for quite a while now, I'm a senior, I'm not an industry leader or anyone special, but I have worked for several organisations and been through enough difficult periods in my career to have collected some stories and learned some lessons. There are several things I'd tell my younger self if I could, but I can't, so I'm sharing them in this talk instead!
My stories are:
* stepping up: a period of time when our team lost its product owner, business analyst and had no scrum master/agile delivery person, how we really self organised and experienced great success.
* stepping back: a period of time off sick and a phased return to work following very difficult circumstances at home
* stepping in: several times I've had to speak up for people who felt they had no voice
* stepping away: deciding to switch team/domain after 2 years worth of development, complete with heart and soul poured in was scrapped due to issues getting various business functions to agree
* also re-orgs/re-structuring - no-one tells you about these sometimes devastating but depressingly common events!
This is a new talk, the target audience would be software engineers, especially those towards the start of their careers.
How to fall in love with automated tests!
This session is in two parts:
1) How to get the maximum mileage from a minimal number of tests - end-to-end component tests
2) Integration Tests - how to not hate them and also sort out your local dev experience!
Part 1 Introduces, explains and demonstrates an approach to automated testing which covers as much of the surface area of your codebase as possible.
Imagine a unit test where the 'unit' is actually multiple executables! A single test can cover the whole happy path flow of a complex piece of orchestration, from API handlers, service bus handlers, database calls etc all in-memory, fast and with a nice fluent developer experience!
Because everything including the Program.cs and startup code are covered we can spot configuration and IoC issues which are hard to test with more traditional methods. I include a method of mocking and asserting against Azure Service Bus
Part 2 discusses the usual issues with integration tests and how they expose the issues with running an app locally. It shows some strategies for fixing some of those issues and actually making integration tests useful, mainly leaving the thing you are testing in a running state on your machine. This is a achieved by means of a script to set up local configuration without having to remember not to check env secrets into appsettings.dev files. Also using Fixtures which do things like setting up queues, topics and subscriptions.
The aim of both parts of this talk is to have a repo which when pulled down onto a fresh machine, builds first time, component tests pass first time, then having run the script and the app, the the integration tests pass first time, after which you can push F5 and have it all run with almost no time or effort!
This talk is two shorter talks in one. There will be slides, code and demos.
Leeds Sharp
What if there was a way to declaratively describe a chain or flow of methods, especially async methods, which could be used when handling API requests or messages from a queue or anywhere actually? What if that flow of methods was self-documenting and understandable at a glance?
Recently, while refactoring a growing piece of business logic, my team and I found a way to achieve this. My talk tells the story of that refactoring journey. It is a mixture of slides and live coding demos in Visual Studio, where I show that the flows of chained methods are easy to read, navigate, debug and test. We end up with orchestration code which describes a whole system or vertical slice and, with some care, is even readable by product owners and business analysts!
.Net Cardiff
Kevlin Henney will be exploring the evolution of programming languages. By looking back at the past, Kevlin will examine how current trends, from FOSS to LLMs, will shape programming languages and their use in the future.
Andrew Poole shares his valuable insights into declaratively describing a chain or flow of async methods, which can then be used when handling API requests or messages from a service bus queue or actually anywhere.
dotnet York
Fluent Method Chaining in C# with Andrew Poole
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
dotnetsheff
Fluent Method Chaining in C#
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug. The flows are self documenting and with some thought, even readable by product owners and business analysts etc.
DDD South West 2024 Sessionize Event
.net London Meetup
Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
.net Edinburgh
Andrew Poole: Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
Cheltenham and Gloucester Tech Meetup
Andrew Poole: Async method chaining in C# => super clear orchestration code
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere?
Recently, while refactoring a growing piece of business logic, Andrew found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
Developer South Coast Meetup
Async Method Chaining in C# with Andrew Poole
What if there was a way to declaratively describe a chain or flow of async methods, which could be used when handling API requests or messages from a service bus queue or actually anywhere? Recently, while refactoring a growing piece of business logic, we found a way to achieve this. The logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is very easy to understand, navigate and debug.
.net southwest meetup
Async method chaining in C# by Andrew Poole, lead software engineer at Clearbank
What if there was a way to declaratively describe a chain or flow of async methods, which can be used when handling API requests or when handling Messages from a service bus queue (or in fact anywhere!) We have found a way to achieve this and the logical conclusion is that related flows can be described in one place, in a single piece of orchestration, which is extremely clear and easy to navigate and debug.
Please note that Sessionize is not responsible for the accuracy or validity of the data provided by speakers. If you suspect this profile to be fake or spam, please let us know.
Jump to top