Proof of concept

[donbonifacio]

The is a RFC for a CLI application that will register and process performance data points. It will be able to handle several types of data points and information about developers.

The application will also generate html files with reports about these data points. It will generate a full file with everything, and a file per developer. This developer file will have his performance evaluations, feedback and history. And will be easy to compare his evaluation with the evaluation average per area and per role, thus showing how he stacks against his peers.

The app will have work with files and rely on a git repo for storage. But should have abstractions that allow extending this in the future.

Models

Areas

There will be a config file that defines the possible areas of intervention of a developer.

[{"area": "fullstack"},
 {"area": "frontend"},
 {"area": "backend"},
 {"area": "quality"}]

Roles

There will be a config file that defines the possible roles that a developer may have.

[{"role": "Eng I"},
 {"role": "Eng II"}]

Data point definition

This will be a config file that categorizes several data points. Developers will have specific entries for each data point.

[{
  "type": "1on1",
  "metrics": [
    {"name": "learning"},
    {"name": "comfortZone"},
    {"name": "recognition"},
    {"name": "productivity"},
    {"name": "satisfaction"},
  ]
},
{
  "type": "quartelyPeerEvaluation",
  "metrics": [
     {"name": "softSkills"},
     {"name": "hardSkills"},
     ...
  ]
}]

Developer definition

{
  "id": "pedro.santos",
  "name": "Pedro Santos",
  "role": "Eng I",
  "area": "fullstack"
  ""
}

Data point definition

{
  "developer": "pedro.santos",
  "from": "someone.else",
  "timestamp": 1244,
  "type": "1on1",
  "detail": {
     "satisfaction": 123,
     ...
  }
}

API

The application will have a cli interface that will allow the import of data points.

performance360 register 1on1 pedro.santos learning=8 satisfaction=7 ...
performance360 register quartelyPeerEvaluation pedro.santos from=another.developer softSkills=8 hardSkills=7 ...

This cli is not that great if we also want to add textual feedback. Maybe having a simple app for this?

It could also have an import operation from a file. We could have some google forms templates and import from that.

Output

Running something like:

performance360 generate

Would generate all the global and per developer pages. It would generate json files with just the required data and somehow have a react web app that consumes that and shows the information. It should use a radar style component to show data points: http://www.chartjs.org/docs/latest/charts/radar.html

Also use something like boostrap.

Tech stack

Not clear yet on what should be the tech stack.

• Javascript
  • 👍 Easy to edit by anyone and get contributions
  • 👍 JSON everywhere
  • 👍 Share models between layers
  • 👍 Can ask some friends for reviews
  • 👍 Good for CLI apps
  • 👎 Javascript
• Clojure/ClojureScript
  • 👍 My favorite stack
  • 👍 edn end to end
  • 👍 re-frame
  • 👍 Can ask some friends for reviews
  • 👎 Harded to get contributions
  • 👎 Harder (?) to use JS components
  • 👎 Harder (?) to create a CLI app
• Rust
  • 👍 Could be a change to play around with rust
  • 👎 Can't share models, would still need the react app
  • 👎 Still need to learn and would need to invest on that
• Ruby
  • 👍 Will need to get back to ruby
  • 👍 Good for CLI apps
  • 👎 Can't share models, would still need the react app
  • 👎 Not so good for multiplatform

[jqmtor]

I am going to dump a few things that came to mind. The comments will be somewhat unstructured, so feel free to ask for further details.

• Maybe this is a detail, but I would consider not calling this performance360. There are metrics that don't seem to be related to performance and some of them are not only about the person (e.g. satisfaction). Feedback seems a good alternative, both because it's more neutral and because it goes both ways.

• Regarding the CLI, I have a few things to say:

  • The suggested CLI seems rather verbose. If you decide to go with it, my main suggestion would be to use the common Unix pattern (e.g. -o, --option);
  • With so many options, it is somewhat error-prone;
  • Would it make sense to build an interactive CLI instead? One that asks for the options one at a time? It seems somewhat tedious but at least you wouldn't have the limitations of the text fields you mention. I guess this would work better if all the metrics are required (otherwise people would have to skip things all the time);

• Not sure if you wanted me to look at the sample config files, but there is a metric that I think is important and that I didn't see. I've seen it somewhere being called generativity. It's basically the idea of someone spending time mentoring/unblocking/helping others, making them more productive. There are people who don't have high throughput on their own but have high generativity, making them very valuable for the group.

That's all that came to mind after a quick read. Hope it helps :)

[donbonifacio]

👍 for changing name to feedback 👍 for generativity

And yeah, the whole CLI thing is something to reconsider.