[trav4225]

I always find advice like this a little confusing. A lot of these things seem (to me) to be none of the engineers' business.

To me, engineers receive specs from management and implement solutions that meet those specs. And that's it.

I suppose my personal experience must not be how things work elsewhere! Kind of fascinating, and it makes me wonder if people enjoy all this extra responsibility and how things go when engineers disagree with management.

[iteria]

What you're talking about to me is mid-level work. Seniors deal with ambiguity and feasibility analysis. Non-technical people often don't understand the level of tech necessary. They'll say, "I want a bridge about this long" very nice, but but did you consider the about wind that whistles through this area ? Also, how many lanes? Yeah that many is too few because once this bridge goes up we're not gonna be reasonably able to close it even for maintenance. We need at least 4 lanes. Isn't there a cement shortage? Hm.. maybe we can use this material instead? No. I don't think building with wood for this length is a great idea.

You get the picture. Yes lead developers exist, but they only have so much time to do little battles and they're busy making sure the big things are arguing correctly. Senior engineers should be able to talk to design about a redesign necessary because iOS just isn't capable of this it turns out or the cool effect you saw is only available on a version we don't use and can't update to right because complex reason.

If you're just taking your requirements and working without having to negotiate with another person, you're probably not doing senior work.

Some of it I the site I don't think is senior work really unless you're a tiny shop, but they're not weird since these are all skills a for senior adjacent roles that any senior might be called on to take randomly. It's not uncommon in many shops for leads to be a spontaneous and temporary role for some project that disappears on major release.

[trav4225]

Sorry for the late reply (I have been too busy!), but I appreciate your helpful response. Thanks!

[cratermoon]

I'm not even sure that a mid-level engineer would be just taking specs and implementing them. Maybe early-mid, the sort who are moving up from building easy things to building bigger things, but even at mid level an engineer should be able to take ownership of some small set of related features for a system.

[noitpmeder]

Everyone is building to spec. As you get more senior the specs just get more vague ;)

[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!

[nuancebydefault]

Sometimes (often) you feel like following the requirements is not the correct way, because they look fine at first sight but not so bright when doing a first analysis or design. Then you tend to get involved with the "none of my business" business.