[flagged]
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.
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.
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?
> 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.
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.
Over my career I've seen all kinds of people leave coding. Some of them were poor coders and some of them were excellent. Some of them were good or bad communicators or architects.
Out of interest, just who do you think should be doing the high level architecture?
People who will maintain it have more interest in keeping it maintainable, rather than architects that won't actually do any of the work to maintain it, and will not learn from their mistakes.
When things scale up and in bigger orgs though, it doesn't work nearly so well. There are so many different business and technical requirements and strategies to take into account and signed off. This is a full time job. It may lead to really annoying things being imposed on the developers that they would never have chosen.
However, this does not mean that the architects are idiots, although that is of course possible!
High-level architecture at scale demands a level of knowledge that engineers from a specific team might not have, not due to incompetence but because the scope of the team is bounded and the context is very local, at large enough orgs it's not possible even for senior engineers to keep track of all the weird interactions systems have at a higher level, you need someone whose job is to look at a higher level and validate cohesiveness, someone that knows about other similar work being done across other orgs to see points of cross-pollination, etc.
Honestly I can't see how I could depend only on myself and other senior engineers in my team to validate architectures that span cross-org, it'd be exhausting to shift my context all the way up and down architectural layers for every single RFC I write.
I've never seen a competent software architect. They make wild statements, draw some trivial diagrams with impressive sounding words.
Then some diligent programmer discovers that none of it works, silently creates the real architecture. Then the "architect" takes credit for the result.
The days of Internet RFCs that are carefully written are over. We are in the age of agile self-promotion and B.S. (this also applies to foreign policy, with the same results).
Having senior dev / "architect" focusing on higher level / abstract design and working with junior dev to code it and get it up and running is a very common pattern in big company (especially not tech-first company). And it does work.
No? It applies to anyone having the same opinion.
From there, by experience, people who aren't good juniors aren't good seniors. Good juniors might never become good seniors, but bad juniors won't be good seniors.
I don't see what my life history has to do with anything, when we have all the information right here :)
But I must admit that this is karma. For I have had an almost identical take as you more than a decade ago. Feels like I'm looking in a mirror.
Being an expert in the domain of writing code is relatively easy. Being a domain expert of your businesses value and the tradeoffs its making is very difficult. Just because people like the writing code part of the job doesn't make it the end game for the most valuable skillset.