After 18 months investigating claims that LLMs can do X, or Y or Z, I think - going forward - I'm just going to skip straight to disbelief to save time.
I believe the real product of software development is software development teams; that building software products builds capability to create & adapt software when future needs demand it.
So, to me, outsourcing it's like throwing away the toy and playing with the box.
When I hear developers complaining about a colleague who's a "perfectionist" that is "slowing them down", even just a cursory investigation usually reveals that the team has low standards and that the "perfectionist" keeps trying to raise them.
This is normally when things like "pragmatic" and "just get it done" get bandied about to try and make it sound as if the developers who've been checking in untested code are the real professionals in this set-up.
@alcinnz I watched a "tutorial" on how to build your own version of Zoom recently. Not a single word about video streaming. Half an hour about start-ups, MVPs etc.
The way software development's shifted from people wanting to do it better to people wanting to get rich reminds me of how contemporary music schools shifted from people wanting to get better at making music to people wanting to get famous.
There's a real X Factor feel to the common discourse, with lots of folks obsessing over levels of commercial success they're never going to experience - too busy preparing for hypothetical stadium tours to learn scales.
If 99% of developers have little to no refactoring skills, then it should come as no surprise that most engineering managers have never seen refactoring in action.
This is important to bear in mind when they tell you that you have to plan for future possible use cases in your design. They assume that significant changes won't be possible.
The fun starts when the dumpster chicken it's procuring for you is chicken that was output by older dumpster chicken recycling engines. Until what you're eating really isn't chicken at all.
Copying and pasting code off the Interwebs is like eating chicken you found in a dumpster. Automating the procurement of dumpster chicken through LLMs might not be the productivity boon some people think it is.
6 Ideas That Transformed The Way I Make Software ------------------------------------------------
Day #2- Iterative & Incremental Delivery
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 wasn't unheard of to be so far out of the ballpark that it ended up being abandoned. Just too much work. Quite often design decisions taken months earlier got baked in by all the code we added since.
That final frantic "stabilisation" phase was typically characterised by very frequent user feedback. Okay, we fixed that bug. Waddaya think? Okay, we moved that column. Waddaya think?
Sounds great, doesn't it? All lovely and simple and predictable (and businesses *loooove* predictable). There's just one small problem: it's bollocks.
Even on what seemed like relatively straightforward systems, when the software was put in front of customers and end users, we'd get an avalanche of feedback about what was wrong with it. So there'd be a frantic phase of change requests and bug fixes to try and get the software into the ballpark of usable.
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.
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.