Hacker News Reader

Comment by VyseofArcadia | Hacker News Reader

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.

View on HN

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

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.

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.

I have been a senior IC. I spent no time training in the mountains by myself. I spent all my time in meetings attempting to do system design but actually just getting bogged down in politics.

There needs to be a third track. IC (training in the mountains), EM, and IC (planning and design). A lot of orgs would call that last position a PM, but I have never worked with a PM competent enough to actually carry out that kind of work without ICs stepping up to do most of the PMing themselves.

In my experience, PMs are the corrupt bureaucrats that serve as antagonists in wuxia stories.

In many of these organizations, PMs serve to insulate the "planning and design" ICs from conversations with customers.

Not ideal either, IMO, ICs involved in planning and design should get out there and talk to customers themselves!

The most successful software project I've ever worked on, in terms of our utility to the business and our customers, as well as personal satisfaction to the team members, was one where myself and a technical PM handled "planning and design" in lock step with each other. My (former) management tried to build a template out of our success and failed, horribly, because you cannot account for the personalities that sit behind these titles/roles.

> you cannot account for the personalities that sit behind these titles/roles.

This is an important point, and should be more obvious than it is. Projects succeed or fail more as a function of individual personalities than of whatever their job titles are. Easy to forget given that people who share a job title are usually treated as interchangeable components of the machine (at least in big companies and at least in my experience).

Or Architects

Imo, the politics is the design.

Who is going to pay for what? Who's responsible for when a certain part goes wrong?

If you figure out the politics well, you've mostly constrained the system design to something straightforward

Or, you built a poorly architected piece of software that replicates your organizational structure.

It's basically a law of the Universe that your software will look like your org structure. You have to treat it as a hard engineering constraint, just like you'd treat seek latency on a spinning disk, or the speed of light between two data centers. You can't increase the speed of light, but you can still function. Treat org constraints like that.

Or, you build a well architected piece of software that replicates your organization structure if the people (director+) who are in charge of the org structure do their jobs well.

Any organization that designs a system (defined broadly) will produce a design whose structure is a copy of the organization's communication structure.

— Melvin E. Conway

I guess the trick is to flip this by modeling your organization to the system design (i.e. create teams around the components of the system, not components around pre-existing teams). This is easier said than done, and as architecture changes one needs to adapt the organization structure...

it's not a complete solution, as 1/I've seen this cause games of musical chairs happen that essentially stall the work and 2/ creating silos make cross-cutting concerns fail to be addressed...

Hahaha. Perfect.

In systems: Politics is as much a constraint as budget, and technical constraints.

If your manager will not accept way X. It really doesn't matter if X is optimal. You'd better find Y, or convince the manager.

The secret is — when you’re a senior IC, if you think that it’s important to spend 2 days a week coding, you’re expected to tell people to fuck off so you can spend 2 days a week coding.

Starting in 2018, I was a tech lead (at the time, my title was Senior) for 2 teams spanning ~4 years. I have a Staff title today.

Here's my problem with these roles. Going by the definitions from Will Larsen in your link, I am currently expected to be: a tech lead, an architect, and a solver. I engage primarily with tech lead and solver work. I also frequently have to dig in to "regular" IC work tickets. No single individual has the capacity to do all of these things well but the business will see you succeed in some degree with tasks associated to these different roles, fail to recognize that these roles are distinct from each other, and unrealistically expect you to do it all.

I am working with my management on this problem, specifically about expectation setting (because it's a mess, everyone, and I do mean literally almost everyone, has a different idea about what my role confers), but it's frustrating.

Yeah, you've described my challenge exactly. I'm all three and it's annoying. My title is Architect or Principal Architect. Boss sees me and uses me as Tech Lead across multiple teams (and the teams have really needed it). For me it's more about coding standards, best practices, and education than it is about interpreting product needs into stories - we have others for that. Boss's Boss doesn't appreciate that stuff and wants me as Architect, which puts them into battles. And in practice, I get pulled off both to be Solver - they call them "emergent issues", and the hard ones come to me. There isn't anyone technical above me that I can ask for help. Meanwhile I get dinged at quarterly reviews by our scrum-master for not having a predictable velocity.

Story of my life. Please please let us know if you ever come to a satisfactory solution. I'm starting to take my head of the sand about this now, finally.

Tell your scrum master to go jump (or even better don’t work anywhere with a scrum master). If your title is principal architect, then the business expects different things out of you than story points.

> 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.

> 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?

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.

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…

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

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.

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.

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.

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.

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.

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".

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.

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.

I do, and oftentimes as a professional, not taking action (or taking some alternative action, or referring to another professional, etc) is the best thing you can advise a client.

A good surgeon will also very often advise a patient that surgery is not indicated.

> saying my job isn't to write code is like saying a surgeon's job is not to fix people up

A surgeon is a perfect example against your argument -- the surgeon's job is to achieve a positive patient outcome, not to cut someone open. Sometimes achieving the first is best done by cutting someone open, but when it is not then it is the surgeon's job to say that a different approach is needed.

That goes without saying, and is not incompatible with a reasonable reading of what I said.

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.

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.

You say that with few years under the belt. Come in a decade.

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.

> 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...

> After a while, you will have created a majority of the potential things you can create and everything will start to look the same.

This sounds like the famous quote: “Everything that can be invented has been invented.”

It’s as wrong now as it was a century ago. We’re surrounded by opportunities, things waiting for someone to invent them. If you don’t see them, maybe you’re not looking hard enough. I certainly work with plenty of people who feel like we’ve basically solved it, our system works fine. It doesn’t. It’s shit, they just don’t feel like building anymore.

I’m in my third professional decade, for what it’s worth. Far from leveling off in the long run, an IC’s capability is exponential, if you keep trying.

> This sounds like the famous quote: “Everything that can be invented has been invented.”

Thats for science and invention. Not engineering. Less, the current tech space in which we are catering to the public. Even when there are new inventions, it takes decades for one of them to materialize.

You could definitely work in a large research organization, do research with large funding - the research that your funders want you to do, of course. Then you can spend a few decades researching something, and maybe you can invent something new. If that would satisfy you, that's also a career option.

What I'm saying is that it sounds naive to think you will be the same person in one year, let alone a decade and to think that your interests won't change.

We've got only one life, and as much as I like programming and engineering, and fp, maths, logic I really hope life has also other things to show me and enrich me, and I hope I moved my interests elsewhere in a decade.

I think what other commenters are getting at is that at some point you won't be interested in

* manipulating lists with functional programming * manipulating lists with OOP * manipulating lists with a non memory managed language * manipulating lists with a hard type safe language

and will start being interested in * guiding people to manipulate lists as simply as possible to MAKE SOME MONEY

Yeah, I hear that, but there are so many deeper things to learn, and it's totally possible to continue learning these things while building real things and making good money (not necessarily in any job, but there are jobs out there that give you more or less autonomy and latitude).

Proof languages, dependent types, other category theory -inspired abstractions... For example I've been really enjoying reading this journal lately: https://www.cambridge.org/core/journals/journal-of-functiona...

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.

“overbooked calendar”: the ultimate status symbol

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).

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.

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

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.

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.

Senior physicians are called consultant XYZ.

Senior teachers are principals, department heads, etc.

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.

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.

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/

> 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.

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

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.)

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.

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.

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.

Well I would disagree that anyone would get to that level. Some folk just never seem to learn how to properly build and maintain a software project. Sure though I agree that any virtuoso coder should branch out to mentoring and architecting as that's basically expected of them having the experience.

Yet I don't know hour-wise how much they'd have to put in having meetings if they already kinda know how to build the system. I don't think that would necessarily be scary to them, just annoying if they had to be constantly distracted by having to mull over details that aren't that important.

To me a virtuoso is the consultant who knows how to build all parts of the project who is not there to lead the team but will help out anyone in the project - and will take care of it being built properly.

… that’s literally what all the meetings are for, to take care of building the project properly, because you know how to build all of the parts of the product.

There is no level of skill at which anyone will ever just be able to do an entire project on their own; no matter how good you are, you’re always going to be better with others.

+1. Coding is such a wide field - and while there are some areas that one can probably master in a short time (CRUD apps as you mention, which are rather repetitive), there's also a lot of other areas where even people with decades of experience can still learn.

I've worked a lot on networking stacks, protocols and servers, and it found to be extremely specialized. It's unlikely one can an engineer with 5 years of "generic coding experience" which would be immediately productive in the field. I assume the same goes for implementing operating systems, databases, compilers (like LLVM), graphics engines, etc. Sure, a junior engineer that is new to the field could probably also implement something - but it would likely end up less reliable and less extensible and maintainable than if someone who has worked on a similar system before.

At that level it's however also all a bit of a mix between coding/implementation and design. While there's no real "system design" since the piece of software might just be a single component, there are still the usual design questions involved like "how does this component fit into the environment, like the APIs the operating system offers", "how will it be used", "what operational requirements need to be fulfilled", and "how can it be made to be as efficient as possible". Having a good amount of experience on how components will work together will be very helpful.

I agree, but ability to code well may help you to guide others. In case that you can code, you may create diagrams as well. You can also create presentations from code. You can point out what is important to solve given problem and use code as example, show some diagrams that describes given process, describe facts and knowledge that you used to solve this problem.

I still like to code, but today I do it mostly in form of some kind of presentations, this might be informal presentation for developers/operations for given use case, this might be presentation describing deployment/infrastructure/architecture, but in general purpose is to guide less experienced engineers to use efficient methods of solving problems instead of just smashing code together.

Based on my experience, communication barriers are biggest issue in big corporations and it's crucial to communicate your knowledge to others in approachable way, even if solution is technically not optimal. It's described so it can be improved later. However sophisticated solution that is not documented, may technically work better, but it's maintenance nightmare.

Has anyone ever liked situation, where you get alert about production incident and you have no idea how to fix it, because you don't understand what happened? This is a people problem, not technical problem, because you cannot understand everything and either someone will explain system to you or you may have no idea how to react. People that understand people problems will ensure that there's always proper documentation and processes to follow, so no-one is stuck. Technical master will create greatest technical solution, but eventually systems fail and that's where the problem begins, if others don't really understand them.

virtuoso? i'd settle for ability to think and learn. i have been surprised by someone hired as senior software engineer - two levels above me - struggle to understand simple multithreading and synchronization concepts even when provided with an article that gives comprehensive overview of the OS's scheduler.

> 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.

That's why software is a shithole compared with less abstract machines.

As software is eating the world this becomes a greater problem with every year passing. And the even greater problem behind that is that we won't be able to fix the already created mess, ever. The current shithole is almost unfixable as it would require decades of fundamental clean up…

Exactly the above cited attitude brought us into this situation.

It's like all doctors would says: "Well, up to 30% of our patients die while treated, but who cares? You can't get better medical care anyway anywhere because just nobody cares—and it would be actually to expansive to put more caution into this." ¯\_(ツ)_/¯

If that would be the common sense among almost all doctors the patients that make it would be "totally okay" with that likely too; as they would not even know that their chances with most treatments could be much better, if only the doctors would be more willing, and of course capable, in the first place.

The "code is good enough if it works", and "bugs in software are god given" attitude is imho the root cause all evil in software development.

As long as this does not change broadly humanity is doomed to have only bug ridden security nightmares, that barely work, instead of proper "virtual tools". It's even a wonder that actually anything computer related works despite this "who cares" attitude among the majority of coders.

Might be off topic, but are you saying doctors aren't like how you described?

Because while modern medicine has advanced a lot, AFAIK there are still some cases where the quality of medical treatment is exactly how you described. For one, there aren't really any processes in place to ensure doctors actually keep themselves up to date with the latest medical knowledge, so the doctor you see might be say 20 years out of date. And yes, for this example, it would be expensive to fix this, say you enforce a rule that 20% of the doctor's time must be spent on something other than treating patients or revenue generation. So nobody's gonna do this.

At least software doesn't often lead to deaths. At least not directly.

Reply on news.ycombinator.com