Bill Atkinson...who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
...He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2,000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.
Baumol's cost disease (or the Baumol effect) is the rise of salaries in jobs that have experienced no or low increase of labor productivity, in response to rising salaries in other jobs that have experienced higher labor productivity growth.
The rise of wages in jobs without productivity gains derives from the requirement to compete for employees with jobs that have experienced gains and so can naturally pay higher salaries, just as classical economics predicts. For instance, if the retail sector pays its managers 19th-century-style salaries, the managers may decide to quit to get a job at an automobile factory, where salaries are higher because of high labor productivity. Thus, managers' salaries are increased not by labor productivity increases in the retail sector but by productivity and corresponding wage increases in other industries.
There are three variants of procrastination, depending on what you do instead of working on something: you could work on (a) nothing, (b) something less important, or (c) something more important. That last type, I'd argue, is good procrastination.
That's the "absent-minded professor," who forgets to shave, or eat, or even perhaps look where he's going while he's thinking about some interesting question. His mind is absent from the everyday world because it's hard at work in another.
"Always produce" is also a heuristic for finding the work you love. If you subject yourself to that constraint, it will automatically push you away from things you think you're supposed to work on, toward things you actually like. "Always produce" will discover your life's work the way water, with the aid of gravity, finds the hole in your roof.
One thing I've been enjoying about working as a technical writer is that the minute-by-minute texture of the work feels right. Something about formatting text, faffing about with SVGs, trying to rewrite a sentence more clearly... it's just enjoyable in itself, and I feel at home with it.
...Working as a programmer was very much not like that. There's something in the rough vicinity of professional dev work that I do like, which I could probably label as 'iterative hobbyist tinkering with websites'. I like working on something with a strong visual component, and I like to be inside of a fast feedback loop, and I'm mostly interested in just somehow bodging through until it works. I'm not very interested in either the computer-sciencey side of programming — data structures, algorithms — or the software-engineerey side of making things run reliably at scale in a maintainable way. So maybe it's not surprising that the minute-by-minute texture of professional programming was just... kind of bad. Occasional fun bits when I got into something, but the background experience was not fun.
Many of us have come to expect work to involve no slack time because of the negative way we perceive it. In a world of manic efficiency, slack often comes across as laziness or a lack of initiative. Without slack time, however, we know we won’t be able to get through new tasks straight away, and if someone insists we should, we have to drop whatever we were previously doing. One way or another, something gets delayed. The increase in busyness may well be futile.
The central goal of Slow Productivity is to keep an individual worker’s volume at a sustainable level. A natural fear is that by reducing the amount of work each employee tackles at any given time, it might reduce the total amount of work an organization is able to complete, making it less competitive. This fear is unfounded. As argued, when an individual’s work volume increases, so does the accompanying overhead and stress, reducing both the time remaining to actually execute the tasks and the quality of the results. If you instead enable the individual to work more sequentially, focussing on a small number of things at a time, waiting until she is done before bringing on new obligations, the rate at which she completes tasks might actually increase.
Forget 10×. With a focus on outcomes and an eye towards the border between net-positive and net-negative work, any team can push their productivity beyond their previous limits.
...If you can perform one task better than most people, you might be a 10× designer or developer or product manager (or whatever you are). But if your team can find small ways to make many of their tasks net-positive, 10× is just the start.
In his course Being Productive: Simple Steps to Calm Focus, Kourosh Dini emphasises the importance of taking a moment to “be with” the work every day (or however frequently you need to tackle a project). “Being with” your work is to be fully present and intentional about that activity and doing nothing else.
This idea was inspired by Dini’s piano teacher, who encouraged him to sit at his piano and touch the keys every day. Even on the days that he felt he had no time or inclination to practice. Sometimes touching the keys would lead to a good practice session, even when he didn’t feel like it would before he actually gave it a go.
Just like Dini, I find that once I give the task my full attention and be present, the actual doing of it turns out to be much easier and more enjoyable than my mind had been expecting. As usual, the resistance to getting started is far more uncomfortable than actually doing the thing.
Bill Atkinson...who was by far the most important Lisa implementor, thought that lines of code was a silly measure of software productivity. He thought his goal was to write as small and fast a program as possible, and that the lines of code metric only encouraged writing sloppy, bloated, broken code.
...He was just putting the finishing touches on the optimization when it was time to fill out the management form for the first time. When he got to the lines of code part, he thought about it for a second, and then wrote in the number: -2,000.
I'm not sure how the managers reacted to that, but I do know that after a couple more weeks, they stopped asking Bill to fill out the form, and he gladly complied.