When Software Engineers Think They Need More Focus Time(jola.dev)
jola.dev
When Software Engineers Think They Need More Focus Time
https://jola.dev/posts/enough-focus-time
10 comments
> So how do you balance this?
You don’t.
The leader’s job is being available, a high speed router constantly context switching. The IC’s job is the opposite.
Striving to be good at being available and not being available (what?) is like compromising when you can just find the answer. I think it’s 5 and you think it’s 7. Let’s just agree to disagree and call it 6. That’s mediocrity. You could just walk over there and measure it.
But measuring, in this case, doesn’t happen in a planning meeting. It happens when you give the user something to interact with, from which you can get feedback. You give them the thing that has 5 or 7 and let them say, ”what the hell is this? It’s off by a factor of 10. You’re using the wrong units” or whatever. Then you know.
Sitting in meetings and correcting people’s assumptions feels good. But here’s the thing: that’s not actually your job.
You don’t.
The leader’s job is being available, a high speed router constantly context switching. The IC’s job is the opposite.
Striving to be good at being available and not being available (what?) is like compromising when you can just find the answer. I think it’s 5 and you think it’s 7. Let’s just agree to disagree and call it 6. That’s mediocrity. You could just walk over there and measure it.
But measuring, in this case, doesn’t happen in a planning meeting. It happens when you give the user something to interact with, from which you can get feedback. You give them the thing that has 5 or 7 and let them say, ”what the hell is this? It’s off by a factor of 10. You’re using the wrong units” or whatever. Then you know.
Sitting in meetings and correcting people’s assumptions feels good. But here’s the thing: that’s not actually your job.
I disagree with this assumption. I work at organizations that have follow the sun coverage so we ended up having engineers in all timezones even though the majority of engineers are in the USA.
One common thing I've noticed over the years is APAC is always the most productive timezone from an engineering aspect because they don't overlap with the disruptive/time consuming meetings.
They get the most focus time out of any of the timezones.
One common thing I've noticed over the years is APAC is always the most productive timezone from an engineering aspect because they don't overlap with the disruptive/time consuming meetings.
They get the most focus time out of any of the timezones.
Personal experience - it comes down to how good the product manager on my team is.
Bad PM: I need to make sure I am not wasting time building the wrong thing. So I am forced to be "distracted" and play the role of a PM.
Good PM: I need to stay focused building. The PM has already done a great job figuring out what needs to get built. They have given me a good mental model of how the customer thinks.
Sure some facetime with customers is good but the article has a simplistic conclusion.
Bad PM: I need to make sure I am not wasting time building the wrong thing. So I am forced to be "distracted" and play the role of a PM.
Good PM: I need to stay focused building. The PM has already done a great job figuring out what needs to get built. They have given me a good mental model of how the customer thinks.
Sure some facetime with customers is good but the article has a simplistic conclusion.
Hard agree. To me this article just sounds like a breakdown of team structure, or at least someone who has never had a good manager or PM.
Disagree with the generalization. Software engineers need more uninterrupted time. If they need to reach out, let them do it. Otherwise, stop asking for status meetings every 2 hours.
This is a sign of extremely poor management, if your manager is constantly asking for updates and interrupting you, then look for another place ASAP, because either the company is dying or your manager is incompetent ... or both
Companies - even apparently successful companies - still love to destroy productivity with a constant stream of interruptions (email, teams, slack, etc.) which must be responded to immediately in order to maintain employment.
Yep poor management cannot tell the difference between busy and productive - pure unproductive busyness gives the illusion of progress, so as the demands for output increase, they often slow things down even more!
Theres no content here. I think (or I hope) its abundantly clear that when you're writing code for a paycheck, you're solving business problems using code as a tool. Its one of the requirements to progress to a senior engineer.
The question is whether focus time is the best way of doing this and I think yes it is. There are more engineers out there who care about outreach and feedback than the thought leader machine cares to admit. I think the one principle is minimise time to contact with users. As soon as its ready, release. Code that doesnt see the light rots.
The question is whether focus time is the best way of doing this and I think yes it is. There are more engineers out there who care about outreach and feedback than the thought leader machine cares to admit. I think the one principle is minimise time to contact with users. As soon as its ready, release. Code that doesnt see the light rots.
I work like that, ergo, everyone is the same as me.
I notice more and more product manager responsibilities being foisted upon engineers because everyone thinks we need a corporate kool aid mustache of “impact.” Instead, I think we should return to the idea that engineers are craftsmen. They care about doing good work and honing their craft. It is a leaders job to align the goals of the business annd the craftsmen. Unfortunately, our capitalistic society does not have a reward function that aligns with the craftsman’s, in general.
I think AI has poisoned the waters here a bit. It’s brought a fear of relying on AI tools and losing pure skill versus raw productivity. Business folks used to be fussy about timelines, but now they feel even more empowered to push back because AI has brought code to their level. If AI can write code that fast, why can’t you?
The article reads like if someone in the C suite was trying to tell me how to work who has no idea what actually goes on in my day-to-day or willfully ignores my pleas for better system stability and security in lieu of only taking the highest “impact” work (I.e. money). It’s just a greedy algorithm: almost always guaranteed to be suboptimal, but any effort to chart a different, more measured approach is seen by leaders as perfectionistic or even sabotage.
I’m not jaded; you’re jaded.
I think AI has poisoned the waters here a bit. It’s brought a fear of relying on AI tools and losing pure skill versus raw productivity. Business folks used to be fussy about timelines, but now they feel even more empowered to push back because AI has brought code to their level. If AI can write code that fast, why can’t you?
The article reads like if someone in the C suite was trying to tell me how to work who has no idea what actually goes on in my day-to-day or willfully ignores my pleas for better system stability and security in lieu of only taking the highest “impact” work (I.e. money). It’s just a greedy algorithm: almost always guaranteed to be suboptimal, but any effort to chart a different, more measured approach is seen by leaders as perfectionistic or even sabotage.
I’m not jaded; you’re jaded.
I disagree. The real fun is in solving problems. Real user problems are harder than toy coding problems. Contact with users is what gives the craft meaning. Notions such as good code, clean code when chased as goals become stale too quickly. Good code is code other people can read, nothing more. Clean code is code that is modular and flexible enough for the near future. Next up are feature requests and feedback cycles which is the real fun part.
Yeah, I actually don’t disagree with you. I’m speaking from my experience of being told that we don’t even want to modularize the code. It’s just slap the keyboard and make it work literally as fast as possible. The craft is anticipation of user requests, and not building it out in the moment, but knowing how to build it so it’s a smooth transition to the next feature. When you lose the ability to think (what I equate to focus time) before doing, you end up with unhappy developers, users, and managers. Every time I have tried to advocate for thinking first vs. doing first in my circles, I’ve met strong resistance akin to the perfectionistic claims. Even unit tests are seen as developers simply wasting time to make a product perfect despite said product already having hundreds of users and processing millions of dollars daily.
That is not conducive to getting anything complex done and will likely burn the team out and create slop over a period of time.
A better long term approach would be to onboard people and give their time to lean in, understand practice and do their best work.
When deadlines are short, there needs to be a well defined practice and things to quickly execute on, with everything well documented.
A better long term approach would be to onboard people and give their time to lean in, understand practice and do their best work.
When deadlines are short, there needs to be a well defined practice and things to quickly execute on, with everything well documented.
While I see some truth in the article, it misses the point of unimportant interruptions, which might kill productivity. A lot of meetings falls into this category. Many meetings aren't well prepared and are not held in a useful way. So, in my opinion, focus time and social interactions (meetings, calls, helping) should be balanced well.
The author assumes his experience applies to all software development.
It really grates on me when people feel they know the only way to do software development and say you're doing it wrong unless it's their way.
The post might have been more effective had it been worded as an expression of his own personal experience and personal journey instead of telling the reader how to do it.