blatherings on software…
My goal with this post is to propose a model for structuring .NET monoliths in a modular fashion that both keeps distribution complexity low whilst at the same time keeping options for distribution in the future, open!
In this final part I will share my experiences with custom instructions and custom prompts for refactoring and bug fixing
Since my first post on agentic refactoring and having attended O’Reilly Coding With AI seminar, I have learnt about a couple of techniques (more like still learning to get good at them), that have improved the results I have had with agentic coding somewhat
Last week I attended the O’Reilly “Coding With AI – The End of Software Development As We Know It”…so in this quick post I will share my bullet point takeaways, ideas and lessons from that event
I have been reading, hearing a lot about how AI/vibe coding will make software engineers obsolete and that agentic coding is like magic…so I decided to give agentic refactoring a shot
I wanted to reflect on and share my experience and learnings from big picture event storming sessions. Hopefully it will be helpful for others as well, but if there are tips and tricks I am missing please feel free to leave a comment or two
In part 1 I talked about the key aspects of my TDD practice from a workflow pov, in this final part I will talk about the more tricky aspects of TDD – scope and design.
Having recently completed several weeks of pairing with a junior engineer on one of my teams, I came away with some reflections on the practice of TDD and its effect on design that I want to share.
I will attempt to define each element of the style a bit and also show some C# code examples to illustrate the points
In this post, I will share my experiences leveraging Domain Driven Design strategies and Team Topologies to reorganise two product engineering teams in the Purchasing domain at Coolblue (one of the largest e-commerce companies in the Netherlands).
In this final part, I will review the current domain model, explore alternatives and make some model improvements keeping in mind the outcome of the design level event storm. Finally I will end with some DDD takeaways that should be applicable generally
A practice in domain (re)modeling using my pet project, guided by strategic and tactical DDD patterns.
Artineering 