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.
sontek · 32m ago
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.
thewileyone · 57m ago
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.
lowlystatsguy · 21m ago
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.
halfcat · 31m ago
> 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.
elzbardico · 3h ago
I work like that, ergo, everyone is the same as me.
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.
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.
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.
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.