7 ms·

First, I love Always Sunny, so this is amazing. Second, could I get some perspectives on this: > While senior engineers are individual contributors; the best e

• jedberg 3y ago
  There are two types of senior engineers. One is the type talked about here. Someone who loves to design and code, but wants to have more impact, and finds that guiding other engineers is a more effective use of their time. See the examples in the article: Creating a new RFC process, introducing a post check-in hook for security audits, setting up a new platform team that builds libraries for everyone else. All of these things multiply the work of everyone else. They make what everyone else is doing faster/more effective/easier. Then there is the other kind of senior engineer -- the one that can output well structured, efficient, self documenting, code quickly. The one that you give the thorniest problems and they surprise you with a solution a few days later. Solving things that junior engineers simply couldn't. There is value to both kinds of senior engineers. The first kind is much more valuable though because most orgs aren't doing the deep tech that the second kind of engineer is good at solving.
  • bobthepanda 3y ago
    Realistically you want a little bit of A and a little bit of B as well. The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on; at the end of the day, sometimes parallel workstreams are more effective, and relying too heavily on a senior engineer can create a bad bus problem.
    • jedberg 3y ago
      > The best is a senior engineer who can spit out the skeleton of B for junior engineers to work on That's what person A does. Agreed that having a super senior engineers is bad for the bus factor (FYI people are calling it the lottery factor now, as in "what if they won the lottery and retired") but sometimes you don't have the luxury of having backup people.
      • mecha_ghidorah 3y ago
        That's silly though because even if they won the lottery they'd probably at least have an exit period while they sorted out their winnings, and you could potentially pay them to work a reduced schedule or something, especially if they like working there. If I won the lottery I wouldn't stop working immediately, I'd give notice and could do some hand over. Bus factor though - if a bus hits me I am immediately gone and people have to catch up without hand holding
        • e1g 3y ago
          The “lottery” framing is the normalized and gentle way of asking “What’s our plan for when Stripe / OpenAI offers them a $1M/yr Staff role but only if they start immediately?” Think about the great engineers you’ve met, and how many of them would say “Sorry, but no - my current team relies on me, and I should help them transition”.
          • jasonm23 3y ago
            Lottery framing is the gentle way of saying, what if they die. But sure, go with the "other" lottery. That's why we called it a Truck number.
          • RugnirViking 3y ago
            I feel like a team that won't accept > Sorry, but no - my current team relies on me, and I should help them transition as a reason to allow a transition period is setting themselves up for failure. Isn't that the kind of engineer you want?
  • proc0 3y ago
    Excellent, thanks for the input.
  • vsareto 3y ago
    The first sounds like an architect or engineering manager in disguise without the title (and probably without the pay), but probably gets to skip out on some of the more boring meetings That leads us to wider communication problems for hiring: 1) pay is usually searched by title 2) job postings are also posted with titles 3) with those titles as ambiguous, you have to dig in to find out what kind it is The link from title to pay and the confusion around it is advantageous to companies because it means calling someone a Senior Engineer, but giving them more responsibilities, still justifies a lower pay range
  • soco 3y ago
    I'm the number two and must I agree, the need is punctual and there's quite some networking required to be able to reach to those corners of the (big) organization where they feel lost. It's almost always about some legacy thing and it's way cheaper to get me to fix and document it, right before thinking of rewriting/replacing.
• nkjnlknlk 3y ago
  It's not true everywhere but it's pretty much rewarded everywhere. Software engineering is pretty difficult to evaluate and managers will default to evaluating "soft skills" because they haven't looked at a PR in a decade. Also, the problems most organizations solve don't require much ability. That said, I also do not think the author means admin/business related tasks, but non-"coding" things like software design, technical vision, etc.? You might want to look at earlier stage start ups that don't need the management/pseudo-management positions (if it fits your life). Warning that you'll have to jump ship as the startup becomes successful and you get pushed into non-technical roles. :)
• jghn 3y ago
  Job levels are tied to the amount of business value one provides. At some point in one's journey, for most developers, they will hit diminishing returns in terms of what they can provide from just their hands on keyboard contributions.Thus at some point people will tend to either peter out level-wise or need to find ways to augment what they bring to the table in terms of coding. As an example, senior devs can be spending time mentoring, teaching, and guiding the junior devs in their team/org. Bringing up those around them will often, again not always, provide more business value than what they could have done on their own in that time.
  • scarface74 3y ago
    > Job levels are tied to the amount of business value one provides In many companies they aren’t tied to anything besides a meaningless title someone negotiates
  • re-thc 3y ago
    > Job levels are tied to the amount of business value one provides. How do we measure business value? Do all those new products that Google launch and kill off add value? But they create promotions... It's more like the illusion of business value.
  • krageon 3y ago
    > Job levels are tied to the amount of business value one provides. The other replies have told you already this broadly isn't true, so I will ask this: Do you have an example of a company where what I quoted is the truth? Normally promotions are almost entirely political, I'd love to see some examples (or even one) where this isn't the case.
• twic 3y ago
  Note that the examples of non-code output are ultimately still code - just not code written by the senior engineer. Part of what an effective senior person does is to take their own knowledge and wisdom, and externalise it in ways that let their colleagues take advantage of it without having to learn it from scratch. One of the most obvious ways of doing this is writing reusable code. Maybe you know the ins and outs of reliably spawning a child process in OS/2; you write a spawn_child_process_os2 function which does it, so others can take advantage of it. But there are less obvious, and sometimes more powerful ways to do this. The example of an RFC process externalises the engineer's understanding of how to rigorously think through and effectively communicate large changes. The example of security check-ins externalises the engineer's understanding of how to write secure code. The example of a platform team externalises the engineer's understanding of all sorts of code and build details particular to the organisation.
• ebiester 3y ago
  The further up the ladder you go, the less this is true. I tell people about a senior plateau - after this point, the growth gets smaller. Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve. Further, as organizations grow larger, there are more implications to every extra feature. That is, all of the easy stuff is done and the hard stuff means a change in multiple parts of the system, introducing fragility and cross-team coordination. In some cases, the effort in coordination outweighs the effort in code. And that's what I need a senior developer to do - can they understand multiple systems, work with multiple teams, or do they need engineering managers to figure it all out and give it to them bite-sized? And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them.
  • proc0 3y ago
    Good points. It makes sense overall. I'm wondering if the perception is that high level engineering doesn't have as much business value as lower level engineering that allows teams to work in parallel. > Everything is just another framework, just another language, just another pattern. At this point, unless you are a spectacularly proficient programmer, there's a limit to how much further you are going to improve. I believe this is mostly a business decision, although one that could be justified. In theory, systems can be built such that changes and updates are simple configuration changes, including new features. Another example is using advanced techniques to guarantee no bugs. So while any given feature could be coded by multiple teams of mid-level skill, it could also be coded by a small team of high level engineers. As the system matures the cracks become visible and unless there are sophisticated techniques, codebases tend to deteriorate and that introduces otherwise unnecessary business costs to fix issues or even build a new system. The main reason I can think of why this is an accepted "sacrifice", is that a team of high level engineers cannot be as transparent as multiple teams with lower level engineers and managers. High level engineering is often opaque to everyone except others that have the knowledge. > And that is the impact that engineering leaders look for - someone who can code faster than everyone else just means there's a giant bottleneck everywhere around them. So yes, this makes sense but I think it's only a bottleneck if others are not as technically proficient. Speed comes as a result of more technical knowledge, and it seems to me at some point software companies are cutting that off in favor of using that experience to get everyone else up to speed, instead of continuing to leverage the direct skillset and building teams of highly proficient engineers, which in my opinion would deliver exponential business value (by coding sophisticated systems that can do virtually anything).
• javier_e06 3y ago
  I hear you. The so-called (full stack) jobs they have you doing everything under the sun not necessarily because you are proficient at any given assignment but because you can identify risks and bad practices quickly out of experience. The worst the job the more experience developers they need. I only once had a job where we were doing things right. The customer received our solution and it was so good, the customer said: "This is great, your solution is well put-together and well documented, your API's work out-the-box as expected, and they are fully tested. We can take it from here, thanks". Layoffs started a month later.
• jakey_bakey 3y ago
  I am very glad to hear you liked it :) That's a really good point - I suppose you could rephrase to say "the work that's easiest to discuss achievements in the first round interview is rarely code" Basically, it's hard to explain, even to a technical person, how hard a code problem was, even if your solution was brilliant. But being able to do stuff that isn't code is a really easy way to showing you can 'getting shit done' I actually cover this in my follow-up post, around the difficulty in detecting strong technical proficiency in a short first-round interview.
• syndacks 3y ago
  Your job isn’t to code, it’s to solve business problems. To make more money for the company. That’s it.
  • proc0 3y ago
    If the title is software engineer, it is though. Solving business problems is not engineering. I get that at the end of the day it's about making money, but these expectations are not clear and the title ultimately reflects your expertise. I think part of the problem is the lack of standards in software engineer compared to other engineering, which have code of ethics and often require a license to practice. Those other engineering jobs are probably not doing management or solving business problems.
    • l33t233372 3y ago
      I personally know a senior mechanical engineer who’s basically doing what other posts are complaining software engineers end up doing — managing and solving business problems. I think this is more common than you’d think.
  • silveroriole 3y ago
    “Your job as a bricklayer isn’t to lay bricks. It’s to solve building problems.” If you’re actually looking for an architect or designer or salesperson or manager, hire them instead of berating developers for not doing all of those jobs at once. Also in most countries devs don’t get paid enough to solve business problems. American tech wages are the exception.
    • another2another 3y ago
      Which would actually lead to an awesome job description: "Full Stack bricklayer."
• explorer83 3y ago
  That's funny. I studied information sciences because I loved systems but didn't want to get stuck coding all day and (no offense?) was less introverted than many of my fellow tech majors (to where even my professors would be surprised when I'd take on a coding role in a project because they stereotyped me as not fitting the part.). We studied things like documenting systems, workflows, use cases, project management, networking and introductory programming courses in databases and several coding languages. In theory it sounded great. But I the job market it's actually extremely difficult to get those code-adjacent jobs when you don't have coding experience.
• asdfman123 3y ago
  Would you rather the person making the decisions about the code you write be a developer too, or not? I’d rather be managed by developers, and you only get that by promoting developers into management. You can stay an individual contributor if you want, and the pay is still very good. If it doesn’t work at your company, you can find others that will let you stay an IC.