yeah I think the point is a bit muddied. Academics are always working... to me, the main take-away is that he got 6 days to think, and only had a single day of "disruptive meetings" to help ground/discuss whatever he was thinking...
Yes, his job was literally to spend his time "thinking and recording his ideas" which he did probably 6 days a week. I imagine the day he "gather likeminded colleagues to read papers and discuss ideas" was the 'fun' part of his time allowing him to decompress
One of the silly things of our culture is over-specialization. A human needs to challenge his or her memory, must do a good deal of thinking, must study but also must make strength and endurance efforts. Perhaps you don't need to but we should at least configure society to allow it if you desire it. The casual thoughts while doing manual work is lovely if you have something constructive to think about.
I suspect these trades are artefacts of that way of thinking. Some people have a frequent flow of ideas they are compelled to capture in one way or another.
Because they want to talk about things from their life (which is because, among other reasons, having personal experience with the things they're talking about is rather helpful), and if they were saying how great their life was, that might evoke resentment. It also seems possible that the space of "funny things you can say about how something sucks" is bigger than the space of "funny things you can say about how something is good".
I mean, to be fair, the article isn't actually advocating that he was "only working a single day per week" despite what the title says. Furthermore, there's a big difference between "working" as defined by your employer, and "working" as defined by your productive contribution to society.
I suppose by the latter, some people never work a day in their lives, eh? ;)
Yeah, the title is clickbaity. It’s saying “Dijkstra was most productive when he went into the office one a week to tend to regular things and had the freedom to do whatever he wanted on other days”. Well, duh, I would also be more productive if I had the political freedom to collapse all of my meetings into one day and make them only about what I wanted to talk about and I could do whatever I wanted to on the remaining four. I’m sure if I was a Turing prize winner like he was I would also be afforded that same freedom.
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.
one related thought: many of the ideas he is famous for (and are named after him) came from his memos. Can you imagine an academic even acknowledging they got an idea from a non-peer reviewed sources, let alone giving him the credit?
Being a relatively highly paid "consultant"/"contractor" on an hourly basis grants you the same status - management tries to minimize bs on your way so the company pays for a real work done.
When I'm working on a new algorithm, nobody is going to be surprised if they don't hear from me for 2 weeks :) It all boils down to trust and managing expectations.
Not that I have to communicate a lot on a day-to-day basis today, but I worked for someone for a number of years where he traveled a lot, I traveled a lot, and I worked more or less independently. I'd be in contact with various people related to whatever I was doing at the time but I might not really be in touch with my manager or other people on his direct team (who were mostly doing things largely unrelated to what I was doing) for a few weeks at a time.
I don’t think you can know that. He might be on campus on Tuesdays, work at home Mondays, Wednesdays, Thursdays and Fridays, and enjoy a work-free weekend.
(Though he’s an academic, so “his work is his life” is not unlikely.)
Cal Newport has become a particular kind of hustle culture charlatan, and it's been pretty fascinating to watch. I began reading his writing when was focusing on teaching study habits to college students when I myself was a college student. As he grew up, finished his PhD and started his academic career, he began building a brand around offering advice on "deep work". It sells the idea that you can, and should, only work on meaningful problems with limited distraction, and have a solid work-life balance, filled with "valuable leisure activities".
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.
I don't see how reading good advice on doing deep work is at odds with spending time doing it. "Give me six hours to chop down a tree and I will spend the first four sharpening the axe," etc.
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.
>I don't see how reading good advice on doing deep work is at odds with spending time doing it. "Give me six hours to chop down a tree and I will spend the first four sharpening the axe," etc.
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.
Indeed, I think the "right way" to use advice like his is to understand the index card version and apply it. Spending a lot of time following everything he writes isn't really consistent with the concept of deep work.
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.
To be precise this should be called one meeting day work week.
For many knowledge workers this should be the default too - 4 days of deep work and 1 day agreeing on the scope of the work etc
Sure sometimes you may need feedback in the middle but it can wait or maybe the person you are interrupting is a project manager etc
His work also spanned large regions of CS. We owe most operating system architectures for his work on T.H.E. Computer designs including the basic ISO stack.
As opposed to my one day work week which is 4 days of pointless meetings and 1 day of actual productive work peppered with interruptions and spread across 5 days.
An hour of straight concentration is something I crave right now.
This sounds very familiar to me from a previous job at the height of the pandemic. All those interruptions are very mentally draining. I'd have about 4 or 5 meetings a day, and would get actual work done between interruptions.
Because most people whose job is research today have to work all the time in busywork BS, lest they get fired. To churn BS papers just to stay afloat of publish-or-perish, to attend all kinds of BS meetings, to do all kinds of BS administrative work that has bureaucratically exploded in the last 30 years, to do dog and pony shows for grants, and so on.
They could only dream of "spending almost all of their time thinking and recording his ideas"
Most people in general have this problem. You have to be Dijkstra (or his equivalent in your field) to solve it. And some people can't: you can't be so good at plumbing you only have to work 1 day a week, and can think the other 6.
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.
>And some people can't: you can't be so good at plumbing you only have to work 1 day a week, and can think the other 6.
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 had a research advisor explain that the timesheets are a formality if you are productive: You might mentally write your abstract in the shower, think about the research problem in the bus, get distracted while you're in the lab, rehearse parts of a talk with a friend between classes... Which of these counts as work time?
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.
> 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.
I'd love a schedule like this: the one day gathering with likeminded people and discussing interesting topics, the rest of the time is self-directed learning and creating, delegating all the parts that are deemed less important for the "unique value add" of the person.
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.
Absolutely. When I went freelance, I traded my one boss for multiple bosses: myself, plus every potential and landed client. And federal/state/local governments. And insurance providers. Thank goodness it was software so I didn’t need a landlord and bank loans, too.
I imagine by “self-employed” what they really meant was “early retired”.
Also best suited for academia. Self-directed engineers would most likely not work towards the company vision of building whatever the customer wants, but play around with technology and forever improve their code.
There is much to learn from Dijkstra since Human nature is not that very different. Problem-solving requires a multifaceted approach and if we find that somebody had used a Method/Process which gave them exceptional results then we need to extract the essence of their methodology and learn to apply them in our own individual contexts.
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 counterpoint to your second point is Gall's law:
> 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.
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.
I don't think this is actually contrary to my point (although it is just a heuristic). People completely misunderstand terms like "upfront design"/"waterfall model" nowadays. It does not mean that every facet of the system is nailed down "completely" before implementation. What it means is that the overall structure of the system is sufficiently clear with proper separation of concerns and modular boundaries to begin implementation. The design is "exact" at a high level but the details would be worked out iteratively. Top-down design and Bottom-up implementation.
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.
> What it means is that the overall structure of the system is sufficiently clear with proper separation of concerns and modular boundaries to begin implementation. The design is "exact" at a high level but the details would be worked out iteratively. Top-down design and Bottom-up implementation.
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.
> With a complex enough problem, that doesn't work as well as you imply.
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.
I am glad you found it useful; your appreciation is much appreciated :-)
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.
This right here is the best take here - half of the work I do as a software dev is explaining what I'm doing to other people, raising tickets dealing with pipeline woes and infra problems and everything but writing code.
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.
The difference is Dijkstra’s interactions with the other people who worked with were limited to one day per week. He had the other days for sustained focus.
I think Newport is more interested in how he worked than where.
It might have been less work from home than it appears at first glance. Browsing through the EWDs, he seemed to have been on road trips of various sorts about 8 weeks a year, and those involved more than a day a week of public appearances.
I can’t remember the history exactly but isn’t Cal Newport the one who became famous for being a postdoc who was super prolific while still rabidly being 9-5 40 hour schedule ? Used to piss me and my friends off so much as if WE wanted to burn up by working more as opposed to the environment forcing it on us.
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.
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:
"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.