1) Identify the problem - it invariably isn't to do with code but a combination of time and cost. 2) Can the problem be solved without a line of code, such as changing the process and removing the issue that way? 3) Is there an off-the-shelf application, software or component that will solve the problem. 4) Maybe you do need to code something.

We are also all too quick to just dive straight in at (4) because that's what we identify as, that's what we enjoy and unfortunately what we get paid to do rather than getting paid to think, advise and value-add.

Anecdotally, because I've brought up this issue a lot, I've heard many responses from bother sides. From some engineers, not in the room: "I would never want to be in the room, because then I'd have to work with those people". From other engineers: "They'd never want us there, we're just resources to be used."

From the non-engineers who are in the room: "we didn't know you wanted to be there, of course you're welcome", or "we didn't want to interrupt your work for such a high-level meeting".

I find that the reason for exclusion is either incompetence (in which case, get out), or a lack of awareness that certain engineers are exceptional sources of opinion, in those rooms.

But I've never seen a culture that's pushed engineers into those strategy meetings; it's always been opt-in rather than opt-out. (It's always opt-out for the product org).

But: "Damn those stupid meetings again, wasting my time."

It is like a lot of developers don't consider meetings part of job. I am currently less and less into actual typing of code and much more into understanding what others are trying to accomplish.

On (1), many corporate meeting rooms have terrible ratios, and so they intuitively feel unproductive. On (2), it’s much easier to improve the ratio in code than it is in words spoken by people.

It requires a lot of patience, but in the long game, engineers do improve that ratio in meetings and strategy discussions, and the company benefits from it.

My theory is that most engineers are not interested in playing the long game, because (1) it’s not as fun (2) they don’t plan on being at the company on time scales where the investment will have been worth it.

While I personally don’t emulate their behavior, I think the developers you describe could conceivably be acting perfectly rational for their career goals.

In my experience it is a key skill to objectively evaluate ideas that are different from my preferences and accept those that are good enough, but not use my preferred way of doing things. This is a quick path to get a seat at the table and getting your opinions heard. My 2c.

The only times I've ever found that to be true is when there's other details available that I'm not aware of. Business constraints "everyone knows" about but aren't documented anywhere, for example. Decisions made in a meeting that aren't communicated out, meaning, essentially, that you only are given a portion of the problem and request. This gets back to the 'seat at the table' concern above.

The 'seat at the table' is far more related to interpersonal/political skills than technical ones, but can be chicken/egg in some places.

That said, engineers are a highly opinionated bunch and a group of 5 will have 5 different personal preferences. But they are smart and will quickly recognize an objective opinion that is not hard-driven by personal preferences. Folks with good technical judgement who are willing to accept a different approach quickly become a highly respected member of the community. They frequently end up with more tables offering them seats, in a technical expert role, than they care to occupy.

Programming is an abstraction (a perspective on what the computer is really doing) that is very much shaped by the tools we choose to use. Meta-religion is probably a fair way to describe it, and can be every bit as divisive in some circles.

Also, in saying that, I do believe domain knowledge is far more valuable that programming chops, and not understanding the domain to be able to translate that into an application process is worse that someone with domain knowledge trying to come up with how it should be coded.

Some of the best projects I've worked on involved a lot of sitting and drinking coffee with the domain expert.

This. We don’t get to change the problem after the fact either.

Getting someone who is really skilled can of course be beneficial but it certainly has the problems of retention, things like providing interesting challenges, high compensation. Not all businesses have deeply interesting technical problems. That's fine. There is plenty of use for the wide parts of the bell curve fpr both businesses and developers.

A lot of business software is boring. It does not take skill to do. It only requires someone to know a handful of tools and be willing to put in the time. So my advice to non-FAANG developers: if you want to make development your career, learn to be bored. Still work on marketable skills, learn new languages, etc. But remember that not every task will be an interesting new technical issue, it's probably going to be something you've seen a hundred times before.

I guess it depends on your definition of "skill". ERP systems are complex, full of problems, inflexible and managed by bean-counters with "battle-axe" personalities. If you look at the work holistically, it does take skill and experience. There is a lot of room for improvement in these systems but the problems involve people as much as they involve technology.

is life at FANG really that different tho? Can't imagine that everyone is working on exciting stuff all the time. Would appreciate if someone could enlighten me.

It's not always rainbows and butterflies here either but I do feel much happier with the work I do here.

And once you’re done with that, there’s a whole load more refactoring for the latest language update!

The same software build by a small team of experts would cost both less, and lead to a high quality result.

It might also relate to intellectual satisfaction. A "great" developer could be hungrier in that sense, that they need worthwhile projects to challenge their skills - and may get bored more easily.

If you spend 6 months working on the wrong thing, you aren’t taking responsibility for delivery. It’s a mistake that most smart programmers seem to fall into at some point in their career, when they’re still learning. It’s a classic sign for me of a mid level developer made into a tech lead before they’re quite ready for the role. I’ve seen that happen way more often than I’d like.

If your tech lead is making mistakes like that, your team is operating without a real senior dev at the helm. That’s not insurmountable, but don’t mistake that sort of thing for real expertise.

Do these folks face any consequences for behavior like this?

A Business Analyst focused on figuring out business solutions and constraining those to realistic technological limitations.

An Engineer focused on architecture and implementation.

Seems to me you just chose the BA area of expertise... there is a lot of value in that, but the Engineering side is just as valuable in my book as if you have great ideas and plans but the actual engineering is poor (and vice-versa), your company is going to suffer.

What do you do when management doesn't want to move their business goal? Now you look like you're incompetent and incapable of just doing the damn thing they asked for.

Asking rhetorically, not as criticism, but because I've been there and it fucking sucks when the people who aren't working on the problem think they might have a better understanding of the big picture than they do.