Maker’s schedule, Manager’s schedule

“…the mere consciousness of an engagement will sometimes worry a whole day.”

Charles Dickens

One reason programmers dislike meetings so much is that they’re on a different type of schedule from other people. Meetings cost them more.

There are two types of schedule, which I’ll call the manager’s schedule and the maker’s schedule. The manager’s schedule is for bosses. It’s embodied in the traditional appointment book, with each day cut into one hour intervals. You can block off several hours for a single task if you need to, but by default you change what you’re doing every hour.

When you use time that way, it’s merely a practical problem to meet with someone. Find an open slot in your schedule, book them, and you’re done.

Most powerful people are on the manager’s schedule. It’s the schedule of command. But there’s another way of using time that’s common among people who make things, like programmers and writers. They generally prefer to use time in units of half a day at least. You can’t write or program well in units of an hour. That’s barely enough time to get started.

When you’re operating on the maker’s schedule, meetings are a disaster. A single meeting can blow a whole afternoon, by breaking it into two pieces each too small to do anything hard in. Plus you have to remember to go to the meeting. That’s no problem for someone on the manager’s schedule. There’s always something coming on the next hour; the only question is what. But when someone on the maker’s schedule has a meeting, they have to think about it.

For someone on the maker’s schedule, having a meeting is like throwing an exception. It doesn’t merely cause you to switch from one task to another; it changes the mode in which you work.

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect. If I know the afternoon is going to be broken up, I’m slightly less likely to start something ambitious in the morning. I know this may sound oversensitive, but if you’re a maker, think of your own case. Don’t your spirits rise at the thought of having an entire day free to work, with no appointments at all? Well, that means your spirits are correspondingly depressed when you don’t. And ambitious projects are by definition close to the limits of your capacity. A small decrease in morale is enough to kill them off.

Each type of schedule works fine by itself. Problems arise when they meet. Since most powerful people operate on the manager’s schedule, they’re in a position to make everyone resonate at their frequency if they want to. But the smarter ones restrain themselves, if they know that some of the people working for them need long chunks of time to work in.

Our case is an unusual one. Nearly all investors, including all VCs I know, operate on the manager’s schedule. But Y Combinator runs on the maker’s schedule. Rtm and Trevor and I do because we always have, and Jessica does too, mostly, because she’s gotten into sync with us.

I wouldn’t be surprised if there start to be more companies like us. I suspect founders may increasingly be able to resist, or at least postpone, turning into managers, just as a few decades ago they started to be able to resist switching from jeans to suits.

How do we manage to advise so many startups on the maker’s schedule? By using the classic device for simulating the manager’s schedule within the maker’s: office hours. Several times a week I set aside a chunk of time to meet founders we’ve funded. These chunks of time are at the end of my working day, and I wrote a signup program that ensures all the appointments within a given set of office hours are clustered at the end. Because they come at the end of my day these meetings are never an interruption. (Unless their working day ends at the same time as mine, the meeting presumably interrupts theirs, but since they made the appointment it must be worth it to them.) During busy periods, office hours sometimes get long enough that they compress the day, but they never interrupt it.

When we were working on our own startup, back in the 90s, I evolved another trick for partitioning the day. I used to program from dinner till about 3 am every day, because at night no one could interrupt me. Then I’d sleep till about 11 am, and come in and work until dinner on what I called “business stuff.” I never thought of it in these terms, but in effect I had two workdays each day, one on the manager’s schedule and one on the maker’s.

When you’re operating on the manager’s schedule you can do something you’d never want to do on the maker’s: you can have speculative meetings. You can meet someone just to get to know one another. If you have an empty slot in your schedule, why not? Maybe it will turn out you can help one another in some way.

Business people in Silicon Valley (and the whole world, for that matter) have speculative meetings all the time. They’re effectively free if you’re on the manager’s schedule. They’re so common that there’s distinctive language for proposing them: saying that you want to “grab coffee,” for example.

Speculative meetings are terribly costly if you’re on the maker’s schedule, though. Which puts us in something of a bind. Everyone assumes that, like other investors, we run on the manager’s schedule. So they introduce us to someone they think we ought to meet, or send us an email proposing we grab coffee. At this point we have two options, neither of them good: we can meet with them, and lose half a day’s work; or we can try to avoid meeting them, and probably offend them.

Till recently we weren’t clear in our own minds about the source of the problem. We just took it for granted that we had to either blow our schedules or offend people. But now that I’ve realized what’s going on, perhaps there’s a third option: to write something explaining the two types of schedule. Maybe eventually, if the conflict between the manager’s schedule and the maker’s schedule starts to be more widely understood, it will become less of a problem.

Those of us on the maker’s schedule are willing to compromise. We know we have to have some number of meetings. All we ask from those on the manager’s schedule is that they understand the cost.

Text extracted from

O que é Coding Dojo?

Segundo o “Um Coding Dojo é um encontro onde um grupo de programadores se reúne para trabalhar em conjunto em um desafio de programação. Eles estão lá para se divertir, e, através de uma metodologia pragmática, melhorar suas habilidades de programação e de trabalho em grupo.”

O Coding Dojo tem algumas regras básicas:

  • Desenvolvimento guiado por testes: Antes de fazer qualquer implementação, deve ser escrito um teste, que ao passar indica que a implementação está correta.
  • “Passos de bebê”: Se um teste não está passando, você deve escrever o código mais simples possível que faça o teste passar. Quando for escrever um novo teste para o mesmo método, escreva um teste que teste só um pouquinho a mais da funcionalidade desejada.
  • Pair programming: A programação é feita em duplas. Cada dupla tem um piloto e um co-piloto. Ambos pensam em como passar no teste atual, mas só o piloto digita. Cada par tem por volta de 5 a 10 minutos no seu turno. Quando esse tempo acaba:
    • O piloto volta para a platéia
    • O co-piloto assume o lugar do piloto
    • Um novo co-piloto vem da platéia
  • Todos devem entender: O piloto e o co-piloto devem sempre explicar em voz alta o que estão tentando fazer para solucionar o problema. Qualquer um na platéia pode pedir explicações se não entender algum raciocínio.
  • Três fases: Um Coding Dojo sempre está em alguma dessas 3 fases, dependendo do estado dos testes:
    • Vermelha: Pelo menos um teste não está passando. A dupla da vez deve se concentrar em fazer o teste passar. A platéia não deve falar nessa fase, para não atrapalhar piloto e co-piloto.
    • Verde: Os testes acabaram de ser rodados e todos estão passando. Essa é a hora de quem está na platéia dar sugestões para melhorar o código.
    • Cinza: O código foi modificado de acordo com as sugestões, mas a bateria de testes ainda não foi rodada. Deve-se evitar fazer grandes modificações no código nessa fase.

Texto retirado do site

Vídeo Youtube: