ソフトウェアを書くことについて私が学んだ７つの教訓

それは進行中だ。ちょっとずつ、そして少しずつ、私はエンジニアからある種の…マネージャーに変身している最中だ。ああ、誤解しないで欲しい。私は今でも毎日コードを書いている。しかし気が付くと分析とディスカッション、ミーティングや電話、より高いレベルの意思決定、チームの編成、そして戦術ではなく戦略の策定に費やす時間が増えている。
もちろん、これは悪いことではない。より高いレベルの決定は、個々のクラスおよび機能の詳細よりもはるかに大きな影響を与えることが多い。チームをより生産的にすることは、自分自身をより生産的なものにするよりも、ずっと高いレバレッジ効果を持っている。しかし、私は自分がコードを書いた日々から、いくばくかの教訓を得てきたものと思いたい。個人的にはそれらが、私のマネージャー業の知恵として転換されることを望んでいる。そして、ここでそのいくつかを共有する図々しさを読者に認めて貰いたいと願う：
1. ルールはない。公案があるだけだ。
例を挙げてみよう：DRY（Don’t Repeat Yourself：同じことを繰り返すな）という奴を考える。これはソフトウェアの基本的なルールとしてとてもよく理解されているため、しばしば意思決定を正当化するために使われる：「XをしたのはDRYの原則に従ったからだ」といった具合だ。それは理に適っている筈だ。そう思うだろう？さて、同じ

リンク元