Does having a higher paid technical job mean you do not get to code any more?
programmers.stackexchange.com
programmers.stackexchange.com
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.
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.
You resent this?
That does match my experience of working with an "architect." At a relatively small company (just under 100 employees.)
Maybe you are luckier (or the person doing the hiring is smarter.)
How many employees does your company have?
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.
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).
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.
So it's definitely possible to be a very senior engineer and still write code.
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.
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.
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.
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.
YMMV, of course.