[HN Gopher] What makes a senior engineer? Writing software vs. b...
___________________________________________________________________
What makes a senior engineer? Writing software vs. building systems
Author : fagnerbrack
Score : 172 points
Date : 2022-09-12 13:24 UTC (9 hours ago)
(HTM) web link (codewithstyle.info)
(TXT) w3m dump (codewithstyle.info)
| VyseofArcadia wrote:
| 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.
| onlyrealcuzzo wrote:
| At FAANG, I think it would look like:
|
| Junior eng: screenshot of code (with some help chat)
|
| Eng: screenshot of code (with no help)
|
| Senior eng: screenshot of design doc
|
| Staff eng: screenshot of calendar with a wall of meetings for 5
| days
| yodsanklai wrote:
| 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.
| JimmieMcnulty wrote:
| The problem is that "just coding" isn't all that valuable,
| relatively speaking.
|
| College grads can do it barely, and 5 years in they're fine.
| What do you do with the rest of the people who, 10 years after
| that, want to do the same things but get paid 50%+ more?
|
| "Virtuoso" coders aren't worth much (relatively), because it's
| not _that_ rare, and honestly bugs aren't really a big deal.
| Heck, you can write some pretty terrible code, and as long as
| it's not some specific flavors of bad, your company will be
| totally okay for a very long time.
| tekkk wrote:
| It depends what you are building. Make a simple CRUD, sure
| any code-monkey can eventually build one from ground-up even.
| Move on to something more arcane and complicated, you really
| need a specialist with eye towards simplicity and
| maintainability rather than having bunch mediocre coders
| building some buggy monstrosity. That's how you end up with
| these bloated and inefficient systems that go millions over-
| budget.
|
| Single virtuoso coder - or just a coder who just actually
| puts the effort to keep the mess contained - can be the glue
| that keeps the project actually usable and who in-turn
| educates others to be better programmers.
|
| They may not produce +50% more code than their less senior
| peers but the code that's in total written will be of much
| higher quality. That's how I see it. It's like having a great
| musician in a band - everyone will strive to play better to
| meet their standard.
| JimmieMcnulty wrote:
| epgui wrote:
| This!
|
| My dream job is to have none-to-few meetings and to have my
| head in code all day.
|
| I do have something close to this right now, but I really hope
| that in 10 years I can still be writing code.
| zasdffaa wrote:
| I'm a dev and I see my job very much in contrast to what
| you've described. My job is to solve business problems,
| typically using code, but it all the things around it like
| requirements gathering etc.
|
| It also definitely includes trying to solve business problems
| by not writing code; by saying "this is a business problem
| not a technical one, how about trying <some non-coding
| approach>"
|
| Not to disagree with you, just giving a contrast.
| VyseofArcadia wrote:
| Frankly, I see it as my job to write code. That this code
| happens to solve business problems is a lucky coincidence.
|
| Of course, this attitude may be a reflection of the fact
| that I have never written software for a domain in which I
| have expertise. Maybe if I were working on a product that I
| myself used, I would be able and happy to help solve
| business problems. As is, that is better left to a SME, and
| I am happy to solve technical problems.
| rconti wrote:
| I'd say "your day is spent writing code. That this code
| happens to solve business problems is why someone pays
| you to do it".
| epgui wrote:
| 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.
| idontpost wrote:
| > 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.
| epgui wrote:
| That goes without saying, and is not incompatible with a
| reasonable reading of what I said.
| zasdffaa wrote:
| I once solved an urgent business problem (related to
| interfaces FYI) by realising there must have been a 3rd
| party solution. A quick search and I found it. It went
| onto client sites soon after.
|
| To be fair, the problem had to be solved using code
| anyway (why I was originally brought in), so another team
| wrote that, but it took several man-years. My interim
| 'fix' bought the company a lot of time.
|
| This isn't a great example as the code had to be written
| anyway, but you get my point I hope.
| epgui wrote:
| 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.
| unity1001 wrote:
| You will likely get bored eventually. For you'll start to see
| patterns, you'll start to see much further ahead after some
| time. You'll be able to see things from a much wider
| perspective. You will see that there are many things that can
| be done, must be done, and must be avoided. Many potential
| opportunities and pitfalls. Your horizon will broaden. You
| are now able to think and plan much further ahead and you are
| able to plan much bigger things.
|
| But you will notice that you are just one person. Its
| impossible to do all of that alone. Then you realize that you
| need to work as a team.
| epgui wrote:
| Most engineers I hear say this ("you get bored and after a
| while it's all the same") don't seem to share my interest
| for learning very-different languages or academic computer
| science theory. I am interested in all of that, and I am
| pretty confident I will never run out of things to learn.
| epolanski wrote:
| You say that with few years under the belt. Come in a
| decade.
| epgui wrote:
| I studied biochem for 12 years and know what it's like to
| reach the edge of human knowledge on a very very very
| narrow and specialized topic.
|
| I know enough about the breadth and depth of computer
| science to know how insane it is for any one person to
| think they've run out of things to learn.
| fuzzy2 wrote:
| 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.
| twblalock wrote:
| > It's like if a virtuoso musician were told that he can't play
| music anymore. He needs to move on to conducting
|
| That's because coding skill, once you reach a certain baseline,
| is _good enough_ and other things like architecture matter far
| more than raw ability.
|
| Unless you are an outlier like John Carmack, improving your
| coding ability really does not improve your ability to provide
| business value. The difference between a junior and senior
| engineer is really the difference in knowledge about what can
| go wrong, and that knowledge is fundamentally about
| architecture and edge cases, not coding ability.
|
| > Some business somewhere ought to make an effort to let the
| virtuoso coders keep doing their thing, and break out the
| engineers who want to go into system design as a separate
| career track.
|
| That does happen, mostly at large companies that can spare the
| resources. I know a number of people who have been around for
| decades and make a _lot_ of money doing that.
| bcrosby95 wrote:
| > The difference between a junior and senior engineer is
| really the difference in knowledge about what can go wrong,
| and that knowledge is fundamentally about architecture and
| edge cases, not coding ability.
|
| What do you define as part of coding ability?
|
| You're making design decisions anytime you code things.
| Sometimes its smaller scale but sometimes it's larger. Edge
| cases and consequences of your code are abound in every line
| you type.
|
| Trying to divorce these things from coding ability feels
| really artificial. If they aren't coding ability, what is?
| Raw typing speed?
| twblalock wrote:
| 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.
| bee_rider wrote:
| Perhaps we should come up with different job titles for people
| who do design, and people who do implementation.
| lhorie wrote:
| There _are_ two different career tracks, namely IC (individual
| contributor) and EM (engineering manager). The latter revolves
| almost entirely around people management. For the IC track, I
| 've found this writing[0] on staff engineer archetypes useful.
| The gist is that there are archetypes that involve a lot of
| people management, but there are also some that are highly
| technical / coding oriented.
|
| One analogy that comes to mind is wuxia/murim novels (i.e.
| stories set in ancient times east asia, involving martial arts
| sects). Among the strongest characters, there's the sect leader
| type that is involved in politics most of the time, but there's
| also the recluse master training in the mountains type.
| Naturally, there's also plenty of characters clinging to
| titles, overconfident fools, etc.
|
| I think this analogy is interesting because there's a clear
| parallel between the two worlds in terms of how titles are
| perceived, the craft that they purport to represent, and their
| place in the world. Titles can represent both status and
| mastery, but only loosely at best, the craft can be honed
| irrespective of both titles and the state of the world, and
| it's only through increasing a sphere of influence that one can
| have a sizable impact in the world and its citizens.
|
| [0] https://staffeng.com/guides/staff-archetypes
| PuppyTailWags wrote:
| 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.
| VyseofArcadia wrote:
| 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.
| ilc wrote:
| In systems: Politics is as much a constraint as budget, and
| technical constraints.
|
| If your manager will not accept way X. It really doesn't
| matter if X is optimal. You'd better find Y, or convince
| the manager.
| 8note wrote:
| Imo, the politics is the design.
|
| Who is going to pay for what? Who's responsible for when a
| certain part goes wrong?
|
| If you figure out the politics well, you've mostly
| constrained the system design to something straightforward
| kkirsche wrote:
| Or, you built a poorly architected piece of software that
| replicates your organizational structure.
| jrockway wrote:
| 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.
| zamfi wrote:
| In many of these organizations, PMs serve to insulate the
| "planning and design" ICs from conversations with
| customers.
|
| Not ideal either, IMO, ICs involved in planning and design
| should get out there and talk to customers themselves!
| jacobr1 wrote:
| Or Architects
| scruple wrote:
| 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.
| glomgril wrote:
| > 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).
| tkzed49 wrote:
| 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.
| scruple wrote:
| 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.
| tunesmith wrote:
| 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.
| vhold wrote:
| I get the impression that John Carmack has achieved this, and I
| bet it required him to forcefully take control of his schedule.
|
| Which reminds me of this game: https://www.saynomo.re/
| nitwit005 wrote:
| That's essentially the Peter principle. Skilled people being
| promoted to a role they are not skilled at.
| jakey_bakey wrote:
| 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.
| ilc wrote:
| 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.)
| wppick wrote:
| The same is true in other industries. For example, most of the
| cooking in a professional kitchen is done by the more junior
| cooking staff. The head chef doesn't actually cook much, but
| handles more logistics like the ordering of the food/wines and
| dealing with suppliers, planning the menu, maintaining a high
| level of service.
| alistairSH wrote:
| My employer attempts to solve this by offering several
| overlapping tracks.
|
| Engineer (junior through principal) - screenshot of code
|
| Architect (mid-career through principal) - screenshot of system
| diagram alongside code that implements part of the diagram
|
| Technical Fellow (principal+, considered equivalent to
| directors, but still IC) - screenshot of system diagram
| alongside overbooked calendar
|
| Manager (mid-career+) - overbooked calendar, maybe an IDE on a
| light day
|
| And also product managers and business analysts and others.
| spaetzleesser wrote:
| "overbooked calendar": the ultimate status symbol
| mywittyname wrote:
| > What makes a senior engineer?
|
| 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.
| epolanski wrote:
| I don't think the article is as bad as you make it.
|
| I too find that seniority should involve understanding systems
| and business e.g. and the author layed it down nicely.
| greatpostman wrote:
| 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
| bluGill wrote:
| 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.
| chrisweekly wrote:
| > "They also have experience on what doesn't work. "
|
| This. "An expert is a person who has made all the mistakes
| that can be made in a very narrow field." - Niels Bohr
| rconti wrote:
| 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.
| ZephyrBlu wrote:
| In most companies being "rigorous" seems to mean "checking
| the correct arbitrary boxes". What does it mean at your
| company?
| rconti wrote:
| There are boxes, for sure!
|
| 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.
| NAHWheatCracker wrote:
| Not in big tech, but most of the senior engineers I've worked
| with were hired to the position.
|
| I agree with your assessment for the ones who were promoted to
| it.
| lagrange77 wrote:
| 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.
| bbarn wrote:
| 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.
| lagrange77 wrote:
| I'm not sure, if i get your point.
|
| 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.
| epolanski wrote:
| Even assuming it's great original code for an interesting
| problem, I don't think it says much about the candidate and
| how he will do in your company.
| Cerium wrote:
| 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.
| [deleted]
| mkl95 wrote:
| 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.
| bigmattystyles wrote:
| 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.
| [deleted]
| nitwit005 wrote:
| 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.
| ChrisMarshallNY wrote:
| 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
| _XXX_ s 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.
| dim9000 wrote:
| Software development is not a regulated field like civil or
| mechanical engineering. The term "Senior" is complete BS. I
| prefer SDE I, II, etc
| rodenmonte wrote:
| Why are numbered SDE ranks less "BS" than junior/senior?
| epolanski wrote:
| Because they are bs faang titles, so in his opinion more
| relevant.
| dim9000 wrote:
| Its all bs, but I prefer numbered ranking since faang uses
| them.
| revskill wrote:
| To me, it's ability to build good abstraction that differentiates
| senirority of an engineer.
| analog31 wrote:
| 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.
| JoeMayoBot wrote:
| 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.
| AlotOfReading wrote:
| _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.
| lbriner wrote:
| 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"
| rconti wrote:
| 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.
| activitypea wrote:
| That makes Uncle Bob a junior engineer :^)
| g051051 wrote:
| > I'm a Frontend Engineering Manager
|
| So this is a _managers_ view of it.
| angarg12 wrote:
| 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.
| zwkrt wrote:
| Or even worse: an indicator of time spent in the industry
| firstSpeaker wrote:
| 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.
| wildfire wrote:
| The bar is per-team at Amazon, which is one of the bug hiring
| problems.
|
| Worse, your title - and your quality of life at Amazon - is
| entirely dependent upon what your manager thinks of you.
|
| It matters _way_ more than at other companies.
| knightofmars wrote:
| 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.
| naet wrote:
| 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.
| TrackerFF wrote:
| 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.
| ZephyrBlu wrote:
| 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.
| 0xB31B1B wrote:
| 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.
| zeroonetwothree wrote:
| 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.
| eikenberry wrote:
| 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.
| zamfi wrote:
| "Senior" the title is different from "senior" the role. The
| former is close to irrelevant; the latter is what's
| interesting.
| TheYahiaBakour wrote:
| Plasmoid wrote:
| I've heard it said that comparing levels across companies is
| like comparing salaries across countries.
| tayo42 wrote:
| 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.
| NAHWheatCracker wrote:
| 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.
| epolanski wrote:
| So does any corporate and non-corporate title since 3 decades.
| automatic6131 wrote:
| 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.
| dgfitz wrote:
| 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.
| epolanski wrote:
| I would argue time is a poor metric.
|
| It's about the value you are able to bring, not howmany
| days you worked.
| deathanatos wrote:
| 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?"
|
| 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.
| orangesite wrote:
| 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.
| p1nkpineapple wrote:
| 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"?
| hosh wrote:
| They synergize together.
|
| 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".
| 0xB31B1B wrote:
| 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.
| CiPHPerCoder wrote:
| Not really.
|
| 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.
| unity1001 wrote:
| 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.
| egberts1 wrote:
| 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.
| donretag wrote:
| 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.
| Test0129 wrote:
| 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.
| didibus wrote:
| 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.
___________________________________________________________________
(page generated 2022-09-12 23:00 UTC)