How can a developer evaluate the effectiveness of his workflow?

Question

This question has been on my mind for probably 10 years. Ever since I've started programming for a living. And I've seen multiple discussions about good fit, distractions, being in the zone, etc. But I haven't seen links to some information/research that could give an objective self evaluation measure/tool to understand how you're really doing.

What constantly bugs me, is that I think I'm not spending enough time on coding, and the effective work hours are not 8 out of 8, but less, with some days being even super ineffective, exactly like in this article.

There are some metrics expressed as lines of code per day, with some sources quoting 1.5 being good and some sources indicating 500 per day being normal, but this again, is completely invalid metric as far as I can see.

So at the end of the day, you have an assignment, you do it, but part of the time evaporates in sort of like "wth I was doing" kind of way. Emails, just staring at the code, thinking, painting a mental picture of the code in your head, floating somewhere, rethinking how things could have done more effectively, etc.

And because of that, I'm never sure if I need to do something ASAP, to keep the raises coming, or am I paranoid, or is it just normal.

The only half-good measure I've found so far, is seeing the amount of code other developers produce-vs-code I produce. And that usually floats around same number. But when I look at my code, or others code I still always get a feeling it could be done 10x faster.

Then again, code crunching doesn't seem to work, or does seem to cause a burnout if not handled properly.

So do you know of a good self evaluation approach to see if you're ineffective/effective? How do you weight the work you've done?

Answer 1

I don't know if there's a "documented best way", but I would suggest that you should try personal A/B testing. Pick your favorite metric - lines coded, progress towards goals made, features implemented, etc - and then switch things around on a bi-weekly schedule. Start using the Pomodoro technique. Try using multiple monitors. Try blocking internet access to time-wasting. Try exercising in the middle of the day. Try any of the bazillion or so fads that promote themselves as increasing productivity, and see which ones work for you.

It will take a long time, sure, but it's all during your regular work anyway, and worst case scenario you've just tried a bunch of different things and now you know that you're just as (un)productive no matter which ones you use.

Answer 2

You are right about lines-of-code is a completely meaningless figure. As one of the original bearded UNIX hackers put it: "Today was a very productive day. I deleted 1000 lines of code."

You are also right about crunch mode being mostly counter-productive. It is possible to force yourself to type faster, but this inevitably comes at the cost of thinking your code through. You'll build up technical debt, and you'll have to pay for it one way or the other. Permanent crunch mode is a perfect recipe for unmaintainable code.

Your problems doesn't seem to be one of productivity, but rather one of management. It looks like you are being managed badly, or not at all. You need a list of tasks with priorities and time estimates. The time estimates have to be yours (you are the best qualified person to estimate how long it takes you to do something), the prioritizing has to be done by the person responsible for managing the project. With these two in place, it is both clear what your next task is, and when you'll get around to task X. Be sure to include all the overhead (thinking, staring, research, communication) in your estimate. Also, measure how long it actually took you to complete the task, and use this information to adjust future estimates - your estimates are going to be more reliable over time if you do this.

About the "actual coding vs. overhead" issue; don't expect to be actively coding 8 hours a day, it's simply not realistic. Spending 1/3 or more of a project's budget on design is not unusual, and it's not a bad thing either - design changes are generally cheaper than code changes. Add to that self-management overhead, mental blocks (we all have those), interruptions, communication overhead, paperwork, keeping your development environment up-to-date, and all those other pesky little annoyances, and you'll quickly drop below 50% of your working day spent on programming. Of those 50%, you probably spend half or more thinking, reading code, researching, etc., so spending three hours or less per working day on actual programming isn't unusual at all. Programming is a mind game, it's not like assembly line work.

So, how do you assess your productivity? Programmer performance isn't generally quantifyable, so you'll have to go with subjective figures:

• Customer satisfaction
• Employer satisfaction
• Reliability of the software you write
• Correctness (does your software meet the specs? does it consistently produce the right results?)
• Robustness (does your code handle errors gracefully? does it contain a low number of critical bugs?)
• Code maintainability (is it easy and safe to change your code?)
• Usability (do users find your application easy to use?)
• Personal growth (does the subjective quality of your work increase over time?)
• ...

Answer 3

Counting the lines of code is one of the most useless metrics I can think of. Sounds like there's more of a prioritizing issue at play than effectiveness.

Answer 4

You don't appear to refer to the objective of the code you are writing at all. I'm of the opinion that if you want to evaluate how effective you are in writing code, you need to evaluate it in terms of how well it matches the requirements fed to you. I don't see this as an evaluation of workflow - an evaluation of your workflow should cover a) does it leave you constantly stressed, b) does it enable you to write effective code that fulfills your requirements c) do you spend a lot of time firefighting/bug fixing d) do you design effectively up front e) do you split your time for design/code/testing effectively such that you get a balance that doesn't cause you to spend a lot of time bug fixing, firefighting and stressing. f) do you have the right tools to do help you do your job effective and if you don't can you recognise what's missing

In short, you need to differentiate between evaluating your workflow (process) and your output. They are two different things although it is likely that an effective workflow will improve your ability to generate output.

Counting lines of code is a very bad way of measuring output or workflow. It's an accounting idea that sees code as widgets. Code isn't a widget however, it's a way of doing things and sometimes something important can be done in 2 lines of code more effectively than in 1000 lines of code. A LOC metric fails in this respect and it's not uncommon

I work on a system where brevity and speed are vital. But because of business requirements, it's not always wise to use least LOC as a metric either. What matters is effectivity versus business requirement and most people have trouble measuring that.

Answer 5

You can only evaluate a productivity enhancing technique if, during your experimentation everything else remains constant. This is obviously impossible if you have a varied workload.

My advice would be to find a number of problems of equal difficulty, (for example, by looking at problems from project Euler) and then trying different techniques on different problems, measuring your completion time.

It's important that the technique that you use is the only variable changing, so try to eliminate every other variation. Perhaps you could eliminate alertness from the equation by only doing one or two problems a day before anything else.

Repeat until your results are conclusive.