9 ms·

There's a meme I've seen making the rounds that is something like - junior engineer: screenshot of code, engineer: screenshot of code, senior engineer: screensh

There's a meme I've seen making the rounds that is something like - junior engineer: screenshot of code, engineer: screenshot of code, senior engineer: screenshot of zoom. To me, what a non-senior engineer and a senior engineer do are so different that they ought to be different career tracks, but this progression seems depressingly organic and inevitable. The more experience you get, the more people come to you for answers. The more people who come to you for answers, the more involved you are in the big things. The more you involved you are in the big things, the less time you have to code. It seems crazy to me that you would spend so much time and effort mastering the arcana of coding only to let it go unused later in your career. It's like if a virtuoso musician were told that he can't play music anymore. He needs to move on to conducting, and after that composing. And he can't just stay at his current level and keep doing what he's been training for years to do. If he wants a future with this orchestra, he needs to exhibit career growth. The expanding business has no place for stagnant employees. Some business somewhere ought to make an effort to let the virtuoso coders keep doing their thing, and break out the engineers who want to go into system design as a separate career track.

epgui 4y ago
This! My dream job is to have none-to-few meetings and to have my head in code all day. I do have something close to this right now, but I really hope that in 10 years I can still be writing code.
- zasdffaa 4y ago
  I'm a dev and I see my job very much in contrast to what you've described. My job is to solve business problems, typically using code, but it all the things around it like requirements gathering etc. It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>" Not to disagree with you, just giving a contrast.
  - VyseofArcadia 4y ago
    Frankly, I see it as my job to write code. That this code happens to solve business problems is a lucky coincidence. Of course, this attitude may be a reflection of the fact that I have never written software for a domain in which I have expertise. Maybe if I were working on a product that I myself used, I would be able and happy to help solve business problems. As is, that is better left to a SME, and I am happy to solve technical problems.
    - rconti 4y ago
      I'd say "your day is spent writing code. That this code happens to solve business problems is why someone pays you to do it".
  - epgui 4y ago
    I don't disagree, but saying my job isn't to write code is like saying a surgeon's job is not to fix people up, or a bricklayer's job is not to lay brick. Anyone's job can be described as "solving a business problem" or "adding value", but that's not usually the best way to describe it unless you're in a room full of MBAs. (And even a bricklayer's job goes beyond "merely laying bricks".) IMO, it goes (or should go) without saying that my work output is valuable, and that I do what I do for a reason, and that "writing code" does not encapsulate everything there is to know about the job.
    - zasdffaa 4y ago
      I once solved an urgent business problem (related to interfaces FYI) by realising there must have been a 3rd party solution. A quick search and I found it. It went onto client sites soon after. To be fair, the problem had to be solved using code anyway (why I was originally brought in), so another team wrote that, but it took several man-years. My interim 'fix' bought the company a lot of time. This isn't a great example as the code had to be written anyway, but you get my point I hope.
      - epgui 4y ago
- unity1001 4y ago
  You will likely get bored eventually. For you'll start to see patterns, you'll start to see much further ahead after some time. You'll be able to see things from a much wider perspective. You will see that there are many things that can be done, must be done, and must be avoided. Many potential opportunities and pitfalls. Your horizon will broaden. You are now able to think and plan much further ahead and you are able to plan much bigger things. But you will notice that you are just one person. Its impossible to do all of that alone. Then you realize that you need to work as a team.
  - epgui 4y ago
    Most engineers I hear say this ("you get bored and after a while it's all the same") don't seem to share my interest for learning very-different languages or academic computer science theory. I am interested in all of that, and I am pretty confident I will never run out of things to learn.
    - epolanski 4y ago
      You say that with few years under the belt. Come in a decade.
      - epgui 4y ago
        I studied biochem for 12 years and know what it's like to reach the edge of human knowledge on a very very very narrow and specialized topic. I know enough about the breadth and depth of computer science to know how insane it is for any one person to think they've run out of things to learn.
        unity1001 4y ago
        > I know enough about the breadth and depth of computer science Its not about learning. Its about creating. After a while, you will have created a majority of the potential things you can create and everything will start to look the same. If you are a CS researcher and will remain as such, your perspective may be applicable. In the actual industry that apps, services are created and provided to the users, its not. So as long as you stay in research and not go into actually making apps, you'll be fine. That is, if constantly learning and not creating does not start to bother you...
lhorie 4y ago
There are two different career tracks, namely IC (individual contributor) and EM (engineering manager). The latter revolves almost entirely around people management. For the IC track, I've found this writing[0] on staff engineer archetypes useful. The gist is that there are archetypes that involve a lot of people management, but there are also some that are highly technical / coding oriented. One analogy that comes to mind is wuxia/murim novels (i.e. stories set in ancient times east asia, involving martial arts sects). Among the strongest characters, there's the sect leader type that is involved in politics most of the time, but there's also the recluse master training in the mountains type. Naturally, there's also plenty of characters clinging to titles, overconfident fools, etc. I think this analogy is interesting because there's a clear parallel between the two worlds in terms of how titles are perceived, the craft that they purport to represent, and their place in the world. Titles can represent both status and mastery, but only loosely at best, the craft can be honed irrespective of both titles and the state of the world, and it's only through increasing a sphere of influence that one can have a sizable impact in the world and its citizens. [0] https://staffeng.com/guides/staff-archetypes https://staffeng.com/guides/staff-archetypes
- tkzed49 4y ago
  Yeah I mean this is a cool concept assuming that you get to choose which "archetype" you progress into, rather than it being dictated by the organization you're working in. It's less cool when you get forced into the people management archetypes, which I feel are way more common in many places, because of the natural progression that GP described.
- PuppyTailWags 4y ago
  Something to note about leader-types and recluse-types: the recluse-types very rarely if ever have influence over the broader org, and if they do, only in limited critical circumstances unique to them (often in the enablement of critical leader-types). I think this is critical to note because an additional complaint by many senior engineers I know of is that they don't have enough influence when managers make dumb decisions or their opinions about the direction of the product aren't valued more than less-experienced product people. That is to say, I don't think the deliniation between IC and Manager work in practice because the influence of even a lower-level manager will often supercede an experienced IC, much to IC chagrin, except ICs also don't want to be in all the meetings managers are in where such influence is exerted.
onlyrealcuzzo 4y ago
At FAANG, I think it would look like: Junior eng: screenshot of code (with some help chat) Eng: screenshot of code (with no help) Senior eng: screenshot of design doc Staff eng: screenshot of calendar with a wall of meetings for 5 days
- yodsanklai 4y ago
  In my team, there are a couple of very senior engineers who still do a lot of coding. They are extremely good. Fix all sort of problems very fast, lot of code review, some design (it's not everyday we design new systems), a lot of useful feedback, communicate very well on what they do, anticipate risks and so on... They manage to keep the number of meetings reasonably low. They are very knowledgeable for sure, but I'm more impressed by their throughput and resistance to stress.
wppick 4y ago
The same is true in other industries. For example, most of the cooking in a professional kitchen is done by the more junior cooking staff. The head chef doesn't actually cook much, but handles more logistics like the ordering of the food/wines and dealing with suppliers, planning the menu, maintaining a high level of service.
alistairSH 4y ago
My employer attempts to solve this by offering several overlapping tracks. Engineer (junior through principal) - screenshot of code Architect (mid-career through principal) - screenshot of system diagram alongside code that implements part of the diagram Technical Fellow (principal+, considered equivalent to directors, but still IC) - screenshot of system diagram alongside overbooked calendar Manager (mid-career+) - overbooked calendar, maybe an IDE on a light day And also product managers and business analysts and others.
- spaetzleesser 4y ago
  “overbooked calendar”: the ultimate status symbol
  - alistairSH 4y ago
    Ha. I wish my calendar was more open. And even when it is a bit more open, I’m often too distracted to write production-worthy code. I can bang out a PoC or do some design work, but sitting down to bang out code just doesn’t happen much any more. Sometimes I think I should go back to being an IC. It was much less stressful and not much less money (vs being a senior manager).
  - deleted 4y ago
    [deleted]
fuzzy2 4y ago
I actually like solving other people’s problems because even if I fail to solve them they’re still other people’s problems. :-D I find distributing knowledge just as important as using it. Help others help themselves. It’s not for everyone! But if you enjoy it, you should consider going that way, even if you still enjoy coding. Or maybe not “even if” but “because”. If you stop coding, you’ll quickly get out of touch. I (also) code in my free time. The most interesting technologies I learn when I’m not coding for work.
nitwit005 4y ago
That's essentially the Peter principle. Skilled people being promoted to a role they are not skilled at.
jakey_bakey 4y ago
It's all about leverage - regardless of if you're a brilliant engineer, you can't have the same impact coding vs exerting soft power on the business to architect a system in the optimal way. And most companies want the brilliant engineers to be the ones making those decisions, hence the pay incentives guiding the brightest towards that direction.
twblalock 4y ago
> It's like if a virtuoso musician were told that he can't play music anymore. He needs to move on to conducting That's because coding skill, once you reach a certain baseline, is good enough and other things like architecture matter far more than raw ability. Unless you are an outlier like John Carmack, improving your coding ability really does not improve your ability to provide business value. The difference between a junior and senior engineer is really the difference in knowledge about what can go wrong, and that knowledge is fundamentally about architecture and edge cases, not coding ability. > Some business somewhere ought to make an effort to let the virtuoso coders keep doing their thing, and break out the engineers who want to go into system design as a separate career track. That does happen, mostly at large companies that can spare the resources. I know a number of people who have been around for decades and make a lot of money doing that.
- bcrosby95 4y ago
  > The difference between a junior and senior engineer is really the difference in knowledge about what can go wrong, and that knowledge is fundamentally about architecture and edge cases, not coding ability. What do you define as part of coding ability? You're making design decisions anytime you code things. Sometimes its smaller scale but sometimes it's larger. Edge cases and consequences of your code are abound in every line you type. Trying to divorce these things from coding ability feels really artificial. If they aren't coding ability, what is? Raw typing speed?
  - twblalock 4y ago
    The difference is understanding the architecture at a higher level: how programs communicate with their dependencies, how to do resiliency and failover, how to scale an entire system of such programs, how to react when something is wrong in such a complex system, and crucially how to design your programs so they can behave as expected when things fail.
    - still_grokking 4y ago
      And how do you program such complex software in the first place if you don't know all those things? Not understanding the architecture means not knowing what you do at all! If you don't know what you're doing you should be strictly prohibited form doing it anyway. Or else you will very likely cause damage. Or do you think it's viable that some programmers require constant hand holding with almost every line of code they write because they otherwise don't know what and how to implement anything correctly? The model "coding monkey" just does not work; as everybody knows…
bee_rider 4y ago
Perhaps we should come up with different job titles for people who do design, and people who do implementation.
JimmieMcnulty 4y ago
The problem is that “just coding” isn’t all that valuable, relatively speaking. College grads can do it barely, and 5 years in they’re fine. What do you do with the rest of the people who, 10 years after that, want to do the same things but get paid 50%+ more? “Virtuoso” coders aren’t worth much (relatively), because it’s not that rare, and honestly bugs aren’t really a big deal. Heck, you can write some pretty terrible code, and as long as it’s not some specific flavors of bad, your company will be totally okay for a very long time.
- tekkk 4y ago
  It depends what you are building. Make a simple CRUD, sure any code-monkey can eventually build one from ground-up even. Move on to something more arcane and complicated, you really need a specialist with eye towards simplicity and maintainability rather than having bunch mediocre coders building some buggy monstrosity. That's how you end up with these bloated and inefficient systems that go millions over-budget. Single virtuoso coder - or just a coder who just actually puts the effort to keep the mess contained - can be the glue that keeps the project actually usable and who in-turn educates others to be better programmers. They may not produce +50% more code than their less senior peers but the code that's in total written will be of much higher quality. That's how I see it. It's like having a great musician in a band - everyone will strive to play better to meet their standard.
  - JimmieMcnulty 4y ago
    That's not really virtuoso, that's just what you get a while (5-10 years, sometimes less) after starting your coding career. My larger point is that they're not worth as much as the coder who can also project manage/lead/mentor/etc, because the latter coder can both be a "virtuoso" (or like 95% of one) and also make the people around them better, and that's substantially more valuable. The thing folks who "just want to code" don't realize is that their "value above replacement" is never going to be high enough to justify the desired pay increase over time that most folks expect as they advance in their careers. That said, it's probably more fine if you want to be 10+ years into your career and accept the pay comparable to those more junior coders. Some people do get this by negotiating fewer hours, for example. And not for nothing, but leading/mentoring is highly achievable for any "virtuoso" coder; not wanting to help others and pitch in on design is a personal choice, as most "virtuoso" coders would probably be great at both if they put in the effort. It just means holding meetings more and coding less, which is outside of their comfort zone and therefore "scary" in some sense. They could be doing so many other great things, I wish they would please try to get over their insecurities and fears! I will help, as that's my job because I did get over those things and transition into this role from a coding role.
ilc 4y ago
For a programmer: Coding is like being fluent in a spoken/written language. Some of us are even polygots. But really... As you go on in life, what you do, and why you do it matter more... because everybody knows how. Duh. /s (But this is really the way of thinking.)
vhold 4y ago
I get the impression that John Carmack has achieved this, and I bet it required him to forcefully take control of his schedule. Which reminds me of this game: https://www.saynomo.re/ https://www.saynomo.re/
btilly 4y ago
When I was at Google it was pointed out that people who got sucked out of coding and into architecture eventually wind up losing contact with what works. After that they might sound smart, but were actually useless for both coding and architecture. There are a lot of organizations where people can be sucked down that career path. If you find this happening to you, switch roles or switch jobs. Because it is an anti-pattern and a dead end.
analog31 4y ago
There are plenty of occupations where somebody gets paid to keep doing their thing. Examples are physicians, K-12 teachers, auto mechanics. I know of no "senior physicians" or "senior teachers." A friend of mine spent his entire career as a tree surgeon, right up to the day he retired. Some of them get paid well enough, or have decent enough pensions, that they retire well before age 65.
- Macha 4y ago
  Senior physicians are called consultant XYZ. Senior teachers are principals, department heads, etc.
  - analog31 4y ago
    Indeed but like senior engineers, they are paid to stop doing the original job that they loved. What I'm saying is that engineering is not unique in this way.
stingraycharles 4y ago
> It seems crazy to me that you would spend so much time and effort mastering the arcana of coding only to let it go unused later in your career. It makes me much happier, though, which is also important.

epgui 4y ago

This! My dream job is to have none-to-few meetings and to have my head in code all day. I do have something close to this right now, but I really hope that in 10 years I can still be writing code.

zasdffaa 4y ago
I'm a dev and I see my job very much in contrast to what you've described. My job is to solve business problems, typically using code, but it all the things around it like requirements gathering etc. It also definitely includes trying to solve business problems by not writing code; by saying "this is a business problem not a technical one, how about trying <some non-coding approach>" Not to disagree with you, just giving a contrast.
- VyseofArcadia 4y ago
  Frankly, I see it as my job to write code. That this code happens to solve business problems is a lucky coincidence. Of course, this attitude may be a reflection of the fact that I have never written software for a domain in which I have expertise. Maybe if I were working on a product that I myself used, I would be able and happy to help solve business problems. As is, that is better left to a SME, and I am happy to solve technical problems.
  - rconti 4y ago
    I'd say "your day is spent writing code. That this code happens to solve business problems is why someone pays you to do it".
- epgui 4y ago
  I don't disagree, but saying my job isn't to write code is like saying a surgeon's job is not to fix people up, or a bricklayer's job is not to lay brick. Anyone's job can be described as "solving a business problem" or "adding value", but that's not usually the best way to describe it unless you're in a room full of MBAs. (And even a bricklayer's job goes beyond "merely laying bricks".) IMO, it goes (or should go) without saying that my work output is valuable, and that I do what I do for a reason, and that "writing code" does not encapsulate everything there is to know about the job.
  - zasdffaa 4y ago
    I once solved an urgent business problem (related to interfaces FYI) by realising there must have been a 3rd party solution. A quick search and I found it. It went onto client sites soon after. To be fair, the problem had to be solved using code anyway (why I was originally brought in), so another team wrote that, but it took several man-years. My interim 'fix' bought the company a lot of time. This isn't a great example as the code had to be written anyway, but you get my point I hope.
    - epgui 4y ago
unity1001 4y ago
You will likely get bored eventually. For you'll start to see patterns, you'll start to see much further ahead after some time. You'll be able to see things from a much wider perspective. You will see that there are many things that can be done, must be done, and must be avoided. Many potential opportunities and pitfalls. Your horizon will broaden. You are now able to think and plan much further ahead and you are able to plan much bigger things. But you will notice that you are just one person. Its impossible to do all of that alone. Then you realize that you need to work as a team.
- epgui 4y ago
  Most engineers I hear say this ("you get bored and after a while it's all the same") don't seem to share my interest for learning very-different languages or academic computer science theory. I am interested in all of that, and I am pretty confident I will never run out of things to learn.
  - epolanski 4y ago
    You say that with few years under the belt. Come in a decade.
    - epgui 4y ago
      I studied biochem for 12 years and know what it's like to reach the edge of human knowledge on a very very very narrow and specialized topic. I know enough about the breadth and depth of computer science to know how insane it is for any one person to think they've run out of things to learn.
      - unity1001 4y ago
        > I know enough about the breadth and depth of computer science Its not about learning. Its about creating. After a while, you will have created a majority of the potential things you can create and everything will start to look the same. If you are a CS researcher and will remain as such, your perspective may be applicable. In the actual industry that apps, services are created and provided to the users, its not. So as long as you stay in research and not go into actually making apps, you'll be fine. That is, if constantly learning and not creating does not start to bother you...

lhorie 4y ago

There are two different career tracks, namely IC (individual contributor) and EM (engineering manager). The latter revolves almost entirely around people management. For the IC track, I've found this writing[0] on staff engineer archetypes useful. The gist is that there are archetypes that involve a lot of people management, but there are also some that are highly technical / coding oriented. One analogy that comes to mind is wuxia/murim novels (i.e. stories set in ancient times east asia, involving martial arts sects). Among the strongest characters, there's the sect leader type that is involved in politics most of the time, but there's also the recluse master training in the mountains type. Naturally, there's also plenty of characters clinging to titles, overconfident fools, etc. I think this analogy is interesting because there's a clear parallel between the two worlds in terms of how titles are perceived, the craft that they purport to represent, and their place in the world. Titles can represent both status and mastery, but only loosely at best, the craft can be honed irrespective of both titles and the state of the world, and it's only through increasing a sphere of influence that one can have a sizable impact in the world and its citizens. [0] https://staffeng.com/guides/staff-archetypes https://staffeng.com/guides/staff-archetypes

tkzed49 4y ago
Yeah I mean this is a cool concept assuming that you get to choose which "archetype" you progress into, rather than it being dictated by the organization you're working in. It's less cool when you get forced into the people management archetypes, which I feel are way more common in many places, because of the natural progression that GP described.
PuppyTailWags 4y ago
Something to note about leader-types and recluse-types: the recluse-types very rarely if ever have influence over the broader org, and if they do, only in limited critical circumstances unique to them (often in the enablement of critical leader-types). I think this is critical to note because an additional complaint by many senior engineers I know of is that they don't have enough influence when managers make dumb decisions or their opinions about the direction of the product aren't valued more than less-experienced product people. That is to say, I don't think the deliniation between IC and Manager work in practice because the influence of even a lower-level manager will often supercede an experienced IC, much to IC chagrin, except ICs also don't want to be in all the meetings managers are in where such influence is exerted.

onlyrealcuzzo 4y ago

At FAANG, I think it would look like: Junior eng: screenshot of code (with some help chat) Eng: screenshot of code (with no help) Senior eng: screenshot of design doc Staff eng: screenshot of calendar with a wall of meetings for 5 days

yodsanklai 4y ago
In my team, there are a couple of very senior engineers who still do a lot of coding. They are extremely good. Fix all sort of problems very fast, lot of code review, some design (it's not everyday we design new systems), a lot of useful feedback, communicate very well on what they do, anticipate risks and so on... They manage to keep the number of meetings reasonably low. They are very knowledgeable for sure, but I'm more impressed by their throughput and resistance to stress.

wppick 4y ago

The same is true in other industries. For example, most of the cooking in a professional kitchen is done by the more junior cooking staff. The head chef doesn't actually cook much, but handles more logistics like the ordering of the food/wines and dealing with suppliers, planning the menu, maintaining a high level of service.

alistairSH 4y ago

My employer attempts to solve this by offering several overlapping tracks. Engineer (junior through principal) - screenshot of code Architect (mid-career through principal) - screenshot of system diagram alongside code that implements part of the diagram Technical Fellow (principal+, considered equivalent to directors, but still IC) - screenshot of system diagram alongside overbooked calendar Manager (mid-career+) - overbooked calendar, maybe an IDE on a light day And also product managers and business analysts and others.

spaetzleesser 4y ago
“overbooked calendar”: the ultimate status symbol
- alistairSH 4y ago
  Ha. I wish my calendar was more open. And even when it is a bit more open, I’m often too distracted to write production-worthy code. I can bang out a PoC or do some design work, but sitting down to bang out code just doesn’t happen much any more. Sometimes I think I should go back to being an IC. It was much less stressful and not much less money (vs being a senior manager).
- deleted 4y ago
  [deleted]

fuzzy2 4y ago

I actually like solving other people’s problems because even if I fail to solve them they’re still other people’s problems. :-D I find distributing knowledge just as important as using it. Help others help themselves. It’s not for everyone! But if you enjoy it, you should consider going that way, even if you still enjoy coding. Or maybe not “even if” but “because”. If you stop coding, you’ll quickly get out of touch. I (also) code in my free time. The most interesting technologies I learn when I’m not coding for work.

nitwit005 4y ago

That's essentially the Peter principle. Skilled people being promoted to a role they are not skilled at.

jakey_bakey 4y ago

It's all about leverage - regardless of if you're a brilliant engineer, you can't have the same impact coding vs exerting soft power on the business to architect a system in the optimal way. And most companies want the brilliant engineers to be the ones making those decisions, hence the pay incentives guiding the brightest towards that direction.

twblalock 4y ago

> It's like if a virtuoso musician were told that he can't play music anymore. He needs to move on to conducting That's because coding skill, once you reach a certain baseline, is good enough and other things like architecture matter far more than raw ability. Unless you are an outlier like John Carmack, improving your coding ability really does not improve your ability to provide business value. The difference between a junior and senior engineer is really the difference in knowledge about what can go wrong, and that knowledge is fundamentally about architecture and edge cases, not coding ability. > Some business somewhere ought to make an effort to let the virtuoso coders keep doing their thing, and break out the engineers who want to go into system design as a separate career track. That does happen, mostly at large companies that can spare the resources. I know a number of people who have been around for decades and make a lot of money doing that.

bcrosby95 4y ago
> The difference between a junior and senior engineer is really the difference in knowledge about what can go wrong, and that knowledge is fundamentally about architecture and edge cases, not coding ability. What do you define as part of coding ability? You're making design decisions anytime you code things. Sometimes its smaller scale but sometimes it's larger. Edge cases and consequences of your code are abound in every line you type. Trying to divorce these things from coding ability feels really artificial. If they aren't coding ability, what is? Raw typing speed?
- twblalock 4y ago
  The difference is understanding the architecture at a higher level: how programs communicate with their dependencies, how to do resiliency and failover, how to scale an entire system of such programs, how to react when something is wrong in such a complex system, and crucially how to design your programs so they can behave as expected when things fail.
  - still_grokking 4y ago
    And how do you program such complex software in the first place if you don't know all those things? Not understanding the architecture means not knowing what you do at all! If you don't know what you're doing you should be strictly prohibited form doing it anyway. Or else you will very likely cause damage. Or do you think it's viable that some programmers require constant hand holding with almost every line of code they write because they otherwise don't know what and how to implement anything correctly? The model "coding monkey" just does not work; as everybody knows…

bee_rider 4y ago

Perhaps we should come up with different job titles for people who do design, and people who do implementation.

JimmieMcnulty 4y ago

The problem is that “just coding” isn’t all that valuable, relatively speaking. College grads can do it barely, and 5 years in they’re fine. What do you do with the rest of the people who, 10 years after that, want to do the same things but get paid 50%+ more? “Virtuoso” coders aren’t worth much (relatively), because it’s not that rare, and honestly bugs aren’t really a big deal. Heck, you can write some pretty terrible code, and as long as it’s not some specific flavors of bad, your company will be totally okay for a very long time.

tekkk 4y ago
It depends what you are building. Make a simple CRUD, sure any code-monkey can eventually build one from ground-up even. Move on to something more arcane and complicated, you really need a specialist with eye towards simplicity and maintainability rather than having bunch mediocre coders building some buggy monstrosity. That's how you end up with these bloated and inefficient systems that go millions over-budget. Single virtuoso coder - or just a coder who just actually puts the effort to keep the mess contained - can be the glue that keeps the project actually usable and who in-turn educates others to be better programmers. They may not produce +50% more code than their less senior peers but the code that's in total written will be of much higher quality. That's how I see it. It's like having a great musician in a band - everyone will strive to play better to meet their standard.
- JimmieMcnulty 4y ago
  That's not really virtuoso, that's just what you get a while (5-10 years, sometimes less) after starting your coding career. My larger point is that they're not worth as much as the coder who can also project manage/lead/mentor/etc, because the latter coder can both be a "virtuoso" (or like 95% of one) and also make the people around them better, and that's substantially more valuable. The thing folks who "just want to code" don't realize is that their "value above replacement" is never going to be high enough to justify the desired pay increase over time that most folks expect as they advance in their careers. That said, it's probably more fine if you want to be 10+ years into your career and accept the pay comparable to those more junior coders. Some people do get this by negotiating fewer hours, for example. And not for nothing, but leading/mentoring is highly achievable for any "virtuoso" coder; not wanting to help others and pitch in on design is a personal choice, as most "virtuoso" coders would probably be great at both if they put in the effort. It just means holding meetings more and coding less, which is outside of their comfort zone and therefore "scary" in some sense. They could be doing so many other great things, I wish they would please try to get over their insecurities and fears! I will help, as that's my job because I did get over those things and transition into this role from a coding role.

ilc 4y ago

For a programmer: Coding is like being fluent in a spoken/written language. Some of us are even polygots. But really... As you go on in life, what you do, and why you do it matter more... because everybody knows how. Duh. /s (But this is really the way of thinking.)

vhold 4y ago

I get the impression that John Carmack has achieved this, and I bet it required him to forcefully take control of his schedule. Which reminds me of this game: https://www.saynomo.re/ https://www.saynomo.re/

btilly 4y ago

When I was at Google it was pointed out that people who got sucked out of coding and into architecture eventually wind up losing contact with what works. After that they might sound smart, but were actually useless for both coding and architecture. There are a lot of organizations where people can be sucked down that career path. If you find this happening to you, switch roles or switch jobs. Because it is an anti-pattern and a dead end.

analog31 4y ago

There are plenty of occupations where somebody gets paid to keep doing their thing. Examples are physicians, K-12 teachers, auto mechanics. I know of no "senior physicians" or "senior teachers." A friend of mine spent his entire career as a tree surgeon, right up to the day he retired. Some of them get paid well enough, or have decent enough pensions, that they retire well before age 65.

Macha 4y ago
Senior physicians are called consultant XYZ. Senior teachers are principals, department heads, etc.
- analog31 4y ago
  Indeed but like senior engineers, they are paid to stop doing the original job that they loved. What I'm saying is that engineering is not unique in this way.

stingraycharles 4y ago

> It seems crazy to me that you would spend so much time and effort mastering the arcana of coding only to let it go unused later in your career. It makes me much happier, though, which is also important.