by jonaldomo on 7/26/19, 2:16 PM with 108 comments
by weliketocode on 7/26/19, 3:35 PM
what?
Please don't listen to this. Give junior engineers bugs right away. It forces them to set up their environment for debugging and begin to understand the flow of the project.
Even if he/she needs to be guided to the solution, this is a GREAT litmus test for the standards of your documentation, and ease of environment setup.
by guitarbill on 7/26/19, 3:41 PM
Ugh, not this again. Obviously don't hire people who aren't good at their job. But most improvements come from investing in your team.
> are they putting their code up for review [...]
Missed one: Are their code reviews/pull requests high quality? I.e. do they go out of their way to document how they tested it? Reproduction steps? Do they invest time in making code reviews as easy to review for other people as possible? Or does their code reviews always take multiple rounds of review due to sloppiness?
by perlgeek on 7/26/19, 4:12 PM
That really depends on what you want the code review to achieve.
Catch typos? Yes, a new engineer can do that.
Check if code fits into the existing architecture, adheres to the invariants of the code base, uses base libraries idiomatically etc? I don't think a new engineer can contribute that from the start.
> Creating metrics through issue trackers and time sheets
Which metrics? It's far too easy to create metrics that are easy to measure, rather than metrics which actually increase the business when optimized for (and developers will optimize for / game a metric when it's used to assess their performance).
by Dayshine on 7/26/19, 3:32 PM
It's a completely different skillset, and you're probably only measuring how eager people are to have breadth of knowledge or how familiar they are with your specific system.
Similarly, the explanation for "Debugging and troubleshooting complicated issues" is a bit odd. Why is knowing where the log files are, and knowing how to do complicated test setups for your specific environment a performance measure. Again, that's not really measuring skill but familiarity.
The other two measures are just "Do they complete tasks" and "Do they follow code review guidelines", neither of which are very good measures beyond pass/fail.
The conclusion is: > Once a set of skill areas for a role is landed and agreed upon you will want to make sure your team knows in advance what they are being measured on
So, to do well in your business, I need to pick easy tasks, snipe code reviews, make pointless CI tasks and spend all my time learning the build/test processes not actually developing the product? :)
by januzis on 7/26/19, 4:34 PM
As a technical lead, I feel that I'm able to judge the ability of individual team members, but I'm having a hard time objectively judging productivity. Simple count of PRs doesn't really tell the whole story, and some tasks look simple in hindsight, when in reality it took a lot of effort to find a good solution. There are also a lot of other complications I'm not going to dive into, but the end result is that it's hard to have an objective productivity evaluation based on the engineer's output only.
I'd be interested to know how other people evaluate individual productivity?
by caymanjim on 7/26/19, 3:38 PM
This article contains dozens of grammatical errors (starting right off with the title). Whenever I read something like this, I'm so distracted by the errors that I can't even focus on what the author is trying to say. The English language is dying.
by sytelus on 7/26/19, 9:32 PM
This article reads like a series of bad advice from 1990s.
- No, engineers shouldn't be writing code that "adheres" to specifications. They should study, understand, question and contribute to problem statement and approach at all times (also called "requirements" in pre-2000s).
- Manager shouldn't be at center of evalauting performance but rather establishing process, standards and collecting feedback and metrics.
- Bonuses are inherently evil and would always motivate individuals to exploit short term gains at the expense of long term sustainibility. Any performance evaluation strategy must keep this issue front and center at all times.
- Large part of performance feedback shouldn't come from managers but peers
- Performance reviews should never be entirely metrics-driven. No finite set of metrics tell the full story and all metrics are susceptible at gaming.
- Don't treat new comers as incapable of fixing bugs or do X but not Y. Don't create class system of seniors vs juniors. Titles cause more troubles then they are worth.
by jimbokun on 7/26/19, 6:23 PM
Tie their compensation to the product's financial success.
This means, to the greatest extent possible, everything relevant to the product's success must be owned by the team and become their responsibility. Maybe there are some cross cutting concerns that should be the responsibility of a group separate from any product team, but those should be rare and require a strong justification.
This will have an amazing effect of clarifying prioritization of what to work on and figuring out how to deliver it as quickly and reliably as possible. Suddenly the whole team will be in the loop about what features are most important to the customers. Suddenly the things blocking new features demanded by the customers from shipping will be cleared away.
I think for any other metric you can devise, either intentionally or unintentionally, employee behavior will be optimized for satisfying the metric, and not customer satisfaction with the product.
by dfeojm-zlib on 7/26/19, 6:45 PM
- coolness (cooperation, proactiveness, professionalism)
- carefulness
- integrity (ethics)
- morale
- cadence (speed) of work
- skills competencies (matrix)
- grit (badassery)
- estimated time to completion multiplier
by pmiller2 on 7/26/19, 9:06 PM
by slaymaker1907 on 7/26/19, 6:21 PM
The best strategy after looking at various strategies under simulation is to focus on developing the people you already have since fixing your quality through hiring is very difficult and expensive.
by gorzynsk on 7/26/19, 9:25 PM
Managers will argue that they have so much responsibilities that they cannot code together with teh team, but I again would say that the problem may be reduced with reduction or higher management. Bussiness part shall talk with engineers on feasibility of their vision and ideas without proxies who are so in the middle that they neighter understand bussiness nor technology.
by alexbanks on 7/26/19, 9:35 PM
by backtobecks on 7/26/19, 3:58 PM