Ask HN: Favourite definition of seniority of software engineers?
I'm pulling together a list of criteria for the various levels of software engineers. I know some are public. What are the public definitions that you like the most/feel are accurate with your experience?
4 comments
Unfortunately, what I see the most is:
An increase in seniority comes with (A) a decrease in hands-on time with technical problems and (B) an increase in time spent on project management, team organization, and people problems.
None the less, there are some possibly interesting resources regarding levels at Honeycomb [1], Netflix [2], and Gitlab [3]. There's a whole book if you're going to venture into "staff" [4]. Last but not least, don't forget the Peter Principle [5].
[1] https://www.honeycomb.io/blog/engineering-levels-at-honeycom...
[2] https://blog.pragmaticengineer.com/netflix-levels/
[3] https://about.gitlab.com/job-families/engineering/developmen...
[4] https://staffeng.com/guides/staff-archetypes
[5] https://en.wikipedia.org/wiki/Peter_principle
An increase in seniority comes with (A) a decrease in hands-on time with technical problems and (B) an increase in time spent on project management, team organization, and people problems.
None the less, there are some possibly interesting resources regarding levels at Honeycomb [1], Netflix [2], and Gitlab [3]. There's a whole book if you're going to venture into "staff" [4]. Last but not least, don't forget the Peter Principle [5].
[1] https://www.honeycomb.io/blog/engineering-levels-at-honeycom...
[2] https://blog.pragmaticengineer.com/netflix-levels/
[3] https://about.gitlab.com/job-families/engineering/developmen...
[4] https://staffeng.com/guides/staff-archetypes
[5] https://en.wikipedia.org/wiki/Peter_principle
Wasn’t familiar with the Peter principle before but seems it’s a common trope. Doesn’t this assume the individual stops learning though?
I was throwing it in as a bit of humor, but your comment illustrates how it really can provide fuel for an interesting set of conversations around ladders/roles where an engineering team can thrive.
Does the peter principle assume a person stops learning? On the surface, yes. And if learning leads to skills, maybe we could also consider success in different jobs as a combination of both skill and motivation. This would highlight a couple of the common, real-world problems I see when engineers "rise" up the ladder:
1. A first problem is many senior roles require new organization and leadership abilities, thus the core of the Peter Principle. (skill)
2. The second is that absent careful thinking and goals, many engineers will seek arbitrary advancement only to find their ability to succeed disappearing when those new skills aren't as fun/engaging/fulfilling. (motivation)
Does the peter principle assume a person stops learning? On the surface, yes. And if learning leads to skills, maybe we could also consider success in different jobs as a combination of both skill and motivation. This would highlight a couple of the common, real-world problems I see when engineers "rise" up the ladder:
1. A first problem is many senior roles require new organization and leadership abilities, thus the core of the Peter Principle. (skill)
2. The second is that absent careful thinking and goals, many engineers will seek arbitrary advancement only to find their ability to succeed disappearing when those new skills aren't as fun/engaging/fulfilling. (motivation)
If we’re talking about “favorite” definitions: the more senior the less time one spends at their “desk” - whatever that means now with everyone being remote
Posted a comment about this just the other day: https://news.ycombinator.com/item?id=32826054
[deleted]