Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

paulgraham.com

Post reply on HN
Print view View original

51–60 of 76 posts

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

#51

Post by gymbeaux »

KnobbleMcKnees wrote: post #4

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.

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

#52

Post by snicker7 »

solatic wrote: 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 had a good tech lead. They did occasional code reviews and made occasional contributions and did some PoCs. But most of that was delegated to the rest of us. He instead instead managed most of the communication with stakeholders and then product manager.

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

#53

Post by 7znwjshsus »

solatic wrote: 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 think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

It's amazing to work with a good team lead like that since you can focus 90% of your working time on getting top priority things done.

What I've seen from the opposite approach is that ICs have a lot of pressure to estimate, plan, document, communicate etc because the managers are too detached from the day to day work. Almost no actual work is getting done because of all the interruptions and endless technical bikeshedding because nobody has either the authority or understanding to call the shots. The ICs compensate for this by working overtime for free.

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

#54

Post by tajd »

gregwebs wrote: post #13

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 also arrived at this approach too! Totally agree with the thoughts here.

Writing things down really helped give me a better perspective on the process I use to organise work as well.

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

#55

Post by solatic »

7znwjshsus wrote: post #53
solatic wrote: 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 think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but…

> I think it works quite well when they focus on architechture, mentoring, product planning, estimation, cross team communication, code review, devops and small feature/config requests. On slow days they can fix those nasty bugs that have been in the backlog for a while, or on tight deadlines they can help in the parts lagging behind in the important project. But yes I can see how this could be considered "bad" IC, but all that gruntwork is work that doesn't need to distract and slow down your team now.

What you're describing is a good manager, period. You can't slot an MBA with no engineering experience into a TL position, to serve as some kind of bureaucrat. When the team's stuck in the weeds, a good leader rolls up their sleeves and helps. It just goes to show what a sorry state the industry is in, that we no longer think of that as intrinsically a leadership skill.

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

#56

Post by ryandrake »

gymbeaux wrote: post #49
vegetablepotpie wrote: post #45

Earlier quoted context omitted.

I work at a large company, and the answer is no. We programers are a naive and innocent bunch that take things at face value. When business people say they want to increase productivity, we take that literally and work accordingly. The dynamic hasn’t changed because managers do not actually want productivity from their developers. They want legibility and alignment. They want to see what their programmers are doing a…

The status quo as you describe it has persisted, it seems, for about as long as the role of “software engineer” has existed. I’ve often said that management treats software engineering as an assembly line and software engineers as assembly line workers- for example, most seem to expect us to be typing, and not typing == not working. Working remote helps this, but we only have these companies being full-remote because…

Software company managers want assembly-line-like predictability out of a process that is more like artwork: Good programming output requires discipline and process, but it also relies on creativity, inspiration, luck, the ability to explore and dabble, following roads down dead ends, and so on.

If you ask most high-ups in your software company whether they would rather a 100% guaranteed release date of Sept. 1, 2023 or a 75% confidence sometime between July and October, if they are honest with themselves, they will admit they would rather have the 100% date. So much other stuff needs to happen on fixed dates. Marketing campaigns need to ramp up, sales teams need to get started, maybe your project is part of a bigger product which has a known release date, maybe your project gets flashed onto hardware that goes on a boat on some fixed date.

It would be so much easier for software companies if making software was like making a bolt or a screw: Raw material go in -> machines do their machining -> product come out a known time later, at a known rate, with a known yield.

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

#57

Post by siliconc0w »

solatic wrote: 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'd do the meetings in the afternoon but the timezones involved prevent that. I'm not the highest-volume IC but I'm reasonably good at identifying high-value targets since I have a lot more context so in the one focus block a day I can do some damage. If it's a bigger project I might just try to start it/find the shape of it and then shop it around to get it on the appropriate teams roadmaps.

It's pretty crazy to me that the people making most of the resourcing decisions in companies were maybe once technical but haven't actually pushed a line of code in years so that muscle has atrophied and this leads to a complete lack of nuance in decision making. So I definitely think you need at least few 'blended' roles who keep their technical chops a bit honed but still participate in the 'command'/resourcing discussions (but of course I'm biased).

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

#58

Post by gregmac »

solatic wrote: 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…

My company had tech leads that are explicitly not managers of the team. There are still managers scattered throughout - some of the tech leads, and some people who are otherwise ICs - but they are always from other teams.

This is an interesting model, because it means when someone disagrees with their tech lead they are explicitly not disagreeing with their manager but with a peer.

The managers also can't assign work (explicitly or implicitly) because they're not even on the same team. This stopped a bunch of non-planned work, such as when a manager said something like "it would be nice if you built x" or asked questions that required a lot of research, as it's too easy for an IC to take that as a directive to actually do it. Now that is more like "good idea, you should ask my tech lead or PM to create and prioritize a ticket so I can do it."

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

#59

Post by loloquwowndueo »

gregwebs wrote: post #13

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…

The “leave it broken but easily fixed” technique sounds somewhat similar / complementary to this. Apologies for the LinkedIn url, it’s the only reference I could find. https://www.linkedin.com/pulse/leave-broken-easily-fixed-shö...
Post reply on HN