[dumpster_fire]

There's a misunderstanding here due to context. Someone working in a startup (been there) will find it difficult to understand just now much communications are required to get anything done in a large MNC. Out of necessity, people who have pushed enough code to understand the systems have to step up to do the comms instead of being siloed. I had many a time freaked out some other team because the phrasing of my email made them think we're going to dump more work on them. This is the actual difficult part about engineering at scale: Getting everyone on the right page.

You can opt to keep coding, but it won't get you far in your career. Does this mean the communications have more value than actual implementation? It depends. Again, this value differs at different company sizes.

I just got the chance to code again last month, and I've already completed 5 features (code reviewed) that the juniors couldn't complete in a year. I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot.

I stand by my statement. Code is easy and code is cheap. One day you'll understand.

[Tainnor]

It's not as if there are only startups and MNC, though.

My current company is very small, we're less than 15 developers. But it's a multi-tenancy B2B software that has, in some form or another, existed for 15 years, uses tons of outdated tech, where most of the original authors have long left the company, and so on. Getting up to speed with the code base and changing stuff is slow, but not because of organisational red tape - it's because it's really difficult to predict the impact of changes.

[bombolo]

> I stand by my statement. Code is easy and code is cheap. One day you'll understand.

You don't have people under you that can complete in a year what you can complete in a month, and you're still insisting that anyone and their cat can code?

I guess they can code… but evidently not as good?

[FemmeAndroid]

I think you’re overlooking this:

> I won't say they are worse at coding, but more that I am more familiar with how dependencies work because I've already done the same thing when I was a junior. Also, knowing who to ask for help also helps a lot.

I might phrase this a bit differently, but I think it’s getting at my thoughts as well.

I work with developers who would destroy me in a race to implement various search algorithms, or whatever discrete metric of coding prowess you want.

What they struggle with is:

- Efficiently getting other teams to answer their blocking questions in a way that makes the other team happy to work with them.

- Understanding the existing features of our fairly complex stack.

- Judging when to ask for help, and who to go to about a particular problem.

- Identifying dead ends quickly, and pivoting to alternative solutions at the first sign of trouble.

- Incorrect assumptions about the company’s priorities, and how the priorities can help shape the request.

I end up in a lot of meetings, but I also occasionally (a couple times a year on average,) take a few weeks and implement a business goal that a team has been stuck at for months/years.

[dumpster_fire]

The problem was that they only knew how to code.

[bheadmaster]

> One day you'll understand.

Read: I'm (ironically) not good enough at communication to explain my point, so I'll just say a grandiose sentence to convince you I'm right without giving you any useful information.