Hacker News Reader

Comment by KnobbleMcKnees | Hacker News Reader

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.

View on HN

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.

Yes, both of you only contributed anecdotes and no data. (Neither did I)

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?

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

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 (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

diag of what?

From the parent comment: ADHD

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.

> 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.

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.

Reply on news.ycombinator.com