必死にプログラム勉強したのに冷遇されるのはなぜ？
23 ：仕様書無しさん：2005/10/25(火) 12:30:40
一般に日本における技術者のステータスって低いよな。
だから技術者はいつの時代も冷遇されるんだ。
いい思いしたかったら事務屋になれってことなんだと思う。
理科系で成功スル奴はほんの一握りなんだから、
自分の子供はより確実な文系にしようと思う。
だから技術者はいつの時代も冷遇されるんだ。
いい思いしたかったら事務屋になれってことなんだと思う。
理科系で成功スル奴はほんの一握りなんだから、
自分の子供はより確実な文系にしようと思う。
世の技術者は自分たちを不要にする技術を一生懸命開発している。
開発した本人は達成感と、暫くの間生き長らえる権利を得る。
だがそれは次の世代に高いハードルを与えることになる。
開発した本人は達成感と、暫くの間生き長らえる権利を得る。
だがそれは次の世代に高いハードルを与えることになる。
25 ：仕様書無しさん：2005/10/25(火) 21:08:55
技術者をボロ雑巾のように使って敬わないのは、朝鮮文化だよなぁ。
まったく日本はとんでもない国と合併したものだ。
まったく日本はとんでもない国と合併したものだ。
それは階級の高い人の話しでしょう。
朝鮮では身分の上下関係が厳しく、下の者はとことんまで酷い扱いを受ける。
朝鮮では身分の上下関係が厳しく、下の者はとことんまで酷い扱いを受ける。
共産主義だからな
共産主義が登場するよりもずっと前からの朝鮮文化ですよ。
>>18
> >>15
> 技術なんてのは、やってて面白ければ身に付くものだし
おまいはアホか。
アインシュタインですら完全に理解できなかった
位相幾何学なんていう超難解な学問技術はそう簡単には
身に付かないぞ。学問を究めるのは非常に時間と苦労がかかり、大変なんだぞ。
それをわかっていない文系や営業や顧客や無能なワンマン経営者が
多すぎてウンザリする。
> >>15
> 技術なんてのは、やってて面白ければ身に付くものだし
おまいはアホか。
アインシュタインですら完全に理解できなかった
位相幾何学なんていう超難解な学問技術はそう簡単には
身に付かないぞ。学問を究めるのは非常に時間と苦労がかかり、大変なんだぞ。
それをわかっていない文系や営業や顧客や無能なワンマン経営者が
多すぎてウンザリする。
>>24
> 世の技術者は自分たちを不要にする技術を一生懸命開発している。
それはどうかな。日本各地でアンテナを撤去された
哀れな時代遅れセルラーシステム開発者
の事例のような、撤去作業が終わったら仕事がなくなって退職になった奴らもいるが、
世の中にもそういう勿体ないことをする奴もいれば
そうなるのを恐れて陰湿にもわざとジラして立場を守るために
他の技術者や客に嫌われるような行為、つまり保守的になって
自分にしかわからない技術を独占しようとする者もいる。
喩えば、本人にしかわからないようなスパゲティコードを量産して
自分の仕事、手柄を後継者に横取りされないようにする
COBOLerとか、C言語厨とか。富士通とかが似たような手を使って
サーバソフトウェアに、ちょっとした足りない機能があると、
その機能を追加するためにオプションとして何十万、何百万と顧客から
金を横取りしようとしている。
> 世の技術者は自分たちを不要にする技術を一生懸命開発している。
それはどうかな。日本各地でアンテナを撤去された
哀れな時代遅れセルラーシステム開発者
の事例のような、撤去作業が終わったら仕事がなくなって退職になった奴らもいるが、
世の中にもそういう勿体ないことをする奴もいれば
そうなるのを恐れて陰湿にもわざとジラして立場を守るために
他の技術者や客に嫌われるような行為、つまり保守的になって
自分にしかわからない技術を独占しようとする者もいる。
喩えば、本人にしかわからないようなスパゲティコードを量産して
自分の仕事、手柄を後継者に横取りされないようにする
COBOLerとか、C言語厨とか。富士通とかが似たような手を使って
サーバソフトウェアに、ちょっとした足りない機能があると、
その機能を追加するためにオプションとして何十万、何百万と顧客から
金を横取りしようとしている。
>>24
そのほか、
昔、UNIXでサーバ管理をしていたシステムプログラミングが得意なC言語厨には
非常に保守的でかつプライドが高い連中が多いことも事実。
Solarisサーバ管理者、*BSD信者など様々な奴がおり、エンジニアはそれぞれ得意不得意分野があり
複雑多岐になっている。
同じエンジニアでもよのなか様々な奴が居る、
同じエンジニアでも非常に複雑多岐な分野にわたって、異なる有利不利、異なるチャンス、
異なるメリットデメリットが存在する。ただただ一言でエンジニアといっても種類は様々だ。
ソフトウェア、ハードウェア、情報科学、情報工学にかかわらず、強電、弱電、機械工学、化学、数学、物理学、
建築、バイオ、心理学、メカトロニクス、宇宙物理学、原子物理学、量子力学、航空宇宙工学、海洋開発など、
エンジニアの種類は数え切れないものさまざまだ。
そのほか、
昔、UNIXでサーバ管理をしていたシステムプログラミングが得意なC言語厨には
非常に保守的でかつプライドが高い連中が多いことも事実。
Solarisサーバ管理者、*BSD信者など様々な奴がおり、エンジニアはそれぞれ得意不得意分野があり
複雑多岐になっている。
同じエンジニアでもよのなか様々な奴が居る、
同じエンジニアでも非常に複雑多岐な分野にわたって、異なる有利不利、異なるチャンス、
異なるメリットデメリットが存在する。ただただ一言でエンジニアといっても種類は様々だ。
ソフトウェア、ハードウェア、情報科学、情報工学にかかわらず、強電、弱電、機械工学、化学、数学、物理学、
建築、バイオ、心理学、メカトロニクス、宇宙物理学、原子物理学、量子力学、航空宇宙工学、海洋開発など、
エンジニアの種類は数え切れないものさまざまだ。
不要にする技術を開発する人と不要になる人は別人だよ
>>23
> 一般に日本における技術者のステータスって低いよな。
> だから技術者はいつの時代も冷遇されるんだ。
> いい思いしたかったら事務屋になれってことなんだと思う。
> 理科系で成功スル奴はほんの一握りなんだから、
> 自分の子供はより確実な文系にしようと思う。
そんなことをいっているから科学離れが引き起こされる。
海外に行ってみるといい、海外では理系的な人間を必要としている地域が多数ある。
日本ではどこから言われ続けているのかしらないが、環境問題や倫理的な問題から
科学技術の闇の側面を誤解して「科学はもう終わりだ」と叫ぶバカが強い権力を
もってそんなことを日本中に吹聴しているのか、科学離れがより促進されている。
最近の小学生のアンケートでは理科は必要ないと回答するバカが非常に多い。
こいつらが将来大人になったら、なにも生み出されない。科学はますます衰退し、
日本ではますます天才が生まれにくくなる。
アインシュタインも、ホーキングも、それに、アメリカンヒーローも。
科学は悪の側面を引き起こしたから使うべきでないとか、
これ以上科学が進歩する必要がないだとか、アホなことばかりいっている悲観論者が
いるが、そんなバカどもは相手にするな。鵜呑みにするな。そんな奴らに金を喰わせるな。
宗教色が濃いあの連中どもは科学が引き起こした問題は科学では一切解決できないと
勘違いしている。実際にはそうではないことが研究からすでにわかっている。
科学が引き起こした問題も、科学によって解決できるのだ。
ミサイル技術は始めは戦争に使われ、科学の陰の象徴のひとつとされてきたが、
宇宙開発という平和利用に大いに貢献しているではないか。
それをわからず、ただただ科学や、人類そのものを批判するどこかの文系のバカどもには呆れる。
> 一般に日本における技術者のステータスって低いよな。
> だから技術者はいつの時代も冷遇されるんだ。
> いい思いしたかったら事務屋になれってことなんだと思う。
> 理科系で成功スル奴はほんの一握りなんだから、
> 自分の子供はより確実な文系にしようと思う。
そんなことをいっているから科学離れが引き起こされる。
海外に行ってみるといい、海外では理系的な人間を必要としている地域が多数ある。
日本ではどこから言われ続けているのかしらないが、環境問題や倫理的な問題から
科学技術の闇の側面を誤解して「科学はもう終わりだ」と叫ぶバカが強い権力を
もってそんなことを日本中に吹聴しているのか、科学離れがより促進されている。
最近の小学生のアンケートでは理科は必要ないと回答するバカが非常に多い。
こいつらが将来大人になったら、なにも生み出されない。科学はますます衰退し、
日本ではますます天才が生まれにくくなる。
アインシュタインも、ホーキングも、それに、アメリカンヒーローも。
科学は悪の側面を引き起こしたから使うべきでないとか、
これ以上科学が進歩する必要がないだとか、アホなことばかりいっている悲観論者が
いるが、そんなバカどもは相手にするな。鵜呑みにするな。そんな奴らに金を喰わせるな。
宗教色が濃いあの連中どもは科学が引き起こした問題は科学では一切解決できないと
勘違いしている。実際にはそうではないことが研究からすでにわかっている。
科学が引き起こした問題も、科学によって解決できるのだ。
ミサイル技術は始めは戦争に使われ、科学の陰の象徴のひとつとされてきたが、
宇宙開発という平和利用に大いに貢献しているではないか。
それをわからず、ただただ科学や、人類そのものを批判するどこかの文系のバカどもには呆れる。
36 ：仕様書無しさん：2005/10/26(水) 12:31:52
バイオマス技術なんてものは科学が生み出したものだ。科学が環境破壊を
生んだことは確かだが、それと同時に、環境を回復する方法も生んだのだ。
優れた脳みそを持った集団である人類をなめちゃいけない。
昔、ミサイルの弾道計算のために戦争で使われたもの、そう、今俺たちが使っているコンピュータを見てみろ。
それは今平和目的に使われ、だれもが使っている生活必需品でありビジネスでも欠かせないものだ。
インターネットを見てみろ。戦争に備えて研究され作られたものが今ではビジネスでも欠かせないものとなっている。
工学は戦争から生まれた。だが、平和利用も可能だ。
核兵器は、今、人類を滅ぼす悪の象徴とされている。
だが、宇宙から落ちてくる隕石を迎撃し破壊することができれば、
人殺しどころか人類を救う平和の有り難い象徴にも
なりうる可能性をも秘めている！
金持ちはみんな文系
歴史に名を残すような人は月給取りじゃないしな
40 ：仕様書無しさん：2005/10/26(水) 16:16:42
>核兵器は、今、人類を滅ぼす悪の象徴とされている。
>だが、宇宙から落ちてくる隕石を迎撃し破壊
その時地球は核の炎に包まれた！！
>だが、宇宙から落ちてくる隕石を迎撃し破壊
その時地球は核の炎に包まれた！！
> 宇宙から落ちてくる隕石を迎撃し破壊することが
できたとしたらそれは核の力ではなく迎撃の計算と制御機構のおかげだと思います。核でなくてもよい。
できたとしたらそれは核の力ではなく迎撃の計算と制御機構のおかげだと思います。核でなくてもよい。
42 ：仕様書無しさん：2005/10/26(水) 17:20:49
計算できても、タマ無かったらどうするんだよ。
相手を破壊するだけのバワーがないと。
野球のグローブでキャッチ出来ると思ってる？
頭だいじょうぶか？
相手を破壊するだけのバワーがないと。
野球のグローブでキャッチ出来ると思ってる？
頭だいじょうぶか？
アホな経営者・管理職が多い。
頻繁に違う専門分野の仕事をさせていたら、広く浅くなりSEにしかなれない。
技術者は会社の資産だと思っていないから、製品ラインごとに重複して技術者を抱えていて、
その製品ラインを廃止するときに、そこで仕事をしていた技術者を全員切ってしまう。
習得するのに時間のかかる技術を習得したら、それを複数の製品ラインで活かすべきだよね。
ところが、組織というシステムによって、殺してしまう。
頻繁に違う専門分野の仕事をさせていたら、広く浅くなりSEにしかなれない。
技術者は会社の資産だと思っていないから、製品ラインごとに重複して技術者を抱えていて、
その製品ラインを廃止するときに、そこで仕事をしていた技術者を全員切ってしまう。
習得するのに時間のかかる技術を習得したら、それを複数の製品ラインで活かすべきだよね。
ところが、組織というシステムによって、殺してしまう。
例を挙げると、
今度○○の機能を付けようと思うのだけど、そのためには○○の技術が必要だ。
誰か○○を覚える気のある奴いないか? 1ヶ月で覚えて1ヶ月、合計2ヶ月でやってくれ。
作ってしまえばいらない技術だから、ヤッツケでいいぞ、ちゃんと覚える必要ないぞ。
こんなことをマジでやってる。
社内を探せば、○○の技術を既に覚えていて、いくつもの案件で使って習熟していて、
1ヶ月よりも短時間で、しかも格段に手離れよく作れる人がいたりするんだけどねぇ。
広く浅くやると、習得と実装の比率が1:1だとすると、
狭く深くやると、習得と実装の比率が1:10とかになるわけで、
会社としては、そのほうがずっと儲かると思うんだけどねぇ。
今度○○の機能を付けようと思うのだけど、そのためには○○の技術が必要だ。
誰か○○を覚える気のある奴いないか? 1ヶ月で覚えて1ヶ月、合計2ヶ月でやってくれ。
作ってしまえばいらない技術だから、ヤッツケでいいぞ、ちゃんと覚える必要ないぞ。
こんなことをマジでやってる。
社内を探せば、○○の技術を既に覚えていて、いくつもの案件で使って習熟していて、
1ヶ月よりも短時間で、しかも格段に手離れよく作れる人がいたりするんだけどねぇ。
広く浅くやると、習得と実装の比率が1:1だとすると、
狭く深くやると、習得と実装の比率が1:10とかになるわけで、
会社としては、そのほうがずっと儲かると思うんだけどねぇ。
替えが利かない部品は危険
バランスの問題だろ。
プログラムを勉強したのはぜんぜん苦労だとは思わないが、
ちゃんとしたプログラムを書くと「わかりにくい」と言われて
職場でいじめられる。特に C 言語で、K&R(ついでながら、2nd.) で
「こうすると速い」「これが便利」と薦められているコード
（三項演算子とか）を書くと、「直せ」と強要される。
ちゃんとしたプログラムを書くと「わかりにくい」と言われて
職場でいじめられる。特に C 言語で、K&R(ついでながら、2nd.) で
「こうすると速い」「これが便利」と薦められているコード
（三項演算子とか）を書くと、「直せ」と強要される。
三項演算子は使っちゃダメ。
あなたが書いたプログラムは将来、
あなたよりもスキルの低い人間が、
よくわかっていない状態でいじることになる。
だから、スキルの低い人間に合せてコーディングするっきゃない。
サンプルプログラム級にエラー処理なしなしで作って、
とっとと他の人に引き継いで逃げるのが、
この業界でうまくやっていく方法ですよ。
あなたが書いたプログラムは将来、
あなたよりもスキルの低い人間が、
よくわかっていない状態でいじることになる。
だから、スキルの低い人間に合せてコーディングするっきゃない。
サンプルプログラム級にエラー処理なしなしで作って、
とっとと他の人に引き継いで逃げるのが、
この業界でうまくやっていく方法ですよ。
会社のコーディングルールを勝手に破るのはよくないな。
三項演算子、今検索してみた…
いつの間にかこんな分岐方法が出来てたのか…(((( ；゜Д゜)))ガクガクブルブル
いつの間にかこんな分岐方法が出来てたのか…(((( ；゜Д゜)))ガクガクブルブル
三項演算子ってa ? b : cだよな
俺よく使うけどダメなのか
俺よく使うけどダメなのか
>52
貴方がリーマンPGで、「使っちゃだめ」というルールの元で働いてるならNG。
そうでなければセーフ。
ただこーいうモノは必殺技と同じで、乱発のしすぎは美しくないから、
普段は温存して地味で確実な書き方を心がけ、ここぞという場所で
ビシっと使った法が綺麗なコードになると思うな漏れは。
貴方がリーマンPGで、「使っちゃだめ」というルールの元で働いてるならNG。
そうでなければセーフ。
ただこーいうモノは必殺技と同じで、乱発のしすぎは美しくないから、
普段は温存して地味で確実な書き方を心がけ、ここぞという場所で
ビシっと使った法が綺麗なコードになると思うな漏れは。
ライブラリやマクロの中で使うのはいいと思う。
普通のコードで使うと可読性を低めると思う。
コーディング規約があれば、自由はないのだが。
普通のコードで使うと可読性を低めると思う。
コーディング規約があれば、自由はないのだが。
>>48-49
さてさて、合わせるべきスキルの低さにも限度ってものがありまして。
STLは使わない方がよさげ。仮想関数なんてもってのほか。
みんなprintfデバッグしか知らないのでデバッガ対応のコード（assertとか）は書けない、
とかっていやだろう？
さてさて、合わせるべきスキルの低さにも限度ってものがありまして。
STLは使わない方がよさげ。仮想関数なんてもってのほか。
みんなprintfデバッグしか知らないのでデバッガ対応のコード（assertとか）は書けない、
とかっていやだろう？
STLや仮想関数を使ってもいいけど、
後で変更かける人のミスを誘うような下手な使い方をしなきゃいいのよ。
ちょっとSTLは、知らないでいじると大変なことになりそうだな・・・
コメントで注意を書いておけ。
後で変更かける人のミスを誘うような下手な使い方をしなきゃいいのよ。
ちょっとSTLは、知らないでいじると大変なことになりそうだな・・・
コメントで注意を書いておけ。
assertは、マクロでprintfに置き換えれるようにすりゃいい。
アサートするかわりに、printfでエラー吐いて止まればいいんじゃね?
アサートするかわりに、printfでエラー吐いて止まればいいんじゃね?
>>55
コーディングルールなら従うべき。それ以上の理由はない。
コーディングルールなら従うべき。それ以上の理由はない。
デバッガぐらい使えるようになっとけ
60 ：仕様書無しさん：2005/12/04(日) 00:28:19
>>49
> 三項演算子は使っちゃダメ。
>
> あなたが書いたプログラムは将来、
> あなたよりもスキルの低い人間が、
> よくわかっていない状態でいじることになる。
>
> だから、スキルの低い人間に合せてコーディングするっきゃない。
まてまて釣りか？
Javaでは三項演算子は高速化するために重宝するのだが。
そんなに難しくないしシンプルなものだったらコードが読みにくくなることもない。
問題は、コーディングスタイルのほうだ。
こっちのほうが危険。それもコードフォーマッタなどで解決できるが。
Javaなら、CheckstyleやFindbugsで見つかるような警告は
すべて排除するくらい綺麗なコードをかいてもらいたい。
それからロバート・Ｃ・マーティンの「アジャイルソフトウェア開発の奥義」
に載っていることを徹底的に実践するほうが
今後のためだ。そこで初心者がわからないからオブジェクト指向の設計原則を
守らせるようなコードを書くなとか言うべきではない。
会社のコーディングルール自体が古くさく、問題を持っている場合もある、
そのときは会社の悪いルールにただひたすら従うのではなく
問題点を速やかに指摘し改善方法を提案すべきだ。
さもないとソフトウェアクライシス(ソフトウェア危機)はますます促進する。
> 三項演算子は使っちゃダメ。
>
> あなたが書いたプログラムは将来、
> あなたよりもスキルの低い人間が、
> よくわかっていない状態でいじることになる。
>
> だから、スキルの低い人間に合せてコーディングするっきゃない。
まてまて釣りか？
Javaでは三項演算子は高速化するために重宝するのだが。
そんなに難しくないしシンプルなものだったらコードが読みにくくなることもない。
問題は、コーディングスタイルのほうだ。
こっちのほうが危険。それもコードフォーマッタなどで解決できるが。
Javaなら、CheckstyleやFindbugsで見つかるような警告は
すべて排除するくらい綺麗なコードをかいてもらいたい。
それからロバート・Ｃ・マーティンの「アジャイルソフトウェア開発の奥義」
に載っていることを徹底的に実践するほうが
今後のためだ。そこで初心者がわからないからオブジェクト指向の設計原則を
守らせるようなコードを書くなとか言うべきではない。
会社のコーディングルール自体が古くさく、問題を持っている場合もある、
そのときは会社の悪いルールにただひたすら従うのではなく
問題点を速やかに指摘し改善方法を提案すべきだ。
さもないとソフトウェアクライシス(ソフトウェア危機)はますます促進する。
61 ：仕様書無しさん：2005/12/04(日) 00:32:37
62 ：仕様書無しさん：2005/12/04(日) 00:32:57
>>58
> >>55
> コーディングルールなら従うべき。それ以上の理由はない。
アブナイやつだな、お前みたいな奴が組織にいると
汚職事件を犯す大蔵官僚みたいな悪い奴が
組織にはびこるんだよな。
その様はまさに腐敗した古代ローマ帝国の末日そのものだ。
ルールに従えと言っても、ルール自体に問題があるときがある。
法律や憲法を改正できるようにコーディングルールを逐次改善していかなければ
国や組織は荒廃し堕落てゆく。
変なルール、北朝鮮のような社会主義というルールを
徹底的に国民に守らせてしまった結果貧乏になり、飢餓に
苦しむ人々を生み出してしまった北朝鮮政府は非常に問題だ。
あまりにもルールや教本に従いすぎると、お前は原理主義者になってしまうぞ。
そのことをよく覚えておくべきだ。
エクストリームプログラミングには上司に進言する勇気というものがある。
ルールを違反してルールを良い方向に変える勇気がないやつは
プログラマには向いていない。
> >>55
> コーディングルールなら従うべき。それ以上の理由はない。
アブナイやつだな、お前みたいな奴が組織にいると
汚職事件を犯す大蔵官僚みたいな悪い奴が
組織にはびこるんだよな。
その様はまさに腐敗した古代ローマ帝国の末日そのものだ。
ルールに従えと言っても、ルール自体に問題があるときがある。
法律や憲法を改正できるようにコーディングルールを逐次改善していかなければ
国や組織は荒廃し堕落てゆく。
変なルール、北朝鮮のような社会主義というルールを
徹底的に国民に守らせてしまった結果貧乏になり、飢餓に
苦しむ人々を生み出してしまった北朝鮮政府は非常に問題だ。
あまりにもルールや教本に従いすぎると、お前は原理主義者になってしまうぞ。
そのことをよく覚えておくべきだ。
エクストリームプログラミングには上司に進言する勇気というものがある。
ルールを違反してルールを良い方向に変える勇気がないやつは
プログラマには向いていない。
> サンプルプログラム級にエラー処理なしなしで作って、
> とっとと他の人に引き継いで逃げるのが、
> この業界でうまくやっていく方法ですよ。
例外処理をひとつも書かないのか。糞だな。
それをなんども繰り返す奴が沢山増えるとどうなると思う？
そのうちお前のところにも返ってきて自業自得になるぞ。それを考えたことがあるかね？
64 ：仕様書無しさん：2005/12/04(日) 00:34:00
>>20
それは日本だけの話だし。
おまえみたいなことを言う香具師は大抵、文系で
ソフトウェア開発能力が薄く、スキルがないことを
嫉んでいる香具師らばかり。スキルがないから
嘘ついたり誤魔化したりしてプログラマを騙して
なんとかしてこきつかおうとしている。
それは日本だけの話だし。
おまえみたいなことを言う香具師は大抵、文系で
ソフトウェア開発能力が薄く、スキルがないことを
嫉んでいる香具師らばかり。スキルがないから
嘘ついたり誤魔化したりしてプログラマを騙して
なんとかしてこきつかおうとしている。
おまえが美少女だったらその命令を受けてやる。
だがキモ男だったらお前を殺す
だがキモ男だったらお前を殺す
OK5分で書かれた>>60-65を華麗に読み飛ばした
>>62
コーディングルールが要改善なら、
コーディングルールに違反するのではなく、
コーディングルールを改善して、
コーディングルール通りに書くべし。
各人の判断でコーディングルールを反故にしてよいとなると、
いつまでたっても、コーディングルールが改善されずに形骸化が進むよ。
コーディングルールが要改善なら、
コーディングルールに違反するのではなく、
コーディングルールを改善して、
コーディングルール通りに書くべし。
各人の判断でコーディングルールを反故にしてよいとなると、
いつまでたっても、コーディングルールが改善されずに形骸化が進むよ。
>>60
速度上のネックになっているところなら使ってもいいかもね。
それ以外の大半の場所では良くない。
一概に言うとしたら、使ってはいけない、ということにしておき、
速度上のネックになっているのなら特例的に、使ってもいい、ということにすればいい。
速度上のネックになっているところなら使ってもいいかもね。
それ以外の大半の場所では良くない。
一概に言うとしたら、使ってはいけない、ということにしておき、
速度上のネックになっているのなら特例的に、使ってもいい、ということにすればいい。
>>63
同僚の誰しもが書けるようなプログラムを書いているレベルでは、やってはいけない。
面倒な仕事を他人に押しつけ、できる限り最新のものや高度なものに取り組むべし。
メンテナンスもやってはいけない。できる限り、新規のコードを書くようにすべし。
それを繰り返すうちに、同僚たちはあなたのコードのブラッシュアップとメンテで忙殺され、
いわば、あなたのプログラムの清書マシンになる。
そして、あなただけは交換不可能なキーパーソンとなる。
同僚の誰しもが書けるようなプログラムを書いているレベルでは、やってはいけない。
面倒な仕事を他人に押しつけ、できる限り最新のものや高度なものに取り組むべし。
メンテナンスもやってはいけない。できる限り、新規のコードを書くようにすべし。
それを繰り返すうちに、同僚たちはあなたのコードのブラッシュアップとメンテで忙殺され、
いわば、あなたのプログラムの清書マシンになる。
そして、あなただけは交換不可能なキーパーソンとなる。