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.
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.
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.
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.
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.
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...
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).
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.
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.
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.
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.
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.
> 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…
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.
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.
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).
> 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.
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>"
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.
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.
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.
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.
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.
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.
+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.
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.
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.
> 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.
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.
Senior Engineer is one of the most abused terms in the industry. Depending on the company it can mean anything from "literally not a novice" to "leads the delivery of complex systems involving several teams". Without context the term has become almost useless.
This. I hate hearing people whine about "still a junior engineer at 25" or boasting that they "reached senior engineer at 24 after 3 years" or whatever nonsense. It's apples and oranges between companies.
To take it a step further, I’ve been in the industry for closer to 15 years than 10, and while I am considered “senior” I don’t consider myself as such. 15 should be the minimum cutoff. Spending 3 years doing __literally anything__ doesn’t make someone an expert. You could argue 10 years but I’d argue back.
It's not direct time, but experience, which is incredibly hard to measure. I've met several engineers that have been working for years and years … and yet seem to have little to no experience. Things like, "why are you writing a parser, in a language you claim to be an expert in, for a language for which the language you're writing in has a parser in its standard library?" And then of course, the people who, if they have the need to use something, will have the docs open next to it as they work with it, diligently Google for answers, seek out tutorials or reference materials … and 3 months later are basically experts in that topic. Age is irrelevant, time is only tangentially related; it's that they put the effort into learning something.
I'm less clear on if it's value. There's "direct value", like, I literally helped make $X, or so. And then there's "what my employer wants done", which might very well be worthless. For the latter, I could argue that I am valuable to them, from their perspective, as I am doing what they desire … even if ultimately it is not worth something.
That is, I've plugged away at many valueless projects, things that the company wanted done, but ultimately won't bring value. Nonetheless, I can bring my experience to bear on the problem and move a mountain or two.
The times I have brought value have usually been quick and unexpectedly. Like, just by being aware of what's running & catching a $20k/month mistake. Or understanding how something is done, to unstick / enable someone else. But it is often not part of my goals, what I am doing day-to-day, or something I get to claim/matters in performance reviews.
And sometimes, you don't get to know what your value is. I remember at one company we had this really onerous customer: completely custom thing was built for them, it was always lots of back and forth, weird corner cases, just lots and lots of custom stuff. We thought we were mostly bending over backwards for someone for little gain. Turned out they paid quite well, but for the longest time, we had no idea: finance didn't share that information with us. And this is true of most companies I've worked for: the financial details are completely opaque, unshared, and I couldn't tell you if I'm bringing value or not, ultimately.
It’s also dumb since I’ve had that title for almost 10 years now but I’m easily 3-5x better at my job than when I initially got it. I do get paid more which is nice and work at a better company. I still mainly like to code and system design so I’m not planning on becoming a professional meeting-goer.
I think the title has seen some inflation in the past years.
When talking with my oldest collogues, those that started out in the 70s, "Senior Engineer" was apparently reserved for, well, very senior engineers. People could have worked 10-15 years, before getting promoted to that.
These days, it's almost something which happens automatically after 5 years. I've even seen people get angry and frustrated if they haven't gotten that promotion after as little as 2 or 3 years.
But to their defense, A LOT of companies just use the various titles to place them in the correct salary bracket. I've seen examples of hiring more junior people than the title would indicate, simply because they were good candidates / seemed to have potential. And then they were stuck without salary promotions for 2-3 years, as their work output didn't necessarily warrant any higher salary.
Lots of weirdness in this industry, compared to the others I've worked in.
To be fair, in the 70s it was much harder to be productive as an engineer. You weren't writing javascript, you were writing fotran, or cobol, or assembly code, or C. Everything was much less "standard" than it was today, from processor instruction sets to compilers to system calls to source control, etc. It took A LOT of work to understand all the arcane knowledge and become productive. Nowadays, you can read some books, deploy your code to AWS where it runs with 99.99999999% x-platform consistency. The benchmark of being a senior engineer is not "p85 engineer" its "has demonstrated ability to deliver value at specified scope" and its just takes less time to learn everything you need to do that now. Can a person with 3 years XP be a senior? No, they can be a sophomore (think they know it all but mess everything up), but do you need 15 years experience to be a true senior, no you do not.
I don’t see why there is so much emphasis on years. I have 15 years experience myself but I’ve met people with 5 years that were clearly superior to me at leading large scale engineering efforts.
Skills and experience aren't the same thing. The second amplifies the first. If you aren't good at/don't like leadership then finding less senior people who are better at it is not going to be hard. Fortunately leadership is only one skill among many that are valuable in engineering.
It's because companies got liberal with titles. Probably in part due to how fast pay has increased. It's seen as commonplace now, so people expect this fast progression.
reading around the internet, people put way to much emphasis on titles like senior. people also seem to act like there is a standard for senior across companies. even in a company i've seen senior titled people doing work with the same scope or have the same responsibility as junior people.
ime the only thing you can count on the term senior meaning is that you're in a different pay band then other levels. other then that the term is meaningless.
At my employer it extends to staff/principal engineers.
They do the same low-level code work, but I'll hand it to them that they are some of the best engineers at the company.
The difference is that principals left the company for a couple years to come back for the higher pay. Staffs were promoted while staying at the company.
A "senior" title often equates to a pay range in companies. This can lead to employees that want/need to get paid more (and leadership wanting to retain/hire them) getting a senior title without the expected experience.
My title was recently changed to Sr Software Engineer. I only have about 3 years of experience (though I would say they are some good quality years spanning a ton of different properties and projects).
I just happen to be at the top of our small (less than 10) team of in house developers, so tricky things are escalated to me and I do my best on them.
No kidding. I think part of the reason is also the huge amount of people flooding into dev roles, so having 2-4 years of experience puts you ahead of 70% (random number) of the other applicants, who all have 1-2 years, and you're relatively 'senior' (compared to other industries, where it would require several times longer, at least). That plus the depressingly reductionist Medium-article-writing culture with people elaborating on how to become ~Senior~ in three simple steps. Context is everything here.
Hell yeah, what I've seen in the past year of job hunting what they asked from a senior devs, are either or in combination of (ordered by number of occurrence):
- expert at programming
- dev ops
- business / system analyst
- team lead or project / people manager
- automated test engineer
- product owner
It's almost feels like they're searching for a unicorn
I will add my contextual industry experience. When I started out roughly 20yrs ago a "Senior" engineer started at 10yrs experience. Junior was < 5yrs. Intermediate between.
One of the first steps to title inflation was people started to include internships and their time in college as "years of experience" . So this meant new grads could have 5 years experience in their minds. Part of this is fair because if the industry is going to start a 12 week boot camp person at 0, there should be _something_ for the 4 year bachelor.
One of the few companies that I have seen to have constantly kept the bar is Amazon. I have seen many other who have just inflated the titles to keep folks happy.
I always take these "If you don't pass this litmus test, then you aren't an XXX," or "Only an XXX will pass this litmus test" articles with a grain of salt.
In my experience, the litmus test is frequently one that the author of the article can easily pass, which makes them an XXX, by default, and the article is really just about how awesome XXXs are, or the author assumes they have the authority to bestow the mantle of XXX unto others.
The word "senior" means "Has more responsibility/experience." That's about it. It can mean "Manages/directs others," but doesn't have to be that. It can mean "Is an architect," but that doesn't mean they are.
I have watched senior blacksmiths at work (awesome, BTW), and they got their hands dirty, and their aprons spotty, just like their juniors.
I was a "Senior Manager," but was only a first-line manager. The title was really just there, so I could have an office, and the folks in Japan would take me slightly more seriously. Banks can have hundreds of "Vice Presidents," that work in cubicles, and don't have any direct reports. It's really just a title.
I'm definitely a "senior engineer," these days, and I architect stuff, but I don't manage or direct others, and the scope of what I do, is smaller, because, every time I count myself, it comes up "1."
It's really up to each organization to define "senior," and to set up a professional environment that implements their definition.
Litmus tests are fine, I guess. I fail them all deliberately, because I'm an ornery sumbich. I won't join any club that would have me as a member.
As someone promoted to senior software engineer three times in my career, in a rather short interval, I can tell you with reasonable certainty that the title means nothing.
Not even a year into career as a developer, and being hired as a Junior, I just started interviewing as a Senior, and then got a Senior position with the salary to match it. First year I thought I'd be "found out", but apparantly there really is no bar for entry.
I don't want to give the impression that I'm knowledge gating, I'm not, in fact, one of my mottos is to try to make myself redundant. Even if I succeed there, more work will find me. With that caveat out of the way, when you're Senior and paid accordingly, I agree that day to day you may not be more productive than someone else, but the pay delta, and it can be significant is like a retainer. At least that's how I've come to see it. I'll give you my 40 hours a week, but if a critical situation comes up, I, the senior, am there, knowing which levers to pull to resolve the situation quickly.
In big tech, I see a lot of “senior” engineers get there by virtue of being on the team 5+ years. Rarely are they substantially better, but they are very good at attending meetings, gate keeping domain knowledge, and using their political connections
I've kind of found the opposite. I'm at a bigger / reasonable well-known tech company now (FAANG types would probably call it a 'tier 2 company', and there are rigorous standards for proving your worth at promotion time.
It's a huge change from my 25 years in industry at 'smaller' / less prestigious companies where most promotions happened because it's the only way my boss could get me a 5% instead of 4% raise, or whatever. Or in other companies where they gave you a promotion INSTEAD of a raise. In all my previous companies, it happened just because somebody gave it to you, not because you met any real standard.
There's a rubric of requirements. Technical proficiency, leadership, mentorship, cross-functional impact. If you want to be cynical about it, sure -- it can mean you drive projects just for the impact, you lead internal conferences, you hold meetings, you mentor, whatever, all for the self-serving benefits of promotion.
And you definitely get the whiff of that occasionally from certain initiatves people take on.
But I generally find it pretty positive and inspiring to see how it encourages people to grow, and how it drives the tone of the organization. For example I've never worked somewhere where it was so encouraged to take on tasks outside of your comfort zone. To suck at things, and learn, and get better -- versus staying in your own little hole and getting very good at your specific role, but no more.
They also have experience on what doesn't work. This doesn't mean they are great at the job, but is often a big advantage over someone who is otherwise better but doesn't have experience.
Yeah. When I was tasked as a senior software engineer to choose a file system for one of our embedded device, I used bonnie+ and iodisk to evaluate and on a 10GB SDD disk in 2005.
I gained crazy insights but was unable to published because it was done on company’s dime.
We call that “Trade Study”.
Good times, good times.
(This was before Phoronix’s popularity)
What’s crazy was that ReiserFS came out ahead for the read/write data flow composition modeling that we were using.
At most places I've worked being a senior engineer mostly meant being patient and being good at countering management's bullshit. Those two traits can get you far.
I totally agree with the premise that while technical knowledge is crucial, it shouldn't be the determining factor of whether someone is a Senior Engineer. What is also important is the ability to communicate effectively and mentor other developers.
I think there are lots of things that a Senior should be better at, in fact anything that is part of the job:
* More emotionally mature
* More pragmatic
* More business aware
* More recruitment aware
* Better at whatever process you are running
* More security aware
* More performance aware
But more than all of this, ideally there would be an objective progression ladder to ensure they have actually done all of these things not just assume they have because they worked somewhere for 10 years and was called "Senior"
Agreed. The "value" of the senior engineer is not that they write code faster than a junior. The value they bring is that they level up a team. They hire well, they provide mentorship, they help the team avoid making time-and-money-wasting mistakes.
Everyone should be able to communicate effectively, regardless of their role. I'd argue that one of the primary differences between a junior and senior in terms of capability is their prior experience and the degree to which the skills required for their job are developed.
As long as we continue to associate systems-level thinking with high status and ridiculous remuneration it will be impossible to identify the folk with the skills to actually do this work.
I have found that there is very little difference between a senior, junior and even intern engineer. The responsabilities are the same, but a senior generally completes tasks faster and is paid more. The same JIRA tickets.
It is not until you get to a lead/architect level that the responsabilities change. The system building comes into focus.
Yeah this has also been my experience more or less. Senior engineers do get some tasks (scope the work, design the implementation, etc) but generally "building systems" is in the purview of the principals and architects. I've had some companies that let seniors do more as they get closer to their next rank but generally these opportunities are fairly isolated and triple checked by the actual shot callers. At senior you're still a code monkey. Just typically very experienced and capable of managing a small team of juniors.
> To them, creating software is just one of the steps. First of all, they question whether the software needs to be built in the first place. They ask what problems would it solve and why it’s important to solve them. They inquire who will be using the software and on what scale. They think about where the software would run and how they’re going to monitor whether it’s working properly. They also decide how to measure whether the software is actually solving the problems it was supposed to solve.
Based on this definition I would suggest the author is using "senior" as a modifier to include all positions above junior rather than the typical titling. Moreover, the amount of times I've been given any time at all to actually think about the system things will run on, or how we will determine if it's performant, I can count on one hand. If this is the author's experience he is very lucky to have a company that cares about end-to-end performance.
I believe the article was using Senior Engineer as equivalent to lead/architect, because at big tech companies like Google or Amazon, that's what a Senior Engineer is, they act effectively as team lead/project lead, and as team(or multiple teams) level architect. When you become senior at those companies you also start to report directly to the skip level.
Be careful, despite participating across all stages and areas described can be awesome, and enriches you a lot, you are under the risk of generating toons of dependencies on your team, since you are the person for all and that culture ir insane for you and your team. From my point of view seniority is measured in terms of how you get the more impact with the less time invested. For instance: Senior engineers should realise about wrong decisions and intermediate then, on the other hand takin the decission from scratch would generate 3 problems: feed the dependency on the senior profile, not allow other to develop themselves, too much time investement from the Senior.
Some time ago in another HN thread, someone said, that library consumer vs. library author is a much better metric for differentiating coder's skills, and i think he was right.
Unless you work for an incredibly benevolent company, "library author" means you're doing that on your own time, outside of what provides for your income.
Many of us are quite capable of writing libraries, and likely do so in an internal-only fashion, but have no interest in trying to be the nth new library that accomplishes the same thing during our free time.
Skill vs. effort vs. drive are all very different things.
What i'm saying is that, from the perspective of an employer, i'd be rather impressed by someone who can show me one or more libs, that he wrote and people are actually using, than someone who was given the title 'senior' by whoever with whatever motivation to do so.
The library does not need to be public to be authored. In my experience there are far more people using internally written libraries to accomplish various goals than writing the library that provides the leverage.
Nothing in that article. It only means the person (probably) fits the 8 or so bullet point skills that management has said a senior engineer needs to have. And it's company specific.
If you want to be promoted, then either, ask your manager, or apply for a senior job somewhere else.
I don't get how these articles get so much traction. They are like fortune telling, just spout off some non-specific high-level items and let the audience fill in the blanks.
Hi there,
I know it's a little distasteful to hijack your comment on an unrelated topic but I didn't know any other way to contact you. About 6 months ago, you commented on my post (https://news.ycombinator.com/item?id=30687601) about making an SMS based browser with improvements over coldsauce's Cosmos Browser. I just wanted to let you know that I've basically finished all my major goals with it and released it publicly! (here's that post: https://news.ycombinator.com/item?id=32905496 ). I hope you enjoy it!
Being able to understand other people is a big item on that list. That makes you able to understand the needs and perspectives of your teammates, other teams, the organization at large, and most importantly, your user/customer base.
A larger view of things, considerable foresight are second, but close companion. They tie into being able to understand people and things. They give you the ability to avoid things that would be problems in the long run. And allow you to build stuff that will last.
I'd say that everything else trails behind. Technologies come and go. Fads come and go. Anything can be sorted out as long as you can build things for the purpose at hand without straying outside the scope and build them in a way that will last.
As a junior with the regular high aspirations for career growth to Staff engineer/leadership, am I doing myself a disservice by orienting myself early in my career around "Systems thinking" (NFRs, requirements analysis, testing, observability etc as the article discusses), instead of focusing on the technical "code quality, best practises and cutting edge qualities"?
My biggest suggestion to anyone looking down this path is, in addition to your normal SWE responsibilities, really understand production engineering concepts (testing, reliability, alerting, monitoring, running an on call rotation, capacity planning, etc). At a smaller company being the one SWE who can do these things in addition to their normal job roles is probably the fastest skill set to develop to unlock staff promo. It's less important to be the quickest arcane bug solver and more important to be the person who can see all of the problems with a system and work independently fixing them.
As an example, what's beyond code quality is writing library code where doing the right thing is easier, and is aligned with the system. If, for example, one uses a design pattern whose anti-pattern is misaligned with the overall system, then it is easy to do the right thing locally and the wrong thing systemically.
As another example, the "best practices" are actually sound engineering principles applied specifically and locally. In a different architecture, with a different constraint and use-case, how those principles applied may sometimes look different than what "best practice" says, but not so strange if you understand the engineering principle underlying the "best practice".
Lastly, I would say, "systems thinking" always includes people: the people writing the code, the people making sure the infrastructure is running, the people using the system as end-users, the people supporting the users, the people running the business, the people paying the business, the people depending on the technology. Incorporating that means dipping into a product perspectives where people talk about things like, ux, or "job to be done", or "lived experience" rather than "requirements analysis" or "observability".
Systems thinking is broader in scope and responsibility. You're going to have to cross the rubicon eventually (unless all the software projects that hire you fail gloriously before they achieve any significant scale, I guess).
Code quality, best practices, etc. involve the same values and priorities as systems thinking, but is scaled down to a bus factor of 1. (i.e. the code you, personally, write or review).
Going beyond n=1 requires building mechanisms and guard-rails to prevent a failure of the individual level from affecting the larger system in a bad way. Thinking about it early won't significantly kneecap you from writing good code.
If it interests you, go for it.
The only reason you might not want to do so is if it doesn't interest you right now. You'll likely get there one day, once a project you care about scales up enough.
I think the problem is that the title is a multipurpose tool. It might signify an actual change of responsibility, or a way to push a needed salary increase through the approval process. So it doesn't have a single unifying meaning, even within a single organization.
Well this is just ridiculous. What makes me a senior engineer is I convinced someone to call me that for my job title. That's it - that's 100% the distinction. It has never had the slightest apparent impact on what I wind up actually doing.
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.