@jasongorman@mastodon.cloud
@jasongorman@mastodon.cloud avatar

jasongorman

@jasongorman@mastodon.cloud

Software developer, trainer and mentor at Codemanship. Now run your tests.

This profile is from a federated server and may be incomplete. Browse more on the original instance.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

They say a picture speaks a thousand words

jasongorman,
@jasongorman@mastodon.cloud avatar

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.

jasongorman,
@jasongorman@mastodon.cloud avatar

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

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

6 Ideas That Transformed The Way I Make Software

Day #4 - Separation Of Concerns

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...

(thread)

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

6 Ideas That Transformed The Way I Make Software

Day #3 - Continuous Testing

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.

(thread)

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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.

jasongorman,
@jasongorman@mastodon.cloud avatar

@zl2tod Autonomous teams don't need that, though. They're empowered to say "no", they nurture from within (e.g. mentoring) and engaging with stakeholders outside the team is very much part of The Work 🙂

jasongorman,
@jasongorman@mastodon.cloud avatar

@zl2tod Software developers aren't children

jasongorman,
@jasongorman@mastodon.cloud avatar

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 .

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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)

jasongorman,
@jasongorman@mastodon.cloud avatar

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.

jasongorman,
@jasongorman@mastodon.cloud avatar

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?

jasongorman,
@jasongorman@mastodon.cloud avatar

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.

jasongorman,
@jasongorman@mastodon.cloud avatar

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.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

6 Ideas That Transformed The Way I Make Software

Day #1 - Usage-driven Design

Instead of asking ourselves "What does this system need to do?", a more useful question is "What do our users need to do /using/ the system?"

The user could be a person, or another system, or another class, or another function (or a test, of course).

When we approach design from the user's POV, we're much more likely to end up with the right set of features.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

"Here at Acme Megatech Corp, we empower teams to do their best work. Also, here is the form you need to fill out to get pencils."

ecomba, to random
@ecomba@ruby.social avatar

On related news, if you know of a place in London for my partner, motorbike and myself in London (from the 30th of June till the 7th of July) I’d highly appreciate it! 🙏🏼

jasongorman,
@jasongorman@mastodon.cloud avatar

@thirstybear @ecomba I mean way out, though. Like Norfolk.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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, to random
@jasongorman@mastodon.cloud avatar

TDD doesn't do the design for you.

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.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

Those devs who say "LLMs have 10x my productivity"... I've finally figured out how they do it.

https://chatgpt.com/share/85bf5ca9-dc40-4188-95b8-8545c9e269ab

jasongorman, to random
@jasongorman@mastodon.cloud avatar

If you genuinely believe people get worse at software development the older they get, you're a self-fulfilling prophecy.

jasongorman, to random
@jasongorman@mastodon.cloud avatar

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.

  • All
  • Subscribed
  • Moderated
  • Favorites
  • •
  • JUstTest
  • mdbf
  • ngwrru68w68
  • tester
  • magazineikmin
  • thenastyranch
  • rosin
  • khanakhh
  • InstantRegret
  • Youngstown
  • slotface
  • Durango
  • kavyap
  • DreamBathrooms
  • megavids
  • tacticalgear
  • osvaldo12
  • normalnudes
  • cubers
  • cisconetworking
  • everett
  • GTA5RPClips
  • ethstaker
  • Leos
  • provamag3
  • anitta
  • modclub
  • lostlight
  • All magazines
    •