> A project spec comes out of those discussions, but the discussions themselves have significant technical and business inputs.
Then managers should learn whatever it takes to be able to make these types of decisions. There seems to be a double standard where engineers have to do all of these non-engineering tasks, meanwhile non-engineers never have to learn the systems in depth.
I think programming is a hard enough job that warrants 90% of focus, at least to be able to reap the benefits of computer science. At the dawn of generative AI, we can clearly see software has no limits, yet limits are implicitly imposed by re-prioritizing an engineer's time with "soft skill" tasks and having them spend a huge amount of time thinking about things that have little to do with computer science.
If a business needs that specific intersection of skillset, perhaps it should be a new role, instead of stretching the role of engineering and missing the opportunity to innovate at the software level, which in the end would help the business anyway.
One engineer on their own can only write so much code. As soon as you have two, you have a team, and the team needs to share information. Fundamentally that's what all those meetings are for (and it's a large part of the job of leadership to facilitate that sharing of information as effectively as possible)
> One engineer on their own can only write so much code.
My first internship, a long time ago, was making HTML websites manually. At the time JS was still young and was not widespread, but I still wrote a custom content management system that would write HTML for me... when I presented this to the people in charge, there was no interest. They didn't care I could do the work faster. They had clients, which payed them by job and not by time. This is just one example of many I experienced of how businesses are blind to how much programmers could add value to their company by simply optimizing their expertise of software engineering. Software engineers are boxed into roles where they are unable to focus on engineering only, and as a result they never achieve the technical level that will allow for domain specific innovations.
So no, engineers don't really have a limit on productivity (granted there is a cost), given that you can write code to write code. There really is no limit, we just have to look at AI.
Then managers should learn whatever it takes to be able to make these types of decisions. There seems to be a double standard where engineers have to do all of these non-engineering tasks, meanwhile non-engineers never have to learn the systems in depth.
I think programming is a hard enough job that warrants 90% of focus, at least to be able to reap the benefits of computer science. At the dawn of generative AI, we can clearly see software has no limits, yet limits are implicitly imposed by re-prioritizing an engineer's time with "soft skill" tasks and having them spend a huge amount of time thinking about things that have little to do with computer science.
If a business needs that specific intersection of skillset, perhaps it should be a new role, instead of stretching the role of engineering and missing the opportunity to innovate at the software level, which in the end would help the business anyway.