[jkaptur]

It's definitely interesting how people with the same title can have such different experiences. I'll try to give the other perspective, but please understand that it's a huge topic and this is a simplification.

My experience has been an issue is raised - usually by management or "the business", but sometimes by engineering. "Our website is too slow!". Now someone has to step up and clarify things. Like: * what does "fast" even mean for our website? It would be great to have an objective metric. * Is there such a thing as "fast enough"? * How much time / effort / money is a given improvement worth? * How do we prioritize this vs. everything else we could be working on?

A project spec comes out of those discussions, but the discussions themselves have significant technical and business inputs.

I don't view taking part in these discussions as "extra" responsibility, I view it as a core part of the job. I've also seen what happens when specs are written without technical input: it makes implementing them a lot less pleasant.

[proc0]

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

[krysp]

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)

[proc0]

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

[trav4225]

Apologies for the late reply (too busy!), but thank you for your response. I appreciate it!