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.


7 Answers 7


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

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!


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:

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.


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"


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.


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.

  • While I agree w/ what you say it is not an appropriate response to the question. The question was how to measure daily contributions, not the progression of his career overall. Aug 19, 2011 at 13:15
  • Agreed with @Jarrod. Also, it was specific to not be about management, so talk of promotions and how to get them are out of place. Aug 19, 2011 at 14:17
  • @Jarod: In my opinion, trying to measure daily contributions is going to accomplish one thing: Looking at the wrong thing. How many meetings did I attend today (better: how many did I not attend), how many lines of code did I write (better: how much code did I eliminate by finding a common theme). Programmers are not piecemeal workers. For days at a time progress will appear to be nil, and then suddenly voila! a whole bunch of progress has been made. A longer term view is needed. Aug 19, 2011 at 17:28

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 )

  • 5
    -1: Number of check-ins isn't even a good management metric. It is an easily countable but absolutely meaningless bean: Good for the bean counters, not good for anything else. It is not a good personal metric. Not all check-ins that close a change request/discrepancy report are created equal. The CR to add a checkpoint/restart capability to an application is just a bit harder to finish off than is the DR that involves fixing a one-liner bug. Aug 19, 2011 at 0:48
  • 1
    Number of check-ins is almost as bad as Lines of Code (LoC). Maximizing these kinds of metrics does not equal higher code quality as they do not correlate at all.
    – Spoike
    Aug 19, 2011 at 6:18
  • Agreed with both above. Check-ins does not equate to contribution. Checking in 5 easy fixes is not "better" than one major new feature. Aug 19, 2011 at 14:20

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.