コラボレーティブコーディングが究極のキャリアハックである理由

プログラミングの最初の一歩を踏み出すことは、外国語を習得するようなものです。 最初は、構文は意味がなく、語彙はなじみがなく、すべてが見た目も音も理解できません。 私が始めたときの私のような人なら、流暢さは不可能だと感じます。

そうではないと約束します。 私がコーディングを始めたとき、学習曲線は私を襲いました—大変でした。 私は、現在インポスター症候群として認識している自己不信感を食い止めようとしながら、10か月間自分自身に基本を教えました。 初心者向けのミートアップに参加し始めて初めて、コーディングが協力して驚くべき可能性を開くことに気づきました。 練習するのに適切な人々のコミュニティが必要です。

私にとって、そのコミュニティは創設者とコーダーでした。これは、私のキャリアをコピーライティングからコーディングに切り替えるのに役立った無料のJavaScriptブートキャンプです。 コースを修了してから1年も経たない今でも、ソフトウェアの開発にお金を払っているなんて信じられません。

コラボレーティブコーディングとは、問題に取り組み、解決策を一緒に発見することです。 これには、ペアプログラミングのような技術が含まれます。これは、いくつかの技術会社が面接プロセス中にスクリーニングするのに十分真剣に取り組んでいます。 また、自宅で一人でコーディングしているだけでは習得が難しい便利なスキルも身に付けます。

テクノロジー業界を始めたばかりでも、数年の経験がある場合でも、コラボレーションコーディングの有用性は止まることはありません。 この記事では、これらの常緑のスキルがソフトウェア開発で長く成功するキャリアをどのように身に付けているかを見ていきます。

完璧なペアリング

ペアプログラミングの私の最初の経験は、Coding ForEveryoneと呼ばれる初心者向けのミートアップでした。 仕組みは次のとおりです。同じラップトップでJavaScriptの課題を一緒に解決するために、多くの場合、会ったことのない人とペアになります。 一人が「ナビゲーター」の役割を引き受け、書かれるべきだと思うコードを提案します。 もう1人の「運転手」は、ラップトップで提案を入力し、不明な点がある場合はいつでも質問します。 2時間のセッションが終了するまで、これを継続し、役割を頻繁に交換します。

理論的には、それは単純でした。 実際には、それほど多くはありません。

入力中に画面を見ているのを知らない人がいるのは非常に気が散り、役割を入れ替えるときにコントロールを引き継ぐのは気が進まなかった。 ナビゲートはさらに難しいことがわかりました。 アイデアが最初にパートナーの手を経由せずに頭からコンピューターに入ることができない場合、あなたが言うすべての言葉が重要です。 それは、私たちが単に慣れていないという、私たち両方からのある程度のコミュニケーションを要求しました、そして私たちが別々に働くために分割するならば、私たちは両方とももっと学ぶだろうと確信しました。

幸いなことに、私たちはそれに固執しました。 翌週またミートアップに行きました。 それ以来、何十人もの開発者とペアを組むのに何百時間も費やし、当初考えていた以上のことを学びました。

ペアプログラミングは、信じられないほど速く学ぶ方法です。 この方法の魔法は、最初の厄介さを乗り越えれば、すぐに結果が得られることです。 株式市場のバブルのような一部のフィードバックループは、修正を行うのに数時間、数日、さらには数か月かかる場合があります。 ペアプログラミングには、数秒ではなくても数分かかります。 セミコロンを置き忘れると、2組の目が1組よりも早く間違いを見つけることができます。 不正なエラーメッセージに関する手がかりをStackOverflowで検索する必要がありますか？ あなたとあなたのパートナーはそれぞれ異なるスレッドを読むことができ、答えを見つけるのにかかる時間を半分にします。

さらに難しい問題の場合、暴徒のプログラミングはさらにステップアップすることができます。 この方法では、チームの部門の枠を超えたセクションが同じコンピューター画面の周りに集まり、1人の人が入力している間にリアルタイムでソリューションをブレインストーミングする必要があります。

「すべての優秀な頭脳が、同じコンピューターで、同じスペースで、同じことを同時に行っています。」

— Woody Zuill、アジャイルコーチおよび暴徒プログラミングトレーナー

非効率的な作業方法のように思えるかもしれませんが、Woody Zuillなどの暴徒プログラミングの支持者は、コードが書かれているときに誰もがリアルタイムでコードをレビューするため、個々のコードレビューの必要性を排除することで実際に時間を節約できると言います。 生産性はさておき、モビングはコードについてだけでなく、他の人がどのように問題に取り組むかについて学ぶための素晴らしい方法だと思います。 ペアプログラミングがあなたがさらされている視点の数を2倍にする場合、暴徒プログラミングはさらに多くの洞察をもたらします。

それは、ペアリング、または実際にモブリングが単純な航海であると言っているのではありません。 私が最初に苦労したことは、自分のエゴを片側に置いて、愚かに聞こえるかもしれないと思った質問をすることでした。 このような状況では、特にあなたが両方とも始めたばかりの場合は、パートナーが同じ考えを持っている可能性があることを覚えておくとよいでしょう。

おそらく職場で、より年長の誰かとペアを組んでいることに気付いた場合は、恐れずに彼らの頭脳を選び、あなたの探究心で彼らを感動させてください。 あなたより少し先にいる人でさえ、もっと年上の人には起こらないことを考えるかもしれません。 私のお気に入りのペアプログラマーの中には、私よりも数か月しか経験がない人もいますが、彼らは私が犯そうとしている間違いと、私を正しい方向に導く方法を常に正確に知っているようです。 これらの開発者がばかげた質問のようなものはないと言うとき、彼らは本当にそれを意味します。 最高のペアプログラマーは、幻想的に見えたり、愚かに見えることを恐れたりすることなく、自由に話します。

ペアプログラミングには練習が必要ですが、完成させる価値はあります。 調査によると、問題を解決するためにペアを組むプログラマーは、自信を持って生産的になり、仕事に従事する傾向があります。 次の仕事を探している場合でも、新人研修をしている場合でも、ペアリングは気になります。

リソースと参考資料

• 「ペアプログラミングの役割」、Jordan Poulton、GitHub
• 「Googleを巨大にした友情」、ニューヨーカーのジェームズ・ソマーズ
• 「MobProgramming：A Whole Team Approach」、Woody Zuill、YouTube

エンジニアリングの共感

私がJavaScriptを学び始めたとき、私のコードは寝室の床によく似ていました。それを片付けるしかないまで、コードをどんどん乱雑にしていきました。 私のウェブブラウザがそれを理解できる限り、私はそれがどのように見えるかを気にしませんでした。

他の人のコードをレビューし始めて初めて、自分のコードをレビューしている人にもっと共感を示す必要があることに気づきました。

共感は、開発者の武器の中で最も過小評価されているツールかもしれません。 これが、IDEOがユーザーリサーチをデザインプロセスの中心に据え、Etsyがデザイナーやプロダクトマネージャーにエンジニアリングローテーションを依頼する理由です。 自分の仕事が他の人にどのような影響を与えるかを見る機会があると、共感が生まれます。 コラボレーティブコーディングがそれを構築するための素晴らしい方法であることは不思議ではありません。

ピアコードレビュー—お互いのコードに間違いがないかチェックする行為—は、共感を行使するように私たちに求めています。 レビューアとして、誰かがあなたが批評しようとしているコードを書くためにかなりの努力をしていることを認識することが重要です。 そのため、判断を暗示したり、作業を簡単にしたりする可能性のあるフレーズの使用は避けてください。 彼らのコードを参照するとき、あなたは彼らにあなたが質問している特定の関数と行を示し、彼らがそれをリファクタリングする方法を提案したいと思います。 学習リソースを共有することは、ソリューションをスプーンで与えるよりも役立つ場合があります。 コードレビューから受け取った最も有用なフィードバックのいくつかは、教育記事、ビデオ、さらにはポッドキャストの推奨事項の形で提供されています。

コードに適したドキュメントを作成することも大いに役立ちます。 明確なインストール手順でreadmeを作成するのと同じくらい簡単な行為は、コードを操作する必要がある人に共感を示します。 GitHubの創設者であるTomPreston-Wernerは、開発へのreadmeファーストのアプローチを提唱しています。

「間違った仕様を完全に実装することは無意味です。 同じ原則で、ドキュメントのない美しく細工されたライブラリも、ほとんど価値がありません。 ソフトウェアが間違った問題を解決したり、誰もそれを使用する方法を理解できない場合は、非常に悪いことが起こっています。」

— Tom Preston-Werner、GitHub創設者

また、ドキュメントをオンボーディングの成功に欠かせないものとして扱っている技術創設者とも話をしました。 あるCTOは、ジュニア開発者がチームに参加してから6か月以内に生産性のレベルに到達するのに苦労している場合、コードベースが十分に文書化されていないことを示していると述べました。 作成した複雑な関数に説明コメントを追加するのに数秒しかかかりませんが、チームに参加する次の人の労力を節約できます。

リソースと参考資料

• 「共感とプルリクエストについて」、Slack Engineering、Medium
• 「Readme主導の開発」、GitHubのTom Preston-Werner
• 「Googleが完璧なチームを構築するための探求から学んだこと」、ニューヨークタイムズマガジンのチャールズデュヒッグ

アジャイルアチーブメント

CGI映画の制作に費やされる数百万の工数から、高額なビデオゲームのリリースに至るまでの激しい開発クランチまで、卓越した技術的成果には、驚異的な量の努力が必要です。 現在の雇用主のコードベースを初めて見たとき、私はそのすべての巨大さに悩まされていました。 一体どうやってこれを作ったの？

答えは、適切なコラボレーションフレームワークがあれば、誰もが誰よりもはるかに多くを構築できるということです。 共同コーディングを奨励する企業では、ソフトウェアは孤独な天才の努力から生まれたものではありません。 代わりに、素晴らしいチームが素晴らしい仕事をするのを助ける一緒に働く方法があります。 Founders and Codersの開発者は、「アジャイル」と呼ばれる一般的なソフトウェア開発方法論を実践しており、私の経験では、「機能」を部門横断的な開発チームに配置しています。

本全体がアジャイルについて書かれていますが、ここにコアコンセプトの要約があります：

• 製品開発チームは、大きな作業を「ユーザーストーリー」と呼ばれる小さな単位に分割し、優先順位を付けて、「スプリント」と呼ばれる2週間のサイクルで配信します。
• プロジェクトが継続している限り、サイクルが繰り返され、新しい製品要件が将来のスプリントのタスクのバックログに送られます。
• チームは毎日スタンドアップミーティングを開催して、進捗状況について話し合い、障害に対処します。
• このプロセスは段階的かつ反復的です。ソフトウェアは断片的に構築および提供され、連続するスプリントで洗練されます。

ソロの趣味のプロジェクトがしばしば「フィーチャークリープ」に屈する慢性的ないじくり回しとして、私は誰も使用しないものを作るのに時間を無駄にすることがいかに簡単かを知っています。 チーム全体がユーザーが実際に気にかけている機能の提供に集中できるように、アジャイルがユーザーストーリーに優先順位を付けるように強制する方法が大好きです。 作業を終えた後も生き続ける製品やサービスを構築するという共通の目標に全員が団結していることを知ることは、やる気を起こさせます。

タスクを小さなユーザーストーリーに分割することも、タイムボックスペアプログラミングセッションに最適な方法です。 ゾーンの奥深くにいても、重要な機能の作業を終えることは、デスクから離れて休憩することを忘れないでください。 アジャイルは、他の方法では欠けている可能性があるコラボレーションコーディングに構造を提供します。

一方、毎日のスタンドアップは、あなたを妨げていることについて話す自由を与え、スプリントの回顧は、重要な勝利を共有し、チームがどこを改善できるかを特定するためのスペースを提供します。 これらの儀式は、コラボレーションと説明責任の感覚を育み、私たちが自分たちでできるよりも多くを一緒に学ぶのに役立ちます。

これらのアジャイル原則をすべて実践することは、特にチーム内の誰もこの作業方法に慣れていない場合、困難な場合があります。 ファウンダーズアンドコーダーズでは、ほとんどの学生が毎日立ち上がる習慣を身につけるのにしばらく時間がかかります。 ただし、18週間のプロジェクトベースの練習の後、プロセスとコミュニケーションスキルが大幅に向上することがわかります。 最初のクライアントの仕事を引き受けるまでに、チームでフルスタックWebアプリを構築する方法のはるかに明確なメンタルモデルを形成しました。

アジャイルを学ぶ最良の方法は、他の人と一緒に面白いプロジェクトを構築することです。 ハッカソンに参加することは、潜在的な協力者とつながるための優れた方法です。 多くのオープンソースプロジェクトは、かんばんプロジェクトボードを公開しているため、さまざまな寄稿者が取り組んでいるGitHubの問題を確認できます。 初心者からのいくつかの歓迎された貢献、そしてあなたはしばしばあなた自身を未解決の問題に割り当ててプルリクエストを出し始めることができます。

ほとんどのテクノロジー企業は何らかの形のアジャイルに加入しているため、雇用主が面接でそれについて質問することは珍しくありません。 あなたが経験したことは、アジャイルを念頭に置いて、共同でコーディングしたことのない他の応募者とは一線を画すことができます。

リソースと参考資料

• 「アジャイルとは」、フォーブスのスティーブ・デニング
• 「アジャイルを受け入れる」、ダレル・K・リグビー、ジェフ・サザーランド、竹内弘高、ハーバード・ビジネス・レビュー
• 「素晴らしいファーストプルリクエストの機会」、Shmavon Gazanchyan、Deloitte Digital

リモートコラボレーションコーディングツールの推奨事項

過去数年間で、リモート作業ツールは、ギャツビーやザピアのような著名な企業が「リモートファースト」になるまでに進歩しました。 これがトレンドになるかどうかはまだわかりませんが、リモート開発チームがここにとどまっていると言っても過言ではありません。

その精神で、あなたとあなたのチームが遠くから共同でコーディングするのを助けることができるいくつかのツールがあります：

この記事を読むことから1つ離れるとしたら、チームプレーヤーが個々の寄稿者よりも勝っていることを望んでいます。 隔週で習得するためのホットな新しいフレームワークがあるように思われる分野では、私たちの技術スキルは、私たちのソフトスキルがそうではない方法で老化します。 結果として、他の人とうまく連携できる開発者は、常に自分の能力が求められていることに気付くでしょう。 コラボレーティブコーディングは、学習するための効果的な方法ではありません。 それは、誰もが十分な練習と忍耐をもって開発できる、求められているスキルセットです。