Edsger Dijkstra’s One-Day Workweek
calnewport.com
calnewport.com
"He spent almost all of his time thinking and recording his ideas. He only came to campus on Tuesdays."
The guy wrote 500+ memos on the non-Tuesday working days. That's very far off from a one-day workweek.
Just like comedians. They are always playing scenarios in their head and playtesting jokes.
When I worked in sales I spent my weekends frequently answering emails and improving my knowledge in ways that specifically related to work.
Now I work more in "engineering".. and when I'm gardening, or mowing, driving, I'm thinking about work projects at least half the time.
Yes. Which is why both you and OP are correct.
(Though he’s an academic, so “his work is his life” is not unlikely.)
I suppose by the latter, some people never work a day in their lives, eh? ;)
That came later. He just had a flexible gig that was common for researchers at the time. From what I can tell, none of his behavior would be accepted today:
- participating in a new field without formal credentials
- not writing papers or participating in peer review
- writing books and papers without citing other works
- bouncing between academic and industry roles
Academic research is just a different world, with very different life tradeoffs, even for "big' names.
You can debate the merits of his arguments, and should, as ultimately what he sells is advice, but something truly rubs me the wrong way about how he has continued to market himself. A kind of Andrew Huberman-esque, long form podcast, a thinly veiled advertisement for his courses, books, and products.
One would think that if you were truly living a "deep life", watching a two hour long video podcast every week wouldn't exactly fit into your schedule.
While I credit his critique of the attention economy to opening my eyes a little bit and changing how I view my time, I can't help but feel that as he's risen in popularity following his "deep life" work, he's continued to become more and more of what he used to decry, just another way to waste your time while feeling like you're being productive.
It seems pretty unfair to call him a "hustle culture charlatan" when at the same time later on pointing out his emphasis on work-life balance. Isn't that the opposite of hustle culture?
I've found his advice incredibly useful in my career.. both for getting more done (that is actually important to ME), and for having a less stressful life.
If you read his book(s), and got something out of it, great! So did I. But my issue with where Cal's ideas end and his business begins. His philosophy itself is relatively simple but his business revolves around getting you into his ecosystem and keeping you consuming the same content on how the "deep life" operates. He ultimately becomes a cog in the attention economy he is trying to avoid, and for me, that casts him as a hypocrite.
Like many 21st century self-help gurus, the true content can fit on an index card, and the rest is examples that are repeatedly teased out for additional length. His podcast is the most brutal extension of this. I've listened to it since its inception, but gave up because it hit the right neural circuitry that let me feel like I was improving myself without doing so. It was productivity porn. It stopped being about helping people, and started being about merchandising long ago. You can even hear it in his voice when he says things like "don't waste your time with frivolous podcast listening. Except our podcast of course! we're not frivolous. We're deep". Happens like once an episode.
> It seems pretty unfair to call him a "hustle culture charlatan" when at the same time later on pointing out his emphasis on work-life balance. Isn't that the opposite of hustle culture?
Even his discussion of how you spend your personal time revolves around doing activities that he refers to as "high quality leisure time". It is yet another relentless pursuit of min-maxing efficiency, with the underlying idea being that leisure is the fuel that allows you to burn brighter for longer than the other people around you, but winds up with your personal pursuits functioning as yet another resource to optimize. I think this idea, while well meaning, can be destructive. Embracing this idea that there are certain "right and wrong" leisure activities has led me to constantly question the utility of things I've enjoyed in the pursuit of "high quality". Plus how many people who seek out advice about the kind of optimization that Cal preaches are truly interested in work life balance?
It's like an alcohol company telling you to drink responsibly. It's plausible deniability. This point acts as a defense against criticism for Newport. The people who truly embrace Cal are just as likely to look towards other figures who are selling the same shtick he is. His discussions of these points only serve to differentiate his rhetoric from a figure like Tim Ferris or Andrew Huberman, when they are less distinguishable than they'd like you to believe.
Ruthlessly optimizing life to squeeze every inch of productivity doesn't make for a great life, unless it happens automatically without even thinking about it, because you are already so passionate about what you are doing that you don't have time for much else. If it's just to win the rat race, it will suck, and then suck for everyone once everyone starts doing it.
The flip side of that is that critically evaluating how you spend your time and cutting out things that you don't really need or appreciate can make life a lot more relaxing and fun.
My main criticism of the Deep Work concept is that it ignores peoples internal emotional state, and treats people like robots. Most of peoples work issues come from things like self sabotage due to trauma, imposter syndrome, etc. and can't be fixed with a more optimized schedule or anything like that.
Not sure where you got the 4 days part from the article.
50 percent more deep thinking time will compound enormously over a career, especially in winner-take-all dynamics like Dijkstras profession.
Damn that's kinda nice, never thought about the "compounding effect" of as you call it "deep thinking", I can 100% see how that be !
They didn't get the 4 days part from the article, they said the norm should be 4 days working and 1 day for meetings for normal workers.
An hour of straight concentration is something I crave right now.
If your job is research, why call that a one-day workweek?
People have worked remotely, seldom or never seen "in the company chair", while being more productive than people in offices by orders of magnitude...
> At this point, Dijkstra had become the opposite of busy. He spent almost all of his time thinking and recording his ideas. He only came to campus on Tuesdays. And yet, as Dijkstra’s colleagues noted:
> “The Burroughs years saw him at his most prolific in output of research articles. He wrote nearly 500 documents in the EWD series.”
> In this specific case study we see hints of a general observation about slow productivity. Busyness is not the engine of production. It can, in many cases, instead be the obstacle to accomplishing your best work.
So management was incompetent in not seeing this dude was prolific when thinking at home.
But as with almost anything: it depends. Some people are work better from home, other do better in an office. All these return to office policies are BS IMHO: as long as the people you directly work with are OK with you working from home, go do that.
One of my favorite professors came in only on Fridays (except when the department would meet). They met with the research group, taught, had office hours, and then went home. I don't think they did nothing the other 6 days, but they also never sacrificed mental health for the sake of appearing busy.
They could only dream of "spending almost all of their time thinking and recording his ideas"
It's a rare quality of any profession, and sub-genre in that profession, that you are paid to think, and even rarer that it's worth doing so for an individual.
Sure. But my point wasn't that "all professions/people should have that", but that we should let researchers and thinkers, to research and think, as opposed to bloating their day to day work with bureucratic and "dog and pony" show BS.
In the case of researchers this would be equivalent to letting the plumber do actual plumbing, as opposed to having them attend BS meetings and file increasingly more reports and perform BS rituals some idiots in management create as requirements to justify their salaries.
As we know that this less the case, as you go back in the decades. The administrative "BS" part of academic work has skyrocketed, to the detriment of the actual work.
I frequently have the feeling as we well that I could get so much done if I didn't have to work -- this is not necessarily _correct_ (most likely it isn't), but aligns well with the case made here, so there _might_ be something to it to explore how to get more free (creative time), almost at all cost.
We all would love a schedule like this. No agile, nu scrums, no meetings, no wiki page editing, no unit tests, no menial work, no code reviews, no context switching. Just work on what you deem important. It would project productivity through the roof.
It's achievable only if you are self employed.
I think most self employed people would tell you otherwise.
I imagine by “self-employed” what they really meant was “early retired”.
As an example w.r.t Dijkstra's "working habits" here are my takeaways;
1) His focus on logical rigor in thinking of a Program as a sequence of "Predicate Transformers" (https://en.wikipedia.org/wiki/Predicate_transformer_semantic...) is very fundamental to thinking about programming. Even if i do not use his particular notation/techniques, cultivating the habit of thinking about logical predicates operating in the state space of the program before writing the code which moves the state space from one to another i.e. from Pre to Post condition is essential to writing correct programs.
2) His emphasis on writing everything down by hand before touching a computer. The biggest problem facing a Programmer today is myriads of distractions hindering any attempt to focus and think for long stretches of time consistently. If you sit with paper/pencil and force yourself to think and write out your thoughts/algorithms then the above problem goes away. He famously wrote the THE OS by hand!
3) Learn to focus only on the absolute essentials and not on accessories like IDEs/debuggers/etc. Dijkstra famously stated that programming should only be taught in a precise language for which there are no compilers to machine code in order to force students to "play computer" and think through their program execution. Tools should be used only to augment thought but never to supplant/short-circuit it.
If you look at the working habits of the great Scientists/Geniuses almost without exception they avoided "busyness", ruthlessly cut out all inessentials from their work, wrote precisely, used tools judiciously and thought deeply. This is what we need to hold on to in this day and age where we have a surfeit of everything (distractions, tools, socializing etc.) designed to hinder us at every turn.
> A complex system that works is invariably found to have evolved from a simple system that worked. A complex system designed from scratch never works and cannot be patched up to make it work. You have to start over with a working simple system.
https://en.wikipedia.org/wiki/John_Gall_(author)
At some point, problems are just too complex for any person, no matter how brilliant, to think through ahead of time. The only practical way to make progress on such problems is to implement a simplified version of a solution and then evolve it towards full function. Techniques like test driven development really embrace this idea.
Dijkstra himself says this w.r.t. "Program Correctness" in his EWD288 "Concern for Correctness as a Guiding Principle for Program Composition". The same idea applies to design (replace "correctness proof" with "design" in the following excerpt).
Finally, a word or two about a wide-spread superstition, viz. that correctness proofs can only be given if you know exactly what your program has to do, that in real life it is often not completely known what the program has to do and that, therefore, in real life correctness proofs are impractical. The fallacy in this argument is to be found in the confusion between "exact" and "complete": although the program requirements may still be "incomplete", a certain number of broad characteristics will be "exactly" known. The abstract program can see to it that these broad specifications are exactly met, while more detailed aspects of the problem specification are catered for in the lower levels.
With a complex enough problem, that doesn't work as well as you imply.
The architecture that you come up with initially gets compromised by practical considerations. Which is the reason why re-implementations (often caused by changing languages for unrelated reasons) often result in substantially smaller code sizes because the second time around, the architecture is informed by the experience of implementation.
No, the approach of breaking down a problem into smaller manageable pieces and attacking each piece separately in the same manner is universal. This of course will be guided by one's prior knowledge, experience and techniques to manage Risk. See for example the classic; The Spiral Model of Software Development - https://en.wikipedia.org/wiki/Spiral_model
> Which is the reason why re-implementations ... because the second time around, the architecture is informed by the experience of implementation.
True; but you don't get to do a re-implementation every time. Hence one has to evolve the system architecture carefully with the the same approach mentioned above.
1) i did a quick skim of the predicate transformer wp page, looking at weakest preconditions and taking a short detour onto the definiton of hoare triples. i _think_ it is about minimal pre-statement (statement being the active code in question) assertions and maximal post-statement assertions and using that as a basis to define your program/algorithms. this leads to strong conclusions about the correctness of your code. i would say this is a great and perhaps necessary goal for important systems. i try to do it at a slightly higher and less rigorous level with automated tests, but the desire is the same, and if i really wanted correct code, i would probably do just this sort of thing.
2) i've been programming for a while. about a year and a half ago i noticed that i was falling into this bad habit that i had worked hard to get out of many years ago where i would just take a stab in the dark, tweak some code, and run my program over and over until the output was correct. :feelsbadman: since that time, i have made an effort to develop a habit of thinking much more before running my code, and it is showing results. often i can write code for hours, once recently i even did so for days, and not execute it, reasoning as much as possible about execution and state along the way, and when i finally run it, there are bugs but they are usually quite shallow and i can fix them quickly and then bam! it just works. sometimes i pause in this and for the satisfaction of running my new code i will write automated tests that check the correctness of some of the functionality. and i have paused at times and written in my notebook, explaining to myself what the problem is that i am trying to solve, why my current solutions have failed, and reasoning about what a good and working solution might look like, and designing it before opening the IDE. that works wonders too. i would say again - i'm not quite as rigorous as he was, but the method has helped me write better code.
3) yes, i have done this before, and i try to emulate the idea in my (high level) code. but i'm definitely not at that rigorous level :)
and thank you for the reminder to avoid wasting time.
Neil Gaiman has a speech called "Make Good Art" and i read the transcript (he has made a short book out of it) and watched a video of him actually delivering the speech at a graduation ceremony yesterday. i will conclude with a quote from that speech.
> There was a day when I looked up and realized that I had become someone who professionally replied to email, and who wrote as a hobby. I started answering fewer emails, and was relieved to find I was writing much more.
The point of my post was that studying Dijkstra is essential even if we cannot follow his methods to the letter. The key is to improve our own thinking and adopt better and more productive work-habits.
You might also want to checkout Dijkstra's A Method of Programming and Wirth's Systematic Programming: An Introduction.
Now code is not the only part of being a dev but it's hard to feel productive sat in some agile retro or whatever.
I think Newport is more interested in how he worked than where.
And if I recall correctly, he recanted on it after becoming a professor and realizing that can’t actually work if you are truly responsible for things in a lab? Or something to that tune? Please correct me my memory is frail on this.
https://www.cs.utexas.edu/~EWD/
Many are hand-written in ink, in his distinctive handwriting. They have no cross-outs or corrections. Some are quite long, with pages of mathematical notation. They must have taken a lot of time to prepare. Here is a sample chosen at random, which turned out to be a very nice example: