10 ms·

I also had the pleasure of arguing for a team members promotion once. The domain our team of 5 worked in was pretty challenging (heavy algorithmic stuff). I spe

• lostcolony 10y ago
  So you're basically in agreement with the post - "To me, what makes a senior developer is when you can trust them to get things done without you. "
  • AtheistOfFail 10y ago
    That's the general industry definition. Here's the ones I've learned (I have a CTO title, but I don't believe it is well issued) Junior Developer isn't an insult, it's just someone who may need about 1/3 of your time to showing them around. A "Developer" without Junior or Senior should require 1 day out of 14 for advice/assistance. A Senior Developer should only require assistance when the building is on fire.
    • aaronblohowiak 10y ago
      A lead developer starts the fire by gathering kindling. A principle engineer invents new kinds of fire.
      • paulddraper 10y ago
        Product manager calls for more wood.
        • bmelton 10y ago
          Sales figures out how to pitch the fire as a feature.
          • TeMPOraL 10y ago
            Lawyers provide a solid defense from the locals who for some reason don't enjoy being neighbours of the new wood-burning power plant.
      • angstrom 10y ago
        And someone in AWS gets the 2AM pager wake up call. Kindle. Fire. I'll see myself out.
      • pjc50 10y ago
        "Do people want fire that can be fitted nasally?" (Douglas Adams, https://books.google.co.uk/books?id=YKHJ6WQKD3YC&pg=PT142&lpg=PT142&dq=fire+that+can+be+fitted+nasally&source=bl&ots=eKMzO2ueFF&sig=kaJH1INQ1V4DO2-0fNsHoURTc6Y&hl=en&sa=X&ved=0ahUKEwi5kqGwxO7QAhVkK8AKHX7EB2AQ6AEIRDAG#v=onepage&q=fire%20that%20can%20be%20fitted%20nasally&f=false https://books.google.co.uk/books?id=YKHJ6WQKD3YC&pg=PT142&lp... )
    • porpoisemonkey 10y ago
      I can see where you're coming from but personally I don't like the idea of grading the seniority scale equivalent to how much help you need/ask for. Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process. In my mind the difference between a junior developer and a senior developer is the ability to recognize tasks/issues and accurately prioritize them in alignment with organizational objectives. In particular I've found that when left to their own devices junior engineers tend to focus on irrelevant items and metrics such as lines of code or genericness for genericness' sake where senior engineers target important bugfixes and features that bring highest benefit to the company and customers. There are parallels with this statement and the premise of the parent comment but I think the latter draws with too broad of a brush.
      • spdionis 10y ago
        I think grandparent meant specifically taking the CTO's time, not a peer's time.
      • msandford 10y ago
        > Requests for advice and assistance are not good indicators of intellectual weakness - the expert marshalling of additional resources in resolving an issue is a good thing when utilized appropriately. An example would be an engineer toiling in silence through a difficult problem on their own even though the organization has a competent expert that can expedite the process. Intellectual strength isn't the same as senior developer. There might be correlation but it's probably not super strong. I agree that someone not asking for help is definitely junior. But I might also argue that someone who does need to ask for help probably isn't as senior as you seem to think they are.
        • jiaweihli 10y ago
          In an ideal world, this is probably the case. Unfortunately, there are a lot of non-ideal codebases in the world. Even the worst developer can eventually develop fluency in a poorly-designed codebase and seem much more competent than they actually are, compared to a new hire.
    • deleted 10y ago
      [deleted]
    • TurboHaskal 10y ago
      So basically there is no way to ever become a senior developer if you work for a control freak micromanager.
      • nine_k 10y ago
        Leaving and being hired as a senior may be the easiest way out.
      • AtheistOfFail 10y ago
        Yes, Dice.com / Glassdoor.com / Linkedin.com
    • mcv 10y ago
      I disagree. I think everybody needs assistance every now and then, and it's important that you will ask for assistance when you need it. I strongly prefer a programmer who asks for assistance over one who will get stuck on his own for days or even weeks. But a senior will definitely ask when he needs help, and won't wait until someone comes to him. And even without the right help, he'll still figure out some way to move forward. Usually, he can figure out his own problems while also offering assistance or guidance to others.
      • efaref 10y ago
        I can't quite put my finger exactly on what it is, but it feels like there's a difference between the kind of assistance that a senior developer asks for and the kind that a junior developer requires. I mgiht guess that a senior developer asks for assistance when it will save them time - they could work it out, but it'll be more efficient for everyone involved if they get some assistance - whereas a junior developer would be lost without it.
        • infinite8s 10y ago
          I think the difference is that a senior developer will ask for help when it is a multiplier on productivity, whereas a junior will ask/need help when it is a linear gain in productivity (ie the difference is knowing how useful that help will be).
        • mcv 10y ago
          To some extent, absolutely. A junior is more likely to not know where to start, or to get stuck on a wrong path. A senior is more likely to need someone to bounce architectural ideas off, or some pointers on how to get started with some new technology. But ultimately, anyone can get stuck hunting for a typo causing an inexplicable problem. Sometimes you just need someone to explain your problem to, just to help your own head to solve it.
    • lostboys67 10y ago
      By that definition I should have been a senior dev when I was 22 in my first job
      • lostcolony 10y ago
        Well, there's also a difference between "able to solve a problem" and "able to solve a problem correctly, in ways that won't cause future pain". The latter one is the only one that can be trusted to work on a problem themselves. That said, it's totally possible you were there, yes. The pacing of promotions vs the abilities needed for them are not always correlated appropriately.
      • user5994461 10y ago
        Some people are senior when they are 22. Some people are senior when they are 44. Some people are never senior. Age is not a good predictor.
    • GrinningFool 10y ago
      That metric strongly discourages asking questions - which is a critical part of a Senior Engineer's job. When someone is at the level of SE, they have proven they have skills beyond slinging well-formed code - that's entry stakes for second-tier. They demonstrate a wider understanding of how their work fits into the overall product development, an understanding of customer perspective, and many other attributes. Most if not all of these derive from knowing the right questions to ask, the right people to ask them of, and the right time to do so. The biggest differentiator is that the Senior developer should know when she needs to ask questions to proceed.
    • user5994461 10y ago
      > A Senior Developer should only require assistance when the building is on fire. Senior developers require assistance all the time. Once problems are complex enough there isn't much that can be done as a solo ninja.
• Yhippa 10y ago
  What would you have done if he didn't get the raise? This is a great story by the way. For me this is a good way to keep your staff loyal while signaling to others that they aren't performing up to snuff while not making it completely awkward.
  • garou 10y ago
    It looks like: we are dependent on this guy, we need to raise him to keep him with us. I can't see a company rising someone just because he "deserve" it, the company don't wanna spend more money if not necessary... IMHO.
• thebent 10y ago
  "Every measure of a good developer is qualitative. That makes them all subjective." ^ This post scratches the surface on a timely and relevant question many teams face, but the author seems to throw hands up and say everything is subjective. Our work suggests otherwise: https://blog.gitprime.com/check-in-frequency-and-codebase-impact-the-surprising-correlation/ https://blog.gitprime.com/check-in-frequency-and-codebase-im...
  • Eiriksmal 10y ago
    Engineer happily using GitPrime here. After sitting in on a Skype session we had with your team once upon a time, I took your earlier (pre-Impact) observations on the correlation between commit volume and overall performance to heart and consciously focused on chunking my work more. It will come as no surprise to you that this strategy's helped me stay consistently in the upper right of the 2x2 chart. Thanks, Ben!
    • thebent 10y ago
      Ah nice, @Eiriksmal — 'once upon a time…' and 'pre-impact', sounds like this was a while ago now :) Encouraging to hear that this has been helpful for you.
    • Xcelerate 10y ago
      > I took your earlier observations on the correlation between commit volume and overall performance What does this mean? The best developers tend to have the most commits?
      • jiaweihli 10y ago
        I can believe that there's _some_ correlation. From what I've seen, a high frequency of commits means either: - Has very little understanding and churns out code one day and removes it the next. - Thinks a lot about their code, and divides them into digestible, independent chunks.
        • 10y ago
• IncRnd 10y ago
  That's really a great point. The title should relate to what the developer can effect for the organization, not the length of employment or other like factors.
• danvasquez29 10y ago
  I think that that criteria heavily leans on an assumption of the quality of the other engineers on the team though. If there is a team composed of 4 engineers who are in the bottom 10% of performers in the company, it won't be hard for them to see a very mediocre engineer as a "senior" because that person does so much more than they can; yet to the other 89% of the company, it's absurd that that person would be considered a senior. Granted, many would say it's equally absurd to have so many members of the bottom of your engineering talent on one team, but I've seen it happen over and over again in real life.
  • Bartweiss 10y ago
    "Carrying the team" certainly seems risky, and calls to mind the endless problems of Microsoft's stack ranking (especially the fights to get on a team with losers to "fund your raise"). I do think that the self-directed criterion is an excellent one, though. With that standard, you could promote an entire team if they're doing good work, or have non-senior engineers stretching up into your top decile. That makes the 'senior' title a clear assertion of "can handle these tasks without substantial oversight".
  • bananarepdev 10y ago
    But normalizing a developer's performance across an entire organization is no easy feat. If the subject is performing well enough under the role and team he was placed, then he probably deserves a promotion.
  • marktangotango 10y ago
    I think it's a mistake to think that developer ability is static, "quality" isn't a constant thing, by any means. Certainly we're supposed to keep learning and progressing. But there are plateaus. For example, I don't think myself or the person I championed for the raise/promotion were exceptional, it was simply a situation where what we were doing really "clicked" with both of us. Later on, I had a member assigned to the team. They were going to fire this person, but asked me if he could have a chance on our team. I said sure. Turned out that this person needed a bit more guidance than they had received before, and when they got it, really began to shine. This person went from almost being fired to being a really valuable contributor on our team. Myself, I left that company long ago, looking back I think it was a high point of my career. Never before or since have I had that level engagement with the domain or company.
• user5994461 10y ago
  > I went to my boss and said, X is carrying my team, he does more than any two other developers combined. He needs a raise, I can't lose him! And he got it. How much was the raise? Because giving 10% is easy. But when it comes to giving 50-100% there is suddenly zero support from the organization.
  • ryanbrunner 10y ago
    50-100% is always going to be extremely organizationally difficult, and it doesn't come down to evil managers being penny pinchers. - Even if the individual in question had 2x the productivity of the other developers on the team, doubling their salary relative to other employees trades that one developers risk of leaving with the entire rest of the teams. - If you have enough divergence in compensation that two people at the same level of the hierarchy doing the same role (i.e. an intermediate vs. a senior) can have pay differ by 2x or more, you should be absolutely sure there's no bias to your decisions, whether it's along an identifiable group, or just plain ol' favouritism. - Frankly, I haven't seen much need for such lavish differentials in salary in the first place. Most people are only motivated by salary to a point. Star performers want to be recognized, and not just with a pat on the back, but give people a good place to work and pay well in general, and you shouldn't need to worry about crazy raises like that.
    • user5994461 10y ago
      Lemme explain how it works. The first thing you need to be in a > 50% raise situation is an employee that was acquired for incredibly cheap. (Epic combination: one of this first jobs + don't know the market + just came from abroad). [That makes your first two points moot because that guy is the one making significantly less money and he's not identified at the right level]. The second thing is that he's actually good and he's been working for 1 year here, doing valuable stuff. He's gained a lot of value in the meantime and he can totally leverage the job he's done to sell himself in an interview. Let's give some numbers. The dude started at $80k base with little advantage. Over time, maybe he's gone up to $90k and you got an incredible healthcare plan. It's fine from your point of view. From the point of view of your competitors. Your guy has been vetted by your company. He's proven and he may even have rare skills that are now easily noticeable. They will offer "market rate" and fight each other mercilessly. The package will be around $150k base (which is nothing extraordinary for that position) + $40k in yearly bonus/stock that he didn't have at your company + various other advantages + they'll also pay $50k in recruiter fees cuz he went through a recruiter. Now, you've got a guy that is paid $90 at your place that other companies are willing to pay upfront $240k to acquire. Hope they'll never find out about your gold ;)
• ____nope 10y ago
  I wish this happened more often in companies. Unfortunately I usually see the following happen. A mid-level developer, let's call him Dave, becomes a critical employee after a few years with the company. He silently become "senior" without anyone really asking him to. Other developers notice this and often come to him for help. Management, however, doesn't notice, because nobody in management is exposed to Dave's actual contributions to the team. All they see are completion metrics – story points, etc. – and a project moving forward. Dave is too humble to point out that he did 80% of the work, and he doesn't have regular meetings with his supervisor anyway, so the subject would never come up. After a few years with the company, Dave gets bored and finds another job. The company now has to pay recruiting costs and the ramp-up time that comes with a new person on the team. Dave, meanwhile, gets what he wanted – a promotion, and a higher pay check. The company could have saved money by giving Dave a 20% raise and a promotion (even a nominal promotion, to make him feel valued) but the management structure wasn't there. This is how it normally goes, and this is exactly why there is such a short length of tenure in the tech industry compared to other industries.