[austincheney]

> HOW?

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

[virgilp]

I'm not saying "people can't be managed" and "one can't evaluate the performance of a programmer" - that'd be obviously false.

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.

[athenot]

Poor metrics are meaningless regardless of what you try to measure.

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

[tstrimple]

The way I've experienced it is that when a measurement becomes a metric, it ceases to be a good measurement. When people's bonus is tied to a measurement, they will find creative ways to influence that measurement which, in many cases, defeats the purpose of what it was trying to measure in the first place. It's not simply a matter of choosing the right measurements. It's also a matter of how you incentivize those measurements.

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.

[virgilp]

It's all in the details. If I get to pick who rates "how useful", this translates into a general "how well liked by my colleagues am I" (general problem with 360* feedback; I'm not saying it's useless, but it does have its limitations)

[brlewis]

If it's true that one can evaluate the performance of a programmer, what does that mean? Can it be reduced to a vector of scalar values?

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.

[virgilp]

> what does that mean? Can it be reduced to a vector of scalar values?

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)

[rezeroed]

Re initiative. I've had jobs which did not want initiative on a macro level - my manager would tell me what was wanted, I'd go away and make it happen. Those managers loved me. My current role, bullshitted into a "devops" role, I'm expected to spend my days showing initiative - building things that I think will be useful - and which never get used. I'll take the former jobs. What I have now sounds like freedom, it feels pointless and torturously demotivating. Do my managers know what they're doing? Do they have any roadmap? Can they see shortcomings in our systems? Is it mushroom management or cluelessness? I think these positive sounding words eg "initiative" are not positive - they are context dependent. "Potential" - if you need someone writing endless crud, if they have potential are they going to stick around? Do you really want/need Achilles? Are you really leading the Trojan army? Maybe you just need sticky tape, not a welding torch.

[virgilp]

You touch on two issues here: one, that there's an entire gamut and not a binary "senior/junior"... and management just LOVE to present requirements like "Can walk on liquid water; God asks him for advice on how to run the world" when you ask "what do I need to do in order to get to next level", especially in big corporations [1].

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)

[austincheney]

That is why it is so empowering to have options. I have two employers: one is among the largest and most profitable companies in the US and the other is US Army. In one of those initiative and leadership are rewarded at every level. That makes things interesting because it provides the freedom to rapidly experiment and prototype leadership to empower people the way I experiment with a side code project. In this environment the people you are leading are more eager to learn new things and be creative than my corporate coworkers that need a framework to do anything and panic at the slightest hint of originality.