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,<p>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.
I'm a developer at a small (500 people) Telco.<p>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.<p>That is the only way to "move ahead with my career".<p>Because of this, my direct manager has absolutely no idea what I do, let alone the 7 levels of management above that.<p>It's completely insane, and that's how the company has always done things.
One of the 3 or so most senior engineers at Google is Sanjay Ghemawat (<a href="http://research.google.com/pubs/SanjayGhemawat.html" rel="nofollow">http://research.google.com/pubs/SanjayGhemawat.html</a>). 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.<p>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.<p>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.<p>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.<p>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.<p>I also find that you help troubleshoot connections between the code and possibilities that could exist -- the crystal ball.<p>Often this can come at a point after coding so many solutions in so many industries that you start seeing patterns and similarities.<p>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.
I commented on this in the Maker/Manager transition article from yesterday: <a href="http://news.ycombinator.com/item?id=4816586" rel="nofollow">http://news.ycombinator.com/item?id=4816586</a><p>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.<p>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.<p>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.<p>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.
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.<p>Generally I object to the question, lets break it down:<p>"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.<p>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.<p>If you want to code all day and make a lot of money your <i>only</i> 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.<p>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
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.<p>YMMV, of course.
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.