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 for this position to begin with.
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).
While I appreciate this perspective, it can’t happen in isolation. You were enabled to be successful. Someone understood that you can’t be 100% of both in your role, and set clear expectations with your peers, directs, a level and two above.
Many startups have inexperienced first time leaders at the top who are still running on pure adrenaline. They work unsustainably (not realizing that yet) and create such expectations for everyone else.
You’re constantly pushing beyond 100% in peace time. Now imagine war time. It gets bad - toxic even.
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.
I completely agree. I do less exercise and more code than you, but I keep seeing that the best teams aren't run by a scrum master or product manager, but by a tech lead who can negotiate and translate requirements. It seems to produce the best results.
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.
> 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.
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."
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.
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.
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.
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 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.
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
I 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.
All 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.
Sometimes 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.
We 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.
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 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.
That 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.
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.
You’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
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.
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.
With 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
This 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
To 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.
It'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.
> 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.
You’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.
It'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
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 of specific engineers in specific roles and industries.
In 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).
Not 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.
I 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.
The 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.
We 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.
Doesn'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.
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 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.
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 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.
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.
That lends itself to the notion that they think writing software is akin to an assembly line, which is quite predictable by comparison. But we aren't writing the same thing over and over and over again. It's like they see the stakeholders describe what they want to the BA and the BA gives the requirements to the SWE and then the QA tests it... and they just envision an assembly line.
As 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.)
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.
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.
I 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.
I don't know about infuriating but I share your perspective.
At the end of the day, most of us expect to get paid for the code we write. At some level, there is a customer who is ultimately paying for this code. You need to communicate with them via some means or you won't be able to do your job effectively. Either you talk to your team on some recurring/ad-hoc basis, or you get to talk to the end customers directly.
Which one would HN prefer? Filtered internal comms channels where you get to whine and moan about basically everything, or the direct fire of the actual customer where everything is on their terms always? What would ruin your "flow" more? A boring 30 minute call where you were informed the customer is "not happy" or a 2 hour, unfiltered rant session from the live customer?
I don't think anybody is suggesting elimination of all synchronous meetings from a workday. There should just be preference given to long, uninterrupted blocks of time where deep work can be done. Many teams even have a single day of the week dedicated to "no meetings" now to provide makers with at least one guaranteed day for deep work.
At 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?
Attending 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.
The article is pretending that having a meeting not only waste half a day but actually waste a full day. Your point B is not reflective of the actual content we are discussing.
The article suggests that makers tend to take on ambitious projects that take large blocks of time to complete. This is objectively true; even today. Most of what is built is ambitious or takes large chunks of time.
Editing some text or repositioning a button or something trivial is 30-min and does not require thought, but most everything is not this. Most everything involves large chunks of time and interrupting this chunk is certainly a disaster.
Our 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.
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.
Please - just don't hire for this position to begin with.