Sequential tasks are still sequential. The difference is one engineer can you work on many sequential tasks in parallel.
The old way of working where an engineer picks up a ticket and works it through to completion before working on the next one is over. Engineers in my team work on about 5 at a time, sometimes far more. That might mean working on multiple features at once, or working on CI or DX or tooling improvements or bug fixes while building a feature, but the days of working on one thing at a time are well and truly over
Context size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
I absolutely question the attention to detail and work ethic of anyone working on five issues at once, let alone "far more".
I absolutely see all the crap devs who work on 5 tasks at once create.
Basically I try to explain to them they are not paid by amount of tasks they pick up but amount of tasks that are DONE and DONE doesn't mean "yeah it kind of works, I don't have time to fix details because I have 10 other tasks".
Super annoying, yeah we can make follow up fixes - but that's more work not less and if all would be done right just now topic would be closed.
Too late, already got promoted for being a 10x er
I've always worked best this way. Then again, I got my start in support, where step 2 of every ticket was "wait on the response from the user to clarify their issue." Working only a single ticket was not an option.
To this day, I still prefer Kanban to scrum-based workflows.
I wonder if people are honest to themselves whether they actually did have the ability to work on one and only one issue at once.
I mean at some point you're waiting for a build or test run, or you've submitted your work for code review. Do you sit there patiently and wait, or do you open the next ticket, a new tab, a private project, etc? (This predates AI of course)
I was able to go from 5 to over 20 parallel sessions without burnout by changing my role. I switched from engineer to engineering director. I try to focus on directing and deciding. I built a software for that for myself. Two key features:
1. Each project (= one or more repos) gets a canvas. On it, work is laid out as cards. Position and color let me build a mental map.
2. Agents end each card with a demo, which is typically a narrated video of the new feature or bugfix. I review it like an engineering director in a launch review. If I have comments, the agent goes another round.
With this, I don't feel the pain of context switching because I don't need to keep the context all in my head in parallel. I get it presented every time a card wants something from me.
I totally get the task board and I do almost the same thing myself. The demo idea is cool though. It makes sense that whenever the coding agent wants some judgement from you it spends a bit more tokens to make a report optimized for a complete and readable explanation. I doubt it should be a video (videos impose a minimum time required to get through them), but there's certainly a lot more you can do compared to coding agents' default text responses.
I find the time unproblematic. A bug fix is typically 30 seconds, a new feature 1-3 minutes. I want to review those before they go out, and any other way to review them I can think of would take longer.
FWIW, if the work is better shown on an HTML page (e.g. to show stats of a previously flaky test), the agent can do so.
> Context size and ability to context switch without burnout is what will differentiate a median engineer from a great engineer, not technical ability
I thought the ability to multitask in humans was disproven, as it results in lower quality work.
You’re basically selecting for people that are unable to focus properly. Might as well add a TikTok picture-in-picture to keep them engaged.
Different sort of multitasking.
Best as I can tell, every time we've ever tried to study this we've invariably come to the conclusion that the human brain physically cannot handle both constant context switching and deep work, but that lots of people think they can despite all empirical evidence. If you think you've found a new sort of multitasking that bypasses this, call up the neuropsychologists and there could be some sweet, sweet grant money in it for you if the study gets spun up.
Right. Y’all are talking about two different types of multitasking.
>The difference is one engineer can you work on many sequential tasks in parallel.
Then they aren't sequential.
They said "many" sequential tasks in "parallel". Sure the singular task is still sequential, but in the end more is being done.
Including approaching a burnout faster than doing one task at a time.
Is burn out correlated to the number of tasks someone takes on at once? If you can do five tasks in parallel for 6 hours a day, I wouldn't think that would cause burn out.
Burn out is probably just correlated with the amount you overwork yourself. And just like before AI, great engineers tend to have a higher threshold for what they consider overworked.
Thinking about it a little more, the qualities that made an engineer great before AI are still very similar today, but weighed slightly differently.
Sequential implies a sequence, ie many tasks. One single task can't be sequential or parallel. Or you are talking about a feature that is broken in multiple sequential tasks.
they're very clearly talking about multiple independent features, each of which may have sequential lines of work.