他のアドバイス系エッセイをすべて読んだ新人ソフトウェア開発者への助言
(buttondown.email)- キャリア初期には、有名な開発者の助言であってもそのまま従うのではなく、まず自分の状況に合っているかを考えるべきであり、ソフトウェア分野の多くの主張には確定的な根拠がそれほど多くない
- 気に入ったアイデアは自分で試してみてもよいが、同僚の邪魔をしない範囲で試行錯誤することは学習プロセスの一部になる
Debugging: The 9 Rulesは、初心者向けの本が見落としがちなデバッグ能力を扱う、読みやすい入門書として推奨されている- 「正しいやり方」や「ベストプラクティス」は、特定の失敗事例や歴史的経緯から生まれたものが多く、手法そのものと広められ方を区別する必要がある
- ツールの隠れた機能、他部門の仕事、さまざまな種類のプログラミングに早い段階で触れておくと、自分に合ったソフトウェアの仕事を見つけやすくなる
助言を受け入れる姿勢
- 広く読まれている開発者向けの助言は、書き手が優れたプログラマーだからではなく、文章がうまいから広まっている場合も多い
- すべての助言を自動的に拒む必要はないが、自分の状況にどう適用できるかは慎重に考えるべき
- ソフトウェアに関する「客観的真実」という主張は注意して受け止めるべきで、科学的に研究された内容は多くなく、研究結果も概して結論がはっきりしていない
- 「間違ったこと」を学んでしまうのではないかと過度に心配する必要はない
- 誰かのアイデアが気に入ったなら、自分で試してみてもよい
- 同僚を積極的に妨げない限り、後から別のやり方をすべきだったと振り返ることになっても、最終的には学びにつながり得る
- Debugging: The 9 Rules は初心者開発者に薦められる本
- 読みやすく、他の「初心者プログラマー」向けの本がほとんど扱わないデバッグという重要なスキルを取り上げている
- 図書館で借りたり、会社に購入を依頼したりする方法もある
「正しいやり方」とベストプラクティスの限界
- ある時点でプログラミングの「Right Way」を発見し、皆がその方法に従えばこの分野は良くなると確信することがあるかもしれない
- 例としてテスト駆動開発、関数型プログラミング、Lisp、形式手法などが挙げられている
- そうした方法に夢中になること自体を避けるのは難しく、気持ちのよい体験でもあり得るが、自分のアイデンティティを「Right Way Guy」にしないことが重要
- 時間がたつと、どんな方法であってもプログラミングはもどかしく汚いものになり得るし、その方法を使わなくても優れたソフトウェアは作れると学ぶことになる
- 複数の「Right Way」を知るようになると、問題に合わせて組み合わせて使える
- 最初に出会う「Right Way」は、たいていその方法に完全にのめり込んだ人から伝わってくる可能性が高い
- 後になってその人を責めすぎず、実際の手法とその人が宣伝するやり方を混同しないほうがよい
- 多くのアイデアは、純粋な形そのままよりも、他のアイデアと一緒に使うためにある程度の修正が必要になる
- Julia Evansの言うように、「すべてのベストプラクティスの背後には恐怖の物語がある」
- 理解できないベストプラクティスがあるなら、それを生んだ失敗事例を探してみるとよい
- その失敗事例が自分の状況と無関係なら、別の方法を選んでも構わない
- 多くのベストプラクティスや慣例は経路依存的である
- メンターがやっていたから従い、そのメンターも以前のメンターがやっていたから従っていた慣行かもしれない
- 過去の問題を解決するために生まれたやり方が、現在ではあまり関係なくなっている場合もある
- もっともらしい後付けの説明のように聞こえる慣例は、実際にそうである場合もあり、調べれば形成の過程をたどれることがある
実務感覚を広げる方法
- 散歩は考えを整理するのに役立つ習慣として提案されている
- 使っているツールには、たいてい隠れた奥深さがある
- プログラミング言語、Git、JIRAのようなツールをすべて専門家レベルまで習得する必要はない
- ただし、5〜10分ほど時間を使って、さらに何ができるのかを知ることは推奨される
- 会社内で他部門の人と話すと、業務への理解が広がる
- サポート、ビジネスドメイン、営業などと話すことができる
- 時間があり、頼みやすいなら、彼らの仕事に同行してみることも提案されている
- キャリアの初期には、可能なら複数の種類のプログラミングを経験しておくほうがよい
- 必ずしも転職が必要なわけではなく、ほとんどの会社は複数種類のプログラミングを同時に行っている
- Web開発会社なら、フロントエンド、バックエンド、運用、データベース作業などを試せる
- 学習にも役立つが、それ以上に、自分が本当に好きなソフトウェアの仕事を見つけられる可能性を高める
- 最初の仕事がフロントエンドだったときはつらかったが、その後バックエンドに移ってより幸せになったという個人的な事例が含まれている
- ソフトウェア分野は変化し続けるため、フレームワークの流行に振り回されず基礎力に集中せよ、という助言には理由がある
- インターネット、オープンソース、カンファレンスなどにより、ソフトウェア分野の情報は非常に速く広まる
- アイデア共有の障壁が低いため、1人だけが使っている個人プロジェクトでも、多くの人が知っているように見えることがある
- 耳にする技術のかなりの数は、ユーザー基盤が小さく、広く採用されていない可能性がある
- 強い興味があるならアーリーアダプターになってもよいが、そうでないなら数年待って、本当に続くかを見ても構わない
- 誰も未来を予測することはできず、現在もまた予測しがたかった結果である
- できる最善を尽くし、自分の価値観に沿って生き、過程を楽しむ姿勢が必要である
1件のコメント
Hacker Newsのコメント
最近の趣味プロジェクトで、ジュニア1人と、もう少し経験のある開発者1人と一緒に作業したのですが、どちらも**「正しいやり方」への執着型でした
当面は自分たちだけが動かす、300行ほどのDiscordボット + Rustコードに対して、完全なドキュメント化、QA用と「本番運用」用の別VM、systemdデプロイ、いくつかの文字列のためのテンプレートシステム、4つのSQLクエリのためのORMレイヤーまで要求していました
多くても10人くらいが使うプロジェクトで、しかもそれは「0.3」リリース要件の半分にすぎず、今後さらに過剰な設計を計画していたので、そのプロジェクトからは手を引きました
プログラミングを始めた頃の私も数年間そういう人間でしたが、ベストプラクティスやコードスタイルのようなもの以外にも、コンピュータサイエンスにははるかに深い内容があり、結局重要なのは動くコード**なのだと学びました
本質的な問題よりも取るに足らない細部に不釣り合いなほど多くの関心を注ぐという意味で、原発の承認委員会が肝心の原発はさておき、隣の自転車置き場の色ばかり議論するというたとえがあります
この場合も、ユーザー10人規模のプロジェクトでQA/本番VMの分離、systemdデプロイ、いくつかの文字列用のテンプレート、いくつかのSQL用のORMに注力するのは、典型的な些末性の法則のように見えます
こういう部分は特にジュニア開発者にとって理解しやすく議論もしやすいので、より多く口を出しがちになり、肝心の難しいコア機能はおろそかになりがちです
ただし、プロジェクトの意味のある部分をきちんとドキュメント化することは、些細なことへの過度なこだわりではないと思います
systemdユニットを書いたりORMを使ったりすることは、思ったほど時間はかかりませんが、後で誰かが中身を見るときや、別の人が貢献しようとするときにはかなり役立ちます
頭の中にまだ文脈が残っているうちにやっておく方が簡単ですし、プロジェクトが大きくなってからでは、こうした雑用はほとんど処理されません
趣味プロジェクトだからこそ、ちゃんとやってみてツールを学び、満足感を得たかったのかもしれません
序盤に50ドルのルーターを買わなければならない場面があるのですが、ある人物が既存のルーターを直してみようと提案すると、他の人物たちはその文が終わる前くらいに「やってみた」と答えます
互いをあまりによく知っていて、一緒に過ごす時間も多いため、ほとんど思考を読めるレベルだということを示しています
ところが誰かが新しいルーターの購入に「yes」と言うと、別の人物が「ayeが必要だ」と返します
副業の意思決定投票で使うべき単語のルールが非常に厳格だというわけで、互いに文を締めくくれるほど親しいかどうか、50ドルのルーターなのか、副業の収入が取るに足らないものなのかは重要ではありません
ルールはayeを要求しているのです
「正しいやり方」への執着型の一部は、社会的な集合知に蓄積された知識をまねることで成功してきたものの、自分の頭の中で実際に何が起きているのかはよく分かっていない人たちのように思えます
検証済みの方法論を苦労して自分で発見せずに受け継げる利点はありますが、そのやり方が失敗につながる状況を文字どおり理解できないという欠点があります
監督コメンタリーでは、この場面は、一部の人物がルールをあまりに真剣に受け止め、別の一部は十分に真剣に受け止めていないことを示すために意図的に配置したものだと語られています
こうしたカーゴカルト的な慣行を他人に勧める理由も似ているように見えます。従う人が増えれば、その慣行が大惨事として失敗するときに、失敗するのが自分ではない可能性が高くなるからです
最近こういうケースをあまりにも頻繁に見ますし、こういう人たちを賢いジュニアと呼んでいます。経験年数が1年でも20年でも関係ありません
賢いジュニアはデザインパターンもたいてい知っていて、『人月の神話』も読んでいますが、新しい技術・言語・フレームワークを試してみたくて、ピカピカの新しいハンマーを手に、釘に見えるものを探して走り回ります
その結果、よく最適化された古いデータベースがもたらせる力を理解できず、おかしな判断をします
20年の経験の中で、そうしたプロジェクトが5〜10年後、元のチームの半分以上が去った状態でどう終わるかを何度も見てきました。本当に価値のある部分は残しつつ、不要な半分は切り落とします
私たちは、何が何でも楽しもうとする開発者向けの幼稚園を運営しているのではなく、お金を払って安定し、比較的速い成果を期待するビジネスのために働いています
最先端技術や退屈さを避けるために新しいものを試すことは、長期的には直すよりも壊すことの方が多かったです
チーム全体が理解し、習熟できる技術を導入すべきであって、退屈したスーパースター1人だけが知っている技術を持ち込むべきではありません
履歴書に技術項目をたくさん入れたいなら、そういう会社でやればよく、そういう場所にもそれなりの良さはあります
ただ、こういう人たちはいずれにせよ長く留まらないことが多いので、全体としての付加価値も疑わしいです。誰かにとっては退屈でしょうが、私はこれを熟練したやり方と呼んでいます
サイドプロジェクトの目的が、企業に自分のGitHubを見てもらうことなら、なおさらそれらしく見えます
ドキュメント化は非常に重要です。ボットやWebスクレイパーを含む300行未満のかなり単純なプロジェクトがいくつかありますが、ドキュメント化していなかったため、今では実行できません
動かしていたRaspberry Piが壊れ、ヘッドレスの仮想フレームバッファをどう直せばよいのか、検索しても役に立つ結果が出てこない謎のエラーをどうデバッグすればよいのか、途方に暮れています
コンテナ化していたか、少なくとも設定手順をドキュメント化していれば、こうした問題はなかったはずです
良い記事で、もっと多くの人に読んでほしい。
ソフトウェア、とくにデータ管理分野で15年働いて、まさにこれを学んだ。
上座部仏教の背景から学んだ Kesamutti Sutta も大いに役立った。
繰り返し聞いたから、伝統だから、噂だから、経典にあるから、推測や公理やもっともらしい論理だから、長く考えてきた観念への偏りだから、誰かが有能に見えるから、あるいは師の言葉だからといって、そのまま従うなという内容だ。
自分で「これは善であり、非難されることではなく、賢者たちが称賛し、実践すれば利益と幸福につながる」と分かったときに受け入れよ、という助言は、中学生の頃から無神論者になった後も、人生でとても役に立った。
誰かが、より合理主義的な意味に見えるよう翻訳を歪めたという主張もある。
もし本当なら残念だ。Buddha がこういう「悟った」人だったと信じたかったからだ。
https://fakebuddhaquotes.com/do-not-believe-in-anything-simply-because-you-have-heard-it/
「だまされた」とか「間違ったことを学んだ」とあまり心配しなくていい、という部分に共感する。
TDD が流行っていた頃に学んだか？ そうだ。今 TDD を使っているか？ いいえ。それでも TDD は、より良いコードの書き方を教えてくれたか？ そうだ。
仕事では使わなくなった言語も同じだ。すべてのものは何かを教えてくれる。
両側に少しずつ行き過ぎてみなければ、良い中間地点は見つけられない。
すでにコードがあり、それを拡張しようとしているなら、使い方の周辺にテストをいくつか書くのは合理的だ。
まだコードはないが、頭の中に構造があり、先に作ってテストできる部分を切り分けられるなら、その場合も意味がある。
純粋な意味での TDD ではなく、テスト補助開発に近いが、TDD の精神を活用していることになる。
悪いものを学ぶことも、どのアプローチがより良いか悪いかを理解するうえで大きな部分を占める。
TDD 自体が悪いという意味ではないが、過度にこだわると悪くなり得る。
結局、「失敗は学びの道」という通念にも通じている。
こうした指針や原則は一般に知っておくとよいが、人々が宗教のように受け止めると問題になる。
私たちの業界では、イデオローグは本当に厄介だ。
短く、的確で、すぐ腑に落ちる。
良い記事であり助言だ。
結局ハネムーンが終わると、どんな「正しいやり方」を使おうが、プログラミングはもどかしく散らかったものだし、そのやり方に従わなくても優れたソフトウェアは作れるのだと学ぶ。
時間が経つと、さらに何十もの「正しいやり方」を学び、問題に合わせて混ぜて使うようになる。
ただ、ここ数年は多くの開発者が正しいやり方への執着にとらわれ、知識や視野を広げられていないように見える。
もし本当なら悲しいことで、原因はよく分からない。
最近の短くなった集中力のせいで知識を効率よく広げるのが難しくなっているのかもしれないし、今いる場所があまりに居心地よくなったせいかもしれない。
あるいは、特定のフレームワークだけを学ばせる報酬が大きすぎて、内部でどう動いているかについての基礎知識を学ぶインセンティブが乏しいせいかもしれない。
そのため、今の仕事から教訓を学ぶ時間がなく、その教訓が身に届く頃には、すでに去っている可能性が高い。
同時に、新しい流行技術に集中しないでいられる余裕もない。
こうした流れが成長を大きく妨げている。
私の1セントの助言はこれだ。状態は敵だ。可能なあらゆる場所で状態を減らすべきだ。
コード内の状態だけでなく、仕事をするために短期記憶に抱えておかなければならないものの数、覚えておくべきプロジェクトごとの細部まで、すべて含まれる。
状態は敵だ。第一原理から導けるなら、常にそうするようにすべきだ。
このうち一部は、プログラマーだけに向けた助言を超えている。
最初の項目は誰もが噛みしめる価値がある。多くの著者やエッセイストが読まれる理由は、そのテーマの専門家だからではなく、文章がうまいからだ。
散歩もするべきだ。
いろいろな種類の仕事を試し、会社内の別の職種も学んでみるとよい。
とくに大きな会社では、自分のやっていることがどこかで再び修正されたり、迂回処理されなければならない仕事である可能性があり、自分が変えれば皆がもっと楽になるかもしれない。
最初の項目は、YouTube のような動画共有サービスで学ぶ内容を疑うべき理由でもある。
信頼できそうに話し、専門的にアイデアを提示すると、そのアイデアに欠陥があっても人々は真剣に受け止める。
一部の「エッセイスト」が実質的には Wikipedia の記事や Reddit の投稿を読み上げている程度だったと明らかになった世の中では、表現のもっともらしさと正確さを切り分けて見ようとする姿勢が必要だ。
10番目の項目もさらに広げたい。関係する人たちと話すと、ソフトウェアや開発作業が解こうとしている問題が何なのかがよりよく見え、自分では見えていなかった痛点も見つけられる。
ごく一部の例外を除けば、ソフトウェアはそれ自体のために書くものではなく、問題を解くために書くものだ。
インターネットや学習過程のどこかで「正しい」答えを読み、それが実際に真かどうかを考えないまま、もっともらしく繰り返すことができる。
記事で推薦されていたデバッグ本がとても好きで、何冊も買って配った。
友人、インターン、データサイエンティスト、さらには役員にも渡し、読んだ人は皆感謝してくれた。
大きな技術システムの問題を解くための、優れたシンプルな技法がいくつか入っていて、ほとんど誰にでも役に立つ。
読みやすく面白く、ともすれば無味乾燥になりがちな助言に色合いと文脈を加えてくれる「戦記」も多い。
https://debuggingrules.com/
「人々が私の言うことを聞くのは、私が優れたプログラマーだからではなく、優れた書き手だからだ」という言葉は、優れた書き手の内容を読むときには警戒すべきだという意味にとどまらず、私たちの仕事への向き合い方にも当てはまる。
文章がうまければ、他人と接する能力もおおむね向上する。
ソフトウェア開発者にとって、文章を書くこととコミュニケーションは中核的な仕事である。
初心者なら、経験した困難、実験、思考の過程を文章にしてみることを勧める。
可能ならエッセイも書くべきだ。キャリアの後半で本当に役立つスキルになる。
初心者にきちんと説明するのが難しい言葉が一つある。「あなたの仕事はコードを書くことではない」
私たちは問題を解くための道具としてコードを使う。
コードは目標を達成する手段であって、目標そのものではない。
コードそのもののためにコーディングすると、誤った結果を生むことになる。
問題解決に集中すべきであり、自分のコードがどんな問題を解いているのかはっきりしないなら、コーディングをやめてまずそれを突き止めるべきだ。
会社によってはメールかもしれない。
質問に答え、協業し、チームや組織の方向性に影響を与えることは仕事のように感じられるが、コミュニケーションもコードと同じく、有用なものを作るための道具であって、それ自体が有用なわけではない。
たいていのコードは、たとえ「コードのためのコード」として書かれたコードであっても、何らかの問題は解決していると考える。
多くのプログラマーも、少なくとも無意識にはそれを分かっているので、そうしたコードを書く。
本当の問題は、他の人たち、たとえばスーツを着たビジネス側の人々が、そのコードに別の問題を解いてほしいと望んでいることにある。
ただし、そのコードは正しいコードでなければならない。
より一般的には「ソフトウェアシステムを適用してビジネス上の問題を解く」と説明する。
ジュニアにこう伝えると、ビジネス要件に集中するようになり、MBAやマネージャー、PMの言葉を批判的に判断して、正しいことに取り組める。
しかし、VCに売り込めるソフトウェアがあること自体に価値がある。
だから時には、本当にコードを書くためにお金をもらっているのだ。