In yesterday's "6 Ideas" I hinted that designing test suites so the majority run entirely in the same memory address space was a "can of worms". Hand me that can opener...
It took me about 20 minutes to confirm through testing that LLM prompts like "You are the world's greatest Go programmer" make no noticeable difference to the quality of generated code. But still that myth persists.
In yesterday's "6 Ideas", I talk about how releasing software early and often can dramatically reduce lead times for businesses, and - understandably - this is something a lot of businesses really, really want.
This is another of those ideas that seem obvious with hindsight, but in the first couple of years of my career, the majority view really was that we gather the requirements, plan the design, write the code, test the software and then release it - usually on a fixed date we committed to months in advance.
It doesn't take a genius to figure out that just maybe we should ask "Waddaya think?" earlier, and more often.
Instead of gathering all the requirements, doing all the design, writing all the code, and then testing all of it, it makes much more sense - for a student of risk - to gather some of the requirements, do some of the design, write some of the code, and then test that to get user feedback, so we can incorporate what we've LEARNED (in capital letters!) in the next cycle.
And it turns out that much - often most - of the value in software isn't in what we planned, but what we LEARNED from what we planned. So we need to LEARN as early and as often as we can. That's where the gold we're panning for usually lies.
The last 30 years I've been doing software development has been characterized by those user feedback loops getting shorter and shorter. In the mid-90s, my teams would tackle a bunch of usage scenarios, getting feedback every couple of weeks.
One common justification for why development teams need managers is that someone needs to see "the bigger picture", remove organisational obstacles, and broker agreements with other teams.
But in my experience, when I've wanted visibility of the bigger picture, or to remove organisational obstacles, or to reach agreements with other teams, it's been the management getting in the way.
It can be a self-fulfilling prophecy. Teams need managers because they need someone with the access and authority necessary to do these things for them.
And teams don't get that access and authority because that's not in the interests of the people they gave it to .
What I find most interesting isn't the image itself, but that someone selling expert guidance on "prompt engineering" felt it was fine to use it in that context.
A lot of developers are from the "If it's new, I gotta have it!" school. I'm very much from the "If I'm still hearing about it 10 years from now, I'll give it a look" school.
@jasongorman too many young developers sound and act like MBA candidates rather than technically trained experts. It's very frustrating, because many don't understand that the flavour of the day is much less important than knowing what the problem is and how to solve it.
Hexagonal architecture doesn't solve all your architectural problems.
Pair programming doesn't replace all other kinds of knowledge sharing.
Iterative development doesn't remove the need to think ahead.
None of these are valid criticisms of TDD, hexagonal architecture, pair programming or iterative development. Any more than "Yeah, but you still have to decide where to go" is a valid criticism of steering wheels.
It sometimes feels like the last 25 years of progress in software development has just been thinking up cool names for the things we were doing in the previous 25 years.
@jasongorman
So... What if the progress, was working on explaining things to folks that are not you, and standardising + big-fixing what you knew? Would that make you any happier about the low perceived rate-change?
A sci-fi horror like The Three-Body Problem, but called "The Two-Party System", in which the solution to the Fermi Paradox is that technological civilisations vote themselves into annihilation.