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

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.....