One of the earlier references to the 10x that I've found is in

https://www.scribd.com/document/557220119/NNPP-Article

> Researchers have found between a low of 5 to 1 to a high of 100 to 1 ratios in programmer performance. This means that programmers at the same level, with similar backgrounds and comparable salaries, might take 1 to 100 weeks to complete the same tasks. [21, p. 8]

> The ratio of programmer performance that repeatedly appeared in the studies investigated by Bill Curtis in the July/August 1990 issue of American Programmer was 22 to 1. This was both for source lines of code produced and for debugging times - which includes both defect detection rate and defect removal efficiency. [5, pp. 4 - 6] The NNPP also produces a higher instance of defects in the work product. Figure 1 shows the consequences of the NNPPs.

The reference to 21 is Shneiderman, Ben Software Psychology: Human Factors in Computer and Information Systems (Cambridge, MA: Winthrop, 1980) and 5 is Curtis, Bill, "Managing the Real Leverage in Software Productivity and Quality", American Programmer July/August 1990

https://archive.org/details/softwarepsycholo00shne/page/8/mo... - this then goes into an entire book of sources and research.

There's also mention of DeMarco and Lister in some literature... which means Peopleware.

From there:

> While this [10 to 1] productivity differential among programmers is understandable, there is also a 10 to 1 difference in productivity among software organizations.

> H. D. Mills, Software Productivity (New York: Dorset House Publishing, 1988), p. 266.

> Our study found that there were huge differences between the 92 competing organizations. Over the whole sample, the best organization (the one with the best average performance of its representatives) worked more than ten times faster than the worst organization. In addition to their speed, all competitors from the fastest organization developed code that passed the major acceptance test.

> This is more than a little unsettling. Managers for years have affected a certain fatalism about individual differences. They reasoned that the differences were innate, so you couldn’t do much about them. It’s harder to be fatalistic about the clustering effect. Some companies are doing a lot worse than others. Something about their environment and corporate culture is failing to attract and keep good people or is making it impossible for even good people to work effectively.

In one of the book on "10x myth", the author bluntly states that there is no objective way to measure "productivity". So any such report is purely subjective. Its a fascinating argument. I don't remember the book, but this author had actually read the papers while researching and based his conclusion of the research papers

As far is reality is concerned, the differences between average and skilled can be as much as 100x or more. It can be even more if you consider that some people add negative productivity

Agreed. My developers go to eleven.

It means how many Mountain Dews you can chug per day.

Native speaker here: yeah, it's awkward.

It's possible to use a multiplier like "10x" or "5x" as a verb like that, but the object has to be the thing being increased, like "productivity" or "sales". And it's usually best to put a word like "the" or "your" in there to avoid confusing it with the case where you're using 10x as an adjective (like in "10x developer" or "10x growth"). So there are a lot of articles and books and stuff with titles like "how to 10x your wealth" and that's fine, but "AI can 10x developers" both sounds kind of wrong and implies that the AI is hiring more developers onto your team.

for what it's worth, it didn't seem odd to me. I guess the missing article and phrase indicate it's a verb.

"So AI can ... developers" is begging for a verb, there is no room for an adjective there.

It definitely misleads the reader for the reasons you mentioned.

These types of sentences are called garden-path sentences. You can read some typical examples here https://en.wikipedia.org/wiki/Garden-path_sentence#Examples

We’ve invented a machine that can spew a lot of garbage out. Sure, you can sift through it to find the nuggets of gold, but the proponents of this new methodology heavily discount this additional effort. Studies seems to show that at the end of the day the benefits are minimal, despite the claims.

Once again, it is a sign of modern programming that the solution to more problems is throwing more code at it, rather than more upfront thinking that will lead to less code overall. The “work hard, not smart” crowd won this round, I guess.

The best engineer used to be the lazy one [1]. The mental effort of micromanaging a machine by explaining what you need in prose is diametrically opposite to just being lazy, sitting on a hammock, and writing directly the simplest possible solution that requires the least amount of maintenance. But sure, enjoy the 200k line vibe coded ball of mud to run ferrets and gas towns or whatever these guys do all day.

1: before dopaminergic stimulants were as widespread as today.

I have this problem with UX Pilot or Stitch for wireframes that I’ve been working on (from my low-fidelity paper ones to high-fidelity digitals). It takes so many prompts to get the model to do what I want, what’s the point?

UXP costs money, you still pay for the many iterations where it’s their product that did a poor job.

So perhaps with code we’re on the same boat. Since tokens aren’t free, people will stop early/at first working iteration to save money.

They can be both annoying about their policies and correct about technical debt caused by LLMs.

Umm, no. Tech debt is a problem for AIs. You can argue current models have gotten smart enough to work despite it, but you still have the same downsides.