Maker's Schedule, Manager's Schedule (2009)
paulgraham.com
paulgraham.com
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.
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.
People tend to start trying to work around the outside of those blocks.
Your 4 hour blocks are scheduled. As committments. And cannot be casually preempted.
That's the same with me. Having a block of time where I know I won't be interrupted definitely helps, though - and I've been trying to do that more and more at home.
But it's far easier to concentrate for 4 hours when you've blocked the time and aren't going to be interrupted.
I'll let you work out the rest yourself.
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.
I like it because it's all automatic.
<rant> This has slowly and surely become the top reason for productivity loss at work for me and in my opinion, also for the team that I work in. I have walked out them once I realize there's no valuable input or output, declined them, carried my work in the meeting room, passively attended them, aggressively tried to keep the meeting on track, MoM'ed the hell out of them and just about tried every single trick I've known to get an ounce of productivity from them. And I have failed.
My next attempt is to measure time spent in meetings per sprint and report it out in the retro (meeting, ironically). I have no clue how I can get the people responsible for developer productivity see this gaping hole that are meetings that I don't have to be a part of. </rant>
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.
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.
https://www.amazon.com/Phoenix-Project-DevOps-Helping-Busine...
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.
Resources as a leg also lines up with the observation from The Mythical Man-Month that adding resources to a late project makes it later. (I have experienced this directly.) So resources are rarely mutable to a significant degree; you have the team you have and the budget you have - and you really do not want to see what happens when you suddenly get an unlimited budget!
So I tend to phrase it as every project is either scope-bound or schedule-bound. One of those can flex - which one? If you can't flex either, you will probably fail.
Mornings are my “thinking” time.
The good idea/solution comes to me in the shower or while I’m sleeping and I drive to work thinking about it. I’m usually able to get a good start on implementing it before people can interrupt me.
As a manager, I have never been consulted about work space beyond a general "how do you want to arrange these desks we bought for you?" kind of way.
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.
What sort of change are you imagining which means someone should stop having an office?
That already shows the problem. Why are offices by rank and not by need? From a rational point of view the big guys probably dodn't even need an office because they are either in meeting rooms or traveling. I don't want an office as status symbol but as a place where I can actually think clearly.
As for the rest, you can argue all you want about status symbols and proxies, but once they're entrenched in the company culture it's next to impossible to change them. Rationality doesn't enter this picture... Or when it does it's through cost-cutting initiatives, and we all know how those are great for morale and boosting productivity.
True, but in many cases, one good way to optimise the productivity of the system as a whole is exactly to optimize productivity locally.
Productivity of the system as a whole is significantly improved by communication.
Yes, but being in an office doesn't mean "no communication". Neither does being in an open environment guarantee effective, efficient communication.
Devs in offices may burn through a ton of tickets very productively achieving failure by building the wrong thing.
Same for devs in an open plan environment.
That's an overly-generalized statement. Communication is sometimes helpful, when the people involved are good communicators. Often it's a source of distraction, e.g. email chains with multiple people replying-all to a topic that is at best tangential to what you're working on. There's also an equivalent that occurs with meetings in which people invite everyone they can imagine having any interest in a topic. This strategy has a wonderful way of bringing together a large number of people, most of whom have no valuable input, or interest, in the topic at hand.
The more detailed a job is, the more uninterrupted time it requires. So, if you want quality work and don't want to push the due date, give the person doing the work some uninterrupted time.
I've been a developer for 26 years professionally and, outside IT, I ran a 501(c)(3) of several hundred people. Yes, you can leave people alone to get work done without compromising organizational goals.
If devs are burning through tickets yet building the wrong thing, it’s not the office layout that is the problem. So having an open office environment while changing nothing else in that example simply means they are going to build the wrong thing much more slowly.
You are correct that it’s hard to come back to open space after having an office, but it isn’t for the reasons you mention. The reason is simply because open offices suck.
I don't like open offices either but I don't know if you can throw that out there. Private offices offers a degree of separation (so does working from home) that will probably reduce certain types of both beneficial and nonbeneficial communication.
Those people are ecstatic because everything is working for them.
Many people choose to suffer in silence. So if the office plan is part of their problem they won't complain very loudly. The conversations you see on the internet won't have their input and so what you witness in these threads seems pretty split.
Anyone like me, who tries to play ombudsman, goes around and tries to figure out what people actually think and make sure they get what they need. This is fairly effectively hamstrung by an open office plan because you can't express your fears and doubts in a one-on-one situation. You can't negotiate and coach them to something actionable.
The usual response at this point is "so get a meeting room". Yeah, the thing is that when you take out private offices and put in group work areas, you need to more than double your meeting rooms because you just nearly doubled the number of people you can fit in the building. But that totally ruins your pie chart showing how much cheaper you made your developers, so nobody does the right thing.
(Also, the next time someone increases density at your offices, I highly encourage you to check out the OSHA laws governing the number of people allowed per bathroom stall per gender. It's a good bet your company is violating the rules, or will if they fill all those cubicles)
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.
These are all serious people-management challenges that require competent people-managers working in cooperation to deal with effectively.
Oh 2002 kicked quite a few asses out of offices and back into cubes.
If it is a money problem, don’t lie to developers and tell them that it is “to encourage collaboration” i.e. don’t pee on my leg and tell me it’s raining.
If management truly believes in the collaboration meme, I fully expect them to share a big office. After all, what could be more important than having the gears of management fully meshed?
Either hire low skilled cooks to make your product and control them rigidly (like McDanals) or hire chefs. You can imaging how unhappy (!) a chef would be if you treated them like a Mcdonalds worker.
Overall, engineers think they are Chefs but we all know that this view isn't shared by senior management in many organisations. So to get an exception for developers to share offices while everyone works in open plan would need special evidence. I don't think the evidence for productivity problems for developers is decisive. None of the tech behemoths made it into a big issue - so there's no PR sale of "do it like Google". It doesn't feel like you could tell a CEO that it's _obvious_ that offices are better - it would just sound like special pleading.
You're right that offices are very expensive: the cost savings can be pretty significant. Even industries where it's traditional to have offices (legal) are moving away from it.
It will never be “obvious” to CEO’s that limiting interruptions to developers makes a difference if their mental model won't allow them to consider it.
It’s a bit like the use of torture, studies show that it isn’t effective but that doesn’t stop people from employing it and believing it is effective.
A company with big shared tables for developers is sending the message that the company doesn’t think of devs as “chefs” but as “code monkeys”. Developers should consider this when choosing who they work for.
I've watched a lot of very highly paid people dive into deeply technical and interesting problems that nobody needed a solution to, and fight to protect their time so they could finish. That wastes more time and money than meetings.
Why do you think planning and management is treating people like children?
How do you know what needs to be done? Are you sure you know what needs to be done?
I said stuff like this when I was young just starting out writing software in the film industry. There were dailies and rounds, progress updates twice a day, and I fought them. I was wrong, and it took time for me to understand why.
In my experience since then as both an engineer and a manager, it's clear that knowing what needs to be done at all times is very difficult, and unless you're a one person shop or in research, it involves talking to other people frequently.
If we knew what needed to be done, businesses would never fail, over-engineering wouldn't exist, no deadlines would ever be missed, and no budgets would ever over-run. I've seen a lot of people who think they know what needs to be done. I've never met someone who actually knows what needs to be done most of the time. If you do, you should manage instead of writing code.
FWIW, I don't know if this will help you or irritate you, but as a manager, your response sounds to me (ironically) quite immature. if I got this response from someone on my team, it would be a huge red flag.
Nothing of the things you describe will be prevented by daily status meetings and sitting in one big noisy room.
That does depend entirely on the kind of work you're doing. In film & games, daily is truly necessary. In pure software at LargeCorp, yeah daily status is too much, but it's common to need recurring periods of daily planning. In high flux environments like a small startup, I don't know how to avoid the constant stream of interruption & planning.
Your suggestion of what's wrong feels different than what I imagine as healthy, so I get the feeling we're talking past each other. I don't want constant meetings at all, and I don't love open offices either. But I do want devs to not go off the rails, which even the "adult" professional ones tend to in my experience. As a manager, you've never had devs who would rather work on something other than what the team is supposed to be producing, and rationalize it convincingly and with professionalism?
What is the right frequency of communication at your job? As a manager, you're responsible for team estimates and team progress reports to your manager, no? You are also responsible, I presume, for technical leadership, information sharing, establishing best practices, assisting devs who need help, etc.? Do people on your team ever get stuck and spin their wheels? How often do you track & report your team's progress? Are you putting most of those activities in a different category than meetings? Are you scheduling updates on a Maker's schedule?
My observation from the few large companies I know is that there is a huge layer of management types who basically report to each other and create a lot of busywork without real output. If a developer doesn't know how long something will take they will grill him for estimates until he gives the politically correct number. I rarely see any of them engage in the real problem or help solving them. It's always "When is it done?". And they certainly never listen to complaints and actually act on them. The A/C making a guy sick constantly because it's too cold? This is what a manager should fix but typically they don't. Workplace too loud? Fix it! Stop calling meetings to discuss that already have been discussed.
You can't plan your way to success. It can only be done by actually working.
You’re not kidding. I either get straight up told what the point estimate will be or if I’m lucky I get a couple of numbers to choose from.
Also, not all teams have poor management. That you worked in the film industry where supposedly people had no idea of the priorities daily says nothing about the software industry in general.
My last several jobs involved sync meetings once every 5-10 days. Every meeting took 5 to 15 minutes and we all knew exactly what to do. Intermittent meetings only happened when somebody was blocked.
They will ignore and steamroll any opinion that does not fit whatever arbitrary metric they need to meet, and when your dire predictions come true they will act like there was no possible way to expect them.
(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.
-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
Add micromanagement into this mix, and the environment quickly approaches to real-life-dilbert.
Addenda: Obligatory dilbert: http://dilbert.com/strip/2018-04-21
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"?
It’s like technical debt. No manager is going to disagree that it’s important. But the test is if they ever make time for it or drop the story for something else.
Sure you can't completely rewrite the billing system from scratch in an hour, but you CAN stub out the new architecture. Then each hour after that you fill in a method.
I feel needing 4-9 hour blocks of time means you AREN'T focusing, not that you are "IN THE ZONE"
This process typically only takes a few hours at most and usually illuminates something really unexpected about the problem space. Selecting for coherence is effective at reducing problem scope since it cuts through unquestioned practices: in a more coherent solution all the answers feed into each other.
In my previous methods I would just sit and stare at the problem and sit and stare at techniques until a match of technique to problem came to mind. That's why it took so long - there wasn't a philosophy there, so my thinking could drift in an undirected way for long periods and even get deep into writing code without doing anything effective.
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.
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.
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..."
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
Too bad my team is trapped in the Outlook world..
Can you share where AI fits in the product?
It's not that I'm skeptical of every time a product vaguely alludes to AI in their copy, but... well... I can't think of a way to end that sentence.
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.
- 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.
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.
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.
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.
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.
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.
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.”
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!
Whenever coworkers try to schedule unnecessary meetings w/ me I send this - https://shoulditbeameeting.com/#/