Very interesting essay. Reminds me of how Donald Knuth describes his job:
> Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study.
It's really not an attainable career for almost anyone. Not even the vast majority of professors, who juggle the actual research with grant writing, mentoring students, lecturing, organizing and participating in conferences.
No, you're mistaken. It's not attainable to make MONEY doing it, as a rule.
I've been doing just that and still am, in my own field. It doesn't make money but it sure does eventually lead to influence and results. The money gradually creeps up (for instance Patreon, once you have enough influence to pull some patrons) but it never becomes comparable to normal work.
If you want to do this but also have some fancy resources, inherit money. That's literally what happened to me, and it's returning to baseline with a moderate boost from having invested what I inherited in tools and materials.
People can often take on more than they think. It just requires tradeoffs or sacrifices. Plenty of people that have kids, health issues, multiple jobs, still find the time to better themselves by going back to school or working out to improve health, or volunteering and or building a community program in some way. It just is rare to make that choice relative to our wealth of leisure options. It is easier (and very understandable) to just choose to find some enjoyment in your life by taking what joy you can. Which is why people that "go beyond" are celebrated in media. But it isn't unattainable in the same sense that, say, loosing weight isn't some magical thing that only the few can do. It instead is something hard, something that incentives conspire against, but nevertheless still accessible to most.
Worth noting it seems like didn't always used to be this way. My impression is researchers had much fewer distractions in the early 20th century. It's not surprising how much ground-breaking progress was made at the time when you see it this way.
If you stay out of the “news stream” you can pursue your ideas deeply and even if someone else is working on something similar, you will have your own unique take on it.
They stood on the shoulders of giants just like we do.
It seems naive to think that getting on those shoulders in this modern age won’t create a brand new batch of low hanging fruit to pick if you’re willing to put the effort in
Eventually the tree is picked clean, it doesn't matter how high you go. There's just very little left and all the pickers are trying to get the same fruit.
People thought the same one hundred years ago, and they will likely feel the same in the next hundred years when we all have our own AI assistants and probably stuff like ocular implants to replace monitors and other unfathomable discoveries
Everything we know about modern physics was being discovered at that time. Math formalism was really taking a foothold. Neither field has seen major advancements since roughly the 70s. Computer science is the same. Now we're computer plumbers, not scientists. I'm not suggesting there won't be advancements, but we solved most of the fundamentals in that time period
> we solved most of the fundamentals in that time period
Arguably this is just one interpretation, the other being "we haven't made fundamental progress since that time period".
In my limited understanding as a mathematician, there's definitely room for progress: settling the measurement problem, or formulating a theory of quantum gravity, say.
It just makes a lot of sense to me that if you give researchers several hours more deep focus time per day, they'll make more progress. I appreciate the low hanging fruit argument, but it depends on an assumption about what's left to solve.
Grant funding has gotten more and more focused on direct applicability to publishable findings or patentable research over time. Metrics rule everything around us. Which means researchers have to spend ever more time "proving" the "value" of their work.
I have the theory that this is due to digitalisation. We are now at the stage where "everybody" needs to know Tech, and everybody now wants to work in the hip Tech companoes, regardless of own technical skills or mindset: Project managers, legal, accounting, etc. nowadays all want to have a say in Tech aspects, and this creates pressure on the actual tech departments of a corporation to create reports and documentation and explain themselves much more than it used to be.
It's a bad situation for tech people to have to deal with the FUD of all other departments because those departments want to present themselves as knowledgeable and contributing to the technical aspects, when they are not able to at all.
Yes, exactly. It's a rare thing and for people that have wealth and are involved in wealthy circles.
On the other side of things, I could never hire someone to help me. I have to spend my time worrying about trivial things like optimizing my food budget so I don't starve. I don't have the ability to pull away the distractions.
And yes, I am a tech worker in the USA. I still have to do this kind of thing.
> I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study.
Then there are the next level of authors who digest The Art of Computer Programming into simpler books for people who don’t have time for such study. Then there are those who digest the books into blog posts. And finally there are those who digest the blog posts into HN comments.
Odd question but are you reading Algorithms to Live By? This quote & a related anecdote features in the book. Or maybe this is just a really famous Knuth quote.
I am! It’s on my bedside table. I also made it through the parts of his opus that were published at least 10 years ago.
Between the art of computer programming and the art of electronics, man I’ve spent a prolific amount of money and time. I’m so impressed by the underlying talent.
I'm not reading it, though it sounds interesting. I found this quote when I was browsing through Donald Knuth's website 10 years ago for inspiration on where to take my life next.
> I try to digest that knowledge into a form that is accessible to people who don't have time for such study
I'm not sure about accessibility. Almost everyone I know who has the AOCP series, use it has a show piece. I've rifled through the pages myself, and I don't think it's not something I'd call accessible. But maybe I'm not his audience, and/or he and I have different definitions of accessibility.
> though I haven't been very effective at moving in that direction
This sentence brings out my curiosity. Why do you think you haven't? What did you attempt, and why do you think it wasn't effective? I've worked for a non-profit scientific institute and now I work as a freelancer, so I guess I got to see both sides.
Keanu spent 8 hours a day for months doing one thing. You can bet your bottom dollar that the director, Stahelski, didn't do that; and that if he had, the movie wouldn't have been a success.
I think the proper recognition here is that there are different kinds of work. In order to scale past a single person, there needs to be coordination work; the work of coordination necessarily means that someone throws a ball to you, you ponder it briefly, and then toss it to someone else. The deep, full-throttled, do-only-one-thing kind of work that Keanu did was made possible by the juggle-dozens-of-obligations work that Stahelski and the other support staff did. Division of labor: Stahelski juggled the balls so that Keanu could focus.
I think where this breaks down is where managers don't realize these different kinds of work. They must juggle lots of balls; this kind of juggling is necessary for scale; and usually people who do well as managers actually like the juggling at some level. So they naturally project that onto the people working for them. Whereas the ideal manager will recognize that their primary job is to juggle balls so that their stars can do a completely different kind of work than they do.
Keanu wasn't producing anything - it was entirely skills acquisition. If anything, it was so the production could move faster, reducing takes, reducing the use of CGI or special camera work using a stunt double in his place, etc, ultimately creating a better, more believable product.
Of course credit to Keanu for having the focus/drive to do this. He gets alot of flack for being a mediocre actor, but like Tom Cruise he is a fantastic action star. He IS Neo, he IS John Wick.
He's improved a lot and is much better these days about selecting roles that play to his strengths, but yeah, Keanu is an example of someone with limited dramatic range. I'd point primarily to a handful of his early 90's roles.
'Much Ado About Nothing' and 'Bram Stoker's Dracula' in particular come to mind. He's just not a good fit for those roles. Seeing him act opposite Gary Oldman or Denzel or Branagh is tough to watch.
Rumor is brandall10 is old enough to remember the clusterf*k situation of Dracula in real time (https://bit.ly/3JlCppX). And other dramatic turns when paired against acting heavyweights like in the Devil's Advocate.
Acting is a craft. Criticism is healthy. As an actor he lacks dramatic range. This is hardly a controversial opinion, to put it lightly. He had some turns that showed promise (The Gift, some smaller films in his early career), but ultimately, that's not his forte. He is a star behind some iconic roles that best suit his talents. And is by all accounts a lovely human being. It's fine to celebrate that and call it what it is.
Finally, brandall10 likewise thinks kubancyk is a swell guy and encourages him to not take criticism of someone he's a fan of personally, even if they are an FBI agent that knows kung fu.
Ah, got it. I honestly wasn't trying to take a jab, I thought it was common knowledge he just isn't considered a good actor, but then again that could be because of my age bracket. I certainly could have worded it better though.
Cal does actually address this in his book “Deep Work”; unfortunately in this blog post he takes a fairly myopic view, perhaps just to reiterate the value of deep work, for those for whom it makes sense.
In the book, he has a section “what about Jack Dorsey” where he explains that the role of folks like a CEO is to make lots of small decisions fairly quickly, and therefore they’re constantly interrupt-driven. But most people get interrupted more than necessary and do focus work less than they could
Also, I have the impression that movie making is a fairly cascade-like process. You pitch a movie, you make the movie, you deliver the movie. There are stories of extreme change in requirements, but they seem rare.
Meanwhile in IT, you pitch a movie, you find that the movie is solving the wrong problem, or doesn't have market fit, or the requirements were wrong, you adjust, repeat this a thousand times, and in the end you deliver a comic book with a qr code that links to a web series on YouTube.
I believe that's more to do with your relative knowledge of either industry. Movie-making is a much more dynamic business than software making: scripts can vary dramatically depending on who's attached to the project at each time, on the cutting room after first viewings, directors can get replaced midway through shooting, etc etc etc. It's madness.
Exactly. And this is true for a lot of industries. Developers seem to have the impression that only software is a bit "messy", but that's because we're looking from the inside.
People wonder why large construction projects are often delayed. Well, it's often for the same reason it happens with large software projects.
You're 100% right. This it's the exact same reason why the writers strike affect something that I theory should have not effect as the shooting or editing of a movie.
In my experience media production only follows the waterfall model in paper or a really small projects, in practice it's like a chaotic version of Scrum/kanban with no standard that changes from production to production.
That depends a lot on the movie. Apocalypse Now is sort of an extreme example of this: large parts of the movie (including the ending) were completely rewritten during filming, some scenes were completely improvised, the lead was recast from Harvey Keitel to Martin Sheen after they did about a week of shooting, an entire massive on-location set was relocated after being built because the director wanted it to be right on the river (and the original set was also destroyed in a typhoon), another set which was destroyed in the same typhoon was used as-is because Coppola liked how it looked, and the helicopters they were renting from the Philippine military occasionally flew off set in the middle of a filming day to fight an ongoing insurgency elsewhere in the country.
Sure, if you are independently wealthy you can do whatever you want, including slow focused work on a topic for months.
But in Reeves case it wasn't that. It's that the slow focused work was the work he was assigned or expected to do. He didn't just do it because he was rich, he got paid for it, as part of his preparation for playing John Wick - same way actors have to bulk up, diet, learn some skills like piano playing etc before a movie.
Plus, the post's point isn't that "Reeves worked like that, why don't we all?", as if putting the onus on the individual. Yeah, "Because our boss doesn't want it, and we're not rich and can't afford to lose the job" would be the answer to that.
But Cal's point is more about "this is a good way of working, why isn't there more of it", including why it isn't being more of what employers set the working environment up for and demand (in which case you wouldn't need to be rich to be able to do it, you'd just be doing your job).
He got the job in no small part because he'd demonstrated he was able to do that in his preparation for The Matrix, his breakout role as a potential martial arts action movie star.
In that case it was more of a gamble, as the movie might have failed.
With The Matrix though, part of the film preproduction was an extended training program not just with Keanu but with Carrie-Anne Moss, Laurence Fishburne, and Hugo Weaving. Keanu was the star but the expectation was that they’d be able to train all the actors to a pretty high level. The main difference with Keanu is that you don’t necessarily want to rely on him to deliver a lot of lines; he can do it, but he’s much more of a kinesthetic, non-verbal actor at heart.
> But Cal's point is more about "this is a good way of working, why isn't there more of it"
There is some, though often half hearted. Employees are often sent to conferences with a mission to learn about "new thing X" or consultants are brought into train the team about trend Y. Encouraging structured training is a real super power. I've seen it make the different with things like "sales enablement" for GTM or effective onboarding programs for certain companies. These are oftern cargo-culted , but when down well are very impactful.
I've went from a 15 men team in big corp where we managed the search feature of an important ecommerce (both the search inputs and filters and result displaying): meeting, meetings, daily, all hands, ceremonies, meetings, committees, pings, train juniors here, train juniors there, help people with whatever is their issue, explain to the designer everything that's wrong or missing with their airbnb-cloned design (like missing all states for hover, disabled, etc).
Now I work in a 3-men company where the CEO is mostly absent and it's me and another developer, that's it. We manage 5 different products. A single team in big corp would've not been able to handle even one of those I'm 100 % sure of it.
I grew to appreciate more small teams made of quality strongly independent people, productivity is infinitely higher than big teams in big corps, those are doomed to be slow and inefficient.
The only con in the current arrangement is that company is obviously very vulnerable to losing me or even my other colleague which is way more proficient and expert than me on many aspects. Our CEO understands that and his priority is to make us happy financially and by allowing us to work how we prefer, at the time we prefer.
Best deal I've ever had in my life. I work much more than I did, but I like it, it's still less than 8 hours per day, but it's not meetings/youtube/chats/some coding.
>> Now I work in a 3-men company where the CEO is mostly absent and it's me and another developer, that's it. We manage 5 different products. A single team in big corp would've not been able to handle even one of those I'm 100 % sure of it.
Are You me? Jokes aside, my company used to be a lot bigger, but most left, and others were moved to big bang rewrite project into modern js (which seems to be going nowhere). And now me and other developer, one admin and one product/sales guy keeps 20-modules app (modules as modules in ERP line env - meaning CRM, Accounts Recivable, Correspondence etc.) written in old forsaken tech working smoothly with new features added daily for 10 quite big customers.
Its really amazing what can be achieved with small team who can focus their whole attention on helping customers directly, ignore unecessary meatings, work from home at whatever hours they want, and not re-doing the same stuff over and over with new shiny technology.
The issue arises with certain managers and non-specialized workers who operate in brief, scattered bursts of time. Their work pattern consists of making calls, writing emails, or superficially scouring the internet. These individuals often view quiet, focused colleagues with suspicion, misinterpreting their intense concentration for idleness as they sit at their desks, lost in their computer screens. Under the mistaken belief that they need to "shake things up," these managers or workers disrupt the focused workers by inundating them with a barrage of messages that demand immediate responses.
Many of these types like to wait till others (the smart ones reading and researching quietly) digest information for them and then go around acting like they figured it out themselves while they were also busy socializing in their meetings and garnering wisdom at the “water cooler”.
Way I see it, work hasn't changed much in 5000 years. You have hunters, farmers and miners. Top jobs usually go to hunters, and they don't understand grind or tending at all.
I put myself on "tentative" in teams meetings except the ones with my direct team members.
I don't check my email more than 5 times a day: start of day, mid morning, before lunch, mid afternoon, end of day. In your case that's 20 emails to look at each time and I bet adding some inbox rules would break it up into something even more manageable (3 to 5 emails per folder they hit).
Teams and slack chats are muted by default for me unless I'm mentioned and that's what most people expect.
This yields good ~90 minute chunks for me to work with despite all the noise. I don't even block out my schedule. I just let some days be shitty if they're going to be (usually no more than about 3 half days lost per week).
Telling people off is no good because it reifies your frustration, leaves a bad taste in the mouth of the counter-party and ultimately fails to achieve your goal since it's just one person out of (presumably) many who are pinging you.
A better way to handle this is to just stop responding. Disable alerts, turn off Slack if you must. Put a message in your bio setting ground rules for how to engage with you with some context on your time management philosophy. If folks complain, have a conversation with your manager about it. In some cases prioritizing responsiveness may be a priority, but this naturally comes at the expense of deep work, and it needn't be everyone all the time. Twice an hour is ridiculous for an IC in any case, hard to diagnose without more details, but it definitely indicates some kind of problem that a competent manager should be able to help you address.
This might work in a large company. But not in a smaller company where you are the domain knowledge for many parts of it. I have raised it with my manager but it's one of those things "that come with the job".
I have this pet theory that you're never as productive as the first year of employment, where you know your stuff and you're getting things done but people don't know it's you yet!!
Tell people immediately that you'll check for the answer ASAP, and delay your response.
This will lead to several desirable outcomes:
- people might try to figure things out, or find an answer that might not strictly how things works, but consistant with it. (this last thing can be extremely powerful, as it can lead to better communication with clients).
- people will internalize that they won't have instant answer and organise themselves with that immuable fact. They'll naturally end up to compound potential questions, and that probable async replies lead them to refine their question in a more precise way.
- occasional instant reply gets valued for what it is.
If instant replies with sync conversation are expected, there is an organisational problem, and it's not sustainable. It's bad habit, being small business is not a good enough excuse.
I mean, in a smaller company, you should theoretically be able to have closer relationships with the people asking you questions; surely you should be able to establish "hey, I might not always respond right away"
yeah I've spent 13+ years in companies of 1-50 engineers, and another 10+ years in larger orgs with thousands of technical staff. Even as a CTO in a small company I still found ways to protect focus time (including telling the CEO to call my cell if something was urgent). There are solutions if you are willing to examine your assumed constraints. Look at it this way: what will they do if you get fed up and leave?
Teams channels are often much better than meetings. They might get their answers faster and for complex ones they can study it better.
Also, nobody has to be put on the spot. Leaving them waiting a couple of hours max for an answer is usually the same wait time anyway. In the meantime you can also ask refining questions before producing the final answer.
Just quit out of slack when you need to focus. I’ve done this before at gigs where people abused Slack notifications. The strategic solution is to improve the culture around chat notifications.
Maybe. One place I was at the CEO said everyone needed to be reachable on Slack within 15 minutes during work time. Nevertheless I would go offline for an hour or two at a time (which is as long as I can do deep work anyway) and it never seemed to be a problem. But directly disobeying the CEO always felt like something that was one unanswered Slack message away from disaster.
That is not true. It's embedded in the way we work and essentially not being on it is either not working, or not being part of the team. You have to use the tools of the job that your team is using.
You can use an app such as Day wise to batch your notifications, else I would totally not check anything. I still do want a ping, but only every X hours.
They're stuff like standups or sprint planning for projects I'm not always actively contributing to. If I need to be there it's because I have a significant number of Jira issues assigned to me.
The other meetings I set to tentative are the huge (hundreds of attendees) quarterlies, monthlies, etc.
I don't usually do this for one-off meetings unless the organizer just optimistically added people from the org chart. In that case I will ask about it.
I'm not saying I won't attend, but just that I don't know if I can. It's an honest answer. All this time adds up.
> Putting tentative is the biggest asshole move you can do calendar-wise.
First of all, thats not a very nice way of putting things. Secondly your answer has little conversational value, you are not adding to the debate. Thirdly - that’s just like, your opinion, man.
I see it a bit differently, I see it as 'I have seen this invitation and know this call is happening, but I have other priorities at that time. I will attend if I can, but I don't think my participation is important enough to reschedule', and it gives the organiser an opportunity to say 'actually, we will need you on this call, can you suggest a time when you could definitely make it?'
Yep. And this is why my work calendar contains several hour blocks where I can focus on the things that I want to focus on and other blocks here and there to do the things you noted.
The only solution is, with sufficient bravado, you can refuse the meetings and risk getting fired if need be. If you are good and they ain’t struggling then they probably will work around your preference and keep you.
If you ain’t good work on that. If they are struggling then the decision is whether to stay (based on your ethics and situation)
Too many meetings indicates some issue with the division or prioritization at work.
Tell them if you do 2 unrelated tasks and switch between them then it is guaranteed they will get work product later than if you do one at a time. This is guaranteed.
If the tasks are related it might be OK but this is a rare exception in coding. Building sheds it may be ok (lay all the foundations first). But then laying all the foundations is the task unit so again this might apply.
Tell them that if management keep changing their mind, it is like calling the pizza restaurant and changing your order every 15 minutes. Food will come late.
Also context switching loses time. For non technicals that don’t understand this give them an IQ test, them every 10 minutes pull the sheet away from them and swap it for a reading comp. test and then every 5 minutes tap them on the shoulder and ask about their pets. Just describing that means they should get it as almost every person had been subjected to those tests in interviews at one point.
I had a similar issue with people ignoring my availability at my previous company. I just started declining meetings. It forced people to either decide they didn’t need me in the meeting or they would reschedule it
If you are in 4 or more meetings in a day and receive 100+ emails then your manager is incompetent and should be fired. The whole point of being a good manager is to maximise the real work produced by the team. Which means minimising interruptions.
This is a weird comparison. On one hand you have an independent contractor preparing for an engagement. The other is actively collaborating with a team to make a thing. The less bad (but still not great) comparison is to Reeves' allocation of time during principal photography.
On multiple occasions I've spent weeks out of the office in training sessions. Even with on-site training we were pretty good at turning peoples' responsibilities off so they could maximize the time spent with someone we flew in for a few days. Or there's that big bit of training before getting a job at all: university. (That's another rabbit hole of arguing about topical focus within education, but still a portion of someone's life dedicated to learning.)
I can kinda see what the author is trying to get at, but it's weird to use training to make a point about time management. Training is the main type of work I've seen offices willing to let someone go fully incommunicado. Unless you work somewhere that doesn't believe in training. And cramming an online module in between normal tasks isn't training, it's more like reading documentation (it's a con so the personnel software can get an entry that X is trained in Foo).
Oh?… I like weird! (I don’t care for how you use the word though.)
Stylistically, semantically, and philosophically I think you’ll get more mileage by avoiding your negative, constrained, unfamiliar-is-bad usage of “weird”. And now my unsolicited advice comes to a close.
Maybe 'unfit', 'ill-suited' or 'irrelevant' would be more suitable.
I love Cal's writing, but I feel like it's really going against his mantra (of Deep Work) to be making posts like this that try to pluck meaning out of nothing for the sake of marketing.
Your comment is so bloody weird. It gives off vibes of those dudes who one day shave their heads and then spend the rest of their lives telling you you should get rid of anger and embrace the light and all that rubbish. Or of Christian assholes wailing on repeat "Jesus still loves you" whenever you disagree with them.
I've too often found that weird is an indirect way of casting aspersions on something. For example, most people are unlikely to say...
> "That idea is unfamiliar to me, therefore I reject it."
... but many would be comfortable saying ...
> That idea is weird.
Shifting the language in that way isn't genuine; it obscures the core reasoning behind a rather vague word ("weird").
Of course, lots of other things can be happening when people use the word "weird"; they might select it carefully for some particular meaning. That's fine.
I sometimes suggest that people be more aware of how their writing comes across. If that is "weird" (definition below), then maybe we need more weird.
A comment gets read by many people, but it is only written by one. So if an author wants to communicate well, the author should be aware of the audience.
weird
suggesting something supernatural; uncanny:
the weird crying of a seal.
(informal) very strange; bizarre:
a weird coincidence |
all sorts of weird and wonderful characters.
I've literally just come home from a meeting with a colleague where we were discussing software/IT project management. We were discussing how terrible modern software project management generally is, and how identifying and focussing on a small number of priorities and clearing them is way more productive than doing "everything everywhere all at once".
I've been working on turning this into a training course for my domain, and have come to ask the question, "why oh why do we prioritise deadlines over productivity"?
Building a software team which can reliably deliver high quality features is way more efficient than grinding out huge piles of barely working crap to a deadline. But deadline management really is still how most of us are forced to do things. Formal Road Maps, Gantt Charts and Microsoft Project put productivity against the wall before the project even starts. Teams don't get to push back on features that they know will kill a project, and project managers seem to think their role is to hit people over the head until morale improves and features are delivered, no matter what. (I've had a project manager who quite literally refused to prioritise features because "they are all important").
What a stupid way to build things. No wonder 27%+ of software projects end up in the bin.
Keanu Reeves focussed on the top priorities that everything else in the franchise relied on, delivered them with high quality, and was able to build the rest of the franchise around that central effort. Loads of work up front, much less work over time.
I only wish this was how most companies approached software.
The deadline is important because of scheduling, and whoever needs to use your thing has a certain stretch of time where they can implement their part.
I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts. You could make a gannt charts from it, if you add all the estimates, and define the available parallelism, but the reason for doing some piece of work is whatever depends on it, and you can follow the dag up to the end feature
Don't disagree, but deadlines are a very indirect and poor proxy which focuses on time rather than deliverables.
> whoever needs to use your thing has a certain stretch of time where they can implement their part
But the idea that timelines are critical to a project's progress must be a myth, because software projects are almost always delivered late. The dependency is always on the feature or deliverable, not on the date. The depending team will work out how to cope because that's what happens every day in most software shops anyway.
I'm not saying that deadlines and timelines are bad. I'm just saying that they should not be the core organising principle for delivering a project.
Bad PMs and biz stakeholders are often the straw men for why deadlines are unreasonable or don't work. But if you take a high performing team with good cross-functional trust, deadlines serve a very valid function as a forcing function to make decisions, cut scope, and otherwise make progress towards shipping. Without them, it's all too easy for time spent to balloon for a million different small but justifiable reasons.
And sometimes (not all the time), it does make sense for a deadline to be the core organizing principle, see this Mary Poppendieck talk for an interesting example: https://www.infoq.com/presentations/tyranny-of-plan/
I enjoyed that video some time ago, but I really didn't get the takeaway about timelines. Maybe I didn't watch it through.
Anyway, I do agree with you that deadlines can serve a purpose, but this doesn't mean that deadlines are the core organising principle. Typically the sorts of deadline you're alluding to are actually milestones. We're not saying "this feature must be delivered in 3 days", we're saying "we want to launch in 2 months, what do we need to do to get there?". In this case the milestone gives us a goal, but it's not the organising principal. We're not trying to guess how long individual features are going to take, and nor should we; there's plenty of research that shows that this doesn't work in practice.
So while I think deadlines can be a useful project management tool, they're not the only tool, and they certainly should not be the primary one. Nevertheless, it's very common to see projects managed using "firm" estimates and "hard" deadlines, and inappropriate pressure put on teams to achieve goals, such as low-cost accurate estimation, that are impossible.
Considering that estimation is both expensive and inaccurate, deadline based management is just never going to work. So I think instead we should be more concerned about team productivity, because a productive team (by definition) gets more done in less time overall, which is ultimately cheaper and more rewarding than being forced to work against poor quality time estimates. And you can't maintain productivity if you're constantly cutting quality corners to meet some artificial deadline due to the way the project is managed.
It's not too different from that situation where someone says "how can I do X" but when you drill down on why they think they want it, there are better things they should be focusing on. Deadlines are about synchronizing different groups. The problem is opaque/arbitrary deadlines. "Why we need it by then" and "What exactly is needed by then" are very important conversations. Pushing for speed at all costs is bound to destroy morale and quality.
> Deadlines are about synchronizing different groups
If we agree that software frequently runs late (and this is backed up by plenty of research) then deadlines necessarily won’t succeed in this role.
Instead, we should be identifying the points where synchronisation will be possible, and using these as triggers.
For example, we could say, “when this set of features F is running with performance P and is passing tests T then we have 2 months to develop a marketing campaign”.
As an enterprise product developer, I’ve been involved in maybe 100 software projects in three industries and I’ve pretty much never seen a situation that actually needed time based synchronisation. The projects launch when they are ready - deadline or not. While my projects were typically small (3-6 months) they were key infra for the businesses I was serving.
Deadlines definitely serve a purpose but given that software is almost always late, using them as a sync point is just asking for failure.
“whoever needs to use your thing has a certain stretch of time where they can implement their part.”
This can be ameliorated many times by attempting to mock something that covers the most likely interaction between the dependencies. For example, you are waiting for an API to provide some data to you: create an agreed upon JSON format that you will expect to receive and use that to mockup the interface till it’s complete. This allows both sides to move forward more independently till both are complete and ready for integration.
I think as well that this is a problem that Kanban solves quite well. Instead of having a team sitting around waiting for another team, ideally you have people who can take a bit of work from a board and be productive even if their primary project is stalled. This is (part of) how I've run my last few projects and it's been very successful from a productivity perspective.
The problems I've had with this is getting management to understand that productivity and developer quality-of-life is important. They want road maps, god damn it, because reasons. And they say they won't hold us to the road map, but then they do. And at the same time, the road map captures productivity because now you're doing what the road map says instead of being productive.
But building software is often like building a tunnel. You don't know what you're going to be drilling through until you've drilled through it.
> I've been liking to instead model the dependencies explicitly, and make the project plan a dag rather than a gannt charts.
Thats called an Event Chain Diagram and it is the bit that comes after doing a CPA, with or without a PERT.
I strongly believe that Microsoft Project is the reason for the incredibly poor quality of project management we generally see in our field. I spent a few years working in organisations where project planning is done properly, by real Project Managers, that understand how to deal with uncertainties around time and effort required to deliver a thing. That was actually glorious and I’m no longer able to tolerate the clowns that saturate our field
> I’m no longer able to tolerate the clowns that saturate our field
I looked up Event Chain Diagrams and it is probably overkill for the scale of projects I typically work on. Nevertheless it's much more reasonable than the kind of MS-Project based things I've been forced into working with over the years.
Perhaps the worst part of this journey for me has been that I've supposedly been in positions of authority when this has happened. The gravitational pull of what is essentially waterfall project management is so hard that refusing to do it expends significant political capital.
So the clowns are out in force even in my little patch, and I laughed out loud when I read your comment.
> ...and project managers seem to think their role is to hit people over the head until morale improves and features are delivered, no matter what.
Sorry to hear. Thankfully I've been lucky in that most of the project managers that I've worked with tended to focus on the things that are blocking their technical staff from completing their work, and those blocks get put on the project managers task list to be unblocked.
I think it really depends on the industry. If you're in a tech company with lots of experienced software people in charge then it's different. But the majority of projects I've worked on (and, I'd argue, the majority of projects) are about getting software into non-software businesses.
In that case, the problem is you need PMs who are well versed in the domain, software, AND project management. But typically, you get people who have done a PMI or Some Agile Framework™ course and think they know how to do it.
> why oh why do we prioritise deadlines over productivity
I feel this is a tradeoff between latency and bandwidth.
Hitting a tight deadline (or Sprint goal) by creating a bunch of technical debt delivers the feature we need today faster (lower latency). But at the expense of making features tomorrow more difficult to create (lower long-term bandwidth).
I think it's OK to prioritize one over the other based on the business needs.
But I think it needs to be an explicit decision and tradeoff, and I worry that too often managers choose low latency because they can feel it and see the results, and don't understand the tradeoff they're making.
Right, there are times when you need deadlines and you need to make decisions. Knowing what I know today, I would recommend cutting scope over technical debt, but that's beside the point really.
My problem is where the whole project is managed based on deadlines rather than the flow of work. Deadlines kill productivity, but productivity = efficiency = saving money.
The financial accounting for these things is complex, but considering most projects run late anyway, why even bother with deadline based management?
I've read Cal's pieces when they've popped up from time to time. It seems like he's always banging the same drum, and that he doesn't realize how different his job is than most people's jobs (being married to a professor, I am familiar with the benefits of its unique cadence).
Can anyone recommend posts he's written that perhaps show a different side of his thinking? Have there been any good analyses or critiques of his work, which describe the types of people his writing is useful for? As a founder, who necessarily wears a lot of hats, I find it to be aspirational but not especially actionable.
I listen to his podcast on a regular basis and he does realize and emphasize that his job is different than most people jobs. The type of job his advice is most applicable to is the typical office job, involving people who receive a lot of emails, slack messages, and other requests during the day. This can really damage real productivity, due to context switching and 'being available' all the time. He gives strategies to minimize disruptions and ways to apply these.
With regard to "banging the same drum", it's true that the core of his advice stays the same, but I really like his way of approaching these kind things. And repetition isn't necessarily bad. Being in a office job myself, I sometimes need to be reminded of the simple fact that I'm far more productive when I work in predetermined time blocks focusing on output. It's easy to fall into the trap of opening new emails and Slack messages all day long and wondering where all your time went.
While I share a bit of this feeling, I think what he says is true. And he does bang the same drum as you say, but it doesn't change the fact that he is mostly right.
I worked for the most part in jobs related to trading - trading floors can be crazy. But once the mathematicians and modern quants arrived, suddenly everybody realized how much more powerful this slow, methodological approach is.
I think it's similar with investing - if you do it right, it's ... boring. It should be boring, long term strategy. So people feel the urge to act. Trade something. Tune your portfolio a bit. etc etc. Don't do it ! Just sit down on your ass and wait !
This whole post sounds like a very false dichotomy to me. The author makes it sound as if `trained eight hours a day, four months in a row` is a single activity. But of course that to be productive, Keanu had to be on top of many different activities, in different locations with different trainers, in addition to what I believe would have been a myriad of other work activities he had to perform for unrelated professional responsibilities.
Keanu Reeves is not a monk practicing the same activity day in and day out, but rather a very busy professional, with a team of people working for him to help manage his schedule.
I don’t think the author nor readers should take it as a false dichotomy. This style falls into a common pattern of highlighting two examples. There’s no language that says the two examples are disjoint.
> In office jobs, by contrast, productivity remains rooted in notions of busyness and multi-faceted activity. The most productive knowledge workers are those who stay on top of their inboxes and somehow juggle the dozens of obligations, from the small tasks to major projects, hurled in their direction every week.
I disagree. I think this looks productive, but people who only do this will hit a terminal level and find themselves stuck.
Getting above this, into Principle/Director/Executive ranks certainly requires being a great communicator, but also typically involves __success__. I see this as shipping a successful product, closing a key customer deal, etc.
It's easy to see productive people and expect that being on top of email and product plans is what made them successful, but this is only an effect of their productivity and mastery of the product development.
Note that John Wick did have great production values: it needed much more than 'just' Keano. That logistics happened in the background.
You might be misunderstanding what Cal Newport is saying here because he agrees with you. He is saying is the people who stay on top of their inboxes and multitask are perceived as being the most productive, not that they are in fact the most productive. He also wrote an entire book that might as well be about his hatred of email titled "A World Without Email," if you need further evidence of his position.
Cal’s writing isn’t clear on where he lands. But he’s probably around to clarify, somewhere. Let’s all send him emails, tweets, etc and see how quickly he replies.
>>In office jobs, by contrast, productivity remains rooted in notions of busyness and multi-faceted activity. The most productive knowledge workers are those who stay on top of their inboxes and somehow juggle the dozens of obligations, from the small tasks to major projects, hurled in their direction every week.
The deal here is focus. You can focus on anything, anything. Even on emails. The real problem is most people aren't even doing that properly. People while away their time on Insta reels, Twitter, Facebook fighting etc etc.
The best productivity example I saw was when I was working with a Chinese colleague. He would have 2 monitors. One split, exclusively for Slack, Jira and Email. He would watch every issue, every communication, every PR, every darnest little thing going on in the project. He would review, it, or learn about it. He knew what code was going in, what was getting deleted, the pipeline of features, bugs and what not. The other monitor was for the terminal, coding and other work tools.
He would also find spare time in a day for TIL, and other long term learning. There was zero FB, Twitter, Insta, TikToK, whatever. There was lots of 'productive context switching'. Or in other words, the context switch was in the boundaries of work.
The biggest lesson is not to avoid context switching. But to not waste time. Wasting time is the biggest time drain here. I define wasting time as doing something that is not relevant to the thing you are trying to achieve. If you are trying to have fun, working in periods would be equally unproductive to having fun. Same with work.
Funny that this is the exact opposite of "Speed matters: Why working quickly is more important than it seems" (https://news.ycombinator.com/item?id=36312295) from a couple days ago here.
Both speed and "slow productivity" have their place depending on the type of work you do.
I think for junior and mid level ICs, and leadership/management focused people (maybe even senior ICs), speed is paramount.
For staff/principal roles, the balance shifts toward being able to be able to focus more singularly on very challenging problems.
I don't think they are opposite. There's a difference between rushing to do something, and shortening the feedback loop. It says "slow productivity" but learning enough martial arts in 4 months to look good in a film doesn't sound slow to me, it sounds like he shortened the feedback loop as much as possible by learning every single day instead maybe once a week like a normal person would.
> It says "slow productivity" but learning enough martial arts in 4 months to look good in a film doesn't sound slow to me
Remember the kung fu scenes in Matrix? It's not the first time Reeves has trained in martial arts. This time he crammed in a particular martial art for this movie.
Tbh I'd bet he practices something regularly, just not often enough for it to make the news.
“I think for junior and mid level ICs, and leadership/management focused people (maybe even senior ICs), speed is paramount.”
Why? I would argue they need to move slower and methodically so they understand what they are doing instead of thrashing a bunch of crappy code that has to be fixed by others.
More experienced people can move faster because they are doing tasks that have parallels to prior tasks. For example, Keanu Reaves was able to singularly focus on “gun fu” as he is an experienced actor for whom remembering lines and handling himself on set is second nature, requiring less effort than from a rookie actor.
1. There are hundreds of people listed in the end credits, most of whom worked in a much more hectic manner. The film couldn’t have happened without them.
2. There are people who already know what Keanu Reeves needed to learn to play the role, but they’re not internationally recognizable actors. The movie wouldn’t make as much money without him playing the lead, only for very superficial reasons.
I'm not sure no. 1 contradicts the post's main point, but it certainly complicates it. There are definitely many people who are rapidly flipping between task to task (my sense is that producers, production assistants, and personal assistants fall into this category).
There are also jobs like focus pullers and various techs who are working in a chaotic, changing environment, but are focused on one (difficult) task. It seems like a large film has people across varying both in how focused they are (few versus many tasks) and how responsive they have to be.
1. But that contrary-to-the-article doesn't really lead to greatness the way the film achieved it. Like the Dune films, there is a critical artistic dogma that exists and propels the movie to greatness. All hectic/frantic actions are in belief/support of that narrow focus.
This applies to work in so many ways. The greatest restaurants exhibit this same focus/pattern.
So it becomes introspective - what thing should you focus on to achieve your "greatness"? All hectic actions support that focus.
I guess the programming equivalent of Reeves’s approach to John Wick would be a programmer spending a few weeks in simply becoming an expert in any new technologies they may have to adopt for a new project and then starting the project once they’re really good at the technologies, frameworks, etc concerned.
The bad thing is that with the modern ways of working and with the fast paced environment, we don’t have anymore the “luxury” of dedicating project time to better ourselves. This is something that each one should/must/has to do on its own, instead of an activity that should be taken under consideration when project time plans are created ;-)
I also liked this phrase from the post, “…creating things that are too good to be ignored, regardless of the setting, is an activity that almost without exception requires undivided attention”.
Western economies are obsessed with why their productivity has flat-lined. Companies wonder why they have such high tech budgets and so little to show for it. Cal Newport says ”your tech people are spending 90% of their time context switching”.
Perhaps these observations are connected.
At an individual level, tech people get ahead by being very active on Slack. At a company and country level, we get ahead by organising our people in a way that senior engineers most of their time focused on solving difficult and valuable problems. We need to align individual progress with macro growth.
Most of the people working on a film aren’t Keanu Reeves spending four months learning to fight. Most of them are very similar to the distracted, fungible office workers mentioned in the article and nobody would have seen these films without them juggling their inboxes.
In the world of SpongeBob SquarePants, the character Squidward Q. Tentacles exemplifies the concept of "Thinking Fast and Slow" in his problem-solving abilities. Squidward, being a more sophisticated and intellectual character compared to SpongeBob and Patrick, often finds himself in situations where he must rely on both System 1 and System 2 thinking.
One situation that highlights Squidward's use of System 1 thinking is when he is tasked with completing a complex painting for an art exhibition. Squidward quickly uses his instinctive and emotional response to choose a subject matter that will appeal to the judges. By tapping into his creative side and relying on his fast, automatic thought processes, Squidward is able to produce a visually striking painting that catches the attention of the judges.
On the other hand, Squidward also demonstrates his proficiency in System 2 thinking during situations where he needs to carefully analyze and make logical decisions. For instance, when he is entrusted with managing the Krusty Krab restaurant in Mr. Krabs' absence, Squidward employs slow, effortful, and deliberative thinking to ensure the smooth operation of the establishment. He meticulously manages inventory, schedules, and customer service, making logical and calculated decisions to maintain a high level of efficiency and customer satisfaction.
Another example of Squidward's utilization of both thinking systems is when he engages in a musical competition. As a clarinet player, Squidward has honed his skills through countless hours of practice, allowing him to execute complex musical pieces effortlessly using System 1 thinking. However, when faced with a particularly challenging musical composition, Squidward switches to System 2 thinking to carefully analyze the notes, rhythms, and dynamics, ensuring an accurate and flawless performance.
Through these examples, it becomes evident that Squidward harnesses the power of both fast and slow thinking to navigate various challenges and achieve success in his endeavors. He recognizes the importance of relying on instinctive and emotional responses when appropriate, as well as the need for deliberate and logical thinking in more complex scenarios. By seamlessly integrating both thinking systems, Squidward consistently demonstrates his mastery of "Thinking Fast and Slow" and consistently comes out on top in his endeavors.
It often strikes me as difficult to fathom that it took only a couple engineers a few months to build the MVP of the company I work for - that has since grown to be a global, publicly traded corporation with many thousands of employees - but it somehow takes thousands of engineers multiple years to, in effect, build it again. In fact, it makes no sense whatsoever to me and can only be explained by how much time is thrown away, day after day, with all the busy work involved in prioritizing and coordinating their activity, and by the possibility that an awful lot of us are not contributing anything whatsoever. Is this incredibly wasteful utilization of labor really be the best way to do things? I cannot accept that it is. The coordination tax is simply too high. If people were just permitted to focus on something, anything, I feel the velocity of the entire organization would lift.
How much of your company’s revenue is earned through that product? If it’s significant then the cost of introducing regressions in quality or functionality goes up. As companies grow and mistakes become more costly, they become more risk-averse and invest more resources into reducing risk. This slows things down and requires more people.
Very good point - a huge chunk of the slowdown also comes from all the work around ensuring operational excellence. Monitoring, dashboards, testing, logging, CI. It's an incredible amount of labor to create production quality software on a continuous basis.
Don't forget security updates, migrations, correctness and reliability.
It's quick to get an MVP running that "mostly" works in the happy path. It's much more time consuming to get something that thoughtfully and correctly deals with most edge cases, and has some more 9s.
The work environment of the film industry is a bit different than most jobs too, even for the “technical” production staff that aren’t famous stars. It’s pretty common for people to work 60-hour weeks for a few months, then take the next 3 months off. I wonder if that kind of setup is even possible for the typical startup/software firm.
I don't believe that top actors don't have similarly busy schedules. Meetings with producers, reading scripts, practicing lines, jetsetting around the world for shoots, trying to maintain a family and social life, making public appearances, physical training, managing diets, makeup and costumes, having charitable foundations, etc. If anything they're busier than the average software dev.
There’s a huge element missing here: the ability to take that risk. What would have happened if John Wick had bombed? Keanu Reeves would still have been a movie star, might have considered doing Marvel to raise his profile.
In your regular-ass salaried job, what happens if you spent 8 months on something and have nothing to show for it?
There is quite a bit of short termism in some businesses, this allows for a direct deal of busyness and the cost can just be paid by more busyness in the future. The problem with a movie is that no amount of busyness in the future can resolve the cost of shoddy rushed work.
It seems like commenters have to do the authors job here since the author asks a good question then basically stops writing and doesn’t explore any of the ideas proposed.
> Email is a wonderful thing for people whose role in life is to be on top of things. But not for me; my role is to be on the bottom of things. What I do takes long hours of studying and uninterruptible concentration. I try to learn certain areas of computer science exhaustively; then I try to digest that knowledge into a form that is accessible to people who don't have time for such study.
https://www-cs-faculty.stanford.edu/~knuth/email.html
It's an aspiration for how I want my career to go, though I haven't been very effective at moving in that direction.