
Advanced Codemunging: How SICP, Emacs, and Lisp Change Your Day Job Performance - pchristensen
http://lispy.wordpress.com/2008/05/13/advanced-codemunging-a-report-from-the-trenches/
======
tc
His essay here touches lightly on a pattern I've noticed among people who work
in large corporations: they fall into the habit of asking for permission and
guidance too often.

It doesn't make any sense to complain about inept suggestions or withheld
permission when the problem could have been solved or a critical decision
could have been made without blessing from above. Invariably though, if you
ask for permission, now you really do need it.

Many of the greatest projects that have ever come out of large corporations
happened because the innovators didn't ask or wait for permission (e.g. Unix).

~~~
baha_man
"It doesn't make any sense to complain about inept suggestions or withheld
permission when the problem could have been solved or a critical decision
could have been made without blessing from above."

The trouble is, if you try to solve a problem you weren't asked (told) to, or
use new and 'unapproved' methods, and anything goes even slightly wrong,
you'll be in serious trouble.

If you do what you're told and use the 'approved' methods, your job will be
safe in the short term - no matter how unsatisfactory the end result.

"Many of the greatest projects that have ever come out of large corporations
happened because the innovators didn't ask or wait for permission (e.g.
Unix)."

Longer term, yes, I think you're right.

~~~
learninglisp
I think it's worse to be stuck with responsibility for a codebase that you
have no real authority over.

You can't live in fear of that kind of stuff. Who's the fricking expert on
software development? Not the managers. If you focus on meeting everyone's
needs lower down on the food chain-- and invest in tools in techniques that
multiply your ability to maintain and extend the code-- then your development
will be so tight and your response to issues will be so comprehensive that the
"play it safe" types will have nothing they can say to you. (Except maybe that
they'd rather have more buttons or something.) If you're a responisible
developer, you'll be addressing the "slightly wrong" stuff well before the
middle managers even hear about it. You'll have a relationship with the real
value-adders such that they talk to you instead of your bosses. You, after
all, are the one that gets stuff done quietly and thoroughly.

Sheesh. They're "play it safe" types. Think about it. Once the code is up and
running, _they're_ not going to be to be suggesting any changes. Suddenly
you're the status quo and they'll defend your work by saying "if it ain't
broke don't fix it" just like they said about the previous solution.

