==================================
ϡ
linux-2.6.20/Documentation/ManagementStyle 
Ǥ
Ρ JF ץ < http://www.linux.or.jp/JF/ >
  2007/2/21
: Unknown
  Noriyuki Taniuchi < n-taniuchi at ay dot jp dot nec dot com >
  Seiji Kaneko  < skaneko at a2 dot mbn dot or dot jp >
          Masanori Kobayashi  < zap03216 at nifty dot ne dot jp >
==================================


                Linux kernel management style
                Linux ͥޥ͡ȥ

This is a short document describing the preferred (or made up, depending
on who you ask) management style for the linux kernel.  It's meant to
mirror the CodingStyle document to some degree, and mainly written to
avoid answering (*) the same (or similar) questions over and over again.

 Linux ͥΤΡޤʿͤˤäƤϻ䤬˺äʪ
ȸ⤷ޤ˥ޥ͡ȥˤĤƽ񤫤줿ûʸ
ǤCodingStyle ɥȤƱͤˡƱʤ⤷ϻ褦ʡ
˲٤֤ⷫʤƤɤ褦ˤ(*)Ūǽ񤫤줿ΤǤ


Management style is very personal and much harder to quantify than
simple coding style rules, so this document may or may not have anything
to do with reality.  It started as a lark, but that doesn't mean that it
might not actually be true. You'll have to decide for yourself.

ޥ͡ȥϿͤ줾ǤΤǡñʥǥ󥰥
롼٤ơϤ뤫̲񤷤ΤǤǤ顢ʸ񤬸
¤§Ƥ뤫ɤʬޤ󡣾̤ΤĤǽ񤭻Ϥ᤿ΤǤ
ʸ񤬼ºݤˤʤ⤷ʤȤ櫓ǤϤޤ
ʬȤȽǤƤ


Btw, when talking about "kernel manager", it's all about the technical
lead persons, not the people who do traditional management inside
companies.  If you sign purchase orders or you have any clue about the
budget of your group, you're almost certainly not a kernel manager.
These suggestions may or may not apply to you.

Ȥǡ֥ͥޥ͡פȸäȤϴȤŪʴ
̳򤹤ͤΤȤǤϤʤ٤ʵѤäͤΤȤؤޤ
⤷ʤʸ˥򤷤ꡢ롼פͽˤĤƲΤäƤ
Τʤ顢ۤܳμ¤˥ͥޥ͡ǤϤޤ󡣤äϤ
ƤϤޤ뤫⤷ʤǤϤʤ⤷ޤ


First off, I'd suggest buying "Seven Habits of Highly Successful
People", and NOT read it.  Burn it, it's a great symbolic gesture.

ޤSeven Habits of Highly Successful Peopleסܸ7
ν- ˤϸ§ä!סˤ㤦Ȥᤷޤ褷Ƥ
ɤǤϤޤǳ䤷ƤϽפǾħŪʰջɽ
Ǥ


(*) This document does so not so much by answering the question, but by
making it painfully obvious to the questioner that we don't have a clue
to what the answer is.

(*) ʸϡΤǤϤʤʤΤ䤿
ʤȤȤϤäꤵ뤳Ȥǡ٤ʤƺѤ褦ˤ
褦ȤΤǤ


Anyway, here goes:

Ȥˤ˿ʤߤޤ礦


                Chapter 1: Decisions
		ϡ

Everybody thinks managers make decisions, and that decision-making is
important.  The bigger and more painful the decision, the bigger the
manager must be to make it.  That's very deep and obvious, but it's not
actually true.

֥ޥ͡㤬Ǥ򤹤롢ƷǤ뤳ȤϽפʤȤפï⤬
ޤǶ¤ΤǤۤɤˡηǤ򤹤ޥ͡
ͥƤʤФʤޤ󡣤ʤȤȿƤޤ
ºݤˤޤ


The name of the game is to _avoid_ having to make a decision.  In
particular, if somebody tells you "choose (a) or (b), we really need you
to decide on this", you're in trouble as a manager.  The people you
manage had better know the details better than you, so if they come to
you for a technical decision, you're screwed.  You're clearly not
competent to make that decision for them.

οʤȤϡǤʤФʤʤʤ뤳Ȥ򤱤פȤǤäˡ
(a)(b)Ǥˤʤ˷Ƥ餦ɬפǤ
ïä硢ʤϥޥ͡Ȥƺʾˤ뤳Ȥˤʤ
ޤʤϤʤȤܺ٤ɤΤäƤΤǤ礦
顢⤷餬ŪʷǤ򤷤Ƥ餦ˤʤΤȤ褿Τ
顢ޤˤΤǤʤ餫ˡ˷Ǥ򤹤
ŬǤԤǤϤʤΤǤ


(Corollary:if the people you manage don't know the details better than
you, you're also screwed, although for a totally different reason.
Namely that you are in the wrong job, and that _they_ should be managing
your brilliance instead).

ʿ ⤷ʤʤܺ٤褯ʬäƤʤ
⡢ޤä̤ͳǤϤޤˤ뤳Ȥˤʤޤ
ʤϴְäŻ򤷤ƤΤǤäơ
ͥ줿ǽƤ٤ʤΤǤ


So the name of the game is to _avoid_ decisions, at least the big and
painful ones.  Making small and non-consequential decisions is fine, and
makes you look like you know what you're doing, so what a kernel manager
needs to do is to turn the big and painful ones into small things where
nobody really cares.

äơǤ뤳Ȥ򤱤סʤȤǶ¤
򤱤סȤȤοʤΤǤ٤ʡޤǤʤǤ
ΤϹޤ󤷡ʬƤ褯ʬäƤ褦˸Ƥ
ޤǤ顢ͥޥ͡㤬ʤФʤʤȤϡ
¤Ǥï⤢ޤ굤ˤʤ٤ʤΤѤ뤳ȤʤΤǤ


It helps to realize that the key difference between a big decision and a
small one is whether you can fix your decision afterwards.  Any decision
can be made small by just always making sure that if you were wrong (and
you _will_ be wrong), you can always undo the damage later by
backtracking.  Suddenly, you get to be doubly managerial for making
_two_ inconsequential decisions - the wrong one _and_ the right one.

ֽʷǡפȡֺ٤ʷǡפμʰ㤤ϡǤȤǽǤ
뤫ɤ򤷤ƤȤ褤Ǥ礦ְäƤˡʤƸ
Ǵְ㤤ˤʤ褦ʾˡĤǤű󤷤ƥ᡼ä褦
ˤƤСɤʷǤǤ⺳٤ʤΤˤ뤳ȤǤޤ
ˡʤĤοäǡʴְäΤΡˤ򤹤
ȤͳǡܴԤݤʤޤ


And people will even see that as true leadership (*cough* bullshit
*cough*).

Сޤο͡Ϥ򿿤Υ꡼åפȤפǤ礦
(


Thus the key to avoiding big decisions becomes to just avoiding to do
things that can't be undone.  Don't get ushered into a corner from which
you cannot escape.  A cornered rat may be dangerous - a cornered manager
is just pitiful.

äơʷǤ򤱤뤿˽פʤȤϡּäʤȤ
ʤפȤȤˤʤޤ򤱤ʤʡɤޤƤ
ޤɤͤ줿ͥߤϴ⤷ޤ󤬡ɤͤ줿
ޥ͡ϻʤǤ


It turns out that since nobody would be stupid enough to ever really let
a kernel manager have huge fiscal responsibility _anyway_, it's usually
fairly easy to backtrack.  Since you're not going to be able to waste
huge amounts of money that you might not be able to repay, the only
thing you can backtrack on is a technical decision, and there
back-tracking is very easy: just tell everybody that you were an
incompetent nincompoop, say you're sorry, and undo all the worthless
work you had people work on for the last year.  Suddenly the decision
you made a year ago wasn't a big decision after all, since it could be
easily undone.

ͥޥ͡˵ʲǤºݤ碌褦ȤۤɥХʿ
ϤɤʤǤ礦顢̾ű󤹤뤳ȤϽʬñȤȤ
ʤޤ֤ʤۤɤ˵ۤΤϲǤ櫓ǤϤʤΤǡű
ͣΤΤϡŪʷǤǤơηǤű󤹤
Τ˴ñǤĤޤꡢʤ̵ǽʥХäȳ˸äƼդޤꡢ
ʤǯˤ餻ͤΤʤŻ򤹤٤̵äˤǤ
ñ˼äǤΤǡǡȤƤʤǯˤǤϤɤ
ߤʷǤǤ̵äΤȤȤˤʤޤ


It turns out that some people have trouble with this approach, for two
reasons:
 - admitting you were an idiot is harder than it looks.  We all like to
   maintain appearances, and coming out in public to say that you were
   wrong is sometimes very hard indeed.
 - having somebody tell you that what you worked on for the last year
   wasn't worthwhile after all can be hard on the poor lowly engineers
   too, and while the actual _work_ was easy enough to undo by just
   deleting it, you may have irrevocably lost the trust of that
   engineer.  And remember: "irrevocable" was what we tried to avoid in
   the first place, and your decision ended up being a big one after
   all.

Ĥͳ顢ͤˤäƤϤΥץ񤷤Ȥ狼ޤ
 - ʬХǧ뤳Ȥϡ񤷤ȤǤ䤿ϳ
   ܤݤΤǡǡְִäƤޤפȸΤ˿
   礬ޤ

 - ֤餬ǯäŻϷɲ̵ͤäפȸ뤳
   ϡ襤Υ󥸥˥ˤȤäƤ˿ɤΤˤʤ
   ޤƼºݤʪǴñ̵äȤˤǤ
   ޤʤϤΥ󥸥˥ο֤Ĥʤ餤˼
   Ƥޤ⤷ޤ󡣳ФƤƤּ֤Ĥʤ
   ϡ⤽䤿򤱤褦ȤƤΤǡʤηǤϷɤ
   ʤΤäȤȤǤ


Happily, both of these reasons can be mitigated effectively by just
admitting up-front that you don't have a friggin' clue, and telling
people ahead of the fact that your decision is purely preliminary, and
might be the wrong thing.  You should always reserve the right to change
your mind, and make people very _aware_ of that.  And it's much easier
to admit that you are stupid when you haven't _yet_ done the really
stupid thing.

ʻˡݤäƤʤȤľǧơʤηǤ
λŪʤΤǡְäƤ뤫⤷ʤȤȤ˸äƤ
СͳϤɤŪ˷ڸ뤳ȤǤޤͤѤ
αݤƤơΤȤ򳧤ˤäȾΤƤ٤
ơ˥Хʻ򤹤ǤСʬХǧ뤳Ȥ
äȵڤʤΤˤʤޤ


Then, when it really does turn out to be stupid, people just roll their
eyes and say "Oops, he did it again".

ȡ˥ХʤȤäƤޤäǤ⡢ޤο͡ܤ
äȲ󤷤ơ֤ޤ䤬äפȸǤ


This preemptive admission of incompetence might also make the people who
actually do the work also think twice about whether it's worth doing or
not.  After all, if _they_ aren't certain whether it's a good idea, you
sure as hell shouldn't encourage them by promising them that what they
work on will be included.  Make them at least think twice before they
embark on a big endeavor.

Ρ̵ǽǤ뤳Ȥ򤢤餫ǧƤȡפϡºݤ˺Ȥ
ͤˡͤ뤫ɤ⤦ٹͤ뤳ȤˤʤǤ
ɡɤǥǤ뤫ɤפοƤʤ
顢ʪʥͥˡ˼ޤ뤳Ȥ«ƴ˾Ƥ
Фˤޤ餬Ȥ˼ݤˡʤȤ⤦
ͤƤ


Remember: they'd better know more about the details than you do, and
they usually already think they have the answer to everything.  The best
thing you can do as a manager is not to instill confidence, but rather a
healthy dose of critical thinking on what they do.

ФƤƤϤʤܺ٤ΤäƤ
ʬƤΤΤФäƤ̾ϴ˹ͤƤޤ
ʤޥ͡ȤƤǤɤλϡȯԤäƤ뤳Ȥ
Ƽ뤳ȤǤϤʤŬ٤ȽŪ˹ͤ뤳ȤʤΤǤ


Btw, another way to avoid a decision is to plaintively just whine "can't
we just do both?" and look pitiful.  Trust me, it works.  If it's not
clear which approach is better, they'll eventually figure it out.  The
answer may end up being that both teams get so frustrated by the
situation that they just give up.

ȤǡǤ򤱤⤦ĤˡϡᤷˡξǤʤΤʤ
ȵ㤭äơߤͶȤǤƤޤޤ
ɤΥץɤΤʤʬäƤʤƤ⡢
츫ĤФǤ礦ξˤ餤餷ξबȤΤ
ˤʤΤ⤷ޤ


That may sound like a failure, but it's usually a sign that there was
something wrong with both projects, and the reason the people involved
couldn't decide was that they were both wrong.  You end up coming up
smelling like roses, and you avoided yet another decision that you could
have screwed up on.

ϼԤΤ褦ʹ뤫⤷ޤ󡣤̾綠ϡξΥ
ȤȤⲿޤȤǤץȤΥС
ǤǤʤΤξְäƤ뤫ǤɤϥХι꤬
褦ɤ̤夭Ԥ⤷ʤ⤦ĤηǤ򤱤
ΤǤ


                Chapter 2: People
		2ϡ͡

Most people are idiots, and being a manager means you'll have to deal
with it, and perhaps more importantly, that _they_ have to deal with
_you_.

ۤȤɤοͤϥХǤơޥ͡ǤȤȤϡʤ
λ¤ʤФʤʤȤȤǤƤ餯
פʤȤϡ⤢ʤʤФʤʤȤȤǤ


It turns out that while it's easy to undo technical mistakes, it's not
as easy to undo personality disorders.  You just have to live with
theirs - and yours.

Ūʲϴñ˼äޤ줿ʹִطäȤϴñ
ǤϤޤ󡣤ʤβʤƤʤβˤ򤿤
ʤƤϤʤޤ


However, in order to prepare yourself as a kernel manager, it's best to
remember not to burn any bridges, bomb any innocent villagers, or
alienate too many kernel developers. It turns out that alienating people
is fairly easy, and un-alienating them is hard. Thus "alienating"
immediately falls under the heading of "not reversible", and becomes a
no-no according to Chapter 1.

ʤ顢ͥޥ͡ȤƤޤ뤿ˡޤ¿Υ
ͥ볫ȯԤ򤷤ꡢ̵¤κ򤭤ꡢ±ˤꤷʤ褦
ɤǤ礦±ˤʤΤϤȤƤñǤդ񤷤ΤǤ
äơ±ˤʤפȡˡּ֤ĤʤפȤˤʤäƤ
ޤChapter 1 ˤȤΤäƤϤʤˤʤޤ


There's just a few simple rules here:
 (1) don't call people d*ckheads (at least not in public)
 (2) learn how to apologize when you forgot rule (1)

ñʥ롼뤬äĤޤ
 (1) ͡d*chheadsפȸƤФʤǤʤʤȤǤϡˡ
 (2) 롼(1)˺ƤȤμդޤФƤ


The problem with #1 is that it's very easy to do, since you can say
"you're a d*ckhead" in millions of different ways (*), sometimes without
even realizing it, and almost always with a white-hot conviction that
you are right.

#1 ϡ100̤θ(*) ֤ d*chhead פȸƤ
ޤΤǡĤäƤޤȤȤǤŤ˸äƤ뤳
Ȥ⤢ޤξϼʬȤθǤ뿮ǰäƸ
Ƥޤ


And the more convinced you are that you are right (and let's face it,
you can call just about _anybody_ a d*ckhead, and you often _will_ be
right), the harder it ends up being to apologize afterwards.

ơʤʬȳοƤۤɡǼդޤΤ񤷤
äƤޤޤʸ¤ǧޤ礦ʤïˤǤ d*chhead ȸƤ
Ǥǽ뤷ϤʤΤǤ礦


To solve this problem, you really only have two options:
 - get really good at apologies
 - spread the "love" out so evenly that nobody really ends up feeling
   like they get unfairly targeted.  Make it inventive enough, and they
   might even be amused.

褹뤿ϡºĤޤ
 - դޤΤˤޤʤ뤳ȡ
 - Ըʿˤʤʤ褦˶ˡְפդޤȡʬŪˤ
   Ƥ򤬤äꤹ餹Ǥ礦


The option of being unfailingly polite really doesn't exist. Nobody will
trust somebody who is so clearly hiding his true character.

鵷ȤϤޤ餫ܿ򱣤Ƥ
ʤï⿮ʤǤ礦


(*) Paul Simon sang "Fifty Ways to Lose Your Lover", because quite
frankly, "A Million Ways to Tell a Developer He Is a D*ckhead" doesn't
scan nearly as well.  But I'm sure he thought about it.

(*) Paul Simon ϡͤ򼺤ˡ50̤ꤢפȲΤޤΨľ
äơֳȯԤˤޤ D*ckhead ȸˡ100̤ꤢפȤ
ޤƤʤ⤷ޤ󤬡ϤƱݤΤȤͤƤ
Ȼפޤ


		Chapter 3: People II - the Good Kind
		3ϡ ͡ II - ͥʿͤ

While it turns out that most people are idiots, the corollary to that is
sadly that you are one too, and that while we can all bask in the secure
knowledge that we're better than the average person (let's face it,
nobody ever believes that they're average or below-average), we should
also admit that we're not the sharpest knife around, and there will be
other people that are less of an idiot that you are.

ۤȤɤοͤХʤ櫓ǤϤĤޤᤷȤˤʤ⤽ΰ
ͤȤȤǤ䤿ϳʬʿŪʿͤޥȤǧ
˰½Ƥޤʸ¤ǧޤ礦ʬʿѤʿѤ겼ȿ
ƤͤʤɤʤΤǤˡΰǡʬοͤ
ǳ̤Ƭڤ櫓ǤϤʤʤϥХǤʤͤ
ȤȤǧ٤Ǥ


Some people react badly to smart people.  Others take advantage of them.

ͤФƤҤɤȿ򤹤ͤ⤤ޤѤͤ
ޤ


Make sure that you, as a kernel maintainer, are in the second group.
Suck up to them, because they are the people who will make your job
easier. In particular, they'll be able to make your decisions for you,
which is what the game is all about.

ʤϥͥƥʤȤơܤΥ롼פˤ뤳ȤΤƤ
ͤϤʤλŻñˤƤΤǡΤ
äƤäˡ餬ʤ˷ǤƤȤ
ȤפǤ


So when you find somebody smarter than you are, just coast along.  Your
management responsibilities largely become ones of saying "Sounds like a
good idea - go wild", or "That sounds good, but what about xxx?".  The
second version in particular is a great way to either learn something
new about "xxx" or seem _extra_ managerial by pointing out something the
smarter person hadn't thought about.  In either case, you win.

äơïʤ긭ȵդʤ顢Ȥϰˤޤ
ƤǤʤδǤϼˡ֤ͤΤ褦͡ǹԤ
סޤϡ֤ߤ͡Ǥ xxx ˤĤƤϤɤפȸ
ʤޤäܤΥСϡxxxפˤĤƿȤؤ
ꡢ긭ͤͤƤʤäŦȤǡΤԤ
Ȥ餷ˡǤˤ衢ʤ
ΤǤ


One thing to look out for is to realize that greatness in one area does
not necessarily translate to other areas.  So you might prod people in
specific directions, but let's face it, they might be good at what they
do, and suck at everything else.  The good news is that people tend to
naturally gravitate back to what they are good at, so it's not like you
are doing something irreversible when you _do_ prod them in some
direction, just don't push too hard.

դʤФʤΤϡʬǤϰǤäƤ⡢̤ʬǤɬ
Ѥ櫓ǤϤʤȤǧ뤳ȤǤʤ̤͡ʻ
餻褦Ȥ硢ϺäƤŻˤĤƤդ⤷
ʤ¾ƺ㤫⤷ʤȤ¤ǧޤ礦ϯʤΤϡ
ϼʬդʤΤ˼˰ᤵΤǡʤ̤ʻŻ餻
褦ȤƤ⡢֤ĤʤȤ򤷤ƤȤ櫓ǤϤʤ
ȤȤǤޤ̵ϤʤǤ



		Chapter 4: Placing blame
		4ϡ̷Ѥ

Things will go wrong, and people want somebody to blame. Tag, you're it.

ʪޤʤȡ͡ï񤷤ʤޤʤï
Ǥ


It's not actually that hard to accept the blame, especially if people
kind of realize that it wasn't _all_ your fault.  Which brings us to the
best way of taking the blame: do it for another guy. You'll feel good
for taking the fall, he'll feel good about not getting blamed, and the
guy who lost his whole 36GB porn-collection because of your incompetence
will grudgingly admit that you at least didn't try to weasel out of it.

뤳ȤϤʤ񤷤ȤǤϤޤ󡣼ο͡
ɬƤʤǤȤ櫓ǤϤʤäΤפ򤷤Ƥ
褦ʿͤʤäˤǤϰ֤ޤˡ
뤳ȤǤޤĤޤꡢ¾ͤؤȤȤǤʥ
͡Ǥˤʤ¾ͤؤ뤳Ȥ̤
ʬˤʤꡢʥߥ򤷤˺ѤǥۥäȤʤ̵ǽ
Τ 36GB ΥݥΥ쥯ޤ뤴ȼäͤϡʤȤ⤢
ƨ򤷤ʤäȤǧǤ礦


Then make the developer who really screwed up (if you can find him) know
_in_private_ that he screwed up.  Not just so he can avoid it in the
future, but so that he knows he owes you one.  And, perhaps even more
importantly, he's also likely the person who can fix it.  Because, let's
face it, it sure ain't you.

줫顢ʤ⤷Ĥ뤳ȤǤ˼ºݤ̵ˤƤޤäȯ
ԤˤΤȤ֤äȡ׶ƤƤϤʤȤ̵
褦ˤȤǤϤʤबʤ˼ڤäȤΤ餷뤿
Ǥ¿ʬ˽פʤȤϡǤΤޤ餯
γȯԤȤȤǤʤʤ顢¤ͤСʽǤͤ
ʤǤϤʤΤϳΤʤΤǤ


Taking the blame is also why you get to be manager in the first place.
It's part of what makes people trust you, and allow you the potential
glory, because you're the one who gets to say "I screwed up".  And if
you've followed the previous rules, you'll be pretty good at saying that
by now.

⤽뤫餳Υޥ͡ˤʤΤǤ
ʤֻ䤬̵ˤޤפȤȸͤǤС
뤳Ȥˤäƿꤵ졢ʤλޤƤ⤷ʤ
ޤǤ˽ФƤ롼˽äƤʤ顢ΤȤƤ
ޤʤäƤ뤳ȤǤ礦


		Chapter 5: Things to avoid
		5ϡ򤱤٤

There's one thing people hate even more than being called "d*ckhead",
and that is being called a "d*ckhead" in a sanctimonious voice.  The
first you can apologize for, the second one you won't really get the
chance.  They likely will no longer be listening even if you otherwise
do a good job.

͡d*chheadפȸƤФäȷ뤳Ȥޤϡ
֤ͤäǡd*ckheadפȸƤФ뤳ȤǤǽΤΤФƤϼդޤ
ȤǤޤܤˤĤƤϤεʤǤ礦
Ȥʤ¾ɤŻ򤷤ƤƤ⡢֤ϤϤʹƤʤ
Ǥ礦͡


We all think we're better than anybody else, which means that when
somebody else puts on airs, it _really_ rubs us the wrong way.  You may
be morally and intellectually superior to everybody around you, but
don't try to make it too obvious unless you really _intend_ to irritate
somebody (*).

䤿ϳʬ¾ïͥƤȹͤƤޤϤĤޤꡢ
⤯ȤޤäƤͤȡΤФǤȤȤǤ
ƻŪˤŪˤ⡢ʤϼïͥƤΤ⤷ޤ󤬡
ï˲Ω(*) ȤΤǤʤСޤꤪäԤˤ
ȤƤϤޤ


Similarly, don't be too polite or subtle about things. Politeness easily
ends up going overboard and hiding the problem, and as they say, "On the
internet, nobody can hear you being subtle". Use a big blunt object to
hammer the point in, because you can't really depend on people getting
your point otherwise.

Ʊͤˡǫ󤷤ˤʤꤹƤ⤤ޤǫˤʤꤹ
򸫤ˤ뤳Ȥˤʤ꤬Ǥ۩֥󥿡ͥåȤǤϡն
ʸʤïʹƤϤޤפȤȤǤݥȤĴ
뤿ˡ̵ۤˤäƤʤʤ顢ʤȤ
ʬäƤʤ褦ʿͤƤˤʤƤǤʤǤ


Some humor can help pad both the bluntness and the moralizing.  Going
overboard to the point of being ridiculous can drive a point home
without making it painful to the recipient, who just thinks you're being
silly.  It can thus help get through the personal mental block we all
have about criticism.

̵ۤäƻŪäꤹ֤˥桼⥢Ȥ褤Ǥ礦
פڤդСʹͤʵʬˤ򤵤ޤ
οͤϤʤХȹͤǤ礦ɡΤ褦˥桼⥢ϡɾ
Ȥ񹳴¤餲뤳ȤǤޤ


(*) Hint: internet newsgroups that are not directly related to your work
are great ways to take out your frustrations at other people. Write
insulting posts with a sneer just to get into a good flame every once in
a while, and you'll feel cleansed. Just don't crap too close to home.

(*) ҥȡŻľܴطƤʤ󥿡ͥåȤΥ˥塼롼
ϡ¾οͤˤʤΥե饹ȥ졼֤ޤ뤿餷ˡ
ǤΤ᤿ŪƤ񤤤ơե졼ˤꤹС
äꤹǤ礦ޤȶʤȤǥХʤȤ򤷤ʤȤ



		Chapter 6: Why me?
		6ϡ Τ錄

Since your main responsibility seems to be to take the blame for other
peoples mistakes, and make it painfully obvious to everybody else that
you're incompetent, the obvious question becomes one of why do it in the
first place?

ʤμǤϡ¾ͤβФơʬ̵ǽ
Ȥˡ뤳ȤΤ褦ǤȤȡ⤽ⲿΤ
ΤȤʵ䤬來ޤ


First off, while you may or may not get screaming teenage girls (or
boys, let's not be judgmental or sexist here) knocking on your dressing
room door, you _will_ get an immense feeling of personal accomplishment
for being "in charge".  Never mind the fact that you're really leading
by trying to keep up with everybody else and running after them as fast
as you can.  Everybody will still think you're the person in charge.

ޤɥå󥰥롼ΥɥáƵ㤭Ǥƥ󥨥λ
ݤߤƤСǤäƤפȤȤߤƴǤ
٤ʤ褦ˤơǤ¤®θ뤳Ȥˤäơ
ºݤˤϤʤƳƤȤ¤򵤤ˤʤǤʤ
ǤԤȳĤͤƤޤ

It's a great job if you can hack it.
