10 ms·

What makes you senior

• moralestapia 11mo ago
  This sounds cool but reality is much more boring than that. If your work title says "Senior" then you're Senior.
  • raw_anon_1111 11mo ago
    Until you get to a behavioral interview at your n+1 job…
    • moralestapia 11mo ago
      What's that supposed to mean?
      • raw_anon_1111 11mo ago
        These are typical questions I ask when I’m interviewing a senior developer: “Tell me about a project you’re most proud of?” Then I’m going to start asking questions about your decision making process, how you dealt with complexity and ambiguity, etc. If all you did was pull well defined tickets off the Jira board, you’re not going to be able to answer that question well and you aren’t the type of person I’m going to delegate a very ambiguous assignment where you have to make good architectural and organizational decisions and have to deal with “the business” to disambiguate. The next question would be “Looking at your resume, I see you have $x years of experience, if you could go back to one of your earlier projects, what choices would you have made differently knowing what you know now?” If you haven’t led any major initiative, what are you going to say? “I would have pulled more tickets off the board?” I interviewed someone from AWS at my last job, he thought he was a shoo in especially after he looked on LinkedIn and saw that I was from AWS. I guess he thought he was going to be reversing a binary tree. No matter what I asked, he couldn’t describe anything he had done of note except be on a team who did stuff. I asked him had he led any features, presented any “six pagers” internally, blog posts on the AWS site, presentations - he had done nothing. I passed over him for a guy at an unknown company who could talk about where he “took ownership”. That’s one of the Amazon BS Leadership Principals. Hell I had a public footprint at AWS after only 3.5 years I had been there as a mid level L5 employee.
        • necovek 11mo ago
          I do all my interviewing in a very similar way, but I don't use that to "level" an employee: I want most of the engineers in my team to have this mindset, and the only difference between seniority levels should be in the size/scope of the initiative they led and took ownership of, and obviously, the level of exposure to wrong things they had a chance to do and learn from. I will sometimes take someone where I believe they were not put in a position to do this, and who I believe I can support to develop this mindset. I know I've done all of this since day 1 of my professional software engineer career (and well, before that too). I've also been "side-moted" to a Tech Lead after 2 years of starting my career in a strong tech company too.
  • onion2k 11mo ago
    Based on a number of people I've worked with whose job title was Senior Engineer, it isn't that.
    • wiseowise 11mo ago
      It is. You might pat yourself on a back that you're "not like them", and in fact might be better than them, but if they hold the same title and earn the same amount of money – they're senior just like you.
  • ursAxZA 11mo ago
    Sometimes that’s true. Sometimes it isn’t. This seems to be a discussion about the latter.
• terrillw 11mo ago
  Great article. The key things often missing in meetings discussing a vague problem is do we really understand the problem and how do we make concrete progress. Its a hard skill and often just comes through experience - being able to put yourself in the user's shoes to understand their problem, and knowing based on past experience, how to execute. That is the value of seniority.
• andsbf 11mo ago
  Oh, so it isn’t about know to solve any leetcode? Good to hear it
• onion2k 11mo ago
  A very important skill for Senior engineers not mentioned in the article is an ability to take the initiative on something. For example, when a dev sees a bug in an area of code they aren't responsible for and thinks "I'll raise an issue for that and mention it to the product manager so we can get it fixed" instead of "Oh, a bug", then they're starting to show that senior mindset. It's a desire to make the whole of the software good rather than just the little bit they work on good.
  • bdangubic 11mo ago
    I have literally never seen or thought of this as “senior” thing. if anyone on the team regardless of their seniority does not operate this way they will see a quick exit to some other place
  • agumonkey 11mo ago
    beware, some cultures are territorial in nature and this kind of hard ownership will make people slap you if you ever try to improve things as they come. i'm in the camp of improving things regularly without hesitation but again this can devolve. another way it can turn sour is when the team is made of people too different from each other. one improvement from someone pov is a waste or even a regression for others .. then it's a 'who decides here' conversation. that said when you have a cohesive group all focusing on pushing in the same direction then it's bliss
    • juancn 11mo ago
      If you're skilled enough, sometimes you can even force the culture to change. It can be painful and not all battles are worth it, but it's doable.
      • agumonkey 11mo ago
        probably, that said i would love to hear stories on this ps: even beyond work, that kind of knowledge is very important, culture is a form of abstract layer over a group, and it can make or break your future
• hoss1474489 11mo ago
  I like this. I more generally look for reduces chaos. I’ve seen the pursuit of disambiguation employed to deadlock a project. Sometimes that’s the right thing to do—the project sponsor doesn’t know what they want. But many times the senior needs to document some assumptions and ship something rather than frustrating the calendars of 15 people trying to nail down some exact spec. Knowing whether to step on the brake or the gas for the benefit of the team and company is a key senior trait. This is a yes, and to the article; building without understanding the problem usually will increase chaos—though sometimes the least effort way through it is to build a prototype, and a senior would know when to do that and how to scope it.
• oh_my_goodness 11mo ago
  It's just a pay grade. Please folks stop trying to analyze "junior," "senior," and so forth. It's just something management told HR to write down.
  • WhyOhWhyQ 11mo ago
    When did this "junior/senior" lingo get cool? I don't remember it being used when I was young. Maybe the leet code trend brought on a sort of gamification of the profession, with ranks etc..?
    • raw_anon_1111 11mo ago
      As a 51 year old, I hate when other old people think that “back in my day things were different” > Evans has held his present position with IBM since 1965. Previously, he had been a vice president of the Fed- eral Systems Division with the man- agement responsibility for developing large computing systems; the culmina- tion of this work was the IBM/System 360. He joined IBM in 1951 as a junior engineer and has held a variety of engineering and management posi- tions within the corporation Dated 1969 https://bitsavers.org/magazines/Computer_Design/Computer_Design_V08_N05_196905.pdf https://bitsavers.org/magazines/Computer_Design/Computer_Des... Next meme that needs to die: “back in my day, developers did it for the love and not the money”
      • WhyOhWhyQ 11mo ago
        The title has always existed. I meant the obsession about being a "a junior" or "a senior", like gaining an achievement in a video game or something. I just thought every young person was a junior engineer and every old person was as senior engineer.
        • raw_anon_1111 11mo ago
          You don’t get to be a senior engineer just because of tenure. It’s not gaming the system to expect a level to be based on the amount of responsibility and not just from getting 1 year of experience 10x. You want a promotion because you want more money. Even though I have found the difference to not be that great on the enterprise dev side. But in BigTech and adjacent, we are talking about multiple six figures differences as you move up. I work in consulting and our bill rate is based on our title/level of responsibility. It kills me that some non customer facing consultants want to have a “career track” that doesn’t involve leading projects and strategy and want to stay completely “hands on”. We can hire people cheaply from outside the country that can do that. There is an IC career track that is equal to a director (manager of managers). But you won’t get there hands on keyboard.
• Razengan 11mo ago
  When someone calls you senpai
• paulcole 11mo ago
  Bro thinks this is unique to engineers.
• z3ratul163071 11mo ago
  age
  • ncr100 11mo ago
    Nah
• random17 11mo ago
  I think a lot of people in the comments are getting hung up on titles and missing the real point of the post. The headline probably didn’t help with that. The post actually does a great job of highlighting a genuinely valuable skill that the best engineers practice regardless of their title. In particular, “reducing ambiguity” is something I believe would be really beneficial for many early-career engineers to intentionally develop.
• rippeltippel 11mo ago
  Junior deals with "if" statements. Senior deals with "what-if" statements. <EoF>
• jamietanna 11mo ago
  Related: Job Titles are Bullshit (2024) https://news.ycombinator.com/item?id=39511732 https://news.ycombinator.com/item?id=39511732
• johndoh42 11mo ago
  Meanwhile the industry standard definition since the 80s: - Junior - someone who can work under guidance. - Regular - someone who can work alone. - Senior - someone who can guide others.
  • agumonkey 11mo ago
    I do wonder how seniors manage cultural / technical differences. If the junior is not responsive to guidance, advices, hints .. what else do you do
    • dijit 11mo ago
      If juniors ignore guidance and advice, they stay in junior roles, handling simpler, less impactful tasks. Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance. It’s perfectly fine to remain a mid-level engineer for your entire career if it makes you happy; it’s solid, honest work that contributes meaningfully. Plenty of people in their 60s have held the same job for decades, and that’s okay; it can be a path to genuine satisfaction.
      • HPsquared 11mo ago
        I don't want career growth, rather homeostasis. That is, growth that matches the rate of decay. At most, maybe something like "tissue remodelling" to be lean, clean and flexible, so to speak, but not "big".
      • luckylion 11mo ago
        > Everyone seeks career growth, but pushing for it too quickly often just leads to inflated titles without real substance. That's why I'm not a big fan of recommending people to often and quickly change jobs to increase titles and pay. Their skills don't level up the same way, and they end up with a title of senior/lead developer and can't actually build maintainable systems or solve problems that nobody tells them the solution to.
        • 11mo ago
• alexgotoi 11mo ago
  > this isn’t talent, but practice This. Totally agree. Seniority level it’s based on the volume of practice someone has. Period.
  • Insanity 11mo ago
    Disagree, it's not _just_ practice. You can do something for 10,000 hours but never actively try to improve. Does that mean you're now more senior because you had more volume of practice? e.g, let's say someone spends 10k hours doing just 'addition and subtraction' problems on 2 digit numbers. Are they now better at maths than someone who spent 0.1k hours but doing a variety of problems? To grow as a software engineer, you need to have volume + have this be outside of your comfort zone + actively try to improve/challenge yourself. Apart from this, I do agree it's not 'innate talent' that drives someone to become a senior engineer, and I think anyone with the right attitude / mindset can do so.
    • bryanlarsen 11mo ago
      “Some people say they have 20 years experience, when in reality, they have 1 year's experience repeated 20 times." - Steven Covey
  • necovek 11mo ago
    There is no denying practice is needed, but... I've been doing this (getting to reduce ambiguity and simplify complex problems) since before my first job in free software communities, yet really, I wasn't anywhere close to "senior" when I joined my first job at a demanding SW organization at 22 years old. There was simply a lot I did not know, but I had the talent to do this part well (sure, one can argue that I had "practice" doing this with any problem since I was ~10 years old, but calling that "senior" would be... over the top: I think it rather qualifies as "talent"). It took me a couple of years of learning good software engineering from my wonderful and smart senior colleagues and through my own failures and successes for me to become a Tech Lead too.
  • anthonypasq 11mo ago
    being senior is clearly about having certain abilities or skills and absolutely nothing to do with how long it took you to acquire those skills
• bpev 11mo ago
  idk about titles, but my basic thought is that when you are less experienced, you're paid to do things, and when you are more experienced, you're paid to know things.
  • Viliam1234 11mo ago
    But it also depends on the organization. If your managers love to micro-manage, you will be paid to do things, because someone else believes they know better than you.
• cod1r 11mo ago
  I suffered with this problem quite often with my previous job. There would be something vague assigned to me and I didn't quite get what to do but I also felt like if I asked questions, it'd give off a vibe like I didn't know what I was doing so I would just start programming and making a bunch of assumptions. That wasted a lot of time which is a lesson to be learned from. I also struggled with self management.
  • agumonkey 11mo ago
    usually what i did is to take an abstract spec, derive thick layers / modules to decompose the problem, and then look at the deadline to see what MVP i can draw in that space. whenever that mvp is not what was expected, if i'm lucky enough, the decomposition allows for easy adjustements to match the need
  • dcminter 11mo ago
    My superpower as a staff engineer was having zero shame in asking questions. Anything from "what does that abbreviation stand for?" through to "what will the traffic look like when we go live?" - mostly people are worried about looking ignorant, so weirdly this makes you look both knowledgeable and confident! I wish I'd known that when I was younger...
    • mooreds 11mo ago
      Yes, this is so powerful. One of my favorite moves is to ask a question that I feel has an obvious answer and then say "what am I missing?" Sometimes I am right, other times I am missing something. Either way I'm modelling: - that it's okay to ask questions to which the answer seems obvious - that it is totally fine not to know everything
      • jofzar 11mo ago
        Mine is "I'm going to ask the stupid obvious question here", then ask the question.
    • tintor 11mo ago
• rented_mule 11mo ago
  It's subtle, but I think the use of "senior" rather than "Senior" in the article is an attempt to distinguish the concept of being a senior engineer from the title of Senior Engineer. The article is focused on actually being senior, not playing title games. I'd take it further and use the term "leader" instead of "senior engineer". Leaders reduce ambiguity, so others can operate with more clarity. The ambiguity involved can be in many different domains. It can be focused on product and tech, as in the article. Another example is ambiguity around people and organizational structure, which is more common in management roles, where some in management are more effective leaders than others. It can be around finding ways for people to understand why they might want a product, which is more common in sales and marketing roles. And so on.
• ChrisMarshallNY 11mo ago
  Eh. Whenever someone posts something like this, you get a bunch of folks, stating how they meet that description, etc. Sometimes, they do it humbly, sometimes, not. In my case, I met that description on my first job, and I guarantee, I was not senior. You see, my initial training was as an electronic technician (RF/microwave stuff). That thought process described, was exactly what they trained us to do. Debugging a wonky RF board is about as ambiguous as you can get. So maybe there's a different definition of "senior."
  • cvdub 11mo ago
    I agree. Someone can totally have this mindset while being an inexperienced developer. In my mind, a senior engineer knows what needs extra attention and where it’s ok to cut corners.
• kittikitti 11mo ago
  One thing that I would like senior colleagues to avoid is the tendency to claim something can't be done or is impossible. Sometimes, a colleague would claim something can't be accomplished but when I do accomplish it, it can create tension and give the impression that I'm undermining them. I would prefer if senior leaders instead enumerate the reasons why it can't be done and avoid dealing with absolutes. Often, it requires research into unknowns that have real limitations such as costs or processing time. Thank you for considering it if this is useful to you.
• farcitizen 11mo ago
  When everyone in the room wants to go in a certain direction. And you tell the team "9/10 times i did it that way it blew up in my face.", and you don't fight them and let it play out as a lesson. And there is still a 10% chance it could work!
  • butlike 11mo ago
    why would you lose your army to something as stupid as 'i told you so?' Don't let them do it.
    • wiseowise 11mo ago
      Because it's not "your army" and there's no point in fighting meaningless wars. Just make a good effort to convey your point and if they still don't listen - let them learn their lesson.
      • butlike 11mo ago
        I might argue metaphorically your direct reports can be considered your army. If not an army, then your microcosm of workforce. If you use up the workforce (in whichever way), then you're implicitly "done" as well. I think saying "no" is easier in a lot of business-related problems, and then when they're the manager, thy can decide. I also accept that as a manager, if I steer the ship incorrectly, I get to fall on that sword
    • deleted 11mo ago
      [deleted]
    • kcplate 11mo ago
      Likely these are not “lose your army level” lessons. I’ve let idiots touch a hot pan if they’ve insisted to do it. I would not let someone pour gasoline on themselves and strike a match
      • farcitizen 11mo ago
        Exactly. That was very intuitive that you picked that up.
• butlike 11mo ago
  age
• wiseowise 11mo ago
  Can someone who worked in multiple industries clarify: is it only software that has constant identity crisis with "what makes you X" and "what is expected of Y"? The only thing that makes a senior are years of experience, that's all. You can be a shitty senior if you only do one thing for 10 years, but you're a senior nonetheless.
  • Gagarin1917 11mo ago
    What if your company has you doing the job of a senior without the pay (because all the actual seniors left)?
    • Viliam1234 11mo ago
      If you have contacts on the seniors who have left, call them, ask them if they like the companies they are currently working for, and whether the companies are looking for new hires. In the job interview, give them the list of responsibilities that you have now. Then ask for a higher salary than you have now.
    • doublerabbit 11mo ago
      Jump ship. You'll forever be bargaining for the pay rise and if you do get it and don't deliver for whatever reason you'll end up shooting yourself in the foot. As the recent justification was for more pay.
  • Viliam1234 11mo ago
    I was a teacher, and I didn't notice anything similar. It's just a job -- if you can do it, you can do it. You can be more experienced, you can be more comfortable with solving certain problems, you can do it better or worse, but there is not... this. Some software developers seem to be in a lifelong dick-measuring contest. "You are not a true X unless you know this one important thing that I know." Okay dude, now do you expect Miss Teacher to come and praise you for how clever you are? You know some things that others don't, perhaps the others know some things that you don't, why is the former important for being a true X and the latter is not.
• hamasho 11mo ago
  > The moment you hand them something fuzzy, though, like ... > “we should probably think about scaling”, > that’s when you see the difference. Senior engineers should ask, "but do we need scaling? And if it does, how much needed now and future?" But I've seen a lot of seniors who jumped to implementing an unnecessarily complicated solution without questions, because they don't think about it too much, want to have fun, or just don't have energy to argue (I'm guilty myself).
• deleted 11mo ago
  [deleted]
• ChicagoDave 11mo ago
  I like the post but I’d add senior is also the instinct to take risks. I was once at a client in NY with an ASP.NET code base that used the compile at runtime capability (like Java used to). The C# source was being pushed to the web server. I ran a compile and the code was riddled with errors. So I went to the PM and explained the code needed to compile and I needed a day to clean it up. I refactored the entire project to compile and deploy that way. After that the development went very fast. The hilarious part was the three devs who’d gone on vacation came back and thought what I’d done was “wrong”. But the client said we (consultants) had done in two weeks what they couldn’t do in six months. That’s what a senior engineer does.
  • lunixbochs 11mo ago
    I'm not familiar with C# compile at runtime. Are you saying your change was to do an AOT compile locally?
    • whstl 11mo ago
      That's an old ASP.NET Web Forms / ASPX thing that was IIS-based. IIS would just compile .cs files into a temporary folder when first running. So the first request takes like 5s or something. It's not the new .NET Core AOT feature, GP was building the DLLs and packaging the website locally. Not GP but funny enough I ran into a similar problem with a team that also didn't know compilation and was just copy/pasting into a server.
      • enraged_camel 11mo ago
        >> So the first request takes like 5s or something. I haven't worked with IIS in more than five years, but couldn't you change some setting to infinity so the thread never sleeps... or something like that? I remember the "5 second" thing being a problem with commercial IIS apps we deployed, and that's always how we avoided it.
        • fuzzzerd 11mo ago
          This feature dated back to the .NET 1.1 days and was a " web site" project vs a "web app" project. It operated much like PBP, in the sense you could ftp raw code and it just worked, but it could also just blow up in your face because the whole site was never compiled in one go.
• hnthrow0287345 11mo ago
  I've had good PMs answer most of this themselves. Only if there's a technical detail they don't know about do they then ask specifically. OTOH other PMs throw vague jira-shit over the fence because they know how to take advantage of seniors who have been taught to reflexively work out the details even though it should be PM's job, just like this right here: >So we end up with “senior” engineers who can reverse a binary tree on the whiteboard but freeze when the spec is half-baked. The story here should be "the senior engineer is senior because they tell the person responsible for the specs to not half-bake their specs", not "senior engineer is senior because they fixed someone else's incompetence", but even then, there is likely a manager that should be demanding that before the senior does. Some of you senior engineers are less senior than others, and what I've continually seen is early senior engineers covering for other people (like half-baked specs). Eventually they learn that maybe a PM/Design should put some effort into a spec and covering for them means more work without compensation, and they stop fixing the laziness.
  • whstl 11mo ago
    If you have PMs answering the how of issues such as "we need to improve performance" or "we should probably think about scaling", then the senior engineer on the team is the PM, not you. The list of example questions at the bottom is clearly not exhaustive.
    • hnthrow0287345 11mo ago
      Sure, those two specifically can be handed off because they involve basically no user journeys for the product and a PM can't reasonably be expected to know the technical details of performance or scaling. But any PM or engineer should be able to at least ask "is the performance bad everywhere, or only specific things"? But a PM absolutely should be diving deeper to get more details on "users are complaining about the onboarding flow" and figuring out what should be fixed or what the ideal onboarding flow should be before involving an engineer. The exception of course is the onboarding flow has errors or is slow, which again the PM is not responsible for.
      • 11mo ago
• INTPenis 11mo ago
  I know how to set the right expectations.
• JohnMakin 11mo ago
  This shows very visibly in the devops/platform engineer/whatever-the-hell-we're calling-it-these-days world. Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like for example "reduce rate limiting for xyz service." Lots of ops guys will just blindly do this ticket shuffle, even very senior ones - maybe for their own sanity, maybe out of preservation - but the best ones I've ever worked with, will often question "Wait, why do you need that?" Then you find out there is some other really trivial solution to fix that underlying problem that doesn't involve as drastic of a change, or maybe even none at all. Especially if it doesn't involve code change on their side, you're not going to face much headwind in pushing back. The reason this is important is that, no disrespect to developers, they often live in a world where they treat infrastructure as a blackbox (as I believe they should). The problem sometimes is they want to also control the behavior of that blackbox. So while the request may seem to solve the problem, often there is a much easier/simpler/safer/scalable way to fix whatever underlying problem got tossed over the fence to you. The senior guys I've respected the most always will ask the "wait, why?"
  • irishcoffee 11mo ago
    I realized I was senior when jr. people would ask me things like "how do I make awk do this this?" and I responded with "what problem are you trying to solve?"
  • enraged_camel 11mo ago
    >> Often you will get a request, sometimes (or quite often) you have no idea what is driving it, like for example "reduce rate limiting for xyz service." At my company, we do not allow tickets that prescribe a solution. A ticket can only describe a problem or a need. The engineer is then responsible for starting a conversation with the stakeholder(s) to discuss which solution might work better for them. They then implement that solution. I know that larger companies have multiple teams that sometimes create tickets in each others' queues. I think this is a mistake. In multi-team environments, requests should go through some sort of custodian or gatekeeper who is responsible for making sure the problem or need are documented fully. This person can be a product manager or a scrum master. It should not be an engineer, though.
  • 11mo ago
• ermaa 11mo ago
  This is so right
• jumbledoor 11mo ago
  [dead]
• gethly 11mo ago
  the blog touches more on the management side rather than development so the term engineer seems misused. i encountered this topic many times in my life and after many years i can safely say that what makes an engineer being considered a senior is simply a talent, or learnt skill, of problem-solving without outside input. meaning, a senior engineer will find a way to get things done, just like special military guys do, without reliance on other people(as in, there is no safety net of skilled colleague who can help when needed or answer complicated or deeply technological questions). one is one one's own, so to speak. it is the same mindset, or rather attitude of not giving up and ploughing trough a problem until solution is achieved.
• cdrnsf 11mo ago
  Leveling and what qualifies as senior has been different at every stop in my career. So, yes, ask questions and look for clarity before you start working on something and while that’s an excellent approach, it’s not that simple.
• deleted 11mo ago
  [deleted]
• robofanatic 11mo ago
  Knowing which road is going to take you to a deadend and which one to the destination as early as possible.
• sapphirebreeze 11mo ago
  [dead]
• alexpotato 11mo ago
  Being senior, to me, is best illustrated by a story: Me: "Sometimes I feel like I'm psychic" Co-worker: "How so?" Me: "Many times on projects, I can tell at either the planning stages or the very early implementation steps if it's going to go well or be a disaster. e.g. people will say they love templated configs but they don't account for what can go wrong when there is a bug in the template etc etc" Co-worker: "I don't think that's being psychic. That means you are a senior engineer who has seen so many projects that you can quickly pattern match on if the project is going to succeed or fail based on only the first 20% of the project."
  • jbmsf 11mo ago
    I feel this way now, but with companies.
  • therobots927 11mo ago
    Ironically this can cause a lot of senior engineers to double down on conservative practices and fail to innovate or take risk imo. I’ve worked with several people at a higher level than me with more work experience who were for all effects and purposes complete idiots.
    • bravetraveler 11mo ago
      'Principal' engineer here, looking to perfect being the idiot! Knowing how to do things, and being known for it, has been an endless source of heartburn. All to say, I think there's wisdom at play. Even there. Having 'innovated and taken risk', juice is rarely worth the squeeze. Watercooler is too crowded and layoffs too arbitrary. A middling job rewards exactly as well. Reliably.
      • ChrisMarshallNY 11mo ago
        I don’t know how to do almost every project I take on[0]. I’m finding LLMs to be a godsend. Helps me to learn stuff, without the sneering. [0] https://littlegreenviper.com/miscellany/thats-not-what-ships-are-built-for/ https://littlegreenviper.com/miscellany/thats-not-what-ships...
• eweise 11mo ago
  Pretty sure my age makes me senior.
• deleted 11mo ago
  [deleted]
• smart-water 11mo ago
  Recently, I have had this thought as well. For a project or a task, it needs to be continuously broken down, clarified, and set with a schedule and acceptance criteria, so that it can be completed.
• devmor 11mo ago
  > What problem are we actually trying to solve? IMO this is the quintessentially most important question to ask as a developer. I probably ask this at least 3 times a week in meetings. One simple question can save you a lot of stress and wasted time realizing that the stakeholder's solution wasn't the best fit to solve their problem.
• NumberCruncher 11mo ago
  This article could have been a sentence: a senior engineer does engineering and does the work of the PO/PM too.
• SarahC_ 11mo ago
  Always been a "Dev"..... "Senior" is often a trap for longer hours, less pay, and more responsibility for nothing. I do like helping other people out with their code, and giving them ideas for alternative easier/better to maintain code. I love talking to our end users about their experience and needs. So often the Jira ticket isn't matching the users "Vison" (however rare users having vision is.... if you ask the right questions, they DO often know what they want, just not how they want it) I've given lots of help in the past but my name never appeared on tickets. My green boxes were few and far between. Sadly when the redundancies came - my boxes were mostly white. Axed. So be careful! I think "Senior" is a massive extent of skills - and most people aren't on the same page of its meaning. Some would even say "Senior" is that grumpy old guy that over-engineers everything and shouts at the youngsters if they say he's making stuff 9/10 other dev's can't maintain even with the documentation.
• ge96 11mo ago
  For me ego-wise I don't feel like I ever will be senior. I have worked with people who claim to be senior and are barely able to function so it's funny. I have worked professionally in some capacity for almost 10 years. Right now I'm working with cloudformation templates. I have seen myself improving over time and recognize my own older-self bad code. Learning faster. But yeah it's one of those things like I'm the quiet guy in a pack. I'm just lucky I lift so I'm big and people don't mess with me but I'm pretty meek as a person. This job is about merit, I'm not saying physical appearance should matter. But I'm emphasizing my self-esteem problem. Counter to myself, a co-worker of mine who's been at the company I just joined longer than me, he gets to set things up, make decisions. Then he has to change directions and hands it to me, I ask him "how did you come up with this" and he says "I asked ChatGPT" and I'm like what?... But it is a learning tool and doing new things (this case was a starting point for Apache Airflow DAG work). But that's a case of "I'm senior". I did read this article and I get the idea. I still have that problem where I ask what to do (mid) and a lot of times it's because I don't know if I can make a decision, is my choice good kind of thing. Uncertainty but again merit or ego? I'm also fine not being anybody, stress-wise and finance. Not sure what the pay jump is where I'm at. Wouldn't mind a coast-type job as I have pretty good perks (gym, walks, beer on tap, hybrid) and I can pursue my other projects outside of work like robotics that I can't do at my day job (agentic work lately). Alright I'll be done ranting, I have been a one-person dev for a startup that died it was a WebRTC document signing platform, damn that was a great project, had like 7 different repos of different tech even wrote a wrapper around Apple CUPS. So tragic when projects go nowhere and get shelved. I think the best thing I have learned is to put ego aside (regarding avoiding arguments) and just go with the flow. In my tense environment anyway, I need money so I need this job. I was able to get along with my manager who I was having problems with in the beginning. He's one of those very blunt, direct people, you'd consider an asshole. But I aspire to be that you know a driver that makes shit happen. Like a Steve Jobs although I'm not really an asshole, I don't like seeing other people in pain. Back to self-esteem.
  • majgr 11mo ago
    > Counter to myself, a co-worker of mine who's been at the company I just joined longer than me, he gets to set things up, make decisions. This is the most funny part I am encountering all the time. Either one has more experience (job hopping), or one has more weight in decision making (staying longer at one company). It is unusually hard trying to convince a manager who had their tech stack calcified the day he was promoted to manager role.
• fleroviumna 11mo ago
  [dead]
• fjfaase 11mo ago
  On top of this you also need to have the skills to communicate this with others, because if you are not able to convince others, in management, you are on a sure track to a burn out. Being the only one who sees the solution and not being able to convince others is going to make you very frustrated or to simply give up. Soft skills are always the more important than all other skills.
• panny 11mo ago
  What this article describes is less "what is a senior" and more "what is not a junior." My observation, juniors have something to prove. We've all been there. We get a problem, we want to show we are as good or better than the seniors, and we dive into it head first. Sometimes, it works out. Other times, it goes very poorly. When I was a junior, someone wanted to put a php marketing site for our product on my server. I didn't want it, saw it as a security hazard, and I had written them a custom CMS in my favorite MVC framework in two days. I had the keys, so I deployed that along side our product. It worked, they started using it, but my boss wasn't all that happy about it. It was deflating. I felt like I had moved a mountain for the company and no one was impressed. After a few months, they worked out a plan to put up a php marketing site on a server far far away from mine and everyone was happy with that. Senior me looks back and thinks I was lucky they didn't ask for a ton of feature requests, because that would have been all my problem. I was hired to work on the product, not a CMS for the marketing team.
• teodorlu 11mo ago
  I prefer «reduces uncertainty» to «reduces ambiguity». The problem isn't ambiguous specifications, it's simply that there are too many unknowns to just do the work at this point. The author talks about the shaping of the work, so I guess this is implicit.
• noduerme 11mo ago
  >>reduce ambiguity Uh huh. The one thing LLMs still suck at.
• pavlov 11mo ago
  It’s something you feel in your knees.
• nirvanac 11mo ago
  > what makes you senior From the perspective of a principal, it’s someone who knows just enough to make a big complicated mess and then feel self-important about it.
• zkmon 11mo ago
  That's very correct, but only in ideal world, isolated from the mess of the real world. We are not in ideal world. So what makes you a senior person is also to be aware that you are not operating in an idealized context and how your actions and thoughts relate to that context. When a powerful person is lecturing about public key and forgot to address private key, and if you thoughtfully ask "but sir what about private key?", you might be shown the door. It actually happens.
• scotty79 11mo ago
  For me it was unwillingness to work for a salary in mid-level bracket.
• maintenance 11mo ago
  As a mid-level developer myself, I am trying to internalize this advice around impact and about thinking from the user's perspective, but I fail to grasp what is perhaps a simple concept. Am I, as a developer, meant to grasp the domain, or even just the product I'm working on, at a level comparable to that of the intended user? Say I'm working in the fintech industry, and my product is meant for financial specialists. For me to be able to come up with solutions that bring the most impact would require me to understand what a user of such systems might need. However, I'm very clearly not the intended user for my product. How do I bridge this gap? Am I looking at it wrong? Edit: I'm not talking about strictly my product, but rather the product I'm working on, the company's product.
  • michaelrpeskin 11mo ago
    Funny you bring this up, I was just talking about this to someone else in a different context. I'm a pretty old dude for programming, I've been hacking in the field since the early 80's, and professionally developing for the last 25 years. Most people would be pretty unimpressed with my skill set, it's pretty much just "linear algebra", and I've basically solved the same 5 or 10 problems over and over again. The thing that, I think, has given me a competitive advantage is that I put a significant amount of effort into learning the domain I'm working in. I've gone from health care system to theoretical physics to image processing to logistics to financial plumbing to electricity markets to obscure stuff for the War Department, and so on. The value that you really provide to a customer is deeply understanding their domain and the problem they have in that domain and then translating that for a computer. If you're just taking tickets off of Jira and writing code without context you're no better than an LLM (just kidding...maybe). So yes, I suggest that whatever field you're working in, you put the effort into learning the domain as well as practitioners in that domain. That's how you become valuable. It's not easy, but after a few iterations you start to see patterns and it becomes easier. Maybe some of my bias is that when you have a hammer everything looks like a nail - or in my case: when you have a matrix everything looks like an eigenvalue. YMMV.
• deleted 11mo ago
  [deleted]
• black_13 11mo ago
  [dead]