ソフトウェア業界で45年間働いて学んだこと
(bti360.com)パンチカードからクラウドまで45年間働いてきたエンジニアが、引退にあたって残した教訓
1. 知識の呪いに気をつける
- 何かを知ってしまうと、それを知らないとはどういうことかを想像することすらできなくなる
- これが多くの誤解と非効率の原因になる
- 複雑なものに慣れた賢い人ほど、その傾向が強い
- 知識の呪いを警戒しなければ、コードからコミュニケーションに至るまで、あらゆるものが理解しにくくなる
- 聞き手を理解しようと努め、最初に学んだときがどんなものだったかを想像すること
2. 基礎に集中する
技術は絶えず変化するが、ソフトウェア開発の基礎はそうしたトレンドを超えて有効である
長く通用する6つの基礎
→ チームワーク : 優れたチームが優れたソフトウェアを作る。チームワークを当たり前と思わないこと
→ 信頼 : チームは信頼の速度で動く。一緒に働きたいと思われる信頼できる人になろう
→ コミュニケーション : 正直かつ積極的にコミュニケーションする。知識の呪いを警戒すること
→ 合意形成 : チーム全体で一緒に取り組む時間を持つ。議論と意見の相違を通じて最良の解決策を探そう
→ テスト自動化 : 十分にテストされたコードは、チームが自信を持って素早く動けるようにする
→ クリーンで理解しやすく、探索しやすいコードと設計 : コードを引き継ぐ次のエンジニアを顧客だと考えること。後任者が読んで保守するのに困らないコードを書こう
3. シンプルさ
- 複雑さとの戦いに終わりはない
- 解決策は可能な限りシンプルであるべき
- 自分のコードを保守する次の人が、自分ほど賢くないかもしれないと想定しよう
- より少ない技術でできるなら、そうすること
"デザイナーにとって完璧とは、付け加えるものがなくなったときではなく、取り除くものがなくなったときである。" - サン=テグジュペリ
4. まず理解する
- スティーブン・コヴィーの『7つの習慣』の一つは「まず理解し、次に理解される」
→ この言葉は、他のどんな助言よりも、より良い聞き手でありチームメイトになる助けになった - 他の人に影響を与え、効果的に協力したいなら、まず相手を理解しなければならない
- 自分の考えを伝える前に、相手の感情やアイデア、視点を理解できるよう積極的に耳を傾けよう
5. Lock-in に注意する
- ソフトウェアの作り方に革新をもたらす次世代の生産性ツールは、いつの時代にも現れる
→ CASE、COTS、ERP、Ruby など - それらは、自分たちの開発哲学を全面的に採用すればコストと時間を節約できると主張するが、初期コストやそれによって生じる制約は明確ではない
- ロックインは主にソフトウェアベンダーに起きていたが、今ではフレームワークにも起きている
- ロックインは変更にかなりのコストを発生させる
- 賢く選ぼう。新しいものが常に良いとは限らない
6. 正直であり、役割に合っていないときはそれを認める
- キャリアのどこかの時点で、自分に向いていない役割を担うことがある
- ミスマッチは人格の欠陥ではないが、無視してはいけない問題である
- このジレンマの解決策は一つとは限らない
→ 自分が変化するか
→ 役割が変化するか - 重要なのは、「何が起きているのか、そしてここから抜け出すにはどうすべきか」についての自己認識を持つこと
7件のコメント
これまでにも良い助言がたくさん上がっていましたが、もう一つだけ付け加えるなら、この文章も後ろに添えておきたいですね。
https://ja.news.hada.io/topic?id=2060
もちろんこの文章もものすごく良いのですが。上の文章はもう少し汎用的な側面から(ソフトウェアに限らず)振り返ることの多い助言だったように思います。こういうものを集めておいて、必要なときに取り出して読めると本当に良さそうです。
わあ〜 技術と人についての洞察が込められた言葉ですね。素晴らしいです〜!
結局、仕事はコンピューターではなく人がするのだという先輩の言葉を思い出しますね
良い文章をありがとうございます
入門者として心に刻みます!
良い文章の共有ありがとうございます。じっくり読んで噛みしめたい内容がいくつもありますね。
わあ、内容がとても素晴らしいですね……ありがとうございます。
貴重な文章をありがとうございます!!