[chadash]

I think that software engineering is about two things: building things the right way and building the right things.

The second one is more important than the first one. If you don't build the right product, it doesn't matter how well it scales or how it has amazing test coverage or wonderful documentation. To that end, I think that too many managers (and companies) do too much shielding of engineers from customers. If you are just given a figma mockup and told "build this", it's easy to get bogged down for a week with the details of building a search bar at the bottom of the page only to realize that the stakeholders would have been OK with a dropdown select. Better to understand the problem you are solving and the only way to really do this is to have some kind of interaction with customers. As an engineering manager, I try to encourage engineers to get on sales calls and see product demos. When you see it from a high level, you a) almost always notice things that need fixing or can be improved and b) see where the piece that you are working on fits into the larger picture.

That said, I find that many engineers don't want to get on customer calls, and usually there's room for those engineers in an organization as well. For example, "build a new video conferencing service for artists to collaborate" would be a very challenging problem (I think) that is not well defined and therefore requires deep customer understanding. "Make Google searches run with 10% fewer CPU milliseconds" is arguably a much harder problem to solve, but it's so well defined that it really doesn't need customer understanding (setting aside the initial decision about whether it makes sense to work on).

[lostemptations5]

As a fellow engineering manager -- I 100% agree. The more your engineers know as much as possible about the customers, the more they will code in the right direction just be understanding.

[spacecadet]

You are given a figma that wasn't already researched and validated against requirements? If it takes a week for a team to fiddle around with a design asset only to learn customers/clients would be fine with a simpler approach, everyone failed the assignment. This was intended as a rhetorical question... I know many teams let designers waste tons of time in a vacuum and PMs are off in lalaland focused on the wrong activities, when they should be focused "building the right thing" and carefully validating that and communicating outcomes to the team and customers. Im all for letting Engineers along for the ride, but too often they (more the jr mid-level ones) are checked out during that process, not asking implementation questions or contributing to research process, until its all hindsight.

[ffsm8]

> but too often they (more the jr mid-level ones) are checked out during that process

Reading this kinda threw me into a loop. Yes, jr and regulars are usually not able to do things generally attributed to senior developers.

Expecting someone that neither knows the implementation nor the language in-depth to be able to do that is kinda monkas

[spacecadet]

I disagree, it's great practice and starting early in a career will only pay dividends later on. It requires the desire to actually want to participate and contribute professionally and not just hide behind a keyboard all day. I get that some people just want to hide behind a keyboard all day- fine. These people often complain the most later on... in my experience.