The next 10% also takes 90% of the time.

The first 90% of a project is easy, the next 90% is the really hard work, then the final 90% is the difference between a good piece of software and something really worthwhile.

Of course, that's the initial build, 90% of software cost is maintenance.

So I've determined that surgeons output surgery, which is basically just cutting holes in people.

I've invented a new AI turbo surgeon which can cut holes in people faster than ever before, I think it can replace surgeons now.

Anyone who complains is a Luddite scared of their job.

It's becoming extremely obvious to anyone paying attention that writing code faster does not actually improve your ability to make change much at all.

But it might mean some changes that were previously not economic become feasible. Just like any other Dev tools or libraries etc we use.

Tricky word. Not a common letter arrangement.

Make sure to not engage your product expertise until as late as possible too.

You wouldn't want expertise spoiling your requirements specifications.

I grew up not thinking that much about it, and one day someone asked me about if fear of cars affects my riding.

Started to say no, then realised, hell why else am I getting up before 6am and picking quiet routes and avoiding right (your left) turns and...

I'd ride all the time if not for cars.

Holy shit those are some terrifying bike lanes.

Ride between these lines and pray adjacent vehicles show the kind of lane discipline you've never encountered before in your life.

It should 1. Be unnecessary to hold a driver's licence, 2. Challenging to get and hold a driver's licence. 3. Impossible to hold a license to drive if you drive dangerously.

Many years of working in layers up in software abstractions, telling people that no their library is not immune from TCP and network frames stuff.

Everyone is doing distributed systems in packet switching networks and pretending they aren't.

Meow meow meow.

Your colleague pushed a change with a bug that will get them in big trouble if you don't help. But it's 5:30pm.on a Friday already.

Do you...

Caveat, it shouldn't be a possible situation in a healthy organisation.

Yes. We are in the time of pop your little web server on the internet and meta will squash it flat with their stupid robot the moment anyone sees it.

Pay your tithes to CloudFlare or watch your service die.

I agree, but I can also say the internet is a far more hostile and difficult environment to run an application than it was even 5 years ago.

Complexity is outrunning our ability to manage it, probably worse than ever.

Very sad time in life when you first realise that having an excellent product isn't going to automatically get noticed.

I had hopes online platforms would make it better but they made it worse I think. It was easier to take classified ads and get people to mail you for a disk for $5

From an engineering standpoint, you can't really say "bad" without knowing the intention of the design. Maybe it has to be built to a price.

I've sadly been involved in plenty of examples of engineering excellence within commercial failures.

Resilience to failure is a hard choice for systems where money isn't on the line.

You can prioritise other things, if you believe they'll ultimately be more important.

For small orgs though, recovery from failure can cost more than the resilience would have.

Ah, the system works

Really something today.

90% of the time they're angry about some other crap and just looking for someone to have a whinge to.

It's kind of like working in retail or hospitality in that way.

I had a systems architect spend a month trying to find bugs in a parser I wrote because he didn't understand how it could work, and was insisting we shouldn't use it because it'd be hard to debug.

Such an unproductive behaviour to bring to a Dev team! We all have things to learn!

I've spent so long keeping good code review culture going. We talk about the code but it's a peer discussion, no-one is a senior person "approving".

Changes are done by persuasion and consensus not dictated.

The goal is to improve, not to gate.

babe, wake up, new form of mansplaining just dropped

My partner had her eyesight become too poor to drive in her early 20s.

I'm still doing pretty good but fracturing your spine certainly helps you realise it's not a given! It takes only a few seconds for things to change.

Good public transportation is so important.

When I was first riding again after my broken back, I saw a dude on the bike path in a wheelchair being pulled by two dogs like it was a chariot and it was one of the coolest things I've ever seen.

I've been doing a project photographing Australian white Ibis. They have a bad rep and get called bin chickens because they pick through rubbish, but they're cool birds.

If you're just going to ignore what I'm saying, then please go write a fresh post. Clearly not what I said.

I'm aware of these issues and I'm addressing them, but I'm not so naive to think that I can ignore massive trends across the industry from my little niche.

I'm aware of the studies, but there's a lot more depth to read about learning in software teams before you can say that applies to all practices and contexts.

A bigger issue is the obsession with production of code over skills development. Software teams are generally terrible for that.

Your question of "productivity gain", how would I measure that as a manager?

If I can get a project done which I couldn't have afforded/got approved otherwise, that seems pretty good.

If I can do some of the quality improvements that I constantly get pushed to cut from a project, also good.

My experience is that there are specific contexts where you can get good results and save some time.

You can degrade your skills or improve your skills regardless. If you exempt yourself from learning and just become an operator of a code generator, that is going to be much worse.

It's a bit stupid, a lot of how "agents" work with code is generalisation from context, if you let it out trash into your codebase it will generalise more trash.

If you aren't constantly putting it back on the straight and narrow you aren't earning your salary.