Ok, we should judge people by what they can and do contribute to the team. The billion-dollar question is, HOW? Humans are extremely skilled optimizers - give them an objective metric and they'll game it for maximum benefit; make it subjective and it can be better or worse - but in either case, you'll no longer have any agreement on "what they contribute to the team".
* Documentation - Can they write?
* Potential - Can they provide original solutions to problems? Do they need hand holding?
* Initiative - Do they need a signal from a starting gun or are they self-entertained with word products for the team?
These are all identifiable maxims.
What I _am_ saying is that it's an art not a science - very hard to teach, impossible to scale.
Take your example with "Documentation" - if you measure anything objective (words written, number of functions/features that have associated documentation) and tie it with the performance evaluation, those metrics will soon become meaningless.
In the example of documentation a better metric might be a composite value of
(i) how many wiki articles a developer has written, weighed 0.33 and
(ii) how useful on a numerical scale his/her peers rate the documentation produced, weighed 0.67.
This is just an example but it's a composite of perceptual and objective, with the perceptual being a lot more important (and to prevent gaming the system by writting lots of useless articles).
When I worked at Microsoft one of the teams I was adjacent to had a metric on number of new apps in the Windows Phone app store. So the teams went out and got a bunch of college students to build shitty apps in bootcamp style working groups. Suddenly the number of apps isn't good enough, so they added review metrics. Now those teams add a "let's all rate each other's apps" portion to the bootcamp taking you even further away from the results you're trying to obtain.
I hate doing performance reviews, and I especially didn't like when at a former employer I was asked to stack rank programmers. I feel like it's a task that's so difficult to get right, I can't even think of a wrong way to do it that's useful.
No, it certainly doesn't mean that "your performance was [7.23541 8.1241 34.412515 .52632 995.154]". It means "you did good/ you did very good/ you need improvement", with some details like "<these things> you really handled well and I appreciate it; maybe you can work a bit on <this area> though". I definitely agree one shouldn't stack-rank people - especially in a good team (it's entirely possible, desirable even, that everybody did a great job)
The second is that different types of people prefer different styles of working and sometimes forget there is another side (multiple "other sides", really). A team needs to be a mix of capabilities and personalities to be successful - a team of 100 identical individuals would likely fail, even if all them are Peter Norvig). So, you need people that are "senior" in the sense that "knows the business well enough to provide different perspectives" (and for those "shows initiative" is critical) but you also need specialists where "senior" means "knows technology X really really well". Say, a DBA - can keep your database up, can write efficient queries to retrieve information that you want; but doesn't know sh*t about what information would be interesting to retrieve. Or whether it's a good idea to keep some information X in the database, considering the various business, legal, social, cost perspectives.
> Do my managers know what they're doing?
Here's the thing: I believe nobody _really_ does. Sure, some know more than others, but in absolute terms, we're all basically guessing. That's why people insist on engineers that "show initiative" - not because they're always right, but in an environment where we don't _really_ know what we're doing, people yelling different perspectives are valuable.
However, as mentioned above - not all senior engineers want or are inclined to show this kind of initiative; and it's unfair to penalize those kinds of engineers, because we _need_ the different types of personalities.
[1] FWIW I believe the reality is , always, that you need to (A) work on a successful project; and (B) be generally liked by your colleagues and maybe managers. For very senior titles, also (C) have a large network of connections within the company - i.e. work on many things, or on one thing but a thing that is used by many teams/ really popular)
Objective metrics are good if you think you can measure accurately for all individuals at the macro level. You may not need that (I mean, really _need_ it for your business to function, unless you're in the metric-tracking business).
If your teams have distinct and articulate enough outputs, you can retribute each team according to its specific outputs. At the macro level, you don't need to have more details (but you still may ask).
Let the team manage its own distribution of the retribution - and so on (so you do need trained managers to do it appropriately at each level).
In thios group we have a programmer in his early 40s, who has been programming for years, that I would still consider a "junior" programmer. He can usually perform a task but needs more guidance and checking than the other members if the team, most of which have been there time.
On the other side we also had a developer work there a few years back that was in his late 50s and wrote some of the worse looking code I've ever seen. Fortunatly he didn't last long and none of his code is running in production.
The 50-something who had been in the same role 37 years, who was laid off and when hired into a new company, just couldn't adapt. The 40-something who's fine to do maintenance and the odd enhancement, but you wouldn't trust to do a major refactor or a large chunk of green-field.
Some people just aren't as able, find themselves a comfort zone and stick to it.
So even experience doesn't necessarily mean experience :)
(This isn't to say such people aren't useful, that's a different measure.)
It's even worse in front-end, because that means their skills are that of a 2 year junior 10 years ago, they don't have any of the skills with new frameworks and techniques. If you want sloppy bootstrap laden html/css and jQuery, they're your person though.
Unfortunately, there's no one size fits all worksheet for those soft skills that HR can hand out to interviewers, so everyone gets lazy and falls back to the whiteboard BS.
This isn't what I'm talking about - I'm talking domain specific skill. If you're a frontend developer for instance, you should understand the new language features of JavaScript that came out in 2015-2016 and be able to use them. You should know how to use flexbox for CSS instead of floats for layout (IMO)
If you're a senior developer still writing code every day, you have to keep up with that stuff. You're ultimately responsible for the codebase in a way that junior/mid devs are not and if you don't understand large aspects of how it works you can't be effective.
It doesn't help that people who stagnate like this usually weren't very good at/engaged with their jobs to begin with. They're usually senior in name only, where their managers know not to actually assign them stuff that matters.
Do new languages, new language features, new frameworks, new methodologies necessarily add business value? Or are they sometimes just being used because they are new and shiny? Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill. One distinguishing attribute I'd expect from a "senior" developer is the ability to quickly evaluate new technologies, choose and focus on what actually provides business value and have the discipline to ignore the rest. It is possible to be a top performing, highly productive developer today by very effectively using 10 year old technologies.
Sometimes they do, sometimes they don't. But the tech stack will eventually come to include these new things whether you like it or not. And even if somehow you're able to stop that from happening, eventually it will become very difficult to hire junior developers with experience in old frameworks and eventually those frameworks stop getting supported and community contributions since so many other shops drop it.
The two things I listed specifically are actual fundamental changes to CSS and JavaScript, not fly by night frameworks and they both do add a lot of value.
>Requiring people to learn new tools simply because they are new (to keep up, in your words) just puts everyone on a treadmill.
I actually do sympathize with this way of thinking, and I used to agree with it. But I've come to understand how misguided it really is. Every well paying knowledge worker profession requires updating your skills from time to time. Doctors have to learn new guidelines for treatment and different ways to do surgeries/procedures. Lawyers have to brush up on developments in case law etc...
Programming already has an extreme advantage over a lot of these professions. There's no licensing board, you don't even need a degree if you can pass the interview. It's silly to think that we should also be immune to honing our craft and changing with the times.
If you're a software engineer, you should have the expectation that you're going to need to do a little bit of career development every year. I don't mean spending 10+ hours a week on it, but to use the examples above... I realized in like 2016 that I didn't know Flexbox and that was pretty much the new standard for how layout was going to happen in CSS. So I made myself learn it. And not only does that update my skills, Flexbox is actually way better to lay elements out on a page with than the old way. It's made building html/css views out much quicker.
I've seen nigh unmaintainable web apps that were entirely laid out in really overwrought nested flexboxes, when using utterly basic HTML elements like <p> and <h3> and <dl> with a bit of CSS would have rendered faster, been developed faster, worked in older browsers, and worked better with accessibility tech.
So really, flexbox is just another new old thing, and what matters is the concept of constraint-based layout as one tool out of many. If it's the first new thing you encounter in your career, it's worth learning it because it's there, but remember that it's just another spoke on an ever-turning wheel.
I've noticed this is changing (spearheaded by FAANG & other top tech companies it seems) - there are frontend specific tracks that test more JavaScript knowledge than leetcode puzzles.
But as usual, if there is a cutting edge, there are many more laggards, and I'd say many companies are still doing leetcode DS&A for frontend too.
It's really impossible to generalize about most aspects of this career in my opinion. There are no hard rules about anything, even hiring.
I think about this in relation to the "skill gap" in programming a lot. There are people who work in very senior positions in software development who couldn't do a LeetCode easy or a FizzBuzz. They don't read articles about how to get better at programming or about concepts like DRY etc... but maybe they do the very specific thing their employer wants well enough, that combined with their long tenure and relationships with other people they are pretty much lifers.
That's why I laugh when I see articles on Hacker News articles where it says if you don't do X Y or Z you're not a "real" programmer. Meanwhile a huge swath of people employed as programmers haven't even heard of a lot of this stuff, much less actually used it.
Half my team is in London (big bank), as is my manager, and I know they leetcode candidates there too - and we're not even a tech company or elite financial firm, just a boring big conservative bank.
If you're looking for a job in this day and age, I think it's safer to assume you're going to get leetcoded and be prepared. Rather than try to find the rarer and rarer company that doesn't leetcode you.
Can you give me an example of a task that I couldn't have done with ten year old tech?
Will it automatically be better because I am using this years chosen framework (or will it be more likely that there are unforeseen problems because of not using a mature technology).
If you're old, then the spectrum of possible experience is much broader. You could range from being totally inexperienced to being extremely experienced.
Also, as I get older, I realize that talent plays a significant part (which is independent of age). But there is a huge problem that almost all companies don't know how to identify technical talent; they focus on the wrong attributes like ability to perform under pressure and ability to recall details. Companies should be focusing on a candidate's ability to synthesize information, to rank problems based on their importance and to communicate simply and clearly; that is the real valuable talent.
So, from my non-tech perspective, that's just every single job at every single employer. Any position I've had that has been in charge of hiring people - I am acutely aware that I can teach the position. I can teach the technical aspects and detail knowledge of how to do a job. What I can't teach is the ability to prioritize, critically think, and communicate appropriately. Those are real talents.
I guess what I'm saying is - tech companies are garbage at evaluating for those things, because (I would argue) all/nearly all companies are garbage at evaluating for those things. It doesn't matter if it's a tech company, garbage company, or insurance company - they're all (again, my experience) equally garbage at finding those skills in people through their standard interview processes.
If you figure out how to implement a standard interview process to evaluate for the three things you list, you will be the world's first trillionaire.
For example, I work with a firmware developer in his 50’s, and he is so efficient it is scary. He’s basically seen it all by now, and he has deeply ingrained work habits which let him solve problems extremely quickly.
That’s not to say that every developer with X years of experience will automatically be great in that way, but if you can find someone who has years of experience producing exactly the type of work you need, this should be viewed as a huge advantage.
It’s like if you are looking to hire a carpenter to built a piece of custom furniture: you can and should consider general qualities like strength, manual dexterity and attention to detail. But if you can find someone with years of muscle memory building exactly that type of furniture, they are almost guaranteed to get the best result.
That said, want to call out that experience in other fields can sometimes be tremendously valuable! (... but isn't guaranteed to be)
Not the same year 10 times but 10 discrete, non-overlapping years.
Ideally I preferred learning the technology for a few years then steeping back and reaping the benefits and do stuff with it. But, there is a fear that not keeping up leads to obsolescence on the job market so we're in this constant cycle of learning new things with diminishing returns
The main skill for senior/staff swe is not in knowing or not knowing some technology, but rather
1. Picking things up quickly
2. Understanding/recognizing generalizable patterns and best practices in any tech.
Almost no job requires some extreme expert level knowledge of language/framework minutiae (obviously you do need some experience in particular tech). Almost every non-greenfield job has a ton of custom tech that has to be learned. Almost every green-field job needs someone with immense breadth.
Having been exposed to very many things people get to naturally see recurring patterns/best practices. When they see a new tech they are able to understand why choices were made. When new tech needs to be made they can draw from broad experience in what others did best. I really think this is most of the eng value of staff swe.
Agreed
> They should be judged by their skills, the same way the young ones are being judged.
Disagree, but this is my subjective opinion. Old people in general are not able to keep up with young people for many reasons. My personal stance is we shouldn't compare them as equals, but rather try to get the most out of everyone. The baseline for judging someone (to be hired or to stay in a job) should depend on the effort they put in. Actual performance should be taken into account when deciding on promotions and bonuses. This would create an environment safe for old people to keep their jobs until they retire, but also fair to people of any age to get higher salaries and roles based on their skills.
However, my solution does not judge people differently based on age. It judges everyone in a way that allows old people to fairly compete with young people on the basis of effort put in rather than pure skills/performance output.
Blindly saying 'ok you are technically better, but your also old and I want young people' is what you are arguing.
That is bad discrimination.
Then they retire. Someone else takes over, and they do exactly the same work in $small_percentage of the time.
So no - effort is not a good metric. Why would you be paying someone who can't do the job - or at least can't do the job well, with enough spare capacity to deal with more complex work requirements?
Of course this is a parable, but I suspect a lot of people have seen something similar happen at work at least once.
Fairly compete in...making an effort? Would you like to get operated on by a surgeon that lacks the skill necessary to perform his job but tries damn hard? Would you want to go to a concert where the string section has been working real hard on learning the material but can't read sheet music and are tone deaf? Would you want to ride the bus where the driver has been practicing all his life but can't quite drive well enough to meet a reasonable standard based on skill? Do you want to follow a basketball tournament where the winner is determined by their effort rather than their score? Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
My most favorable take on your idea is that you simply can't have thought it through.
Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing. It's this attitude that leads to age discrimination in the first place, not that old people somehow can't produce quality work.
Instead of fucking up the workplace by introducing perverse incentives, consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Breaking news, this is already happening. Actually, pure performance-based judgement drives incapable people to hide their inability to perform the task at hand leading to bad results (instead of facing the reality in a safe environment that would help them get better at what they do).
> Why should anyone respect a workplace that is effectively a daycare for try-hards? How can such a workplace result in a good product or service?
This sentence assumes the majority of workers are incapable try-hards which is plain false. A few less-skilled try-hards aren't going to ruin any service. Again, this is already the case in the world we live in.
> Frankly, the whole premise that old people need to be "allowed to compete fairly" by arbitrarily judging workers on some other merit than the quality of their work strikes me as incredibly patronizing.
I clearly stated two layers of judgement. A baseline for effort and a second layer for career progression based on lerformance, both age-agnostic. Never proposed a system discriminating against age. Get over it please.
> consider socialized efforts that can maintain a sense of security for people that for one reason or another can't perform the work available to them to a reasonable standard. Pensions, unemployment insurance, disability insurance...that kind of thing.
Ok so I proposed a system that would ensure someone has a job as long as they are not a lazy-a$$ (but probably wouldn't be able to climb up the career ladder if they don't have the skills), always age-agnostic, but that is somehow not a socialized effort to provide security? Ok.
It seems to me maybe you've got the hero mentality. That sacrifice == hours spent grinding == commitment to the job. "Effort" to you is a measurement of love.
That totally described me in my 20's and 30's. One day, after acquiring the necessary skills, I woke up and learned that it didn't make sense to grind like that anymore. Also, long hours is bad for the mental health.
I switched to "work smarter, not harder" mode and learned about TDD and Agile. I got better at my craft and earned respect from my peers for encouraging them to get better too.
Finally, I had a really eye-opening experience with an older developer a few years ago. He was a contractor and owned a gym. He always took off at 3pm to go train his folks and work his other business without asking/telling anyone. He was gruff and a little bit intimidating physically. He even had terrible typing skills: he typed with two fingers like a kid! Not sure if that was a dexterity handicap or if he just never learned to type, probably the former, but it still pissed me off because he was SOOO SLOW!
It surprised me a bit when he rolled off that he lasted his whole contract and didn't wash out sooner. It surprised me at the time he had such deep networks in the company: VP's knew him and worked with him years earlier and they had lively random conversations. It surprises me now that his contributions to the codebase have endured - he just got a lot done in less lines of code. I think fondly now at the conversations we had, not just on coding, but on parenting, politics, physical health and strength training, military service, and just ... diverse, weird thoughts from my parent's generation.
Think of yourself and your beloved company as The Borg. Your job is to incorporate the technical distinctiveness of aliens into your collective. If people you run across are turds, and you have a culture of hard-charging success, they'll wash out pretty quickly. Just let go of effort and efficiency as metrics - beancounters can concern themselves with that. Focus on winning over the long term.
I have learned that putting in more hours does not result in the benefits one would hope for very early on.
Thanks for your comment though, it made me understand why everyone is super freaking pissed about my comment. Have I understood that earlier I would have edited it to avoid all this mess