Tag: metrics

Things That Require Zero Talent and Other Garbage

Have you ever seen a meme like this?

10 Things That Require Zero Talent
‘It’s YOUR fault you aren’t good enough!’

It’s absolutely a lie.

Every one of those things requires a great deal of talent.

However, it is not that magical ‘talent’ that makes you say “I just will never be as good at <<something>> as <<someone famous>>.”

The truth is: talent is not natural aptitude or skill. Talent is the result of a great deal of work that appears natural to the outside world.

That’s the trick. Talent LOOKS natural, but it isn’t.

Everyone of those listed “no talent required” items relies on a great deal of work with a massive support structure. They require preparation, support, and unseen (and often underappreciated) work.

Example: Being on time

  • Someone had to get your kids out of bed, and logged onto school.
  • Your commute needs to be reliable.
  • Your home needs to be stable.

Did all that happen by itself? Magically?

Example: Making an effort or being high energy and having a positive attitude?

Someone had to give you direction, so you know what you’re trying to do. Someone had to make you feel like your efforts would matter.

Where’s all this work accounted for in the ‘no talent required’ posters?

The being coachable one enrages me because it absolutely requires a great deal of effort. I posted specifically about how to do it. It ain’t easy!

Consider some of the most talented folks you know, whether or not you’re talking about music, athletics, or software development. How many of them sit around and not actively practice their “talent”?

Stephen King is one of the most talented and prolific writers on the planet. He told us how he does it in his book On Writing: A Memoir of the Craft. It’s a wonderful and inspiring book.

Wanna know the secret about how he stayed so prolific? He wrote a lot. He needed a support structure for his writing: a teaching job early in his life, a very patient spouse, and in the end he wrote a lot. That’s all it was.

From a distance though, he’s looks talented.

Talent is the result of a great deal of work, combined with a great support structure. Remember to nurture both.

Developers – Make Your Own Metrics

Writing software can have a bit of a pile of metrics to pay attention to. I especially hate being held toward measurements I cannot get control of. One of the worst offenders can be the ‘Story Point.’

The Problem of Story Points

The story point starts with the best intentions. It gives a way to for a team to build consensus about how big something ‘feels’ without the burden of a deadline. Project managers can get a general gauge of velocity, and an idea of how long a project will take to complete. But there are some glaring holes.

First, there is no baseline for a story point. What’s a 1? Without a definition of the base, what does it mean when a team estimates something at an 8? Is an ‘8’ in fact 8 times bigger than 1? If not, what’s the value of a velocity ‘sum’? If you can’t trust 1+1 to equal 2, the fact that your team got 35 points done in a sprint is meaningless.

Second, in my day-to-day developer role, I can only minimally impact the larger measure of velocity with story points. My largest impact is simply showing up for work. In effect, velocity largely measures who was on vacation for a given week.

Metrics I Care About

Things that get measured, get improved.

There are plenty of things I can demonstrably impact as a developer though. I can write more LOC, or less. I can measure test case counts and the code-coverage of those tests. I can measure the complexity of functions and classes. I can measure the depth of dependency usage, and the number of interface implementations. I can count external dependencies, or compiler warnings. I can do stupidly easy stuff and count the number of ‘.Result’ calls on async methods. (Quick tip, your target is 0.)

It comes down to a issue of my own design though. The trick is to decide what that design is, and how to measure it. For my own aesthetic, I prefer the following:

  • Small code, thoroughly-tested, released often.
  • Code which is apparent in purpose and function.
  • Code with minimal external dependencies, which can be quickly replaced when warranted.

These are my design preferences, and having them help lead me towards the metrics I care about.

Small code, thoroughly-tested, released often = Cyclomatic complexity + Unit Test Coverage * Count of the number of deployments. These are simple numbers I can get out of build tools, and can ‘fiddle with’ right there in my editor. I can target small commits that are easily released to boot. I might not be directly able to control the release schedule, but I can target code that CAN be released often.

Code which is apparent in purpose and function = Average function length / Average class size * Average length of time commits are in code review. Again, I can fiddle with function length and class size directly in my editor, and I can make smaller commits / review sessions. I can do this every day to improve these numbers.

Code with minimal external dependencies = Count them. Did I install a Nuget package that came with 6 dependencies? Is there a comparable package that only has 2? If not, can I make one? If I don’t have time, can I minimize the surface area of that package? All of those items are directly under my control.

Communicate, Communicate, Communicate

Since I have my design aesthetics and metrics that show them, I can use them to communicate value and even push them further beyond story point as a measure of value. Some examples:

PM: We only completed 25 story points this sprint. Last sprint, we got 32. 😦
Me: We improved our test coverage by 28%, and last sprint, we had only gone up 4%. Our system is more robust against failure.
or
Me: We released 7 times this sprint! Last sprint, we released 5.
or
Me: Our average function length decreased by 8.5 lines, and our cyclomatic complexity stayed the same. That means our system is easier to work with for the next sprint!

Will my PM always understand these metrics? Probably not, but then my job is to get involved and communicate my values!

I might have to compromise. You don’t get to win everything, but having your principles backed with hard numbers is a much better way to win something and exercise some authority on some of your work.

I would rather be a stakeholder in what I am building than a cog in the machine.

Developers – Know Thyself

I am not suggesting that we change everything about story points or project management in a software project. There are better minds than mine on that. However, developers should do everything they can to decide how they want to write their code, and how to measure their improvement. Be regular, diligent, honest and thorough measuring your work. It is the best way to improve what you actually care about.