Notices by Jason Gorman (jasongorman@mastodon.cloud), page 2

"A.I. won't replace you, but a shareholder who doesn't care about quality will" is what the slogan *should* say.

Burglars say they're building a new tool to enable you to opt out of being burgled https://techcrunch.com/2024/05/07/openai-says-its-building-a-tool-to-let-content-creators-opt-out-of-ai-training/

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.

(thread)

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.

They say a picture speaks a thousand words

It adds weight to my suspicion that the real key to being "productive" with generative transformers is not caring that the output's wrong.

@jbrains The defining tone of my career is being told a decade later "Turns out you were right about..."

Young folk say to me "You old folk don't need as much sleep as us". We really do. We're just not capable of getting it.

So.you have that to look forward to.

Scrolling through my LinkedIn feed - which is 95%+ software folks - I see no mentions at all of end users, their needs or their goals.

And maybe this tends to reinforce the layperson's stereotype of us as a profession.

Users: "We keep losing orders because the system doesn't show up-to-date stock"

Devs: "Tabs or spaces?! Dark theme!!! Kubernetes!!!!!"

Here's the rub: if we don't take an active interest in what our users want or need, someone else will. And we'll end up calling that person "boss".

The problem with Test-Driven Development is that you have to think about what you want the code to do before you write it. And that ruins the surprise.

Systems can only adapt when they have spare capacity. See what happens to the turning arc of a car moving its top speed.

In case you were wondering how your drive for efficiency killed your organisation's adaptive capacity.

Another classic rookie mistake many developers make is seeking permission to do things like writing unit tests and refactoring code when it's needed. https://youtu.be/aCxCEHePepc

Although my maths is off there. It's the remaining 890, of course. But that's not as punchy as a nice round number 🙂

You night conclude that, if you're on a team of 10, there's a pretty good chance that at least one other developer will be competent. But developers tend to cluster by ability. So some teams "corner the market" while for others its a desert out there.

If you interview 1,000 software developers at random (which is probably about the number I have), you discover that maybe 100 of them are competent, and maybe 10 are actually great.

The 100 who are competent tend to know they're not great, and the 10 who are great often believe they're one of the 100, and the remaining 900 often believe they're one of the 10.

Anyway, that's LinkedIn explained.