Software Engineer
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".
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.
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...
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 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?
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
I've noticed a few NuGet packages reference an underlying .Core package from their solution.
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.
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?