Live data from Hacker News

Maker's schedule, Manager's schedule (2009)

paulgraham.com

61–70 of 76 posts

Re: Maker's schedule, Manager's schedule (2009)

#61
post #48

This is the problem with "Tech Lead" positions in many startups, i.e. ones where the team leader (managerial role) is expected to also shoulder many IC responsibilities (maker role). You end up either being a good team leader and a bad IC, a good IC and a bad team leader, or doing something unsustainable like being a good team leader from 9 AM - 5 PM and then filling in IC work until 9 PM. Please - just don't hire fo…

The tech lead position is great. It is amazing to work with skilled technical people.

The real position that needs to go away are EM1, EM2, Director, Senior Director, Assistant VP, VP, SVP etc.

These positions are mere reporting chains. They have so much free time that they end up playing politics and performance review games. Nothing they do actually benefits the product.

The ideal structure imo is Tech lead reporting directly to a director. It is the directors job to make strategic choices, and tech lead's job to split the work into composable parts that lead to delivery.

Multiple tech leads can work together, under the direction of the director.

All pay, performance, bonus nonsense should be offloaded to an administrative assistant person whose job title is called administrative assistant.

Make the company more technical, not more managerial.

Re: Maker's schedule, Manager's schedule (2009)

#62
post #17

I’m inclined to agree with all this but when I’m conversation with someone who has only ever been in a Manager schedule, what would you recommend I point to as actual evidence? Specifically on the cost of meetings to developers.

Skip the conversation entirely?

I don't really have this problem, but my co-workers often put several-hour meetings on their calendar with the meeting name and participants hidden. Seems to work to prevent others from inviting them to meetings during that time.

Re: Maker's schedule, Manager's schedule (2009)

#63

When I started doing the pomodoro technique I learned to jot down some notes before taking a break from programming. If there’s more complex things going on it’s worth writing down more in a specification, ticket, etc. For me, the context switching issue can often be mitigated by dumping my brain into written form. Much like testing, it often feels like things are being slowed down, but usually pays itself back. With…

I do something similar. Along every repository I keep a thinking.md where I do some light planning, notes/references for items I have had to look up, etc.

Makes getting back into the flow of a project pretty quick

Re: Maker's schedule, Manager's schedule (2009)

#64
post #48

This is the problem with "Tech Lead" positions in many startups, i.e. ones where the team leader (managerial role) is expected to also shoulder many IC responsibilities (maker role). You end up either being a good team leader and a bad IC, a good IC and a bad team leader, or doing something unsustainable like being a good team leader from 9 AM - 5 PM and then filling in IC work until 9 PM. Please - just don't hire fo…

I'm in a 'TL' role and my current schedule is: * quick dog walk/sunlight * meetings * dog walk/sunlight/lunch/exercise * focus work * dog walk * personal development/curiosity/light work * dinner/etc I actually really enjoy breaking up the day with walks and exercise. I usually try to have at least one day with no meetings for two focus blocks but I found there is definitely diminishing returns there. I think ideally…

[deleted]

Re: Maker's schedule, Manager's schedule (2009)

#65

Earlier quoted context omitted.

Your rarity is another man's frequency. Defining all programming in terms of long drawn out creative endeavours isn't very useful, which is the point I was making to begin with.

The quote doesn’t say that no programming tasks can be done in blocks of an hour, but rather that programming well cannot.

The quote says "generally prefer". What programmer generally prefers a half day to complete a sub-hour task?

Re: Maker's schedule, Manager's schedule (2009)

#66

Earlier quoted context omitted.

I'm aware of context switching but that doesn't apply to finite tasks that fit within a predefined timebox of e.g. less than half a day. And there are a lot of those out there. Presupposing that all programming is in the pursuit of grand designs (i.e. it take half a day to a day to make meaningful progress on any task) is the only thing that would justify it. But the reality is, it isn't like that except for a subset…

> Presupposing that all programming is in the pursuit of grand designs (...) is the only thing that would justify it. Inversely, chopping up developers' days might be one way to keep them small, bug-fixing, value-tweaking, code-pasting peons.

That's fair, there's definitely problems in swinging to the other extreme. But the reality is, both exist.

Re: Maker's schedule, Manager's schedule (2009)

#67

Interesting article that makes some good points but this part >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. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…

Can you write a program though? Programs are generally “big”, we can safely assume one isn’t writing Hello World for their employer.

No, that's not an argument that I'm making. Programming as an activity doesn't preclude the comprehensive creation of a program.

Re: Maker's schedule, Manager's schedule (2009)

#68

Interesting article that makes some good points but this part >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. Seems ... made up? There are all sorts of things you can do in an hour as a programmer: update a test, fix an automation script, fix and/or test a bug. Not all programming starts with grandiose a…

I think this analysis misses the point. The point is not about whether a task ends up being less than an hour. That happens all the time, as you say. The point is that, when beginning the task, it is entirely unknowable whether it's definitely going to fit within an hour or not. Any of the 3 examples you gave — updating a test, fixing some automation, or fixing a bug — are things that can easily blossom into all-day…

This seems to imply that the length of all tasks is unknowable until undertaken, which isn't really true. For those that cannot be estimated ahead of time, I agree with you, but also refer back to my point that all programming tasks do not fit that criteria.

Re: Maker's schedule, Manager's schedule (2009)

#69
post #48

This is the problem with "Tech Lead" positions in many startups, i.e. ones where the team leader (managerial role) is expected to also shoulder many IC responsibilities (maker role). You end up either being a good team leader and a bad IC, a good IC and a bad team leader, or doing something unsustainable like being a good team leader from 9 AM - 5 PM and then filling in IC work until 9 PM. Please - just don't hire fo…

I'm in a 'TL' role and my current schedule is: * quick dog walk/sunlight * meetings * dog walk/sunlight/lunch/exercise * focus work * dog walk * personal development/curiosity/light work * dinner/etc I actually really enjoy breaking up the day with walks and exercise. I usually try to have at least one day with no meetings for two focus blocks but I found there is definitely diminishing returns there. I think ideally…

I try to fix non-urgent bugs or make small DX improvements in the code. It forces me to understand pains in the CI/CD, the codebases in general, but I can drop it for an unplanned meeting without causing problems. I also run toy side-projects outside work.

Re: Maker's schedule, Manager's schedule (2009)

#70
post #48

This is the problem with "Tech Lead" positions in many startups, i.e. ones where the team leader (managerial role) is expected to also shoulder many IC responsibilities (maker role). You end up either being a good team leader and a bad IC, a good IC and a bad team leader, or doing something unsustainable like being a good team leader from 9 AM - 5 PM and then filling in IC work until 9 PM. Please - just don't hire fo…

It is possible. I've done it. You have to guard your time carefully. You and your management have to be on the same page about what you are and are not doing. That's not always the case.
Post reply on HN