How can you measure your own daily contributions?

Question

I've recently finished the The Three Signs of a Miserable Job by Patrick Lencioni and one of his core ideas is that you need to have some form of measurement.

I have a pretty standard internal developer job where I work on new tools and do some support/bug fixes for past tools I have written.

For purely personal fulfillment reasons, what things would you measure on a daily basis? (This is not a report to managers and not something to game, just something to help me mark progress).

The goal is to find things that measure not just productivity, but how good of a job you are doing (so a customer service person might record positive interactions in addition to number of calls taken).

My stab at this would be to measure two things every day: support requests opened/closed and number of checkins to source control.

I understand if this gets closed, but once again this isn't a question about management, its about personal development as a programmer/software developer.

Answer 1

Keep a development journal and pay special attention to non-routine happenings. I'm excited by:

• Using a new algorithm, pattern, library, data structure, or language
• Collaborating with a new team or person
• Fixing a bug that was considered especially difficult
• Making a deep personal connection
• Building small tools that make my job easier (and possibly my co-workers' jobs)
• Getting blocked and then noticing exactly what happens to unblock me
• Noticing improvements in productivity caused by diet, sleep, and attitude
• Opportunities to share my passion
• Beauty in unlikely places

As for routine happenings:

• Watch the time required for routine tasks drop
• Watch what you consider difficult diminish
• Break out of routine interactions by giving someone your full attention and energy

Answer 2

If you want some daily affirmation then the simplest metric you can use is to write yourself a task list, or a to-do for today.

1. Write down what you need to do.
2. Can you split up any of those tasks. Make it more granular.
3. Start working on a task.
4. If you need to add more tasks, start over from step 1.
5. When you're finished with the task, cross it out.

At the end of the day, look at all the tasks you've done and feel proud. Now that's personal fulfillment!

Answer 3

I think like most knowledge-based professions, the answer is to keep a journal. Write down goals for every day and see if you meet those. Target a particular practice you want to improve on and record your progress.

For instance, I've always wanted to improve my estimation skills. So I keep a backlog, make and revise estimates on it and then use those to both gauge my ability to complete similar tasks and to see if I've improved at estimating.

I initially started with this spreadsheet from Joel: http://www.joelonsoftware.com/articles/fog0000000245.html

Simple, and a good place to start. (Joel has moved on since then:
http://www.joelonsoftware.com/items/2007/10/26.html)

I do something a little less sophisticated now that fits my workflow better.

So if you're looking for a particular metric to track, estimate correctness is a fun one. The ability to estimate accurately is pretty rare so you're gaining a useful skill, and it often feels like a game since you're trying to beat your "high score" from before.

Answer 4

I have a simple measure of progression:

when my co-workers/ clients say things like:

Stage 1:

"great working, loving it!"

Stage 2:

"that's awesome! I didn't even know you could do that!"

Stage 3:

"That's a life saver! the system would not be the same without it"

Stage 4:

"Absolutely yes, I trust you"

Stage 5:

"Its simply excellent, I don't know what more I could add"

Stage 6:

"You have changed us, changed this company, for the better"

Stage 7:

"thank you, you inspire me"

Answer 5

I would take another tact, depending upon where you are in your career, but particularly if you're junior to mid. Obviously, you want to meet your employer's expectations, you want to get your tasks complete on schedule, sound appropriate alarms if things are going different than expected, do your check ins, collaborate with your peers... everything you need to do.

Beyond that, my strategy is this: Do better today than you did yesterday.

That's it. That's your goal.

This means that the code you wrote yesterday is bad and today, you'll do better. Today, you'll research, fill in some of those gaps, those things you didn't even know you didn't know. Today, you'll refactor. You'll take that method that you left a bit too messy and clean it up. You'll recognize that thing you left too tightly coupled. You'll write that test that you overlooked. You'll learn something new.

If you do these things and you get your other work done, you'll have had a good, productive day.

Answer 6

Learn at least one new language a year, and use it.

Dive into at least one new aspect of the huge world of programming/software engineering each year, and use it.

Push yourself to dive deep. You are not pushing yourself hard enough if you never get the feeling that you are in over your head.

Talk to your supervisor about how to advance your career. A good supervisor is always on the lookout for someone to replace him or her. Talk to your boss's boss, or even higher up the chain, about how to accomplish this end. This might take a bit of finesse; do not give the impression that you are going over your boss's head here.

You'd be surprised how many promotions are given just because someone had the gumption to ask for one.

Answer 7

I think you've got the right idea, number of check-ins to source control is the way I'd do it. Each check-in is a significant unit of program refinement. Of course that only works when you only check-in fully developed program updates/fixes, but that's the way it should be done anyway. If I was measuring then this might help me stick to that rule, too.

Closed issue reports is another good measuring stick, I fully agree with that one, too. Again, it might help remind me to enter bug reports in a "if I don't log this defect before I fix it then I won't be measuring my own progress correctly today" way.

Both values should be easy to collect and graph. I can almost see the spreadsheet now... 8 )