Hacker News Reader

Hacker News

Comment by sytse | Hacker News Reader

Full thread

sytse

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/

View on HN

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?

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.

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

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.

I am definitely not trolling. I'm stating an defensible opinion that happens to be unpopular here.

Arguing that an open-source project is cloning multiple pre-existing projects doesn't make the software any more innovative.

There is still enough work in the 1%, but you have to make yourself known.

> coding doesn't have much room for professional advancement

Coding is like 30% of a developer's job. And I'm being generous.

I think you're on to something. At Microsoft we don't stop at senior. It goes further to principal, partner, distinguished.

Senior is the new intermediate (a title I haven't seen in ages).

At my last several employers, people would go from associate/junior/entry/whatever directly to senior. Usually within 1-2 years from coming out of college (sometimes 2 years-ish out of coding bootcamp for particularly bright folks).

That meant basically everyone was Senior if they weren't fresh out of school. And then getting to the next step up (which had various names... Lead, Principal, Staff, level 3, whatever), is always excruciatingly hard, because it's where people start expecting more than "We didn't fire you for 2 years" and actually look at performance, and there's no title in between.

I've seen companies promote people to senior from being out of school without internships in just a few months, then need 7-10 years of experience to get to the next level. For anyone who actually cares about career tracks, that seriously kills it.

At the company I work at we recently changed the titles and I believe we're calling junior devs "associate developers" now. Seniors are still "senior." Everyone in between it just "developer" or possibly "staff developer." Seems reasonable to me. We did also add a role above senior called "principle developer" but I'm not quite sure how their responsibilities differ from senior devs.

Seniorer

Super Senior

Geriatric

Señor

Which of those do your non-seniors not have to have?

Are your ordinary developers unable "to write modular, well-tested, and maintainable code"?

(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...

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?

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.

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.

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.

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.

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?

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.

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.

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.

This exactly nails the point in the article about checklists and how you can't really create effective quantitative metrics for developers.

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?

> you're unlikely to try and game your own metrics I suppose?

You'd be surprised.

I would add (personal opinion of course):

  * the ability to communicate
  * play well with others
  * plan, schedule and estimate

Reply on news.ycombinator.com