というのが自分の持論である。

色々な組み合わせがあるが、基本的には、両方に秀でることは出来ない。

片方が大きければ、その分、片方は少ない。なんだかそんな気がしている。

ちなみに自分自身は「記憶力5:思考力5」ぐらいの中庸タイプだと思っている。

システムエンジニアの話

たとえばシステムエンジニアの場合だと、

は有利に働く場合がある。

たとえば、

という対応が出来るのだ。

「覚えておかなくて良い」コードは優れている。 (思考力が優れているのだから、久々に見た「覚えておかなくて良いコード」を理解するのは、なおさら簡単だろう)

すべての弱点を武器に

ちょっと話は逸れるが。僕の場合は、

という弱点がある。

だがこれは、

という長所に置き換えられる。

ものすごく細かい部分では、たった1行の

unless a != b

みたいな書き方も、毎回パッとは理解できないし、理解してもすぐに忘れる。お願いだから、なるべく肯定形で書いてほしいと思う。

if a == b

今書いたこの例でさえも間違っているかもしれないとドキドキしているし、事実間違っているかもしれない。

脳科学的に解明されているかどうか分からないが、理解力というのも決して単一のパラメータではない。

とか、人によってばらつきがあるのだ。

だが、自分が特定の領域での理解力が低いということは、逆に武器にできる。

なぜなら「自分の理解力が低いので、理解しやすい構造を作る」ということが出来るからだ。

これは「理解力が高い人」には出来ない芸当だ。なぜなら「すんなり理解できる人」にはそもそも「理解しづらい部分」がどこか分からないからだ。

(改めてだが「理解力が高い」という文脈は、その対象によって変わる。ある領域では理解力が高い人が、ある領域では低かったりする)

そして「理解しづらいと思った人」が声を挙げて、そこを改善することによって、プログラミングのコードはより良いものにすることが出来るのではないか。

リーダブルコードを思い出せ。

この話はもちろん「理解できないなら、理解を諦めてしまえ」という話ではない。何百回理解しようと努力しても、何百回でも自分が突き当たる「ネックとなる問題」には、何か落とし穴が、そして改善点が隠れているという話だ。

声を挙げてみよう。分かりづらい部分を分かりづらいと言うことは、決して悪いことではない。