16 ms·

Levels of Seniority

278 points by arbhassan 7y ago

arcanus 7y ago
This is a good read. Anyone have recommendations for reading on the next steps past 'senior'? This is called various things, like principal engineer, fellow, etc. at bigger organizations. Some people's careers might take them to the point where they do not write much code, and act as a key interface between executives and programmers. If they aren't a manager and can still be on the IC track, where they provide technical leadership, coaching, vision, etc.
- tyingq 7y ago
  My experience is that the fellow, principal, distinguished, etc, positions are almost always appointed positions. So there's little you can do, other than find opportunities for broad exposure, to land one.
- hirako2000 7y ago
  When a senior engineer sits on that role for too many years, the promotion is honorific (and jumps in salary band and benefits), or its a way to reward a very valuable senior engineer before he hop to another job. At least that's what I've seen in large organisations where senior has actually become a mid level engineer. The tiers make me laugh sometimes, as the titled fellow, principal, distinguished, or evangelist are attributed to a few, sometimes even with the "senior" prefix added to those titles.
- deleted 7y ago
  [deleted]
- ath0 7y ago
  There are a bunch of great references for career ladders, broadly speaking, that discuss the rollout process and what each level means for that company. The best not only say something about the levels, but about how the levels are interpreted in line with that company's culture, whatever it means. It's very hard to get to levels beyond senior as a pure generalist: you're typically going to have to have worked on projects with significant, company-wide impact, and that usually means (a) doing something unique within a domain and (b) working with many others, in different types of roles, in your company, in order to have that impact. Two good intro readings on career ladders: https://labs.spotify.com/2016/02/08/technical-career-path/ https://labs.spotify.com/2016/02/08/technical-career-path/ http://dresscode.renttherunway.com/blog/ladder http://dresscode.renttherunway.com/blog/ladder
- alpha_squared 7y ago
  Deliver industry-changing projects with proven results and know your industry/domain; this could also be projects that open up new markets for the org. While I think senior developer is achievable without domain knowledge of the industry, I fail to think of a single principal or fellow I've met who did not have deep understanding of the field they're in. Some had patents to their name, some didn't; all had 'proven' in some way that they're indispensable for their respective domain.
- daxfohl 7y ago
  At Microsoft, I'd say roughly senior is able to lead a project end to end. Principal is being able to represent a department and take responsibility for making sure multiple projects are run smoothly, developers are growing, outages are prevented. There's some overlap, and it's really just a matter of scale and trust. As you produce results, you get more trust and more responsibility for larger things. Progressing through principal is much more about paying attention to the bottom line. It's your responsibility to make sure the things you're doing are things that either customers are willing to pay for, or things that greatly reduce COGS. These are all achievable by mortals so long as you're hard working, determined, and focused on the right things. Beyond that, Distinguished Engineer I'd say is reserved for someone who works at a level beyond the most of us, whose work has produced multiple patents or been widely influential across the company or the industry at large. Fellow is someone who has done this continually throughout their career.
tillmannhgl 7y ago
I think the idea of having three (or four or five) buckets of seniority is not applicable for modern work any more. Leveling is too much about hierarchy and too less about the actual impact. Beyond leveling is something what doesn't need to be defined in a word, but is more about specific knowledge or competence that is needed to solve a problem.
- zdragnar 7y ago
  It is an easy way to justify multiple pay bands. I formerly worked for a company that for a few years referred to all of the engineers as "rock stars" etc. As the company matured a bit, that was dropped from all of the top-down type communication. The company didn't actually value the employees any less, and we were still praised appropriately for good work and / or solid efforts. The issue was that people simply had to acknowledge that no, not all of the engineers put in the same level of effort or had the same natural talents, and pay disparities couldn't make sense when "everyone is a rock star programmer". Granted, by the time i had left, we only had 3 or 4 pay bands from most junior to highest job title that still programmed, but the company wasn't in the west coast and didn't pay west coast salary either, so the actual compensation gradient was narrower than what you might find at a FAANG company.
- Spooky23 7y ago
  Sure it is, you gate underperforming people at the low bands and attrit them out. That’s why in the regular army you don’t see 50 year old Captains.
  - seanmcdirmid 7y ago
    So promote until the Peter principle is activated?
    - hurricanetc 7y ago
      For the military... not really. They have a concept called “high year of tenure” which limits how long a soldier can remain in a rank without being promoted. You are meant to advance and if you don’t advance you will be separated out. For example if you join the Army as a specialist (E4) you have 8 years to get promoted or you’re essentially kicked out.
top_kekeroni_m8 7y ago
Senior level developers are usually people with excellent domain and business knowledge. How does one get a senior programming job without knowledge of the field? I might consider myself a senior in my current job, but I wouldn’t necessarily call myself that when applying to a new field.
- vjeux 7y ago
  There’s usually a “ramp up” period where you get to learn that knowledge. As you get more senior, that period gets longer. You also have to develop your learning skills. How do you identify existing people with knowledge and be able to learn from them.
- Jestar342 7y ago
  IME autonomy is the primary measure of seniority. If you need mentoring, or are completely uncomfortable being told "I don't know, can you figure it out please?" then you definitely have an opportunity to grow. There's a third kind of learning in software. The first two are technical and domain, the third is abstract application and adaptability of your skills. That latter one only comes from experience. How do you efficiently learn both tech and domain? Can you identity waste (time and/or resources) early? Are you resourceful when seeking information? Are your questions and discussions phrased in ways that maintain direction and brevity? So on.
  - BlargMcLarg 7y ago
    >IME autonomy is the primary measure of seniority What if you're autonomous by heart, but the software is so huge and poorly documented, as well as having lots of bureaucratic rules and gripes, that you pretty much can't be autonomous? That's a reality for many developers, junior or senior.
    - enra 7y ago
      I think in that case it’s still a case where as a senior you should figure out how to be most effective in that situation, push for a change, take leadership and convince others.
barrkel 7y ago
What's not covered here is overlap between what an engineer knows and what the business needs; and especially knowledge of the business's existing codebase and architecture. If you know what exists and how it's put together (and this can come from tenure or experience in a vertical) you'll be far more productive. Tasks require less research and are implemented leveraging more of the existing design, possibly with a few tweaks in key locations, where an engineer with equivalent or even more talent may rewrite or reinvent a whole module owing to less deep understanding, and actually add less value. This can lead to an engineer deserving to be senior in one company but not so senior in another. It's also a source of technical debt and risk when employees turn over. Knowledge is lost and merely hiring a replacement doesn't restore velocity. Sometimes modules need to be rewritten and replaced to get back to a good place.
- scarface74 7y ago
  I’ve seen this far too often. Theoretically, your pay should be a combination of what you could get for your same skill set on the open market plus getting paid over the market value based on what you bring to the company based on your domain knowledge and the relationships that you’ve built that allow you to be more efficient than someone off the streets. If you’re not careful, your marketable skills will become out of date, but your salary keeps increasing because you’re very valuable to the company. Then when the company lets you go after a decade, you will be out there competing with people younger than you who have kept up to date and complaining about “ageism”. I’m 45 FWIW.
mberning 7y ago
This is a very good overview. One thing I would add for the junior and mid level developer is “attitude towards work in general”. One thing I see commonly in many junior and some mid level engineers is an inappropriate attitude towards work vs their career aspirations. For example, they will treat their job like an hourly employee with no skin in the game, and then complain about raises, promotions and bonuses. You don’t need the best development skills to show up on time, be diligent, work hard, and be a good teammate.
- eropple 7y ago
  As somebody pretty firmly in the staff/principal firmament (when not in a management role), I absolutely, positively do not care in the slightest and at least low-key discourage people I mentor from having "skin in the game." Unless you have entire points in the company, "skin in the game" is a handle by which people can manipulate you to do things that are bad for you, your health, and your career. It's not that it should be an adversarial relationship, and one of the really nice things at my current job is that it it's the first I've ever been at that isn't (it's a genuinely good place to work, with empathic and decent upper management, and they get a lot more out of us for it)--but most are and it's not a line employee's fault and it's foolish to not recognize the game being played. Professionalism doesn't require emotional attachment and it shouldn't be expected or too generously given. Show up, do your job, do it well. But make sure you are building towards the next one and don't let the current one minimize your ability to get the next one. As your manager I might and generally do care about your personal growth, but it's not because it relates to your KPIs, it's because you're a person and I'm in a place to help you improve and I should do that because doing that is good. And, selfishly, I want to find and build great people to work with in the future. But at most places, me doing this is in tension with what my bosses would like me to do. Which is mold you into a better employee over the expected time horizon of your employee, irrespective of if that makes you a better developer or technologist. (I've learned that pushing people to be better technologists makes better employees too, but my experience is that most management doesn't get this and so we are mostly to be not trusted on that score.)
- scarface74 7y ago
  I’ve been in this field a fair amount of time and my “skin in the game” is not to leave my coworkers hanging. But too often you hear employers talk about “we are family” and “the mission” to convince people to work 60+ hour weeks. I do the best work I can within a normal 40-45 hour week.
k33n 7y ago
The real truth is that none of these titles mean anything outside of a given organizational context. Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list. So much wishful thinking here.
- matwood 7y ago
  > Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list. Why is that hilarious? Anyone can give feedback, maybe even correct feedback, but what is the point of feedback? It should be to help the person receiving the feedback improve. A senior engineer should be thinking about the team and not themselves. This includes their ego. If they are giving feedback to show off how smart they are in a way that hurts the team, that is not senior IMO.
- BlargMcLarg 7y ago
  There's some truth in your statement that most people do not wish to admit and are quick to dismiss as "rebellious, arrogant juniors". I generally see two kind of seniors. The first group is senior in terms of experience and hard work. The second group got there only through obligation, working for years without growing a lot. Unfortunately, I see most management puts a hard cap on minimum experience before being a senior, so the former group and the latter group become indistinguishable. Other problems include Peter principle, where because someone got promoted to senior, he is now attributed as a good leader, despite having no experience leading as a junior before. Skills that are at best orthogonal are attributed to seniority, despite the fact many junior and medior people may be better at teaching, leading and mentoring others than their seniors. Nothing in the track guarantees a senior ever has to practice or show their excellence in these skills, either. Furthermore, most people aren't doing interesting things. They get a revolutionizing experience at work maybe once a month at best, if not far longer. Couple that with an echo chamber and suddenly, they believe it is normal to take 3 to 10 years to become an expert on fairly trivial domain knowledge. We're not talking about top-of-the-line C++ programmers, ML experts, people driving innovation, veteran software architects or whatever. We're talking your average CRUD web programmer who did some backend, maybe some frontend. We're talking people who believe one can only be senior being able to deploy an application from scratch into a new environment, thinking this takes at minimum 3 years to learn when in reality, you could pick up a guide how to do this today. The only real thing you'll miss out are office politics and navigating in a group setting. The former is so volatile and context-dependent, you might as well learn it on the fly or wait until 15 years have passed by and pretty much any possible situation has come up. The latter is severely overstated in difficulty and most people will pick this up in no time, unless the team is dysfunctional to begin with.
psim1 7y ago
This interesting essay is marred by bad grammar. Do you want to rise in the ranks? Learn to write well. Documentation, blogs, email memos, proposals, etc.—this is the evidence of accomplished seniority.
- sputr 7y ago
  His name is Kamran Ahmed and he's from Dubai. This comment didn't make you look good. Not even a little.
  - psim1 7y ago
    The point of discussion here is not to make oneself look good. Do you disagree with my statement?
    - deleted 7y ago
      [deleted]
    - scarface74 7y ago
      English is my first language and I didn’t notice any off putting grammar errors. That being said, especially for a non native speaker, I don’t judge their ability to communicate by their ability to write perfectly grammatically and idiomatically correct English. It’s whether they got their point across.
- kamranahmed_se 7y ago
  I will go through it one more time, thank you! Feel free to submit a PR though. It's on GitHub https://github.com/kamranahmedse/roadmap.sh https://github.com/kamranahmedse/roadmap.sh
- samiru 7y ago
  English might not be his first language. Not mine either, so I did not notice the bad grammar! I have noticed in my own use of English language that after getting into a level where I get understood well enough in work situations and such, my language skills have started to stagnate. It does not help that even I use mostly English in my daily work, there are practically no native speakers around. But I do agree communication skills being part of what is considered seniority. Also, being able to hold different viewpoints and communicate those to others could be considered part of being mature too.
deleted 7y ago
[deleted]
zackmorris 7y ago
I wish that the article mentioned the fourth level of seniority: graybeard. Bluntly, that's any developer over 40. But in terms of mindset, it's more like having multiple years of experience in a discipline spanning 2 or more eras so that you begin to see solutions outside of the immediate problem space in front of you. So for example, a graybeard in the 1990s knew desktop development as well as the web. In the 2000s it was probably web and mobile dev, then NoSQL and reactive programming in the teens. Today it might be digging up old sysadmin knowledge for containerization, or applying functional programming to big data and machine learning problems. Maybe the definition gets fuzzier over time :-P The problem with all of this is the danger of being put out to pasture. I hit an existential crisis last year where I stopped seeing things in code and started seeing everything like this big spreadsheet that I had to keep consistent. Satisfying multiple constraints in very large search spaces started giving me decision fatigue and I reached a point where my productivity fell below the junior developer level. Like, I'd be given a ticket to fix a bug in a view controller and discover that the problem was actually due to an incorrect relationship in the database schema from 10 years ago. After awhile, nobody wanted to hear about refactoring, they just wanted it to work, and we began the long death march of playing whack-a-mole with technical debt. It felt like there was nothing for me to contribute, and I burned out. Now I don't know if I should continue programming, or try to transition to being a mentor in a management role, or get out of the industry altogether and move to something like renewable energy and build stuff in the real world. I'm still struggling, so any thoughts on this would be much appreciated.
- Swizec 7y ago
  I’m only 32 but I started with DOS and later desktop programming, moved on to LAMP in the 00’s, then SPA in the 10’s, and now going heavily to serverless+JAM. Hell I even had a tiny app make it into the official KDE distribution in high school. And I built my own templating language transpiler for a custom PHP framework ... What does that make me? Whitebeard lol?
  - zackmorris 7y ago
    Well I think the whole pirate/ninja thing is a great metaphor for hackers, so technically you are a blackbeard. My friend and old business partner is 3 years older than me but still highly productive making games in Unity, so I think of him as a wizard or maybe a whitebeard. I'm just, haggard, so feel like a graybeard even though I can't grow one.
diN0bot 7y ago
https://roadmap.sh/backend https://roadmap.sh/backend - I notice that this doesn't contain anything about understanding abstraction, abstraction barriers, managing complexity in problem v solution spaces, identifying "as simple as possible but not simpler", etc. I don't even mean design patterns or OOP, though those are nice applications. How things have changed. It's like how there was a time when physics was witnessable visual and tactile grappling with the world around us, and now it's become extreme math: the "programming" joy of yore has been replaced by webdev legoing.
- kamranahmedse 7y ago
  Thank you for the feedback. It's still a work in progress. It was mainly moved from the repository[0] and needs to be updated. Plus it is lacking in a couple of other sections also which we plan on improving. Please feel free to leave your feedback and suggestions in the form of issues on the repository. - [0] https://github.com/kamranahmedse/developer-roadmap https://github.com/kamranahmedse/developer-roadmap
- AlchemistCamp 7y ago
  It also recommends JavaScript and Mongo for back-end devs. My guess is that the author is primarily a front-end dev.
idoby 7y ago
The actual content of the roadmaps doesn't seem to be in the GitHub repo so I can't open PRs to correct typos.
- kamranahmedse 7y ago
  Hey, everything is there at https://github.com/kamranahmedse/roadmap.sh/blob/master/content/guides/levels-of-seniority.md https://github.com/kamranahmedse/roadmap.sh/blob/master/cont...
  - idoby 7y ago
    I was trying to open a PR to fix a typo in the devops map but the repo doesn't seem to contain the text I want to fix...
INTPenis 7y ago
Everyone's talking so positively about seniority but I've seen it backfire horribly. I am sure to catch backlash for this next statement but a lot of times it seems that people with kids stop caring. Which is only natural, understandable, because biologically something has arrived that takes all precedence. But to me as an outside observer and co-worker I see a person stagnating. I've had to teach senior architects not to send private ssh keys to each other and instead use public keys. How to do basic naming schemes for servers. And those are just two "timeless" examples. I won't even mention all the modern tech they ignore because they haven't cared about their profession for the last 15 years. Edit: For context I am mid 30s and these people are late 40s or early 50s. I am not stupid enough to think I can avoid this in the future.
- dancek 7y ago
  That's weird. I find people with kids care more about personal and professional development, and are more diligent in their work. This might have to do with the environment I'm in (7,5 hour days with almost no overtime; recruiting motivated people). I also personally feel I've become more responsible in all areas of my life after having kids. Edit: I'm mid thirties too. I find the least responsible people to be those in their 50s with no kids. But I've only met a few who remained developers; most either have kids or switched to management.
  - yibg 7y ago
    I’ve observed the same. Some of the most productive engineers are those with kids. Difference is they focus on getting their work done and doing it well (so they don’t get paged at night for instance) instead of chasing the new shiny, or being the hero.
    - vsareto 7y ago
      At least one conclusion from this thread is that there are camps of people with different beliefs, and you're senior to one camp, but not another. A productive engineer, or not. Even if you take this feedback to heart, you have a limited sample set of signals. Do you average them out, or do you only care about what one particular camp said (the camp that signs your check, perhaps)? Which camps get weighted more heavily? I don't think there are any real trends to observe yet. The field is too volatile with its labeling to really take seriously any kind of prescribed career plan to seniority that lasts beyond 3-5 years. It's also why we repeatedly test people in interviews.
leto_ii 7y ago
Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn't a single dimension of seniority that we should talk about. To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company's platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.). This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage "20 years of experience - the same year repeated 20 times".
- cle 7y ago
  It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.
  - ivanhoe 7y ago
    Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.
    - deleted 7y ago
      [deleted]
    - Godel_unicode 7y ago
      s/know/think See also yagni, premature optimization, etc, etc
camhart 7y ago
"They know how to give feedback without hurting anyone." Should instead be they use tact when giving constructive feedback. Too many people water feedback down--scared that they might "hurt" people--resulting in the value of the feedback being lost. We shouldn't be scared to be honest with people--even if it means they might be hurt by it. It'll be better for them in the long run to hear the truth now--even if it's tough to swallow. Giving this type of feedback needs to come from a place of love--a desire to truly help, and should never be done with the intention of hurting or trying to make them feel like they were "wrong". It should also be added: "They can receive feedback without being hurt"
- tyurok 7y ago
  Second that. Pain is constructive in the right dose, and it's also risky since you can lose trust if delivered incorrectly. It requires maturity to give honest feedback and recognize that it might be biased since we have a lot of limitations on how we perceive others.
29athrowaway 7y ago
This article conflates personality traits and attitudes towards problem solving with seniority. It also speaks of overengineering, which is a highly ambiguous and subjective term that rarely leads to constructive feedback. It translates to "you are overdoing your job", rather than how you are overdoing your work. It is not actionable feedback. Asking for help is not a trait of junior engineers. Asking for help in a non-structured way, without providing useful context or asking for help without making a reasonable attempt to understand the problem first is something that you would expect of a junior person. Not asking for help while being blocked for a long period of time is also a trait of a junior person. Being able to leverage expertise from team members is a trait of a senior person. Now, about this: > They have respect for the code that was written before them. They are generous when passing judgment on the architecture or the design decisions made in the codebase. They approach inheriting legacy code with an "opportunity mindset" rather than a complaining one. No. Here the author is conflating seniority with blind personality cult loyalty. If something is suboptimal or wrong in a problematic way, then just go ahead and say it when the opportunity arises in the best way you can. Even in the early days of software, people realized the importance of good engineering practices. If your legacy code doesn't reflect that mindset, it is not worth praising. The article author himself recognizes that dumping work on other people is a trait of junior engineers, but applies it inconsistently in this case. Senior maintainers may be able to identify legitimate tradeoffs, but when a code base is consistently bad, especially when it was already bad in its historical context, don't expect a lot of praise for the code or the authors.
lmilcin 7y ago
I only recognize difference between junior/senior levels. My definition of senior developer: - Senior will not be "stuck" with a problem. They recognize there is somebody to get help from and they will seek it. But they can also function when there is no person to get technical help from. They will dig, and dig, and dig, until they finally solve the problem. - I can trust the solution to be usable even without supervision. - They will have minimum standard they will enforce around them (ownership). Ownership for me means they will look for things that are not right and act on it, without being specifically instructed to. - Is adult in behavior, can recognize and control their emotions, can work with other people, recognize and deal with communication problems. From my perspective, people who have huge technical knowledge and experience but can't be trusted with tasks, can't be trusted to not get conflicted with the team on the first possible occasion, are not honest with their results (hide problems), will sacrifice good of the project because they just have to test that new tech -- all these people are junior devs for me.
- enraged_camel 7y ago
  Your list only handles how senior engineers solve problems. IMO the most important qualities of a senior engineer pertain to knowing what problems to solve, and, at an even higher level of seniority, why those problems need solving. For example, senior-level engineers will recognize when a problem is not worth solving at all. They might know that a solution is technically possible/feasible, but they will also understand that the engineering resources (i.e. their time) can, and in fact should, be better spent elsewhere -- fixing more egregious bugs, enhancing existing features and developing new ones. To go back to what you said, being able to "dig, and dig, and dig" until they solve a problem is not what makes someone senior-level. Anyone with sufficiently high levels of dedication and stubbornness can go down rabbit hole after rabbit hole until they stumble upon something that resembles a solution. What distinguishes senior-level engineers is being able to step back and analyze the situation to determine if the rabbit holes are worth diving into.
  - lmilcin 7y ago
    Let's be honest, this is requirements for a senior engineer, not a tech lead. It would, of course, be nice for a senior engineer to have perfect awareness but I think that is too much to ask to qualify to be called senior. Have you watched Star Trek (DS9 for example) lately? You may have a bunch of senior officers but they still do not always understand why stuff needs to happen. They muddle through on principles until they succeed. Then it is always easy, retroactively, to say it was their idea all along.
HugoDaniel 7y ago
People trying to find ways to justify paying less to programmers
narmihou 7y ago
Aren't these two statements below contradictory when taken at face value? Both under Junior dev. Over-engineering is a major problem, often leading to fragility and bugs. When given a problem, they often try to fix just the current problem a.k.a. fixing the symptoms instead of fixing the root problem.

278 points by arbhassan 7y ago

This is a good read. Anyone have recommendations for reading on the next steps past 'senior'? This is called various things, like principal engineer, fellow, etc. at bigger organizations. Some people's careers might take them to the point where they do not write much code, and act as a key interface between executives and programmers. If they aren't a manager and can still be on the IC track, where they provide technical leadership, coaching, vision, etc.

tyingq 7y ago
My experience is that the fellow, principal, distinguished, etc, positions are almost always appointed positions. So there's little you can do, other than find opportunities for broad exposure, to land one.
hirako2000 7y ago
When a senior engineer sits on that role for too many years, the promotion is honorific (and jumps in salary band and benefits), or its a way to reward a very valuable senior engineer before he hop to another job. At least that's what I've seen in large organisations where senior has actually become a mid level engineer. The tiers make me laugh sometimes, as the titled fellow, principal, distinguished, or evangelist are attributed to a few, sometimes even with the "senior" prefix added to those titles.
deleted 7y ago
[deleted]
ath0 7y ago
There are a bunch of great references for career ladders, broadly speaking, that discuss the rollout process and what each level means for that company. The best not only say something about the levels, but about how the levels are interpreted in line with that company's culture, whatever it means. It's very hard to get to levels beyond senior as a pure generalist: you're typically going to have to have worked on projects with significant, company-wide impact, and that usually means (a) doing something unique within a domain and (b) working with many others, in different types of roles, in your company, in order to have that impact. Two good intro readings on career ladders: https://labs.spotify.com/2016/02/08/technical-career-path/ https://labs.spotify.com/2016/02/08/technical-career-path/ http://dresscode.renttherunway.com/blog/ladder http://dresscode.renttherunway.com/blog/ladder
alpha_squared 7y ago
Deliver industry-changing projects with proven results and know your industry/domain; this could also be projects that open up new markets for the org. While I think senior developer is achievable without domain knowledge of the industry, I fail to think of a single principal or fellow I've met who did not have deep understanding of the field they're in. Some had patents to their name, some didn't; all had 'proven' in some way that they're indispensable for their respective domain.
daxfohl 7y ago
At Microsoft, I'd say roughly senior is able to lead a project end to end. Principal is being able to represent a department and take responsibility for making sure multiple projects are run smoothly, developers are growing, outages are prevented. There's some overlap, and it's really just a matter of scale and trust. As you produce results, you get more trust and more responsibility for larger things. Progressing through principal is much more about paying attention to the bottom line. It's your responsibility to make sure the things you're doing are things that either customers are willing to pay for, or things that greatly reduce COGS. These are all achievable by mortals so long as you're hard working, determined, and focused on the right things. Beyond that, Distinguished Engineer I'd say is reserved for someone who works at a level beyond the most of us, whose work has produced multiple patents or been widely influential across the company or the industry at large. Fellow is someone who has done this continually throughout their career.

tillmannhgl 7y ago

I think the idea of having three (or four or five) buckets of seniority is not applicable for modern work any more. Leveling is too much about hierarchy and too less about the actual impact. Beyond leveling is something what doesn't need to be defined in a word, but is more about specific knowledge or competence that is needed to solve a problem.

zdragnar 7y ago
It is an easy way to justify multiple pay bands. I formerly worked for a company that for a few years referred to all of the engineers as "rock stars" etc. As the company matured a bit, that was dropped from all of the top-down type communication. The company didn't actually value the employees any less, and we were still praised appropriately for good work and / or solid efforts. The issue was that people simply had to acknowledge that no, not all of the engineers put in the same level of effort or had the same natural talents, and pay disparities couldn't make sense when "everyone is a rock star programmer". Granted, by the time i had left, we only had 3 or 4 pay bands from most junior to highest job title that still programmed, but the company wasn't in the west coast and didn't pay west coast salary either, so the actual compensation gradient was narrower than what you might find at a FAANG company.
Spooky23 7y ago
Sure it is, you gate underperforming people at the low bands and attrit them out. That’s why in the regular army you don’t see 50 year old Captains.
- seanmcdirmid 7y ago
  So promote until the Peter principle is activated?
  - hurricanetc 7y ago
    For the military... not really. They have a concept called “high year of tenure” which limits how long a soldier can remain in a rank without being promoted. You are meant to advance and if you don’t advance you will be separated out. For example if you join the Army as a specialist (E4) you have 8 years to get promoted or you’re essentially kicked out.

top_kekeroni_m8 7y ago

Senior level developers are usually people with excellent domain and business knowledge. How does one get a senior programming job without knowledge of the field? I might consider myself a senior in my current job, but I wouldn’t necessarily call myself that when applying to a new field.

vjeux 7y ago
There’s usually a “ramp up” period where you get to learn that knowledge. As you get more senior, that period gets longer. You also have to develop your learning skills. How do you identify existing people with knowledge and be able to learn from them.
Jestar342 7y ago
IME autonomy is the primary measure of seniority. If you need mentoring, or are completely uncomfortable being told "I don't know, can you figure it out please?" then you definitely have an opportunity to grow. There's a third kind of learning in software. The first two are technical and domain, the third is abstract application and adaptability of your skills. That latter one only comes from experience. How do you efficiently learn both tech and domain? Can you identity waste (time and/or resources) early? Are you resourceful when seeking information? Are your questions and discussions phrased in ways that maintain direction and brevity? So on.
- BlargMcLarg 7y ago
  >IME autonomy is the primary measure of seniority What if you're autonomous by heart, but the software is so huge and poorly documented, as well as having lots of bureaucratic rules and gripes, that you pretty much can't be autonomous? That's a reality for many developers, junior or senior.
  - enra 7y ago
    I think in that case it’s still a case where as a senior you should figure out how to be most effective in that situation, push for a change, take leadership and convince others.

barrkel 7y ago

What's not covered here is overlap between what an engineer knows and what the business needs; and especially knowledge of the business's existing codebase and architecture. If you know what exists and how it's put together (and this can come from tenure or experience in a vertical) you'll be far more productive. Tasks require less research and are implemented leveraging more of the existing design, possibly with a few tweaks in key locations, where an engineer with equivalent or even more talent may rewrite or reinvent a whole module owing to less deep understanding, and actually add less value. This can lead to an engineer deserving to be senior in one company but not so senior in another. It's also a source of technical debt and risk when employees turn over. Knowledge is lost and merely hiring a replacement doesn't restore velocity. Sometimes modules need to be rewritten and replaced to get back to a good place.

scarface74 7y ago
I’ve seen this far too often. Theoretically, your pay should be a combination of what you could get for your same skill set on the open market plus getting paid over the market value based on what you bring to the company based on your domain knowledge and the relationships that you’ve built that allow you to be more efficient than someone off the streets. If you’re not careful, your marketable skills will become out of date, but your salary keeps increasing because you’re very valuable to the company. Then when the company lets you go after a decade, you will be out there competing with people younger than you who have kept up to date and complaining about “ageism”. I’m 45 FWIW.

mberning 7y ago

This is a very good overview. One thing I would add for the junior and mid level developer is “attitude towards work in general”. One thing I see commonly in many junior and some mid level engineers is an inappropriate attitude towards work vs their career aspirations. For example, they will treat their job like an hourly employee with no skin in the game, and then complain about raises, promotions and bonuses. You don’t need the best development skills to show up on time, be diligent, work hard, and be a good teammate.

eropple 7y ago
As somebody pretty firmly in the staff/principal firmament (when not in a management role), I absolutely, positively do not care in the slightest and at least low-key discourage people I mentor from having "skin in the game." Unless you have entire points in the company, "skin in the game" is a handle by which people can manipulate you to do things that are bad for you, your health, and your career. It's not that it should be an adversarial relationship, and one of the really nice things at my current job is that it it's the first I've ever been at that isn't (it's a genuinely good place to work, with empathic and decent upper management, and they get a lot more out of us for it)--but most are and it's not a line employee's fault and it's foolish to not recognize the game being played. Professionalism doesn't require emotional attachment and it shouldn't be expected or too generously given. Show up, do your job, do it well. But make sure you are building towards the next one and don't let the current one minimize your ability to get the next one. As your manager I might and generally do care about your personal growth, but it's not because it relates to your KPIs, it's because you're a person and I'm in a place to help you improve and I should do that because doing that is good. And, selfishly, I want to find and build great people to work with in the future. But at most places, me doing this is in tension with what my bosses would like me to do. Which is mold you into a better employee over the expected time horizon of your employee, irrespective of if that makes you a better developer or technologist. (I've learned that pushing people to be better technologists makes better employees too, but my experience is that most management doesn't get this and so we are mostly to be not trusted on that score.)
scarface74 7y ago
I’ve been in this field a fair amount of time and my “skin in the game” is not to leave my coworkers hanging. But too often you hear employers talk about “we are family” and “the mission” to convince people to work 60+ hour weeks. I do the best work I can within a normal 40-45 hour week.

k33n 7y ago

The real truth is that none of these titles mean anything outside of a given organizational context. Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list. So much wishful thinking here.

matwood 7y ago
> Hilarious that the author felt the need to add "can give feedback without hurting people" to the senior engineer bullet list. Why is that hilarious? Anyone can give feedback, maybe even correct feedback, but what is the point of feedback? It should be to help the person receiving the feedback improve. A senior engineer should be thinking about the team and not themselves. This includes their ego. If they are giving feedback to show off how smart they are in a way that hurts the team, that is not senior IMO.
BlargMcLarg 7y ago
There's some truth in your statement that most people do not wish to admit and are quick to dismiss as "rebellious, arrogant juniors". I generally see two kind of seniors. The first group is senior in terms of experience and hard work. The second group got there only through obligation, working for years without growing a lot. Unfortunately, I see most management puts a hard cap on minimum experience before being a senior, so the former group and the latter group become indistinguishable. Other problems include Peter principle, where because someone got promoted to senior, he is now attributed as a good leader, despite having no experience leading as a junior before. Skills that are at best orthogonal are attributed to seniority, despite the fact many junior and medior people may be better at teaching, leading and mentoring others than their seniors. Nothing in the track guarantees a senior ever has to practice or show their excellence in these skills, either. Furthermore, most people aren't doing interesting things. They get a revolutionizing experience at work maybe once a month at best, if not far longer. Couple that with an echo chamber and suddenly, they believe it is normal to take 3 to 10 years to become an expert on fairly trivial domain knowledge. We're not talking about top-of-the-line C++ programmers, ML experts, people driving innovation, veteran software architects or whatever. We're talking your average CRUD web programmer who did some backend, maybe some frontend. We're talking people who believe one can only be senior being able to deploy an application from scratch into a new environment, thinking this takes at minimum 3 years to learn when in reality, you could pick up a guide how to do this today. The only real thing you'll miss out are office politics and navigating in a group setting. The former is so volatile and context-dependent, you might as well learn it on the fly or wait until 15 years have passed by and pretty much any possible situation has come up. The latter is severely overstated in difficulty and most people will pick this up in no time, unless the team is dysfunctional to begin with.

psim1 7y ago

This interesting essay is marred by bad grammar. Do you want to rise in the ranks? Learn to write well. Documentation, blogs, email memos, proposals, etc.—this is the evidence of accomplished seniority.

sputr 7y ago
His name is Kamran Ahmed and he's from Dubai. This comment didn't make you look good. Not even a little.
- psim1 7y ago
  The point of discussion here is not to make oneself look good. Do you disagree with my statement?
  - deleted 7y ago
    [deleted]
  - scarface74 7y ago
    English is my first language and I didn’t notice any off putting grammar errors. That being said, especially for a non native speaker, I don’t judge their ability to communicate by their ability to write perfectly grammatically and idiomatically correct English. It’s whether they got their point across.
kamranahmed_se 7y ago
I will go through it one more time, thank you! Feel free to submit a PR though. It's on GitHub https://github.com/kamranahmedse/roadmap.sh https://github.com/kamranahmedse/roadmap.sh
samiru 7y ago
English might not be his first language. Not mine either, so I did not notice the bad grammar! I have noticed in my own use of English language that after getting into a level where I get understood well enough in work situations and such, my language skills have started to stagnate. It does not help that even I use mostly English in my daily work, there are practically no native speakers around. But I do agree communication skills being part of what is considered seniority. Also, being able to hold different viewpoints and communicate those to others could be considered part of being mature too.

deleted 7y ago

[deleted]

zackmorris 7y ago

I wish that the article mentioned the fourth level of seniority: graybeard. Bluntly, that's any developer over 40. But in terms of mindset, it's more like having multiple years of experience in a discipline spanning 2 or more eras so that you begin to see solutions outside of the immediate problem space in front of you. So for example, a graybeard in the 1990s knew desktop development as well as the web. In the 2000s it was probably web and mobile dev, then NoSQL and reactive programming in the teens. Today it might be digging up old sysadmin knowledge for containerization, or applying functional programming to big data and machine learning problems. Maybe the definition gets fuzzier over time :-P The problem with all of this is the danger of being put out to pasture. I hit an existential crisis last year where I stopped seeing things in code and started seeing everything like this big spreadsheet that I had to keep consistent. Satisfying multiple constraints in very large search spaces started giving me decision fatigue and I reached a point where my productivity fell below the junior developer level. Like, I'd be given a ticket to fix a bug in a view controller and discover that the problem was actually due to an incorrect relationship in the database schema from 10 years ago. After awhile, nobody wanted to hear about refactoring, they just wanted it to work, and we began the long death march of playing whack-a-mole with technical debt. It felt like there was nothing for me to contribute, and I burned out. Now I don't know if I should continue programming, or try to transition to being a mentor in a management role, or get out of the industry altogether and move to something like renewable energy and build stuff in the real world. I'm still struggling, so any thoughts on this would be much appreciated.

Swizec 7y ago
I’m only 32 but I started with DOS and later desktop programming, moved on to LAMP in the 00’s, then SPA in the 10’s, and now going heavily to serverless+JAM. Hell I even had a tiny app make it into the official KDE distribution in high school. And I built my own templating language transpiler for a custom PHP framework ... What does that make me? Whitebeard lol?
- zackmorris 7y ago
  Well I think the whole pirate/ninja thing is a great metaphor for hackers, so technically you are a blackbeard. My friend and old business partner is 3 years older than me but still highly productive making games in Unity, so I think of him as a wizard or maybe a whitebeard. I'm just, haggard, so feel like a graybeard even though I can't grow one.

diN0bot 7y ago

https://roadmap.sh/backend https://roadmap.sh/backend - I notice that this doesn't contain anything about understanding abstraction, abstraction barriers, managing complexity in problem v solution spaces, identifying "as simple as possible but not simpler", etc. I don't even mean design patterns or OOP, though those are nice applications. How things have changed. It's like how there was a time when physics was witnessable visual and tactile grappling with the world around us, and now it's become extreme math: the "programming" joy of yore has been replaced by webdev legoing.

kamranahmedse 7y ago
Thank you for the feedback. It's still a work in progress. It was mainly moved from the repository[0] and needs to be updated. Plus it is lacking in a couple of other sections also which we plan on improving. Please feel free to leave your feedback and suggestions in the form of issues on the repository. - [0] https://github.com/kamranahmedse/developer-roadmap https://github.com/kamranahmedse/developer-roadmap
AlchemistCamp 7y ago
It also recommends JavaScript and Mongo for back-end devs. My guess is that the author is primarily a front-end dev.

idoby 7y ago

The actual content of the roadmaps doesn't seem to be in the GitHub repo so I can't open PRs to correct typos.

kamranahmedse 7y ago
Hey, everything is there at https://github.com/kamranahmedse/roadmap.sh/blob/master/content/guides/levels-of-seniority.md https://github.com/kamranahmedse/roadmap.sh/blob/master/cont...
- idoby 7y ago
  I was trying to open a PR to fix a typo in the devops map but the repo doesn't seem to contain the text I want to fix...

INTPenis 7y ago

Everyone's talking so positively about seniority but I've seen it backfire horribly. I am sure to catch backlash for this next statement but a lot of times it seems that people with kids stop caring. Which is only natural, understandable, because biologically something has arrived that takes all precedence. But to me as an outside observer and co-worker I see a person stagnating. I've had to teach senior architects not to send private ssh keys to each other and instead use public keys. How to do basic naming schemes for servers. And those are just two "timeless" examples. I won't even mention all the modern tech they ignore because they haven't cared about their profession for the last 15 years. Edit: For context I am mid 30s and these people are late 40s or early 50s. I am not stupid enough to think I can avoid this in the future.

dancek 7y ago
That's weird. I find people with kids care more about personal and professional development, and are more diligent in their work. This might have to do with the environment I'm in (7,5 hour days with almost no overtime; recruiting motivated people). I also personally feel I've become more responsible in all areas of my life after having kids. Edit: I'm mid thirties too. I find the least responsible people to be those in their 50s with no kids. But I've only met a few who remained developers; most either have kids or switched to management.
- yibg 7y ago
  I’ve observed the same. Some of the most productive engineers are those with kids. Difference is they focus on getting their work done and doing it well (so they don’t get paged at night for instance) instead of chasing the new shiny, or being the hero.
  - vsareto 7y ago
    At least one conclusion from this thread is that there are camps of people with different beliefs, and you're senior to one camp, but not another. A productive engineer, or not. Even if you take this feedback to heart, you have a limited sample set of signals. Do you average them out, or do you only care about what one particular camp said (the camp that signs your check, perhaps)? Which camps get weighted more heavily? I don't think there are any real trends to observe yet. The field is too volatile with its labeling to really take seriously any kind of prescribed career plan to seniority that lasts beyond 3-5 years. It's also why we repeatedly test people in interviews.

leto_ii 7y ago

Many of the points made in the article seem pertinent to me, however I think thinking in terms of discrete levels of seniority is counterproductive. I also think that there isn't a single dimension of seniority that we should talk about. To give a precise example, in my previous job we had very hierarchically senior people who understood the industry and the business side very well and of course knew the company's platform very well. Oh the other hand, strictly in terms of technical competence I think they lacked a lot of the basic mental framework. Their code was atrocious (core code in classes of 1000+ lines with no documentation or tests, lots of copy-paste), their choice of technology and methodology parochial and antiquated (think Java 5-6, Ibatis in 2016 + a lot of in-house built stuff, no code reviews, no QA etc.). This kind of people in some ways would rank as competent architects and in some other ways as fitting the good old adage "20 years of experience - the same year repeated 20 times".

cle 7y ago
It’s also illustrating that we engineers love to nitpick over stuff that ultimately doesn’t matter all that much. You know what’s way more important than short functions and programming platitudes like DRY? Understanding the business, system architecture, and how to deliver fast in the context of what’s already built.
- ivanhoe 7y ago
  Well engineers love to nitpick over stuff that we know will bite us in the ass in a few years. The most wonderfully architected set of business rules is of little help if it takes weeks to debug and it's impossible to refactor and add new features in future because no one knows how the code really works (and the guy who did it left long ago), it's untested and unreadable. Lots of great projects died slow deaths because of this.
  - deleted 7y ago
    [deleted]
  - Godel_unicode 7y ago
    s/know/think See also yagni, premature optimization, etc, etc

camhart 7y ago

"They know how to give feedback without hurting anyone." Should instead be they use tact when giving constructive feedback. Too many people water feedback down--scared that they might "hurt" people--resulting in the value of the feedback being lost. We shouldn't be scared to be honest with people--even if it means they might be hurt by it. It'll be better for them in the long run to hear the truth now--even if it's tough to swallow. Giving this type of feedback needs to come from a place of love--a desire to truly help, and should never be done with the intention of hurting or trying to make them feel like they were "wrong". It should also be added: "They can receive feedback without being hurt"

tyurok 7y ago
Second that. Pain is constructive in the right dose, and it's also risky since you can lose trust if delivered incorrectly. It requires maturity to give honest feedback and recognize that it might be biased since we have a lot of limitations on how we perceive others.

29athrowaway 7y ago

This article conflates personality traits and attitudes towards problem solving with seniority. It also speaks of overengineering, which is a highly ambiguous and subjective term that rarely leads to constructive feedback. It translates to "you are overdoing your job", rather than how you are overdoing your work. It is not actionable feedback. Asking for help is not a trait of junior engineers. Asking for help in a non-structured way, without providing useful context or asking for help without making a reasonable attempt to understand the problem first is something that you would expect of a junior person. Not asking for help while being blocked for a long period of time is also a trait of a junior person. Being able to leverage expertise from team members is a trait of a senior person. Now, about this: > They have respect for the code that was written before them. They are generous when passing judgment on the architecture or the design decisions made in the codebase. They approach inheriting legacy code with an "opportunity mindset" rather than a complaining one. No. Here the author is conflating seniority with blind personality cult loyalty. If something is suboptimal or wrong in a problematic way, then just go ahead and say it when the opportunity arises in the best way you can. Even in the early days of software, people realized the importance of good engineering practices. If your legacy code doesn't reflect that mindset, it is not worth praising. The article author himself recognizes that dumping work on other people is a trait of junior engineers, but applies it inconsistently in this case. Senior maintainers may be able to identify legitimate tradeoffs, but when a code base is consistently bad, especially when it was already bad in its historical context, don't expect a lot of praise for the code or the authors.

lmilcin 7y ago

I only recognize difference between junior/senior levels. My definition of senior developer: - Senior will not be "stuck" with a problem. They recognize there is somebody to get help from and they will seek it. But they can also function when there is no person to get technical help from. They will dig, and dig, and dig, until they finally solve the problem. - I can trust the solution to be usable even without supervision. - They will have minimum standard they will enforce around them (ownership). Ownership for me means they will look for things that are not right and act on it, without being specifically instructed to. - Is adult in behavior, can recognize and control their emotions, can work with other people, recognize and deal with communication problems. From my perspective, people who have huge technical knowledge and experience but can't be trusted with tasks, can't be trusted to not get conflicted with the team on the first possible occasion, are not honest with their results (hide problems), will sacrifice good of the project because they just have to test that new tech -- all these people are junior devs for me.

enraged_camel 7y ago
Your list only handles how senior engineers solve problems. IMO the most important qualities of a senior engineer pertain to knowing what problems to solve, and, at an even higher level of seniority, why those problems need solving. For example, senior-level engineers will recognize when a problem is not worth solving at all. They might know that a solution is technically possible/feasible, but they will also understand that the engineering resources (i.e. their time) can, and in fact should, be better spent elsewhere -- fixing more egregious bugs, enhancing existing features and developing new ones. To go back to what you said, being able to "dig, and dig, and dig" until they solve a problem is not what makes someone senior-level. Anyone with sufficiently high levels of dedication and stubbornness can go down rabbit hole after rabbit hole until they stumble upon something that resembles a solution. What distinguishes senior-level engineers is being able to step back and analyze the situation to determine if the rabbit holes are worth diving into.
- lmilcin 7y ago
  Let's be honest, this is requirements for a senior engineer, not a tech lead. It would, of course, be nice for a senior engineer to have perfect awareness but I think that is too much to ask to qualify to be called senior. Have you watched Star Trek (DS9 for example) lately? You may have a bunch of senior officers but they still do not always understand why stuff needs to happen. They muddle through on principles until they succeed. Then it is always easy, retroactively, to say it was their idea all along.

HugoDaniel 7y ago

People trying to find ways to justify paying less to programmers

narmihou 7y ago

Aren't these two statements below contradictory when taken at face value? Both under Junior dev. Over-engineering is a major problem, often leading to fragility and bugs. When given a problem, they often try to fix just the current problem a.k.a. fixing the symptoms instead of fixing the root problem.