
Maker's Schedule, Manager's Schedule (2009) - ibobev
http://paulgraham.com/makersschedule.html
======
oftenwrong
This meets with my experience. I rarely have meetings, and I regularly get
solid, 4-hour blocks of productivity. Typically two to three time per week.
Those pushes account for most of my work, and my best work.

I do not schedule those 4 hour blocks because I would not be able to stick to
the schedule. I often have trouble concentrating for even 30 minutes straight.
When I hit 4 hours (and my time tracker sends me a notification to celebrate),
I am always surprised. I get into the zone, and then I find myself still
coding 4 hours later.

Every meeting is a chance to miss that enter-the-zone window.

~~~
pavel_lishin
I'm like this too, and I _hate_ it - because it means I can't _reliably_ get
those four hour blocks.

Not having a schedule isn't a good thing, it just means that if you're ever in
an environment where outside factors become significant (new job, new child),
your productivity gets fucked.

~~~
donkeyd
I have the same issue. I'm managing a team, but at the same time I'm expected
to actively participate toward the sprint goals. Because I keep getting pulled
away for meetings, or to help the other developers, I can't get any focus time
and my velocity is incredibly low. To the non-developers in my team, it seems
like I'm a really slow developer and it's really hard to explain to them that
it's really hard to write code ad-hoc.

~~~
pavel_lishin
I hate to tell you this, but you're probably going to have to commit to
writing less code.

If you're managing a team, your time is probably better spent doing that stuff
- going to the meetings, helping the others developers, etc.

My current manager seems to be in the same situation as you, and he tends to
pick out the shorter, less critical stories to work on.

~~~
donkeyd
Thanks. Unfortunately, though, I'm fully aware of this, it's the people around
me however who seem to be unable to accept this fact.

------
SteveJS
I took this to heart when it was published and ensured I schedule full team
meetings that are as short as possible, and either start a day, end a day, or
are directly adjacent to lunch. I also ensure there are 2 days of no scheduled
meetings.

Another thing that helped me as an IC was keeping notes as a habit. It needs
to become ingrained enough that it isn't blocking flow to jot a note into
OneNote or Evernote. This allows you to 'see' the interruptions later.

I'm more of a 'pile' based note taker, so it's a gigantic list of timestamps +
notes. If you are getting too many interruptions it also provides highly
detailed 'proof' to the person in charge.

More recently I realized that getting distracted today is tremendously easier
than it was in the past. When I find that is an issue I set a meditation timer
to ring a bell every 5 minutes. If I'm not doing what I want to be doing when
that bell goes off, I just go back to doing what I planned. At a certain point
the bell ringing is just a habit to ensure your attention is in the right
place.

~~~
justherefortart
I took over as IT Director at a company with a small team. Everyone would take
their issues to the developer all day long, interrupting his day constantly.
So every new "fire" because the latest task.

Not surprisingly the hacked together new website (which went live months late
and $100s of Ks over budget) was a train wreck. Unreliable and constantly
causing errors/issues.

The first thing I did was said the only person that can talk to the
development team is me. It took about 2 months to get all the software
processes in place that were non-existent, to get the entire website working
and stable, and to get our task/goal list under control.

The cocksucker owner comes to me and says "I want these 4 project you quoted
that would take 6 months done in the next 3 months". So I quit (so did their
lead developer that was doing 90% of the heavy lifting).

IT Management is a mess everywhere I've ever been, just to varying degrees.
Maybe this is because most my career has been as a consultant or contractor,
but it's really discouraging.

~~~
curun1r
I hope you didn't jump straight to quitting. There may have been a legitimate
need to launch something that quickly. When I get requests like that, I
usually explain the immutable rule of software development... deadline,
quality, scope: pick two. Since he wants to adjust the deadline, ask him which
of the other two he'll compromise. One answer, quality, would probably lead me
to quit, since I can't stand delivering stuff that sucks, but if he were
willing to adjust scope of those projects, it's a completely reasonable
request.

~~~
justherefortart
The company was a hard sell for me to even take the job in the first place.
The owner is a piece of shit human being. Once I saw the inside, it's likely
even illegal what they're doing.

So no, I didn't jump. I had to be persuaded to take the job in the first
place. Life is too short for bullshit. I delivered what I said I would, and
when they didn't live up to their end of the bargain, they faced the
consequences I told them they would when I was hired.

------
maxxxxx
Reading the comments here I find it interesting how management totally ignores
feedback from developers. A lot of devs think open offices and endless
meetings are a drain on productivity. So you would think the reasonable
response would be to address these issues to get as much productivity out of
these often highly paid people but instead the top guys often do exactly the
opposite. It's a very curious dynamic.

~~~
seanhunter
This is a constant trope, and every time it's wheeled out a bunch of
developers say they would love more uninterrupted time and their own offices
vs open spaces. Both of these ignore the obvious - you don't optimise on
productivity locally you need to optimise on output of the system as a whole.
Productivity of the system as a whole is significantly improved by
communication. Devs in offices may burn through a ton of tickets very
productively achieving failure by building the wrong thing.

Secondly, people who have never been managers often don't understand the
externalities. As a manager, I've been asked "Why should the devs get so much
better computers/bigger screens etc than us?" Different conditions can create
an intense feeling of unfairness among people who don't get those conditions.
Those types of things can wreck the culture at a company.

Finally, open space is much much more flexible, so easier to change up when
you need people to sprint together on a thing, when you need to scale up your
team etc. Offices are extremely inflexible and typically anchorpoints for
people's perception of their own status. Therefore once someone has an office,
it's practically impossible to get them to not have one any more, even if
circumstances have significantly changed.

It's easy to blame management but it may well be that management have a
totally different set of problems to consider than you.

~~~
abc_lisper
This is a trope argument. You don't have to be connected at the hip with the
rest of the company all the fucking time to make sure you are building the
right thing. We are people, not cattle. You can instead do daily standups to
make sure people are going in a direction you want. People (Management esp)
who never get in the zone, don't fucking get it.

Status, envy, screen size - this is all bullshit. You have never been a good
dev.

~~~
slgeorge
> Status, envy, screen size - this is all bullshit. You have never been a good
> dev.

And in one line you've summarised WHY general office workers often think tech
people are blinkered and entitled with poor social skills. The personal attack
wasn't warranted when someone was trying to explain another perspectives.

------
karthikb
I've tried to keep this top of mind for my team. It hasn't been perfect, but:

(every 2nd) Mondays - Planning

Tuesdays - some meetings for followups, sparingly

Wednesdays - NO MEETINGS ALLOWED (screaming intentional)

Thursdays - some meetings for followups, sparingly

Friday - NO MEETINGS ALLOWED (screaming intentional)

Works fairly well. There's a major increase in the amount of work done on W
and F. However, going to three days without meetings didn't really help, as
the problems we are working on do require lots of whiteboarding and
brainstorming sessions between engineers.

~~~
pkaye
I've found if the teams have mostly senior engineers there is very little need
for meetings. In my current situation we just have one meetings per week to
discuss status and priorities. Everything else is slack chats and adhoc
meetings among individuals as needed. Mostly everyone is in sync on what is
the right thing to do or if not, hash it out in a quick discussion.

~~~
haskellandchill
That's how I love to work. We are adults and most of our workload is
fundamentally adhoc, changing with our business partnerships and market fit.
Unfortunately at my current job we squaded up adding extra meeting load anyone
who works across squads. With weekly planning meetings and standups for every
squad it's rough. Also people treat standups like they are free, why not add
more? Well they are not. I have to fight being put on more than one. It's
already one more than I would like anyway :)

------
floodfx
I wrote an app called MakerSession [1] which was inspired by this essay.
MakerSession automatically blocks out time on your (google or microsoft)
calendar based on when your day starts/ends and how much time you need to get
stuff done...

[1]-[https://makersession.com](https://makersession.com)

------
tquinn
I've run a small distributed team for years, and I've mostly resolved the
manager vs maker challenge through a combination of:

-desynced collaboration tools

-avoiding interruption based tools as much as possible

-short & focused bi-weekly meetings at the front or back end of the day

It allows the majority of the day for a maker schedule, while allowing for
just enough manager time. Also with desynced tools (ex: outstanding
support/bug/etc issues in Trello), as long as everyone is checking in at
regular internals (say 2x a day) -- things can move through fairly quickly
without constant interruptions.

For the manager side I use a mix of:

-Calendar/Contacts

-Evernote

-Workflowy

-Trello

-Slack (at scheduled times, leaving it on all day is horrible idea)

For the maker side:

-Workflowy

-Trello

-Pathjet.com (A small tool that I designed for myself which mixes GTD + Kanban + Pomodoro)

-Prior to my own tool, I used a Pomodoro timer + Workflowy on my machine

-Sometimes I think it's great to get off my machine, and just use a pen+legal pad to do planning/sketching/brainstorming

------
bayindirh
I have been parts of projects which failed just because the manager refused to
accept that developers' need uninterrupted time to start and warm-up to
achieve full speed in their daily routines.

Add micromanagement into this mix, and the environment quickly approaches to
real-life-dilbert.

Addenda: Obligatory dilbert:
[http://dilbert.com/strip/2018-04-21](http://dilbert.com/strip/2018-04-21)

------
jbob2000
The problem I have now is; How can I get the manager to read, understand, and
respect Maker Schedule?

Should I send them this link and then try to explain to them who Paul Graham
is and why they should care about him? Should I send them the wikipedia
article about Flow[1]? Should I show them the clip from The Social Network
about "being in the zone"?

[1]
[https://en.wikipedia.org/wiki/Flow_(psychology)](https://en.wikipedia.org/wiki/Flow_\(psychology\))

~~~
reggieband
I find this comic is helpful: [https://heeris.id.au/2013/this-is-why-you-
shouldnt-interrupt...](https://heeris.id.au/2013/this-is-why-you-shouldnt-
interrupt-a-programmer/)

~~~
codemac
Taking notes in a digital lab notebook (i.e. text file) while I'm thinking has
sped up the re-inflation period significantly from ~1/2 hour to ~1-5 minutes.

I can highly recommend it for folks in very noisy/distracting environments. It
also points out how much you struggle to stay focused if you are _not_
continually writing in your notebook.

------
padobson
Working in the eastern time zone for clients on the west coast has allowed me
to find some ways to solve this problem.

The time difference is about a "half day", the one PG is describing here.

So if I schedule all of my meetings in the afternoon pacific time, I can get a
full day of work done before calling into teleconferences.

So I wonder if some kind of staggered scheduling, like PG described in the
essay, is the answer to this problem.

------
mellett68
I have been keeping one day a week for the manager's schedule- style calls and
appointments.

The rest of the week is divided in to half-day blocks which from my own
experience is the minimum useful time to switch context and complete or work
on some task.

I'd never read this before but it sums up problems I've had in teams
previously with scheduling and especially short-notice "quick" meetings that
wreck an afternoon.

It also means there's sacred time in my calendar for unbillable stuff, which
gives peace of mind rather than thinking "but I could be doing..."

------
voxmatt
We started Clockwise to address this problem, and this PG article was a major
point of inspiration. (Looking through the comments, that seems to be a
trend!)

We just launched a private beta of Clockwise for Chrome, which helps
automatically put more maker time on your team's calendar. It's free and we'd
love everyone's thoughts. Feel free to send me an email if you'd like to hop
the line: matt@getclockwise.com

[https://www.getclockwise.com/product](https://www.getclockwise.com/product)

~~~
rupertdev
This is cool!

Too bad my team is trapped in the Outlook world..

~~~
voxmatt
We'll get there! Had to start somewhere, and Google Cal is a little more
common among early-adopters.

------
ccvannorman
My mitigation strategy is I book calendar time for entire days to work on
stuff. "Want to get coffee on X or Y date?" "Sorry, I'm totally booked those
dates -- how about Z date/time?"

It makes me seem unavailable/scarce, and allows me to book things on my
"manager days". The key is using the calendar to your advantage .. control
your own time.

------
thaumaturgy
I've had to juggle the two schedules he describes for about a decade now. I
haven't been wildly successful, but there are some tactics that seem to make
it work okay.

\- Write code in smaller chunks. This has been a huge change in how I do
software. Almost all my code now starts out as an outline in a series of
comments: "// do this", "// then do that". I write software "outside-in" now;
if I need to slurp a file in one format into a database in another format, I
start with the bits that read the file, then add the code that
translates/interprets/processes the data in the file, then separately add code
that talks to the database, then glue it together. At each step I dump output
to the screen. So, I start with a stupidly simple file-dumping program and
iterate it until it does the whole job.

\- Write less code. Find a framework that you get along with, and stick with
it. This takes away all the joy of learning new things, but you can still get
work done. Develop and nurture your personal code library like you're tending
to a garden; your personal code library should be highly modular, and as
simple as possible, so that you can use pieces of it as often as possible in
your projects, so that it's constantly being improved. Reuse as much as you
can from each project.

\- Do your thinking on the toilet. Or in the shower. Challenging programming
often has two separate aspects, the part where you try to understand the
problem you want to solve, and the part where you write code to solve it. You
don't need to be in front of a computer to do the first part. Likewise, when
you're in front of the computer, try not to do the second part -- just sit
down and bang out code under those outline comments for as long as your
schedule allows.

\- Keep a notepad nearby. I carry a Remarkable everywhere now. I can sit in a
meeting and write things on it and it's a lot less rude than typing on a
laptop or my smartphone. People probably figure I'm just taking notes in the
meeting, but I can be flowcharting or braining out the next piece of code. A
paper notebook works fine for this too.

\- Aggressively guard what's left of your productivity. My cell phone sits
behind me or out of sight; my email tab is closed or on another virtual
desktop; headphones are in. Any problems that I regularly encounter in my
development environment get time set aside to permanently solve them in a way
that's convenient for me. If I find that I need to be able to rapidly switch
between different versions of some software, I work and work on my tooling
until it's just a short commandline statement to do it. As a recent example,
managing unique random passwords for everything was starting to cause a little
bit of friction; a few dozen times a day, I had to switch to KeePass, scroll
down to or search for the appropriate password, copy it, switch windows,
paste. The other day, I wrote "pcp", for "password copy", which takes the
title of a password for an argument, opens my KeePass file, locates the
password, and copies it to the clipboard. I only touch the KeePass UI now to
update the file.

\- And finally, say no sometimes, or push back a little bit on your
boundaries. If you can, find a place to work where you're most productive,
whether it's a different office in the same building (so that co-workers
aren't popping their heads into your workspace), or from home, or a coffee
shop. Make yourself unavailable once in a while so you can get caught up. Take
time away so that you're not also fighting off the inevitable fatigue from
doing lots of context switching all day long. Avoid getting talked into
meetings that are optional where you aren't likely to have much influence.

------
nategri
Oldie but a goodie. Play it again, Paul.

------
eddieschod
[http://calnewport.com/blog/2017/04/05/why-are-maker-
schedule...](http://calnewport.com/blog/2017/04/05/why-are-maker-schedules-so-
rare/)

~~~
dasmoth
This is an interesting follow-up to the original example. I quite like the
proposals he makes (although with some reservations about the extreme one —-
some level of contact with end users is always valuable in my experience)

However, relevant to contemporary software (where nearly every project,
regardless of scale, seems to need a team...):

 _The exception, of course, is that makers working in teams have ways to
communicate within their team._

My experience is that “the team” seems to be a disproportionate source of
interruptions. If anything, I wonder about a system where a manager acts as a
form of message-queue within the team. Pretty much the direct opposite of a
lot if contemporary approaches (...scrum...) but perhaps a bigger increase in
maker-schedule time than focusing on external interruptions.

------
lmilcin
The problem with working at the large company is that every manager will see
open calendar as an invitation to put in some meetings.

For this reason I am booking in my calendar actual working time. Since I am
based in Europe and work with people in both US and Asia, I do this smack in
the middle of the day so that I can have meetings with APAC in the morning and
with US at the end of my working day.

I frequently have managers asking me why my calendar is booked so much to
which I respond, "why YOUR calendar is booked so much". This of course has to
follow with suitable explanation which is more or less based on this essay
which I read many years ago.

------
willholloway
Maker Time is an alternative time keeping system I designed after being
inspired by this essay.

[http://willholloway.net/makertime.html](http://willholloway.net/makertime.html)

~~~
codetrotter
On mobile it’s just showing the number “751” on the middle of the page, the
text “maker time” and a background picture of earth seen from space. Is this
how it is supposed to look? If so, what does it do?

~~~
schrodinger
On desktop there's a "What is Maker Time" link that provides the following:

Your clock has it backwards. Time is infinite, but our time on earth is not.
Clocks should count down, not up. Time keeping should be based on meaningful
celestial events like the year (one earth rotation around the sun) and the day
(one rotation of the earth) Each unit of time should be based on a viable
period of work for makers. Maker Time is reset on January 1st each year. The
year is divided into 1095 blocks (1098 in leap year). Every 8 hours the count
decreases by one.

------
raleigh_user
I cofounded a small agency. I really enjoy it. I spend a lot of time away from
our team and this is no shot at the amazing team we built.

But the time where you're in the zone and able to produce/be creative is
imperative to our growth/success.

I still have meetings but days where I don't I go on really long runs in the
mornings (15 miles or so) and during that time get in a great state of mind.
Then 3-4 hours of awesome productivity and the business seems to keep moving
forward at a rapid pace.

------
lainga
Unrelated to managers, this is why I have trouble doing work when I'm home
from university: "Could you fold the laundry now...?"

~~~
chrisbennet
This! That’s why I have an office that isn’t at home. (I’m a
consultant/contractor.)

------
josephcooney
Pro tip: Decline meetings, as many as possible.

~~~
brazzledazzle
I’ve encountered so many people that assume someone has to come to any meeting
they’ve invited them to and it never fails to blow me away. I can understand
the mindset a bit with managers but it seems to have little to do with title.

It always starts with a message or a call asking where I am. When I tell them
where they let me know I’m late for a meeting. When I tell them I declined it
or I was tentative you can practically hear the gears in their heads grind and
seize up. The thought seemingly had, up until that point, never occurred to
them to check the attendance on the invite before the meeting starts. “But...
I booked it in an open spot on your calendar. Aren’t you available, can you
come? Here’s why I need you here...” This is where it becomes clear to me that
they’ve never considered populating the meeting with more than a subject and a
conference link. They treat an open calendar like you’re some kind of
reservation system.

~~~
chrisbennet
A friend of mine got so sick of the many useless meetings at a company he
worked at that he would just started declining any meetings that didn’t have a
written agenda.

When I schedule a meeting with clients, I send them an email with the
questions I’m going to ask them and what I need to learn from the meeting. As
a meeting attendee, I don’t want to be asked a question that someone knew they
were going to ask before the meeting. I want to hit that meeting with
_answers_ so I’m not having to say, “I’ll look into that and tell you at the
next meeting.”

------
vikasuy42
Check out [http://try-tempo.com/](http://try-tempo.com/)

A few friends and I built this to create more "maker time" for ourselves. It
helps you group your calendar events together for the day so that you get
longer stretches of time to be creative.

Would be honored if you gave it a try!

------
kristianc
I read Dan Pink's book "When" recently, and made a conscious effort to
schedule all of my meetings in what Pink calls admin time between 1 and 3 in
the afternoon. It's a win-win - I can go to the meetings having just been to
the gym, and my morning is freed up for making.

------
blablabla123
I've tried this at 2 companies, one was even my own startup. It seems like a
natural separation but in my experience it alienates the makers from the
business. Probably that's not an issue if you just work for the tech that is
in use. YMMV but if not, it's not the best idea.

------
droosevelt
This is definitely a great model to strive for.

Whenever coworkers try to schedule unnecessary meetings w/ me I send this -
[https://shoulditbeameeting.com/#/](https://shoulditbeameeting.com/#/)

------
kyleblarson
A context switch costs many IQ points and it takes at least an hour to get
them back.

------
nkozyra
This is my number one reason for working at nights outside of normal working
hours.

------
Cofike
This was a major problem at my last company. There were days where meetings
weren't an issue but the support channel we had to monitor was. Ugh

------
Fzzr
I regularly send this to people where ever I work. Never stops being relevant.

