9 ms·
Maker's schedule, Manager's schedule (2009)
- derwiki 3y agoI have nothing to add to this specific essay discussion, except that this has been the PG essay I’ve referenced the most over the past 14 years. Wow that feels like a long time.
- drx 3y agoLikewise, and have had many people refer to it as well (including managers!)
- atleastoptimal 3y agoThe important point about this essay is that it brings to light an issue that most people would feel that they'd be blamed as overreacting for complaining about.
- KnobbleMcKnees 3y agoInteresting 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 algorithm design or an architectural green field. Some does, so there's a small nugget of truth, but this is far too great a generalisation. I do agree with the difference in schedule though. Having worked on both IC and mgmt tracks, it was easy to see a whole day fragment in to nothing when needing to get on the critical path.
- lloydatkinson 3y agoThat isn’t made up in the slightest. Creative thought processes take time to get into the flow state. Frequent disruptions to this are deeply frustrating and almost every dev I’ve worked with has made similar remarks. Poor meeting scheduling is a guaranteed way of ensuring your devs have little to no motivation to do anything. In a previous job we called Wednesday “Meeting Wednesday” because total meeting time was at least 4 hours sometimes with small gaps between where nothing would get done. Sure you might be able to do small tasks that truly take less than an hour but in reality that’s rarely the case.
- KnobbleMcKnees 3y agoYour 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.
- smallnix 3y agoYes, both of you only contributed anecdotes and no data. (Neither did I)
- sokoloff 3y agoThe quote doesn’t say that no programming tasks can be done in blocks of an hour, but rather that programming well cannot.
- KnobbleMcKnees 3y agoThe quote says "generally prefer". What programmer generally prefers a half day to complete a sub-hour task?
- williamdclt 3y agoYou’re not disagreeing with your parent, I think their point is that « work restoring creative thought processes » is a subset of the work that a software developer does
- Havoc 3y agoIt's a reference to cost of context shift. Context shift matters a bit less for a manager since they are by definition juggling things already. Doesn't not matter...but less
- KnobbleMcKnees 3y agoI'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 of specific engineers in specific roles and industries.
- oneshtein 3y agoIn professional context, development is driven by a business need: a "feature", a "change", or a "fix". Feature usually requires large number of tickets and multiple iterations, change require few tickets and one or two iterations, fix usually 1 ticket. Each ticket may require number of required steps to be completed, such a coding, testing, integration testing, documenting, reviewing, CI, QA, pushing to production, in production monitoring, reporting,etc. Nobody, except junior developers, will write a unit test out of blue sky. The simplest ticket: a "fix", may require reproduction, automatic test case, debugging, fix in the code, testing, update of documentation, review, CI, QA, push to production, reporting. You can do all that in one sit (half a day), keeping details in the head (harder, but faster), OR you can write off details from the head to the ticket, and then do tasks step by step in small bites, hour by hour, in multiple days (easier, but order of magnitude slower).
- xigency 3y agoNot everything needs to be grandiose. You may need to understand three complex dependencies to write ten lines of code, while thinking of what you actually want to do at the same time. If it took ten minutes to do but 60 minutes to get in the right headspace, hour chunks would still be useless.
- 3y ago
- yard2010 3y agoWith ADHD it's true, unless I'm on some kind of medication, I need time to get into something and once I'm in it's really hard to stop. So if I'm starting to work on something at 17:30 that could take all my night.. I have to plan my day taking this thing into account
- navbaker 3y agoThis is enormous, until I finally got a diagnosis and meds a few months ago, I thought everyone just lived in a constant state of frustration about getting knocked out of focus. It’s absolutely unreal the difference now, it feels like I can drop into focus completely at will, even after interruptions! Makes me wonder what I could have accomplished if I’d gotten a diagnosis decades ago
- mixmastamyk 3y agodiag of what?
- navbaker 3y agoFrom the parent comment: ADHD
- someweirdperson 3y ago> 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. Free time to work between meetings is rarely filled efficiently. An one hour gap is either filled by something that's finshed in 45 minutes with the remaining 15 minutes difficult to fill, or filled by something that takes 1.5hrs and therefore requires a context switch. With meetings its different. They last one hour because they last one hour, not because the content takes one hour to discuss. But like 1 hour slots for work the same is true for fixed 2-week sprints. And for containers on shelves, which cannot be placed where the frames are.
- kzrdude 3y agoIt's not made up. The things you mention are easy to do when you have a structure. You can update a test when the test framework and test suite is already defined. To create a new structure is a bigger undertaking. You can add to existing understanding or analysis quickly if you have an overview. To create a new overview is a bigger undertaking.
- christophilus 3y agoTo each his own, but if I see that I have an hour slot, I prefer to do something like a code review or emails. Even the most menial programming task can easily have a surprise that extends it beyond an hour, and I feel something like anxiety knowing I have a hard interruption coming. Anecdotally, I do like to have discrete, 4 hour blocks of time, and this is something that seems pretty common (though not universal) among the experienced devs I’ve worked with.
- paulcole 3y agoYou’ve got to remember that a significant aspect of his writing is designed to make a certain type of programmer feel special and revered so that they’ll want his company’s VC money.
- q7xvh97o2pDhNrh 3y agoI 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 (or all-week) tasks. And so, with 60 minutes and 3 tasks that might be doable within the time, it becomes that much more difficult to justify investing the time to get into flow exactly because of that unknown ROI. Plus, you need N minutes to get into flow and M minutes on the other side to prep for the meeting, so you only have 60 - N - M minutes to invest anyway. There's a guarantee of an interruption to flow within the hour, but there's no guarantee the probably-small-but-possibly-enormous task will be done by the time that interruption arrives.
- KnobbleMcKnees 3y agoThis 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.
- gymbeaux 3y agoCan you write a program though? Programs are generally “big”, we can safely assume one isn’t writing Hello World for their employer.
- KnobbleMcKnees 3y agoNo, that's not an argument that I'm making. Programming as an activity doesn't preclude the comprehensive creation of a program.
- bambax 3y agoAll true; I have also recently discovered that meetings at the start of the day are not a solution to this problem, because if the meeting is intense (in good or bad, but the effect is more pronounced if the meeting went bad) then you can spend the rest of the day thinking about it. The only solution I can think of about the meeting problem is to have them all in the same day. A day with even just one meeting is ruined, however you organize it. Let's have them all the same day.
- SomeBoolshit 3y agoI don't think I've ever had an intense meeting but the last thing any of them does is ruin my day. My usual response is to not even remember what was discussed minutes after it's over. But I also think most of the meetings I take part in are useless.
- kzrdude 3y agoSometimes you have two meetings at the start of the day and you end up feeling like you spent most of your day's energy on those meetings: they were intense. Usually intense means that new consequences for a project were revealed, new problems, new deadlines, and sometimes intense discussions also resolve problems or the path ahead, but still cost a lot of energy to accomplish.
- afarrell 3y agoIf a work meeting ruins your day by prompting rumination, I think that indicates a separate problem with how your workplace communicates.
- dr_kiszonka 3y agoAnd/or suggests that the person you are replying to could benefit from, e.g., cognitive behavioral therapy.
- gymbeaux 3y agoWe did this at Allstate circa 2015 and it worked really well. I’m not sure how popular this idea was elsewhere in the company, but our team had all meetings on Wednesday (minus the daily scrum). We were remote Monday, Tuesday, Thursday, and Friday. Came in only on Wednesday for the meetings. Wednesday was the perfect day because it was hump day, and it went by quickly typically, because of all the meetings (and coworker conversation). As a software engineer, it was hard to get anything done on Wednesday because coworkers would ping me (in person of course) with questions about the software and so on. Like how can I test this feature, has this feature been pushed to the QA environment, etc. I won’t say that part was necessarily ideal, but being remote 4 days/week allowed me and the other devs to concentrate free of the “annoying” coworkers. This was in 2015, and they’d been doing it for some time prior.
- gregwebs 3y agoWhen 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 this approach, I usually find that an hour of uninterrupted time is sufficient. Of course, this doesn’t somehow mean that meetings are an effective use of time. In my experience, most meeting time is wasted because people are not writing down and organizing what is in their head.
- tajd 3y agoI 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.
- loloquwowndueo 3y agoThe “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ön-bester https://www.linkedin.com/pulse/leave-broken-easily-fixed-shö...
- gregwebs 3y agoI have a really hard time doing strict Pomodoro because I do find there are better and worse times to stop at for focus. I like this article and it's idea of being intentional about the stopping and starting point for the break. Often I take a break when I have the feeling I need to change my approach- stepping away for a bit and coming back a little fresher with some subconscious thinking having gone on. Forced interruptions are harmful, but intentional ones can be very productive.
- nickstinemates 3y agoI 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
- orzig 3y agoI’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.
- WastingMyTime89 3y agoI have been both an engineer doing engineering work (I hate the word “maker”) and a manager. I found this article infuriating and still do. This article is a pure product of this period when software developers thought themselves as extremely special and above such petty issues as having to attend meetings. It’s entitlement masquerading as wisdom. The truth is everyone has to balance their time between obligations and slots they can allocate to do longer work. Writers have to meet their editor. Artists have to plan for the logistic of their exhibitions. That’s part of life. You can work for a bit do something else and get back to what you were doing. If you can’t that’s an issue with you, not the nature of your work.
- afarrell 3y agoAt the end of the day, what matters is getting your job done. If you hire someone, would you rather they be unproductive and avoid talking about this for fear of appearing entitled? Or would you rather they tell it like it is and get stuff done?
- WastingMyTime89 3y agoAttending meetings is part of doing your jobs. Meetings exist for a purpose. The whole attitude that all meetings are somehow a waste of your precious time show that you both are unable to grasp what’s happening and are strongly entitled. I’m not surprised to see it fully on display here considering the readership but you have to understand that it’s why people who interact with developers find them hard to work with and is largely responsible for the stereotype of the software dev as some kind of eternal adolescents you see on display in most business.
- navbaker 3y agoOur group of about 65 is split 2/3 researchers and developers and 1/3 project managers/leads. Since our offices are all along one long hall, we’ve had to be extremely proactive about making sure meetings that involve “makers” are kept to a minimum and they are only allowed to be in the morning to allow for guaranteed blocks of work time. We’ve also gotten really intentional about putting our status on whiteboards on our door so we don’t get pop-ins from managers.
- vegetablepotpie 3y ago> 1/3 project managers/leads That seems quite top heavy. I wonder if your need to be proactive is less driven by the structure of your office and more by the number of bosses you have.
- navbaker 3y agoWe have people from a bunch of other groups working on our projects, we aren’t the only ones
- paul_f 3y agoWe have no meetings at all, other than one weekly a 30-minute standing meeting. Email or slack and no expectation on response time. Been doing that for 5 years with no problems.
- cebert 3y agoI want to work where you work. We have so many pointless meetings, such as daily standups that can take up to an hour each day.
- mactavish88 3y agoDoesn't seem like this dynamic's changed much since 2009 when the article was originally published. Taking the maker's schedule into consideration in small companies seems relatively easy - especially when the CEO's coding alongside you. But I'd be interested to know if there are any medium- to large-sized companies who actively think about this and deal with this problem successfully as opposed to just always giving in to the manager's schedule.
- sokoloff 3y agoAs a now-manager/ex-maker, when I’m setting a meeting with an engineer, I will always try to make mine adjacent to an existing meeting on their calendar, meaning their interruption is longer but at least it’s not an additional interruption. (This isn’t always possible, especially for group/team meetings, but is usually possible for 1:1s.)
- vegetablepotpie 3y agoI 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 and they want to know they aren’t doing anything extraneous because they want to see that their schedule is on track. Productivity is a developer problem. If there is a problem with getting things done, it’s a problem with individual developers and not the environment. The real solution to this problem is to give developers control over their work environment. If developers are in a position to reject meetings and avoid interruptions they are more productive. We’ve seen this happen with WFH and hybrid work environments. This has increased productivity and worker satisfaction. This has also taken away management legibility and alignment and is driving companies to require workers to return to the office despite the benefits.
- gymbeaux 3y agoThe 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 a global event literally forced them to give it a try. It wasn’t all the studies that proved the fruitful outcome of remote work that had any of them consider or adopt it, it was a pandemic. So of course now the same issue lies with the 4-day workweek. They won’t do it unless they’re somehow forced to, either by law (unlikely) or something that’s even outside of lawmakers’ control (strikes?). Anyway, for this reason, I pose that the 4-day workweek is even less likely to gain mass adoption than remote work. To be brash, today’s American workers are pussies, ever-placated by material things and the conveniences of modern society so as to never be too upset with the “arrangement” with Bossman to do something as bold as strike or attempt to form a union. So I guess my point is that many seem to focus discussion on remote work, when really we should be aiming higher. Working remote is the shit, doing laundry during the day is nice, but we all know we can’t go yellow on Teams or lose our green bubble on Slack lest there be hell to pay.
- solatic 3y agoThis 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 for this position to begin with.
- snicker7 3y agoI 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.
- 7znwjshsus 3y agoI 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.
- solatic 3y ago> 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.