Stack Overflow: How I Work
I wrote a post on Meta Stack Exchange as part of the "How I Work" series. I detail my day-to-day work at Stack Overflow and the challenges we face.
Go to site
The Only Agile Meetings You Need
Some places "do agile" because it's the cool trendy thing that tech companies do nowadays. Their teams are usually mandated to do Scrum, which they take to mean two-week cycles with 2-3 hours of stand-up meetings, maybe 4 hours of refinement, 1-2 hours retro, another hour of sprint planning, another to demo, another higher-level roadmap meeting. That's 10 hours of meetings even before you include all the ones you "took offline".
Stack Overflow Podcast Ep. 589
I talk about my path to software development via text-based RPGs, my work on Stack Overflow’s Community Enablement team, why Agile gets so much hate, and what I've learned giving conference talks to developers.
Site Analytics Without a Cookie Banner
On the way to NDC London this year, I sat on the train and wondered, how many people actually read this blog? It's just a static site hosted by GitHub, so I don't see any numbers on the back end. I needed something that runs in the browser and sends data back to me. Of course, I installed Google Analytics. The problem is...
DDD East Midlands: My First Conference Talk
I wrote a guest post for DDD East Midlands conference blog about my first talk there. I go through the submission process, the build up, and what happened on the big day.
CQRS: What and Why?
CQRS is really simple. Sometimes the idea gets conflated with other concepts such as Event Sourcing and DDD, but that is not CQRS. So, what is it then?
The Building Blocks of Domain-Driven Design
When learning DDD, it's easy for us engineers to get caught up in all the technical jargon: "Aggregate Roots", "Domain Events", etc. Fundamentally though, Domain-Driven design is not about the technical details; it's about creating a model and language that the business experts share with the technical experts (the software engineers). It is, perhaps ironically, about not using technical jargon.
Well-Crafted Software
Great engineers truly care about what it is they're building. Not just the end result, making a customer happy and getting paid. They enjoy the engineering process, they love the tools they use, and they get a kick out of the job itself.
Visualising Software in Shapes
When I think of a software system, I see shapes and lines connecting groups of smaller shapes and smaller lines. Like a galaxy of solar systems with planets of continents, each with roads connecting cities with villages and hamlets. It's a structure that fits related concepts together and hides away complexity at different scales.
Domain Events vs Integration Events
There are different kinds of events found in event-driven systems. They often represent the same thing that has happened, but serve different purposes and have different advantages. Here I'd like to outline the differences between a few terms.
You Don't Need Logging Code
This an opinion I've held for some years now. The title is a little disingenuous. What I actually mean is that business classes should not be concerned with what they need to log. Take this example.
Look, No Controllers
Those that have worked with me will know I'm a big advocate for Aspect-Oriented Programming. I generally like to "bolt on" concerns that sit outside of the main logic using the decorator pattern or some kind of behaviour that can wrap around a class or method, which follows the Open/Closed principle.
Software is about Drawing Boxes
That's what it all comes down to. Not to diminish anyone's long, hardworking career, but every design decision we make ultimately boils down to where we want to define a certain boundary. What concepts should we couple together? Which layers "know of" which? It's all a structure of how thoughts and ideas fit together.
Domain-Driven Boundaries
At its core, Domain-Driven Design is about building shared models as a collaboration between domain experts and technical experts. When engineers speak the same language as the rest of the business, we can build an architecture that aligns with how the business works.
Onion Architecture with DDD and CQRS
A lot of software engineering is about drawing boxes. That is, deciding how to break down the code we write. We don't just write everything in the Main method. We set boundaries, create abstractions, and divide things into single responsibilities.
Open Source CI pipeline for .NET with AppVeyor
Plenty of tools offer free licenses for open source projects. Often they work quite nicely with each other. In this post I'll show how GitHub, AppVeyor, MyGet and CodeCov can work together in a complete CI/CD pipeline.
Core Package Naming Convention
I've noticed a few NuGet packages reference an underlying .Core package from their solution.
Introducing Reflectious
Whilst developing Firestorm, I noticed I was often combining Expression Trees with Reflection code. I'd find a static LINQ method, pass it a lambda expression argument and throw the whole thing into Expression.Call.
Why Firestorm?
Firestorm is a little thing I was working on that turned into a bigger thing I'm still working on a year later. As it grew, it spawned another little thing that'll probably turn into a bigger thing too. Rinse and repeat. Sound familiar?