Productivity Illusion

[cjsmith]

While I may FEEL more productive if I can't access LJ at work, at the end of the day I'm not sure I'd gotten any more done than on any other day.

Darn. I'd been so hoping I would magically turn into a whirlwind of Super-Coder efficiency. (There's something about working at a startup that makes me desperately want to be superhuman.)

Maybe I have been guilting myself over something that didn't actually make much difference. When I'm working a hard problem, I take breaks. I have to. I rapidly become useless if I don't let my brain shake itself out every so often. Maybe whether those breaks are LJ or not doesn't matter.

Hard to say, this early. I'll give it more time. Maybe this change is merely a small positive thing.

Comments

[jcgbigler.livejournal.com]

Maybe I have been guilting myself over something that didn't actually make much difference. When I'm working a hard problem, I take breaks. I have to. I rapidly become useless if I don't let my brain shake itself out every so often. Maybe whether those breaks are LJ or not doesn't matter.

I've found this to be true about myself too. I end up taking the breaks no matter what. The danger is that sometimes I get wrapped up in LJ (or whatever my break activity is), and I end up taking a longer break. If you wanted to try a variant, you could try setting an LJ timer that lets you have 15 minutes and then doesn't let you go back for at least 15-20 more minutes. (I remember someone at MIT who was working on his thesis and had bad RSI set his computer to auto-lock every 20 minutes to force himself to take a typing break for at least 2 minutes.)

None of these methods has worked for me. What works best for me is to have a list of deliverables for the end of the day, and to be held accountable for whether each one got done. If the deliverables got done, it doesn't matter how much of the time I spent on LJ.

My guess is that you can probably improve your efficiency by up to 20% or so, but much more than that would be possible only for non-sustainable short bursts.

[cjsmith.livejournal.com]

The danger is that sometimes I get wrapped up in LJ (or whatever my break activity is), and I end up taking a longer break.

Yes, I find this one very believable for me. The timer idea could work well there.

What works best for me is to have a list of deliverables for the end of the day, and to be held accountable for whether each one got done. If the deliverables got done, it doesn't matter how much of the time I spent on LJ.

I like that idea. I find it can work well for deliverables with linear effort-to-results, such as writing up a status report, documenting a complex piece of code, or verifying old bugs. It doesn't work at all for me for debugging. Finding a problem can take a little time or a long time, and it's awfully tempting to say "gosh, still haven't found it, time for some LJ".

My guess is that you can probably improve your efficiency by up to 20% or so, but much more than that would be possible only for non-sustainable short bursts.

Might be. 20% would be pretty useful.

[just-cyd.livejournal.com]

i agree that you need breaks throughout the day. i'm "just a secretary" but i find if i don't get up and move around, give my eyes a brake from the computer, or my brain a break from mind-numbing reports, i'm more likely to get *nothing* done.

i don't let myself LJ from work 'cause i know it'll suck too much time. that, and i just don't wanna go there -- i worry about what the Powers That Be can see.

i admire your discipline for voluntarily blocking yourself from LJ and other fun stuff during work hours. i'm not sure i could be quite so strong.

[cjsmith.livejournal.com]

Maybe I can make my breaks more useful, too. If I go to the kitchen for tea, I'm more likely to run into a coworker. Maybe one of us needs to ask the other something. Plus I get tea, which is good! Fluids! :-)

I'm sure the Powers That Be can see where I'm surfing. I finally stopped reading breastreduction for that reason -- not only will I not click on images at work, but some people have even started using them for USERICONS fergoshsakes. Enough of that! No nekkidity at work -- there are really strict laws about that sort of thing.

[ericainohio.livejournal.com]

In my previous life as a computer programmer, I and my co-workers did something similar. We took breaks. And I suppose, from an outsider's point of view, it seemed as if we took a lot of breaks - and on occasion, someone would complain that it looked like those danged programmers were just "wasting time" back there.

But honestly, sometimes, the work wasn't going to get done if we *didn't*. It's just too mentally taxing, and the brain says, "OK, enough already. Shutting down temporarily." I can't tell you how many times I came up with a solution to a problem while in the ladies' room. LOL! One of my co-workers even joked about that, saying that she needed to take a trip to the "think tank".

In the end, the solution was simply looking at whether or not work was getting done. If everyone got their stats tables when they wanted them, and the clients were happy, no one complained about our breaks and what we did during our breaks. Make sense?

[cjsmith.livejournal.com]

Makes lots of sense indeed. I do wish I could get things done faster, though. An oft-quoted bit of wisdom says that if you measure the productivity -- by lines of code, by bugs fixed, whatever -- of your best programmers and your worst ones, the difference will be a factor of three. Three HUNDRED percent. Salaries aren't anywhere near that different, of course, so it stands to reason that the top people are very desirable and can find jobs easily. I would like to do what I can to be in the top part of that graph.

[eichin.livejournal.com]

and the factor-of-three version is the conservative don't-scare-people-too-much version. I've seen it convincingly quoted as high as a factor of ten - and given some of the programmer interviews I've done, I could probably come up with data for it :-)

Then again, there's another bit of wisdom about measuring productivity, which is that measuring it increases it - because it shows that someone cares. Much more true for "mundane" work, programmers almost always end up treating it as a game...

[cjsmith.livejournal.com]

Yeah, I find ten believable too. I figured if I was too lazy to look up a reference to cite, I'd at least quote the conservative number. :-)

being in the top part of the graph

[moriamerri.livejournal.com]

well, now you are getting the really way-more-interesting-
(to-me) set of problems/issues/questions.

I know there are great and interesting books on this
topic -- I've read some fascinating stuff about programming
efficiency and measurement and such (but not recently and
can't tell ya where to look. I just know there is lots of it
out there.)

Disclaimer: I'm a QA engineer, not a programmer.
2nd disclaimer: that may not really count as a disclaimer,
it could also be a "qualification".

Opinion: A couple of "high return" areas are:

--are you solving the right problems to begin with?
Does anyone want what you are making (for example)?
In many (or is it really just "some"?) compaines the
process of deciding what to make is VERY broken, the
folks in development are supposed to just accept it,
there are no resources or people working on fixing it.
I think this is "not good". Anyway, it is a lot
more efficient if you actually understand what is
needed, wanted, valued, desired, essential, required, etc.

--design. You can save more time and more bugs and
more frustration with design than with coding. This
is PARTLY "good" design (being smart and creative,
for example -- being logical and expressing the
problems and goals and constraints clearly......).
But that is NOT the whole ballgame.
Just having a "well understood" design will get you
VERY far. What do I mean? I mean talking over what
the thing does, how it does it, letting people ask
questions, doing the on-the-surface-"tedious"-tasks
like writing specs and having design reviews and
walk-throughs. (The names for these things are not
important, but doing them is....) I ***ROUTINELY***
eliminate bugs in spec review meetings (by having them
not get created). Sometimes big ones. Can't guarentee it
will happen, but it does happen.
Ask a few questions, and developers will come up with a
few further ideas and problems and changes and so on. My
frustration is that people are not generally convinced
that this is time well spent. (Never mind that QA/doc people
get no recognition for this sort of thing, are often
excluded from meetings of this sort, and that I sometimes
intentionally draw attention AWAY FROM the fact that
big problems are getting fixed so as to not cause anyone
to feel negligent.)
I've seen major problems uncovered just by drawing
a diagram on a whiteboard and asking a few questions.
(This is less threatening to some folks, too.)
Why do (many) developers seem to think that this is not
"real" work? That drawing and discussions about the
3 possible ways to solve this little issue are not
"the real thing"?
(If this mini-rant does not apply, feel free to ignore it.)

Re: being in the top part of the graph

[cjsmith.livejournal.com]

--are you solving the right problems to begin with?

Hah! I can answer this one. I hope I haven't mentioned the name of my company here on this blog. Personally, and this is just one individual opinion, no we are not. The company is what, three years old? four? and we're just now getting down to the business of identifying a target market. In my opinion -- now I know I'm not paid to be a CEO or a marketing analyst, so this is worth what I paid to type it -- this is not a good sign.

In many (or is it really just "some"?) compaines the
process of deciding what to make is VERY broken, the
folks in development are supposed to just accept it,
there are no resources or people working on fixing it.

I've never been at a place where it was considered to be the engineers' job to figure out what to make. It's always been our job to figure out how to make it. So that's a key piece for me when interviewing at a company: do I think their decision-makers have a clue? 'Cause once I take the job, I'm going to have to take those people's orders, directly or indirectly. If I believe they make sense, that contributes hugely to my morale.

--design. You can save more time and more bugs and
more frustration with design than with coding.

Agreed wholeheartedly. I learned this lesson in my first programming class, when we had a three-hour final and we couldn't touch a computer for the first hour and a half of it. I know darned well I would not have aced it like I did, if they'd let me at the keyboard faster. I relearned it again with the most recent revision of the OS: we spent more time in the conference room than coding, and the whole thing went together INCREDIBLY well and quickly.

I also adore design reviews... I seem to be in the minority there. Heck, code reviews (serious line by line examinations) can be enormous time savers if you have careful reviewers; I have caught at least one bug for every one I've attended, so I like 'em, but I know I'm in the minority on this issue as well.

Re: being in the top part of the graph

[moriamerri.livejournal.com]

"I've never been at a place where it was considered to be the engineers' job to figure out what to make."

I have been *sort of*. Or, at least I've been at places
where it was honestly very collaborative about what to make.
And I've also SOMETIMES seen engineers intervene to try
to modify/abort "crummy" plans/features. Although I guess this
is politically iffy, I think it can make for much
efficiency. But it probably should not have been in my
thoughts about being in "the top part of the graph", due
to the political iffiness in spite of possibly great
efficiency. I think I've somewhere seen
it "work", but not something one can count on.

Anyway, not sure I can make any sense with this -- It
shouldn't really be in suggestions for efficiency, even
though it is such a key element of efficiency. You're
right, usually there is little control beyone taking
the job (or not). And where there is control, (or at
least influence) there is also probably some risk.

Maybe this just comes back around to design -- where
sometimes developers have a lot of leeway and control
about what really is being made..... I'm thinking about
the kind of situation where the "requirements" are
very bare bones, so dev really does have a LOT of
control of whether what is made is sensible or not
(at least within the basic outline of the feature, or
whatever....) Maybe I've worked in unusual places,
I don't know.....

[quasigeostrophy.livejournal.com]

I forgot to check if I can access LJ from school at IUPUI when I was on campus getting books on Friday. Not that I'm going to be down there much - except on Wednesdays I don't have a lot of time between classes to kill - but I'm always curious as to what sort of security is in place.

[cjsmith.livejournal.com]

LJ is a security issue?

So once you check, hey, at least you'll know for Wednesdays!

[quasigeostrophy.livejournal.com]

Well, I just meant security in the sense of securing one's system against undesired content. At a kiosk in the Denver airport once, I couldn't get to LJ as it was blocked due to adult content.

[cjsmith.livejournal.com]

Oh, right. I would be a little surprised if schools thought undergrads shouldn't be allowed to see adult content, but I can see them not wanting it on their servers, so... yeah.