41–50 of 76 posts
Earlier quoted context omitted.
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?
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.
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…
Earlier quoted context omitted.
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 an…
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.…
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…
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.
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…
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…
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…
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.
Please - just don't hire for this position to begin with.
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…
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…
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.
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 ruin…
This was in 2015, and they’d been doing it for some time prior.