Well, I can only tell you that at Google there are no "architect" positions, and people expressing a desire to hold such a position will probably not even get an on-site interview, much less actually get hired. Based on that I would say "no" because you can find senior, high-paying jobs where you code all day long every day,
Personally I find the idea of "architect" to be a bit of an industry anti-pattern. It's a person who hasn't written anything in ten years, essentially. If someone wants to write the design doc and implement the first draft and then other people become interested in contributing to the project, that's just technical leadership. But someone who wants to mostly talk about how they would have implemented something, ten years ago when they still remembered how to code, is useless.
The architect at my company is by far the most talented programmer I know, and his position as architect is more often "programming the cross-functional, low and high level pieces that touch across multiple stacks and helping implement the first stages of large projects" than "sitting around and designing things". I have tons of respect for him and his grasp of subjects across many aspects of programming is profound.
So along with that, I resent the idea that an architect must be some neckbeard who spends his days conjecturing and drafting and doesn't contribute. I know the cool thing now is to have flat-hierarchy companies consisting entirely of coders, but then again Google is a very young. I'd bet in the next five years you'll see people moving into architecture positions much like the one I describe.
Just to be clear, your argument is entirely over a word, and not about anything in reality -- right? Words are pointers to concepts. When you say "architect", you mean something different from what most people mean when they say "architect".
At a market rate of ~$4USD per pound of bacon that puts an average weight developer at the $600-800. Assuming this developer is paid that amount per day it will be about 150k - 200k USD per year. I'd say that would be an accurate amount of money for someone that is worth their weight in bacon.
I See 7 job titles. A couple are hardware designers ("architect" like design a building), a couple are "solution architects" which a name for a pre-sales coach/tutor/guide role, and a couple are buzzword soup in project management that I can't figure out what the role actually is, maybe the fabled software architect being derided here.
By very definition, for me to get promoted and a salary increase, I must move away from technical work and become a people leader/manager. I must also move into a department I have never seen/touched/know nothing about.
i.e. right now I'm coding IP stuff, I might become the manager of a bunch of call center workers.
That is the only way to "move ahead with my career".
Because of this, my direct manager has absolutely no idea what I do, let alone the 7 levels of management above that.
It's completely insane, and that's how the company has always done things.
That does sound like a bad management structure but there is another question to ask:
Are there technical problems that need a highly paid senior engineer to solve efficiently?
Most of the time there isn't and that's a major factor in why the upper levels are people management.
The other factor is that everyone treats this as "just how things work" because of MBA programs and general attempts to apply management pseudoscience from the industrial revolution to modern companies. It's not just your company. Don't know if that should make you feel better or worse.
You don't need a smaller company, just a less stupid one. Any of your major tech companies has a fully technical career path and at least some managers with technical background.
It's terrible to have a manager who is really a frustrated top-level coder, put there by other managers to reward his or her success.
It's true that you need good people skills to advance beyond a certain level of being a coder monkey. Try to find a place that respects technical leadership as a separate entity from people leadership.
(For what it's worth, "architects" who don't code are some of the most useless tech people I know of, and I've generally been less than impressed -- in one case, absolutely horrified -- at the result of not keeping ones fingers in the code).
One of the 3 or so most senior engineers at Google is Sanjay Ghemawat (http://research.google.com/pubs/SanjayGhemawat.html). I always joke that it must be a pseudonym for a group of at least 10 people, judging from the number of files in our core libraries that have his name as the author. That guy is a machine, and it's very good code too.
So it's definitely possible to be a very senior engineer and still write code.
Developers have far more say in how they interpret and be in a "higher paid technical job" than they realize.
There is limited value a non-coder doing technical stuff can enable, and inversely, ultimately a limit to the value a technical/coding only person can contribute if they don't work on understanding the business both at the macro and micro.
I find that you DO code and you do as much steering of the ship, technically, architecturally, to find and head in the direction that the code needs to go to solve problems.
Where does it come from? Over time when you build more and more business technology, you understand more and more of the business than just at a technical or functional spec level.
I also find that you help troubleshoot connections between the code and possibilities that could exist -- the crystal ball.
Often this can come at a point after coding so many solutions in so many industries that you start seeing patterns and similarities.
Being on the ground floor of putting together the proof of concept, and more is invaluable, and I continue to code as much as possible.
At weak engineering companies, senior developers are moved into managing roles because (I believe) the company culture doesn't believe engineers truly provide value. In the traditional model, value is built by supervising larger numbers of people and contributing to more projects. To justify your salary, you have to be "in charge" of more people. It's a traditional hierarchy.
At strong engineering companies, they understand that some engineers are multiple times more productive than other engineers and that those people provide real value. So, people who are good at organizing and directing work are moved (not necessarily promoted) to roles ensuring product delivery while people who are good at hacking keep hacking. The delivery guys aren't necessarily "above" the developer guys. In fact, sometimes it's the opposite.
That's a good way to organize things because it ensures that people do the work they're best at and that the whole system is a meritocracy.
But it's rarefied air at the top of the senior engineer ladder. If you want to get paid $200k/year to write code, you have to provide close to equal value to 4 (very smart) recent grads at $50k/year. Not everyone can do that, so for a lot of engineers shifting to a more supervisory role that more strongly leverages their experience is a more economically viable proposition.
As a business owner I've seen how hard it is to attract quality people in general. There aren't many quality people that bridge the coder+architect skills. It's natural to gravitate towards a suboptimal separation of the two, because not doing so means you can put yourself in a position of resting your business on the shoulders of a superstar. As far as I can tell, the best way to avoid this is to build a good team with overlapping skills and a strong sense of how to solve problems.
Part of it is the unclear definition that allows someone to say they are a coder+architect. Is it software architect? How much is it systems architect?
Some things I look for:
- Find someone who is always solving problems and building things to understand how they work, and how an organization works.
- Find someone who gets that the data is the system. If the individual doesn't have an ability to immediately want to learn the data, what it means, how it interacts in all its stages and the various outputs, you don't have a coder+architect who can put the small details together to come together down stream.
If you look at salary surveys you'll find that management positions top out at a higher pay grade than coding jobs. For example the role 'CEO' can pay 7 figures annually, there is no 'technical' job (even CTO) that pay on that scale.
Generally I object to the question, lets break it down:
"higher paid technical job" - "not get to code" those are the active elements in the question. If all you want to do is write code all day and night, then the amount of money you will be paid to do that will top out these days just under $150,000 in the US. Understand though that pay for technical work is a distribution, some folks will get more than that, but the further 'right' of that number, the smaller the pool of people who can get that kind of money. So the general answer for the exemplar technical person, is about $150K max, individual salaries will vary. And that doesn't include 'bonus' programs.
Management jobs top out around $250K. Again, same constraints, some get more but the further right of that number you go the fewer and fewer the people.
If you want to code all day and make a lot of money your only choice is to leverage your programming. Which is to say you work for a combination of cash and equity in the company you are working for. I made more money off the Sun stock I got as stock options and through the employee purchase plan than I made as salary. It doesn't always work out that way, but unlike salary, equity doesn't have a 'limit' on its growth value. I personally know a number of millionaires, many of them who predominantly wrote code throughout their career, but none of them became millionaires because of salary.
My concern is that if you're counting on 'writing code' to make you rich, you're in for a disappointment. If the code you write is making the company you're with more valuable, and you can share in that value, then you're coding is making you rich in proportion to your equity ownership.
There is similar pattern in other type of industries too.. As you grow in the career path, you move more towards management role.
If you write code, most of the time you spend on very small part of a big software. Your impact is very less on the overall product. Being an architect, you have more impact on the product
You certainly have more of an "impact", but that might be just that everyone hates you.
However I'll go with the nugget of wisdom in your post: Some coding involves lots of hard work to small parts of a program, so you don't have much overall impact on the product.
This is typically because you're doing it wrong. You're either using the wrong language (eg. C for a GUI product), or you're reimplementing wheels when you should be using a library, or you're not able to inspire others to join the project and help out on some details.
Or, very very rarely, what you're doing is ground-breaking and highly skilled. You can only write one line of code each day because it needs so much thought. This is not something that one often associates with "architect" and "program manager" in an organization.
I suggest that you make time for what is important to you and be honest about why you love to code. It's possible that coding for your company is a compromise, anyhow - I made a decision a few years ago to only code on my own projects, and I suddenly love programming as much as I did 15 years ago again. In that way, lending your experience to a dev team without having to roll up your sleeves might be a blessing, because many folks find that doing it for other people doesn't satisfy in the same way as doing it for yourself.
My experience says: there is at least one advantage in differentiating an architect and a developer (I have been both developer and architect). If the developer designs the system, he/she will tend to push the system design towards whatever he/she knows the best in the programming language such as libraries. This will restrict the design. In fact, the developer doesn’t think about the design without thinking about how to implement it. But, the architect who is not good at writing code can think without boundaries.
Our Chief Architect is probably the biggest contributor of code, and I can't imagine it being any other way. He definitely leads by example. Some of our customers (Enterprise) have these 'architect' types that just draw pretty vizio pictures, and I can't see how they aren't just laughed out of the room when it comes time to make actual decisions. But I guess once you have 4+ layers of management and decision making it's easy to fall into crazy town.
Personally I find the idea of "architect" to be a bit of an industry anti-pattern. It's a person who hasn't written anything in ten years, essentially. If someone wants to write the design doc and implement the first draft and then other people become interested in contributing to the project, that's just technical leadership. But someone who wants to mostly talk about how they would have implemented something, ten years ago when they still remembered how to code, is useless.