The document discusses the "silent productivity killer" of lack of responsiveness when programming. It notes that responsiveness is key to achieving a state of "flow" where one is most productive. It argues compilers like Scala's are too slow and inhibit flow. It suggests languages and tools should be designed to have immediate feedback and avoid full recompiles whenever possible through techniques like incremental compilation that only recompile changed parts. The document advocates for prioritizing responsiveness over other factors like compilation speed in order to improve productivity.

1. The Silent
Productivity
Killer
Paul Phillips
paulp@improving.org
Source: It's xkcd, yes.

2. Ex-Hacker Tells All!
• One-time scalac hacker
• Now full-time malcontent
• Voted Mr. Congeniality by scala community
• Zero years in a row (and counting)

3. Jon Pretty admits it took
him 10 years to amass 10
years scala experience.
The picture suggests he
was enjoying the forty
weeks vacation standard in
Western Europe.
I dub thee Jon Pretty Slow.

4. < 10 years

5. Scientifically Determined Facts
about me, in the domain of interpersonal orientation

6. How Software Is Made

8. Initiate
build
sequence!

9. TIME
PASSES
You're older than you've ever been
and now you're even older
and now you're even older
and now you're even older
!
You're older than you've ever been
and now you're even older
and now you're older still
!
-- They Might Be Giants

11. Hmm, let's try it with
that one brick three
millimeters to the left.

13. Wait a Minute
• The titular "silent killer" is not the
time spent waiting
• It is the inhibition of flow state
• Outside of flow, you are but a
shadow of your best self

14. Mihaly Csikszentmihalyi
(mee-hy cheek-sent-mə-hy-ee)
identifies these preconditions
for flow:
!
1) Goals are clear
2) Feedback is immediate
3) A balance between
opportunity and capacity

15. The Lag Analogy
• Imagine editing system files on a faraway server
under a 6 second echo lag. No mistakes!
• Is the time to completion only 6 seconds greater?
• Is your error rate only "6 seconds" higher?
• Is the task only "6 seconds" less enjoyable?

16. • How often do we tolerate a "6 second lag"
when writing code?
• To a first approximation: always
• Optimistically: way too often
The Lag Analogy

17. The Lag Analogy
• "You should have been using screen/tmux!"
• Right: why tolerate such uncivilized conditions?
• A highly responsive layer coalesces inputs and
batches them to the high-latency system
• It's madness to have to traverse every
requirement to connect cause to effect

18. What IS a compiler?
• Responsiveness is a (or THE) key to a UX
• It is mandatory to achieve flow state
• We are unwise to turn this critical task over to
a general purpose compiler
• More responsive does not mean faster:
usually it means slower! (i.e. less throughput)

19. repl startup
• Initialize the compiler in a separate thread
• Print the prompt immediately
• Result: startup feels impossibly faster!
• Yet "minimum time to first result" is unchanged
• Responsiveness, where perception IS reality

20. multitasking
• scalac is so slow to build, I always had two work
trees going simultaneously
• Context switching in that codebase is not cheap
for the wetware
• Incremental compilation is useless in scalac

21. Interrupting Myself
• Everyone seems to agree interruptions are costly
• I experience no interruptions - from humans
• Flow state is no less elusive for that
• "Flow interruptions" are everywhere

22. "incremental comp..."
• Incremental compilation recompiles less (at best)
• I say: recompile never! Recompiling is rebooting
• First requirement is a functional compiler
• And we derive the output from the delta

23. A change to a base trait
may incur the
recompilation of
over one thousand files.
!
The regeneration of 100
MB of class files.
!
While the ΔOutput
requires writing 4 bytes to
a single classfile.

25. Skeptical Hippo

26. "that's impossib..."
• Yes, very likely it's impossible for scala, and most
existing languages
• But a language can be engineered around it
• And a language SHOULD be engineered around it

27. "who needs a comp..."
• Bad news: most software cannot be reasoned about
• Try some pure reasoning against a few scalac bugs
• We can design better software, but that won't unwrite
the rest of it
• And regardless, frobbing knobs and seeing what
happens is how most of the humans learn

28. "The next step is to transfer some
psychic energy each day from tasks
that we don’t like doing, or from
passive leisure, into something we
never did before, or something we
enjoy doing but don’t do often enough
because it seems too much trouble.
!
There are literally millions of potentially
interesting things in the world to see,
to do, to learn about. But they don’t
become actually interesting until we
devote attention to them."
Mihaly Csikszentmihalyi