6 ms·

At GitLab we have the following criteria to be a senior: Senior Developers are experienced developers who meet the following criteria: Are able to write modul

by sytse 10y ago

At GitLab we have the following criteria to be a senior: Senior Developers are experienced developers who meet the following criteria: Are able to write modular, well-tested, and maintainable code Know a domain really well and radiate that knowledge Begins to show architectural perspective Leads the design for medium to large projects with feedback from other engineers Leaves code in substantially better shape than before Fixes bugs/regressions quickly Monitors overall code quality/build failures Creates test plans Provides thorough and timely code feedback for peers Able to communicate clearly on technical topics Keeps issues up-to-date with progress Helps guide other merge requests to completion Helps with recruiting https://about.gitlab.com/jobs/developer/ https://about.gitlab.com/jobs/developer/

drvdevd 10y ago
So, wrt the article, by my estimate the quantifiable criteria you listed are: * Fixes bugs/regressions quickly (time spent) * Creates test plans (number of plans created) * Helps with recruiting (number of candidates interviewed) * Keeps issues up-to-date with progress (number of issues updated) * Helps guide other merge requests to completion (number of merges) * Provides thorough and timely code feedback for peers (time between commit and feedback) Just curious if you track any these metrics or if this is mostly a "qualitative" feeling of how the developer is performing?
- closeparen 10y ago
  Here is the incentive system you're advocating. >Fixes bugs/regressions quickly (time spent) Do the least possible to make it work again, don't investigate or fix the underlying confusion or low-quality subsystem that made it break. Volunteer for bug fix tasks that look easy, stay away from the ones that look hard. >Creates test plans (number of plans created) Write low-effort test plans. >Helps with recruiting (number of candidates interviewed) Give lots of interviews without really paying attention. >Helps guide other merge requests to completion (number of merges) Get your friends to split all their changes into the smallest possible merge requests so you can accept as many as possible. >Provides thorough and timely code feedback for peers (time between commit and feedback) Provide rapid but low-effort feedback. Metrics-driven management is cancer and you should run, not walk, from any organization that expresses any inkling of interest in it. You (in general, not parent specifically) are almost certainly not smart enough to create an quantitative incentive system that actually produces the behavior you want, rather than the appearance of it. Respect the difficulty of the task, and don't.
  - drvdevd 10y ago
    Makes perfect sense, actually. Well said. [edit] I will add that much of the responses to the metrics are quite cynical -- assuming people will game the metrics. Therefore, I agree.
    - dkersten 10y ago
      Some people will consciously game the metrics and some people will unconsciously game the metrics. Some people might not game them at all, but if a chunk of the team is gaming them, then its already game over.
  - beekums 10y ago
    This exactly nails the point in the article about checklists and how you can't really create effective quantitative metrics for developers.
    - drvdevd 10y ago
      I have read in the past about developers using various quantitative measures (number of commits, for example) to measure their own work. I think in that scenario it's different because the extrinsic reward is driven by intrinsic motivation -- you're unlikely to try and game your own metrics I suppose?
      - hvidgaard 10y ago
        > you're unlikely to try and game your own metrics I suppose? You'd be surprised.
bottled_poe 10y ago
I think this is a really great list. It makes it very easy to measure the outputs of a productive engineer. However, I think there is important value in humility and reflection, which this list doesn't capture. This is why I would suggest including something like: - Ability to identify gaps in own knowledge and willingness to discuss those limitations with peers. I find that traits like this tend to promote a healthy engineering culture. It's very difficult to grow such a culture, and it needs to come from the top.
mikekchar 10y ago
Every team has their own criteria and their own definitions, but I have to say that this is the level I attribute to an intermediate developer. Similar to the original article - If I leave this developer alone to do their work, they will get it done. Honestly, I want every single developer on my team to be at this level. It takes time to get there, but not an inordinate amount of time in my experience. Somewhere between 2-7 years, anyway. If someone doesn't get there in 7 years, then I see it as a pretty big problem. If you think that my estimate is not totally out of whack, that leaves all people with a 4 year degree hitting this level before they are 30 (assuming they start out in this field). If this is "senior", in what way do you expect your employees to improve in the next 35 years of their career (assuming they retire at 65)? And what title would that have?
- irq11 10y ago
  they're cloning github. it isn't rocket surgery. most of the hard technical work was done by github itself, when they built and released libgit and the other core pieces of their stack. in many ways, that's the whole problem with this conversation: coding doesn't have much room for professional advancement, because 99% of the available work can be done by inexperienced kids.
  - deleted 10y ago
    [deleted]
  - skuzye 10y ago
    I know you are trolling but for the sake of educating both you and someone not acquainted with Gitlab, they offer: * CI/CD * Docker Registry * Testing Pipeline * Self hosting option * I'm sure there's more So I don't think you are being fair here. PS: I'm not affiliated in any way with Gitlab, just an user
    - Tomis02 10y ago
      I'm not sure he's trolling. For the sake of discussion, are the features you mentioned actually "hard technical work" or is it just work that can be done by anyone with some experience in that field? I'm not sure how to define "hard technical work" but I would say that it has more to do with the rarity of people capable of solving a problem rather than the time it takes to solve it. That's not to say Gitlab's work doesn't have value, the only question being if it really falls under the "hard problems" category.
jetsnoc 10y ago
I would add (personal opinion of course): * the ability to communicate * play well with others * plan, schedule and estimate
Singletoned 10y ago
Which of those do your non-seniors not have to have? Are your ordinary developers unable "to write modular, well-tested, and maintainable code"?
- cpayne 10y ago
  (for me) it's your last two points: "well-tested", and "maintainable". It's one thing to get the feature / bug fix in the current branch, its another know what well-tested means and to be able to do well-tested without assistance. Maintainable - this one takes insight. Again, the more junior person just wants to cross the task off their list and move onto the next. Having insight into what is Maintainable (as it relates to the project / client / company) takes time. They just don't teach that stuff at Uni...
zupa-hu 10y ago
This may be an acceptable list _for a senior_ to grant a senior title to a junior - but it provides little help to juniors, because to make sense of the list, you have to first be a senior yourself. Otherwise, how can you tell what is "well" in "well-tested", etc?
- lgieron 10y ago
  That's one of the points of code reviews - as you get feedback on how you should improve tests in your commits, over time you learn what "well-tested" means.
dpritchett 10y ago
Just FYI your calculator's cost of living adjustment makes it completely uncompetitive for the Memphis, TN market. Possibly you are already getting good leads from other countries, but I wanted to point that out all the same.
- r3dey3 10y ago
  I think the calculator is out of wack for the anything but the coasts in the US. A GS-12 government worker (entry level tech position) would make more than Lead with Lots of experience in Cincinnati, OH; and a GS-13 would make more in most places.. with a GS-14 (what would be 'lead') completely blowing the scale. I think the issue is their base salary is completely off.. Especially when the 'rent index' is based in NYC. A Junior Dev w/average experience would make 87k in NYC. A comparable government GS-13 position (average experience) in NYC would make 95k.. that 8k difference compounds a lot when multiplying. Also I don't believe the rent index. Who cares where your employee lives (at least country by country) - if they want to live in the midwest, why not pay them the same as somebody who chooses to live in California, especially if you are an entirely remote company.

by sytse 10y ago

drvdevd 10y ago

So, wrt the article, by my estimate the quantifiable criteria you listed are: * Fixes bugs/regressions quickly (time spent) * Creates test plans (number of plans created) * Helps with recruiting (number of candidates interviewed) * Keeps issues up-to-date with progress (number of issues updated) * Helps guide other merge requests to completion (number of merges) * Provides thorough and timely code feedback for peers (time between commit and feedback) Just curious if you track any these metrics or if this is mostly a "qualitative" feeling of how the developer is performing?

closeparen 10y ago
Here is the incentive system you're advocating. >Fixes bugs/regressions quickly (time spent) Do the least possible to make it work again, don't investigate or fix the underlying confusion or low-quality subsystem that made it break. Volunteer for bug fix tasks that look easy, stay away from the ones that look hard. >Creates test plans (number of plans created) Write low-effort test plans. >Helps with recruiting (number of candidates interviewed) Give lots of interviews without really paying attention. >Helps guide other merge requests to completion (number of merges) Get your friends to split all their changes into the smallest possible merge requests so you can accept as many as possible. >Provides thorough and timely code feedback for peers (time between commit and feedback) Provide rapid but low-effort feedback. Metrics-driven management is cancer and you should run, not walk, from any organization that expresses any inkling of interest in it. You (in general, not parent specifically) are almost certainly not smart enough to create an quantitative incentive system that actually produces the behavior you want, rather than the appearance of it. Respect the difficulty of the task, and don't.
- drvdevd 10y ago
  Makes perfect sense, actually. Well said. [edit] I will add that much of the responses to the metrics are quite cynical -- assuming people will game the metrics. Therefore, I agree.
  - dkersten 10y ago
    Some people will consciously game the metrics and some people will unconsciously game the metrics. Some people might not game them at all, but if a chunk of the team is gaming them, then its already game over.
- beekums 10y ago
  This exactly nails the point in the article about checklists and how you can't really create effective quantitative metrics for developers.
  - drvdevd 10y ago
    I have read in the past about developers using various quantitative measures (number of commits, for example) to measure their own work. I think in that scenario it's different because the extrinsic reward is driven by intrinsic motivation -- you're unlikely to try and game your own metrics I suppose?
    - hvidgaard 10y ago
      > you're unlikely to try and game your own metrics I suppose? You'd be surprised.

bottled_poe 10y ago

I think this is a really great list. It makes it very easy to measure the outputs of a productive engineer. However, I think there is important value in humility and reflection, which this list doesn't capture. This is why I would suggest including something like: - Ability to identify gaps in own knowledge and willingness to discuss those limitations with peers. I find that traits like this tend to promote a healthy engineering culture. It's very difficult to grow such a culture, and it needs to come from the top.

mikekchar 10y ago

Every team has their own criteria and their own definitions, but I have to say that this is the level I attribute to an intermediate developer. Similar to the original article - If I leave this developer alone to do their work, they will get it done. Honestly, I want every single developer on my team to be at this level. It takes time to get there, but not an inordinate amount of time in my experience. Somewhere between 2-7 years, anyway. If someone doesn't get there in 7 years, then I see it as a pretty big problem. If you think that my estimate is not totally out of whack, that leaves all people with a 4 year degree hitting this level before they are 30 (assuming they start out in this field). If this is "senior", in what way do you expect your employees to improve in the next 35 years of their career (assuming they retire at 65)? And what title would that have?

irq11 10y ago
they're cloning github. it isn't rocket surgery. most of the hard technical work was done by github itself, when they built and released libgit and the other core pieces of their stack. in many ways, that's the whole problem with this conversation: coding doesn't have much room for professional advancement, because 99% of the available work can be done by inexperienced kids.
- deleted 10y ago
  [deleted]
- skuzye 10y ago
  I know you are trolling but for the sake of educating both you and someone not acquainted with Gitlab, they offer: * CI/CD * Docker Registry * Testing Pipeline * Self hosting option * I'm sure there's more So I don't think you are being fair here. PS: I'm not affiliated in any way with Gitlab, just an user
  - Tomis02 10y ago
    I'm not sure he's trolling. For the sake of discussion, are the features you mentioned actually "hard technical work" or is it just work that can be done by anyone with some experience in that field? I'm not sure how to define "hard technical work" but I would say that it has more to do with the rarity of people capable of solving a problem rather than the time it takes to solve it. That's not to say Gitlab's work doesn't have value, the only question being if it really falls under the "hard problems" category.

jetsnoc 10y ago

I would add (personal opinion of course): * the ability to communicate * play well with others * plan, schedule and estimate

Singletoned 10y ago

Which of those do your non-seniors not have to have? Are your ordinary developers unable "to write modular, well-tested, and maintainable code"?

cpayne 10y ago
(for me) it's your last two points: "well-tested", and "maintainable". It's one thing to get the feature / bug fix in the current branch, its another know what well-tested means and to be able to do well-tested without assistance. Maintainable - this one takes insight. Again, the more junior person just wants to cross the task off their list and move onto the next. Having insight into what is Maintainable (as it relates to the project / client / company) takes time. They just don't teach that stuff at Uni...

zupa-hu 10y ago

This may be an acceptable list _for a senior_ to grant a senior title to a junior - but it provides little help to juniors, because to make sense of the list, you have to first be a senior yourself. Otherwise, how can you tell what is "well" in "well-tested", etc?

lgieron 10y ago
That's one of the points of code reviews - as you get feedback on how you should improve tests in your commits, over time you learn what "well-tested" means.

dpritchett 10y ago

Just FYI your calculator's cost of living adjustment makes it completely uncompetitive for the Memphis, TN market. Possibly you are already getting good leads from other countries, but I wanted to point that out all the same.

r3dey3 10y ago
I think the calculator is out of wack for the anything but the coasts in the US. A GS-12 government worker (entry level tech position) would make more than Lead with Lots of experience in Cincinnati, OH; and a GS-13 would make more in most places.. with a GS-14 (what would be 'lead') completely blowing the scale. I think the issue is their base salary is completely off.. Especially when the 'rent index' is based in NYC. A Junior Dev w/average experience would make 87k in NYC. A comparable government GS-13 position (average experience) in NYC would make 95k.. that 8k difference compounds a lot when multiplying. Also I don't believe the rent index. Who cares where your employee lives (at least country by country) - if they want to live in the midwest, why not pay them the same as somebody who chooses to live in California, especially if you are an entirely remote company.