Tag
13 related posts.
We picked practices by weighing cost against benefit, and AI has changed both sides of the scale. A tour of which practices get cheaper, which feed the model's context and tools, and where to be careful.
Complexity feeds on our decisions, and we make the biggest ones when we know the least. Some real examples of keeping it in check, from a stream on top of SQL Server to an outbox in a 20-year-old legacy system.
Testing is about confidence and money, not dogma. Know the whole spectrum of techniques so you can pick the ones your context needs, from where your tests start to golden masters on legacy code.
Most team knowledge travels by word of mouth, and that doesn't scale. Techniques for writing it down without burying the team in documents, from the README to ADRs, incident reports, Event Storming, and tests that check your conventions.
The small recipes I keep coming back to when doing TDD, from naming tests like business scenarios to building test data and keeping database tests fast.
Legacy software that still pays the bills is a lucky thing to have. Where the pain comes from, why rewriting is rarely the answer, and three anti-corruption layer strategies for growing new software around the old.
Using an object-oriented language doesn't mean we're doing object-oriented programming. The common ways we get it wrong, where they come from, and what I keep in mind to avoid them.
We hold conversations with our code all the time, from the folder structure to the logs in production and the commit history. A tour of where those conversations go wrong, and why business naming matters in all of them.
Why software architecture should be a skill the whole team practices rather than a role reserved for one architect, using the rogue from AD&D 2nd edition as an analogy.
How, what, and with whom to learn once your career has started, from Shuhari and an overflowing cup of tea to mentors, kindred spirits, and choosing the right company.
Leaving the code a little better with every story and bug fix beats piling up technical debt, plus some thoughts on simple design and the cost of undoing.
From "extreme" programming to freelance to Software Craftsmanship, arguing about loaded words instead of practices gets us nowhere, so give useful feedback instead.
After a year on a project that pairs a lot, my take on what pair programming does well, what makes it hard, and when it's worth it.