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

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