13 ms·
What makes a senior engineer? Writing software vs. building systems
- JoeMayoBot 4y agoI 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.
- lbriner 4y agoI 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 4y agoAgreed. 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.
- AlotOfReading 4y agoEveryone 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.
- donretag 4y agoI 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 4y agoYeah 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 4y agoI 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.
- 2rsf 4y agoIt really differs between companies, and sometimes even teams within one company. If anything a senior engineer will complete tasks better rather than faster by having a wider and deeper understanding of the system.
- angarg12 4y agoSenior 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 4y agoOr even worse: an indicator of time spent in the industry
- firstSpeaker 4y agoOne 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 4y agoThe 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.
- automatic6131 4y agoThis. 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 4y agoTo 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.
- 4y ago
- VyseofArcadia 4y agoThere'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.
- epgui 4y agoThis! 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 4y agoI'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 4y agoFrankly, 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.
- deleted 4y ago[deleted]
- mkl95 4y agoAt 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.
- deleted 4y ago[deleted]
- greatpostman 4y agoIn 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
- NAHWheatCracker 4y agoNot 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.
- bluGill 4y agoThey 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 4y ago> "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 4y agoI'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 4y agoIn most companies being "rigorous" seems to mean "checking the correct arbitrary boxes". What does it mean at your company?
- revskill 4y agoTo me, it's ability to build good abstraction that differentiates senirority of an engineer.
- bigmattystyles 4y agoI 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.
- dim9000 4y agoSoftware development is not a regulated field like civil or mechanical engineering. The term "Senior" is complete BS. I prefer SDE I, II, etc
- rodenmonte 4y agoWhy are numbered SDE ranks less "BS" than junior/senior?
- unity1001 4y agoBeing 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.
- orangesite 4y agoAs 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.
- egberts1 4y agoYeah. 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.
- ridiculous_fish 4y agoDid you end up using ReiserFS? How'd that go?
- egberts1 4y agoRecommendation was made. And then implemented by the team. looks like it is still in use today.
- lagrange77 4y agoSome 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 4y agoUnless 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.
- Cerium 4y agoThe 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.
- lagrange77 4y agoI'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 4y agoEven 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.
- ChrisMarshallNY 4y agoI always take these "If you don't pass this litmus test, then you aren't an XXX," or "Only an XXX will pass this litmus test" articles with a grain of salt. In my experience, the litmus test is frequently one that the author of the article can easily pass, which makes them an XXX, by default, and the article is really just about how awesome XXXs are, or the author assumes they have the authority to bestow the mantle of XXX unto others. The word "senior" means "Has more responsibility/experience." That's about it. It can mean "Manages/directs others," but doesn't have to be that. It can mean "Is an architect," but that doesn't mean they are. I have watched senior blacksmiths at work (awesome, BTW), and they got their hands dirty, and their aprons spotty, just like their juniors. I was a "Senior Manager," but was only a first-line manager. The title was really just there, so I could have an office, and the folks in Japan would take me slightly more seriously. Banks can have hundreds of "Vice Presidents," that work in cubicles, and don't have any direct reports. It's really just a title. I'm definitely a "senior engineer," these days, and I architect stuff, but I don't manage or direct others, and the scope of what I do, is smaller, because, every time I count myself, it comes up "1." It's really up to each organization to define "senior," and to set up a professional environment that implements their definition. Litmus tests are fine, I guess. I fail them all deliberately, because I'm an ornery sumbich. I won't join any club that would have me as a member.
- g051051 4y ago> I’m a Frontend Engineering Manager So this is a managers view of it.
- analog31 4y agoI 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.
- nitwit005 4y agoAs 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.
- mywittyname 4y ago> 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 4y agoI 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.
- lukeasch21 4y agoHi there, I know it's a little distasteful to hijack your comment on an unrelated topic but I didn't know any other way to contact you. About 6 months ago, you commented on my post (https://news.ycombinator.com/item?id=30687601 https://news.ycombinator.com/item?id=30687601) about making an SMS based browser with improvements over coldsauce's Cosmos Browser. I just wanted to let you know that I've basically finished all my major goals with it and released it publicly! (here's that post: https://news.ycombinator.com/item?id=32905496 https://news.ycombinator.com/item?id=32905496 ). I hope you enjoy it!
- activitypea 4y agoThat makes Uncle Bob a junior engineer :^)
- p1nkpineapple 4y agoAs 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"?
- CiPHPerCoder 4y agoNot 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.
- hosh 4y agoThey 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".
- XorNot 4y agoWell this is just ridiculous. What makes me a senior engineer is I convinced someone to call me that for my job title. That's it - that's 100% the distinction. It has never had the slightest apparent impact on what I wind up actually doing.
- fbrncci 4y agoNot even a year into career as a developer, and being hired as a Junior, I just started interviewing as a Senior, and then got a Senior position with the salary to match it. First year I thought I'd be "found out", but apparantly there really is no bar for entry.
- fsergio101 4y agoBe careful, despite participating across all stages and areas described can be awesome, and enriches you a lot, you are under the risk of generating toons of dependencies on your team, since you are the person for all and that culture ir insane for you and your team. From my point of view seniority is measured in terms of how you get the more impact with the less time invested. For instance: Senior engineers should realise about wrong decisions and intermediate then, on the other hand takin the decission from scratch would generate 3 problems: feed the dependency on the senior profile, not allow other to develop themselves, too much time investement from the Senior.