"Participants were identified via media reports featuring Australian firms trialling the 100:80:100 model, in addition to companies listed on recruitment sites that specialise in 4DWW jobs. In other instances, eligible organisations were recommended by the participants themselves."

I'd expect organisations with positive results will be the ones recommended by other participants - "talk to these people, it worked for them too!"

I'm also interested in whether or not organisations converted all staff to 100:80:100, or if it was optional. Is the performance driven by peer pressure?

Finally, the participants' measures of productivity will have significant lag time in them, so it depends on trial's length, e.g. "revenue", "profit", "csat", "projects delivered on time", "net promoter score".

Table 1 has "Duration", but the units are unlabelled, if it's weeks, it's less than a year, months is probably better for seeing performance changes.

It's an interesting qualitative study, I'd certainly like a four day work week with no change in comp.

This is why businesses should put in the effort and sign up for credit terms. Then it's an invoice, and you reduce this risk substantially.

Credit cards are _not_ reliable at this scale. Banks are offline all the time, cards are marked stolen, protocols change, all sorts of things that will cause flags indicating "the money can't move down that path".

Businesses that pay for AWS/Cloud/etc via credit cards are trying to buy reliability but put it behind a single point of failure.

Credit cards are not how you should be paying for business services with uptime requirements!

Common ways this happens? They are using a credit card to run their business with no backup payment method. Then the company's contact person is on vacation.

Sign up for terms. It will get you payment terms!

That makes reviews a lot easier. The review starts from "nothing should be changing" and then reviewers can pattern match on that.

Otherwise, the reviewer is re-evaluating every line of code to make sure nothing has changed. That's really hard to do properly.

The version control systems I've worked with have allowed queues of changes, each one reviewed independently. As I'm developing, if I need a refactor, I go up a commit, refactor, send out for review, rebase my in progress work and continue.

I send out a continual stream of "CLEANUP:" "REFACTOR_ONLY:", and similar changes with the final change being a lot smaller than a big monster of a change.

Your reviewers will appreciate the effort.

Plays the metric game (if you're working in that type of org) without being evil too.

1) As org size grows, it's the team's average quality that matters (so yes, large numbers).

2) Even with a single team, the velocity will increase to match the acceptable level of quality.

Management will push the accelerator until they get too many bugs, then it will be "we need fewer outages".

So, in an team+environment, you end up with a constant (in time) detection rate, which basically means a constant in time injection rate.

If the teams' velocity increases without increasing quality, the bug injection rate (and detection rate) will increase.

AKA if the AI is slightly worse, but 10x faster, stop carrying the pager. :)

If no one is willing to stand up and say "yes this is safe and of acceptable quality", why use it?

It's a software engineering version of the professional engineering stamp.

Auto-installing random software is the problem. It was a problem when our parents did it, why would it be a good idea for developers to do it?

So, the product vs everything that is needed on the way, but isn’t the core.

CI/CD tooling, template population…. Things you write a use once/use few script for.

I typically end up with a library of tools to deal with repetitive finicky tasks.

The Making of Anastasia (1997):

https://www.youtube.com/watch?v=mWffn2clRGk

To the discussion of live-action reference:

https://youtu.be/mWffn2clRGk?t=941

Don't you need something like a network clock to get deterministic replay?

It can't use immediate return on replay, or else the order will change.

This makes me twitchy. The dependencies should be better modelled, and idempotency used instead of logging and caching.

I regularly have tool-generated commits. I send them out with a reference to the tool, what the process is, how much it's been reviewed and what the expectation is of the reviewer.

Otherwise, they all assume "human authored" and "human sponsored". Reviewers will then send comments (instead of proposing the fix themselves). When you're wrangling several hundred changes, that becomes unworkable.

Consider - it's a voip dialing client which has a requirement to provide location for E911 support.

If the OS vendor starts providing invalid data, it's the OS vendor which ends up being liable for the person's death.

e.g. https://www.cnet.com/home/internet/texas-sues-vonage-over-91...

which is from 2005, but gives you an idea of the liability involved.

The group used feature flags...

    if (a) {
       // new code
    } else {
       // old code
    }

    void testOff() {
       disableFlag(a);
       // test it still works
    }
    
    void testOn() {
        enableFlag(a);
        // test it still works
    }

I can do one flag in ~3minutes. Code edit, pr prepped and sent.

The AI can do one in 10mins, but I couldn't look away. It kept trying to use find/grep to search through a huge repo to find symbols (instead of the MCP service).

Then it ignored instructions and didn't clean up one or the other test, left unused fields or parameters and generally made a mess.

Finally, I needed to review and fix the results, taking another 3-5 minutes, with no guarantee that it compiled.

At that point, a task that takes me 3 minutes has taken me 15.

Sure, it made code changes, and felt "cool", but it cost the company 5x the cost of not using the AI (before considering the token cost).

Even worse, the CI/CD system couldn't keep up the my individual velocity of cleaning these up, using an automated tool? Yeah, not going to be pleasant.

However, I need to try again, everyone's saying there was a step change in December.

Even just taking fault incidence rates, assuming constant injection per dev hour...

open a terminal (OSX/Linux) and type:

    man dup

    man dup

To get recursive, you can try:

    man man unix