DevSkiller TalentBoostのロゴDevSkiller TalentScoreのロゴDevSkillerのロゴタレントブーストのロゴタレントスコアのロゴ

ジョン・スキートとの対話。プログラミング界のチャック・ノリス、Yellow Duck Podcastにて

公開されました。 最終更新日

Jon Skeetのコードがコンパイルに失敗したとき、コンパイラが 謝罪?ジョンがGoogleで検索しても、"I'll be right back "しか出てこないのはどうなの? ソースは スタックオーバーフロー

ご存知ない方もいらっしゃるかもしれませんが、Jon Skeetはイギリス・ロンドンにあるGoogleのシニア・ソフトウェア・エンジニアです。彼に関するいくつかの荒唐無稽な主張はまだ検証する必要がありますが、間違いなく事実なのは、Stack Overflowのユーザーで1,000,000以上の評価を得ているのは彼だけだということです。

1998年以来、この男は34,000以上の回答をサイトに投稿し、230,000,000以上のビューを生み出してきました。さて、ありとあらゆる質問に答えてきた彼に、あなたは何を尋ねますか?

ジョン・スキートとの会話を聞いてみましょう。

Marcin Kraszewskiは、Jonに座って彼に新しいことを尋ねました。その結果、他では聞けないような質問も含め、まだまだたくさんの答えが返ってきました。

ジョンがソフトウェア開発を始めるきっかけとなったコンピューターゲームの製作についての話を聞いたことがありますか?ジョンがエンジニアとして解決を任された最も困難な問題については?

今回の対談では、これらの内容に加えて、過去10年間にソフトウェア業界で起きた最大の変化、Stack Overflow以前に開発者が使っていたもの、JonがStack Overflowに貢献する期間、C#とJavaの比較、Jonが好きなカンファレンスなどを紹介しています。

ソフトウェア業界で最も有名な人物の一人が歩んだ個人的な旅を気軽に体験できる、一生に一度のチャンスです。

Jonはこちらでフォローできます。

その前に、Yellow Duck PodcastでのJonとの会話をお聞きください。

以下に、会話の内容を書き起こしたものを掲載します。

MARCIN:皆さん、ようこそYellow Duck Podcastへ!今日は特別なゲストをお迎えしています。Jon Skeetさんにお話を伺います。もしJon Skeetさんをご存知なければ、彼はStack Overflowのトップコントリビューターの一人であり、Stack Overflowのトップコントリビューターかもしれません。基本的にはソフトウェア開発や技術に関する質問だけでなく、Stack Exchangeの親サイトのようなもので、即興コメディから科学、天文学まで何でも質問に答えてくれるウェブサイトなんです。それでは、Jonさん、ようこそ。

JON:どうもありがとうございました。ここに来れてよかった。

MARCIN:イエローダック・ポッドキャストにご参加いただき、ありがとうございます。皆さんにお聞きしたいことがたくさんあります。まず最初に、私が気になっている一番の質問に答えたいと思っています。世界的に有名なStackOverflowでのあなたの活動を少し調べてみましたが、とても充実していました。私が得た情報によると、あなたは2008年9月26日の12時11分にStack Overflowで最初の質問に答えています。その最初の回答にまつわる状況を教えてください。また、どのようにして回答したのかを教えてください。どうやってStack Overflowを使い始めたのか。どうやってその回答を得たのか。どうやってその答えを出すようになったのか。どこから始まったのかを知ることができます。

JON:だから、ある程度はナルシズムの練習になっていました。Stack Overflowのことを初めて知ったのは、Sara Chipのブログでした。彼女は 2008 年に C# の初版を徹底的にレビューしていて、それはとても昔のことのように思えるのですが、私はそのレビューを読み、さらに彼女の他のブログ記事を読んでみると Stack Overflow のことが書かれていたのです。そこで、Stack Overflowで質問に答えてみようと思ったのです。特にC#に関する質問があるかどうかを詳しく調べてみたところ、あちこちで言及されていましたが、C#に関する質問があったので、これには答えられると思い、答えてみようと思い、そこからすべてが始まりました。私はそれまでの10年間、C#とJava Newsgroupsの両方で多くのニュースグループを書いていたので、これはそれらのニュースグループを進化させるための1つのステップだと思いました。私はこれまで、HTMLベースのフォーラムソフトウェアが好きではありませんでした。様々な理由がありますが、私にとってニュースグループほど便利なものはありませんでしたが、Stack Overflowはそれを完全に変えてしまいました。

MARCIN:私たちは、あなたの貢献にとても感謝しています。あなたが答えてくれた質問は約35,000件を超え、コミュニティへの素晴らしい貢献となっています。もちろん、みんな感謝しています。そして、あなたがある意味では一般ユーザーとしてStack Overflowのサイトを知り、質問に答えようと思ったところからスタートしたというのは、とても興味深いことだと思います。Stack Overflowに限ったことではなく、一般的なことですが。情熱を持ってたくさんの質問に答えようと思ったのはいつですか?

JONC#が登場するずっと前から、ニュースグループでJavaの質問に答えたり、Stack Overflowとはあまり関係のない議論に参加したりしていましたが、Javaのニュースグループには何度も投稿していました。これは純粋な利他主義ではありませんが、人を助けることはプログラマーとしての自分を向上させ、ソフトウェアエンジニアリングにおいて非常に重要であると思われるコミュニケーターとしての自分を確実に向上させることができるからです。悪い質問をする人の問題点は、自分に役立つだけでなく、後から来る人にも役立つ質問をするにはどうしたらいいかを考えずに、目先のニーズだけを考えてしまうことだと思います。そういった観点からスタートすれば、Stack Overflowのコミュニティはそのように構築されていますし、良い質問がもたらすインプレッションの数は膨大で、世界中のプログラマーのコミュニティを助けることができるのですから、素晴らしいことだと思います。

MARCIN:そうですね。これは素晴らしいアイデアで、本当に必要とされていたものだったと思います。人々は自分の知識を共有する準備ができていて、Stack ExchangeやStack Overflowが作られたのは、おっしゃるように知識を共有する方法は他にもあったのですが、ちょうどその時でした。でも、質問に答えてもらいたいと思っているユーザーにとっては、Stack Overflowが一番親しみやすいのではないでしょうか。非常に効果的な方法ですし、少なくともローカルのフォロワーにとっては、非常によく管理されていると思います。

JON: そうですね。モデレーションの程度は、多くのユーザーにとって痛いところですが、質問をしようとしても、質問の仕方が悪かったり、十分な詳細が書かれていなかったり、あるいはあまりにも詳細に書かれていたりします。私は、モデレーションは、サイトの質を維持し、できる限り有益なものにしようとする、このサイトの優れた点の1つだと感じていますが、これは間違いなく痛いところで、サイトの目標を伝えて、皆が同じ方向に向かっていけるようにするという点で、やるべきことがあると思います。誰もがというわけではありません。確かに、意図的に悪い質問をしたり、面白半分に悪意のあるモデレートをしたりする人は少なからずいるでしょうね。しかし、私はほとんどの人が嫌な人ではないと思っています。彼らは親切で、自分の時間を割いてくれていて、質の高いサイトを望んでいるのです。

そして、全員が一致団結することができれば、誰もがより良い体験をすることができるのではないでしょうか。というのも、もしあなたが何か問題に直面したとき、Stack Overflowに登録したり質問したりしたことがなければ、最初に感じるのは、「こういう質問をするべきだ」「こういうアプローチをするべきだ」というテキストの壁を見て、「どうでもいいや、今すぐ質問したい」と思ってしまうでしょう。しかし、実際には5分、10分、30分と時間をかけてサイトを閲覧し、さまざまなヘルプリソースを見てみると、「質問をする人を助けるために、私はこのような質問を探しています」という非常に長いブログ記事を書いているのですが、フラストレーションが溜まり、そのようなことをすべて飛ばして質問してしまうのも理解できます。今、私の質問をさせてください。もし、人々が与えられたヘルプを読んでいないのであれば、そのヘルプを改善しても、読んでいないという事実を克服することはできません。ですから、これは難しいことです。

MARCIN:Stack Overflowで興味深いのは、Stack Overflowの全データが入手可能だということです。データセット全体をダウンロードできるようになっていて、それが重要だと思っています。

JON: その通りです。初日からそれを目標にしていました。

MARCIN:スタックオーバーフローが人気を維持しているのは、それが重要な要素だと考えているのですね。

JON: わからないけど、確かにそれは機能ですね。たとえば、Stack Overflowの質問はすべてGoogle BigQueryに取り込まれていて、Stack Overflowのあらゆるデータに対してクエリを実行できるようになっています。データ分析ツールも用意されているので、Stackの質問を使ったあらゆる種類のデータマイニングが可能で、様々なデータサイエンティストがそれを実現しています。そういう意味では非常にクールですね。また、Stack Overflowはあなたの投稿を所有していないという信頼感もあります。しかし、それがどの程度重要なのかはわかりません。誰に聞くかによって重要度は変わると思いますが、データサイエンスのコミュニティにとっては重要です。私は特にそのコミュニティのメンバーではありませんが、これは本当に宝の山だったのではないかと思います。

MARCIN:Stack Overflowを使って機械学習アルゴリズムを学習させて、実際にソフトウェアを書いたり、少なくともソフトウェアをデバッグしたりするようなプロジェクトを聞いたことがあります。例えばStack Overflowでは、本当に似たような質問や、ほとんど同じ質問だけどそうではないものがたくさんありますよね。近い将来、機械学習か何かを使って、コンテンツの重複やそれに近いものを減らすような解決策はあるのでしょうか?

JON:そうですね、Stack Overflowでは似たような質問を探して提案してくれるのですが、質問をしている最中に「Have you looked at these things.これらは似ていると思いますよ」と。また、質問をした後でもです。重複している可能性のある質問や関連する質問は、右側のリストに表示されます。特定のタグにゴールドバッジが付いていれば、デュープハンマーと呼ばれる方法で簡単に質問を閉じることができます。重複している質問があれば、すぐに解決することができます。さらに効率化できるかどうか...難しいことですが、どんな機械学習でも100%の精度を保つことはできないので、人々が質問するのを妨げたくはありません。重複しているのではないかと強く疑われる場合でもです。そのためには、「本当に本当に大丈夫ですか?あなたは本当にこれらすべてのことを見てきたのですか?重複しているかどうかを判断するのに十分な情報や適切な情報を提供せずに質問してくる人たちよりも、重複しているという側面の方が大きいです。私はそれを期待しています。Stack Overflowでは、「あなたのコードはどのようになっていますか」「あなたが使っている言語は何ですか」という質問をするためのウィザードを何度か繰り返してきました。問題を実証する短くて完全な例を考えたか?そういうことです。何が機能するのかははっきりしませんが、Stack Overflowは基本的に良い質問がされることに依存しているので、チームは質問の経験を改善しようと懸命に取り組んでいます。

MARCIN:確かに、技術がどれだけ進歩していても、常に疑問はつきまとうものだと思います。何が主な理由なのか。C#についても、常に新しい質問が出てくるという事実を後押ししているものは何なのでしょうか?C#については、私が言ったように、あなたが35,000件の回答をしていますし、他の様々なトピックについても回答していますが、まだまだあります。これは、ソフトウェアエンジニアリングの本質というか、すべてを抽象化することはできないということだと思います。

JON:いくつかの理由がありますが、ひとつは言語が変化しているということで、私は現在C# 7.2について書いていますが、それを書くために自分で新しいことを学ばなければなりません。そのため、C# 7.2や、かなり新しいC# 7.0について質問されるのはまったく自然なことだと思っています。ですから、言語が進化し、新しいフレームワークやライブラリなど、あらゆる種類のものが登場します。人々が質問するような新しい分野は常に存在します。また、既存の分野について質問する人もいますが、その中には新しい質問もあれば、新しくない質問もあり、中には新しい質問を装ったものもあります。例えば、C#では、ラムダ式が変数をキャプチャする正確な方法、特にC# 5では反復ごとに変数が変更されますが、C# 5以前はその方法が理想的ではなかったため、多くの質問が寄せられました。これらの質問の多くは事実上重複していますが、明らかに関連性があるとは思えないものが多いので、実際にはかなりの数の質問に答えました。答えを知って初めて、この2つの問題は偽装された同じ問題であることがわかるのです。ですから、回答者だけが、実はあなたが他の人と同じ問題に直面していることを知っているということは常にあります。そのような質問を重複として閉じるべきかどうかは、おそらく議論の余地があるでしょう。しかし、ソフトウェアエンジニアリングの世界には常に新しい人たちが入ってきていて、それは素晴らしいことです。Stack Overflowは素晴らしいトラブルシューティングのリソースだと思うので、ぜひそうしてほしいと思います。JavaコンパイラやIDE、Stack Overflowを使ってゼロからJavaを学ぶことはできません。それは言語を学ぶのに効率的な方法ではないでしょう。一方、本やチュートリアルはもっと構造的なアプローチで、Stack Overflowはそれに適しています。例えば、こんな例があって、こうなると思っていたのに、別のことをしていた。そして、私がこうすべきだと思っていたことが、実際には違う動きをしています。ここで何が起こっているのか、誰か正確に説明してください。この種の質問はStack Overflowにとっては素晴らしいものであり、他の学習ツールの補助的な役割を果たすものであることは間違いありませんが、最初の学習ツールとしてはあまり良いとは思えません。しかし、最初の学習ツールとしては最適ではありませんし、言語を学ぶ唯一の方法でもありません。私が言うように、もしあなたが言語やテクノロジーに比較的慣れていないのであれば、それを見つけるのはもっと難しいでしょう。関連する質問というのは、自分の質問が何に関連しているのか、その時点では必ずしも正確にはわからないものですから、質問の数や流れがすぐになくなるとは思いません。それは、新しい人たちのおかげでもあり、新しい技術のおかげでもあり、また、これまでにやったことのないことをやっている古い人たちのおかげでもあります。ある言語をそれなりに知っていると、うまくいかないことや予想外のことに気づくことができます。Stack Overflowで質問して、こうなることは本当に予想していたし、これまでの経験からそうなることを予想する十分な理由があった、と言うのはとても役に立ちます。しかし、ここでは通常は予想しないような技術に関する質問をすることになります。

MARCIN:Stack Overflowでは、オンラインで答えを見つけるというアイデアは、いつからソフトウェアエンジニアリングに不可欠な要素になったのでしょうか。というのも、以前はドキュメントや掲示板、ニュースグループなどがあっても、それだけではどうにもならなかったんですよね。しかし、多くのプロフェッショナルがstock overflowを日常的に使用し、多くのプロジェクトに利用しているようです。そのため、Stack Overflowはライセンスでその問題に対処することになり、基本的にコードを取得したのがサイクルであることを明記しなければならないとしました。あなたの意見では、ソフトウェアエンジニアリングとStack Overflowはこれまでどのように変化してきたのでしょうか。

JON:ソフトウェアエンジニアリングが変わってきたのは、使う技術が増え、ドキュメント化されていない技術を使うようになったからだと思います。Stack Overflowドキュメント化プロジェクトもありましたが、状況に合わずに中止になってしまいましたが、Stack Overflowがソフトウェアエンジニアの日々のツールキットの一部になっているのは確かです。その理由のひとつは、Stack Overflowの反応の速さにあると思います。2008年、2009年、Stack Overflowがまだ若かった頃のことです。ジェフ・アトウッドが「質問を投稿して20分待たないと答えが返ってこないこともある」と言っていました。20分というのは信じられないくらい短い時間だと思って、びっくりしました。彼の言うとおり、良い質問をすれば、たいてい20分以内に答えが返ってきます。以前はニュースグループではそうではありませんでした。読む人の数が増えたのか、世の中の流れが速くなったのかはわかりませんが、確かにニュースグループでは回答を得るまでに丸一日待つこともありますが、最近では回答を得るまでの時間よりも質問を書くまでの時間の方が長いことが多いです。ですから、質問を書くのに30分もかからないことはほとんどありません。というのも、調査をして完全な例を作り上げ、できるだけわかりやすく質問をするためには時間がかかるからです。もし質問を書くのに30分かかったとしても、30分以内には少なくとも「ああ、それは変ですね」というコメントをもらうことができます。これは新しいですね。何が起こっているのかよくわからない」「問題の解決策を説明した実際の回答」などのコメントが寄せられます。そう、低遅延であるという事実は、効果的にそれを可能にしているのです。それは、新しい質問をしなければならない場合です。Stack Overflowが助けてくれる問題に直面したとき、90%は誰かが以前に質問していたので、質問する必要はありませんでした。特に、PythonやBashスクリプトなど、あまり馴染みのない分野では、Stack Overflowで調べてみると、まさに自分が求めていた質問の答えが見つかることが多いですね。それは素晴らしいことです。

MARCIN:オファー開発を知って、もっと詳しく知りたいと思っている人たちは、最初の言語を学んでいるだけだと思いますか?そのような人たちは、コアな部分を学ぶことに十分な時間を割いていないのではないでしょうか。Stack Overflowのようなところに行く前に、コアのドキュメントや、その言語を本当に理解することに十分な時間を割いていないのではないでしょうか?

JON:どのくらいの割合の人がそうしているのかはわかりませんが、言語やツールを使いこなせずにそうしている人は確かにいると思います。しかし、学校や大学で診断プロセスを教えることが不足していると感じています。だからこそ、私はちょっとした不満を持っているのですが、英国ではソフトウェアエンジニアリングのコースよりもコンピュータサイエンスのコースの方がはるかに多く、コンピュータサイエンスのコースがあることにとても感謝していますし、コンピュータサイエンティストは間違いなく必要です。しかし、ソフトウェアエンジニアは、コンパイラの動作の詳細を知る必要はありませんが、「問題を解決してさらに調査するにはどうしたらよいか」を学ぶコースの方が必要かもしれません。そして、もし解決できなかった場合には、どのようにしてその問題について尋ねたかを示します。同僚に聞いたり、Stack Overflowで質問したり、バグを見つけたり、何であれ、診断プロセスのシンプルな側面で、自分が噛み切れる以上に噛み切ろうとしないことです。その言語に慣れていないのであれば、まず簡単なことをやってみましょう。例えば、すぐにウェブアプリやモバイルアプリに手を出すのではなく、コンソールアプリなどに手を出す傾向があります。もちろん、完全にウェブ開発を目的とした言語を使用している場合は、コンソールは不可能でしょうが、可能な限り最もシンプルな環境を使用してください。2行のコードを実行するために100行の定型文を必要としないような、デバッグが可能な環境は、自分が成功するための準備を効果的に行うのにとても役立ちます。100行のコードがありますが、全く理解できませんし、理解できないエラーメッセージが表示されて、どこから始めたらいいのかわかりません。問題は、理解できないものが多すぎるところから始めることです。変化の激しい世界では、私も他の人と同じように罪悪感を持っています。もし私が新しい技術を学ぼうとしたとき、簡単に始めたいと言っても、よく考えてしまいます。よくあるのが、「やるべきことは1つだけだから、とりあえず飛び込んでみよう」という考えです。しかし、動きの速い世界では、今すぐに何かをしなければならないので、すぐに飛び込もうとしたくなりますが、一歩下がって、走る前にまず歩くことを心がける方が、はるかに生産的で、長い目で見ても良いと思います。

MARCIN:キャリアの初期段階で、すでに解決されている問題を解き始めて、後になって、実はAPIや信頼できるライブラリを使えば解決できることに気づいた、という経験はありませんか?

JONサードパーティ製のライブラリを嫌う人もいるようですね。典型的な例としては、XMLの操作があります。アンパサンドをエスケープするだけでいいから、文字列を使ってXMLを直接構築しようとする人がいますが、そうすると、ああ、問題を引き起こす別のものがあることに気がつきます。やがて、最初からXMLライブラリを使えば完全に回避できたはずのコードが、何百行にもわたって追加されることになり、あらゆる種類のものに対してはるかに堅牢で安全になります。だから、サードパーティのライブラリを使うべきなのです。しかし、慎重に選んだとしても、非常に粗悪なライブラリもたくさんあります。しかし、良いライブラリを選ぶことで、プロジェクトに大きな違いをもたらすことができます。

MARCIN:私が言いたいのは、この特定の問題を解決するために、本当にコードを書く必要があるのかどうかを判断できるような知恵が、経験によって得られるということでしょうか。

JON:ある程度はね。それは経験の問題でもありますし、自分を抑えるための問題でもあります。というのも、何かができそうで、それがコードを書くことであり、書いたら楽しいコードだと思えば、そのコードを書きたいという誘惑が常にあるからです。そうすると、本当は書く必要がなくても、そのコードを書きたいという誘惑に駆られてしまいます。私もそのような誘惑に駆られることがあります。本当は書くべきではないのに、C#で簡単なツールを書いてしまうこともありますが、それは自分が一番よく知っている言語だからであり、その方が短期的には効果的なのかもしれません。長期的な生産性は犠牲になるかもしれませんが。あまり気にする必要はないと思います。この種のことで自分を責めすぎず、目を光らせておきましょう。自分から一歩引いて、自分の仕事ぶりを観察し、生産性の低い方法で多くの時間を使っているのはどこか、時間をかけて少しずつ減らしていくにはどうしたらいいかを考えることで、多くのことを学ぶことができます。常に時間をかけて自分を向上させるようにしましょう。

MARCIN:素晴らしい。いいですね。さて、私がやりたいことは、誰もがプログラミングを始めたときのストーリーを持っているので、それを教えてもらえればと思い、ちょっとした歴史を知ることができます。では、あなたが実際にプログラミングを始めたのはいつ頃なのでしょうか?いつソフトウェアエンジニアリングやプログラミング、コーディングなどに興味を持ったのか、その時の呼び名は何でもいいんです。

JON:とても早かったんですね。AztecのSpectrum 48 K SinclairをSpectrumで購入したのは、1984年だったと思いますが、私が8歳のときでした。スペクトラムはその2年前の1982年に発売されたのですが、最初はただゲームをしていましたが、すぐにごく簡単なコーディングをするようになりました。スペクトラムにはBASICインタープリターが内蔵されていました。スペクトラムにはBASICインタープリタが内蔵されていて、コンピュータを起動するとすぐにコードを入力できるようになっていました。ある日、父が病気で家にいたときに、私はくだらない小さなシューティングゲームを書いたのを覚えています。内容は、おそらくASCII文字で構成された宇宙船があって、ランダムな場所にエイリアンが現れるので、宇宙船を上下に動かして、「Face the Fire」を押す、というもので、まったくつまらないし、やっていても面白くありませんでした。でも、インタラクティブなものを書いたのはこれが初めてだったので、自分でも驚くほどの感覚がありました。当時はすべてのゲームが粗雑だったこともあって、私は「Jetpack」や「Lunar Jet Man」などを楽しんでいました。しかし、これらはかなり単純なゲームだったので、私が単純なものを書いていたという事実は、私を躊躇させませんでした。最近の子供たちは、私のアドバイスに従ってとても簡単なことを始めようとすると、ランダムな数字を推測して、高すぎるか低すぎるかを表示するような小さなテキストゲームになってしまうので、ちょっとかわいそうです。これをオーバーウォッチやその他のゲームと比較してみると、ゲームの面白さがわかります。単純なテキストのものから、3Dグラフィックス、それにネットワークや様々なものが加わって、100万光年もの距離があるのですから、どうつながるのかわかりません。しかし、当時は素晴らしかった。だから、自分でコードを書いたりしていました。また、雑誌にはリストが掲載されていて、それに入力していくこともできました。本を買って、巻頭のテープにコードが書かれていて、それを読み込むのではなく、全部タイプしていました。このようにして、特に強調されることなくコードを書くことができるんですね。私の最初の重要なプロジェクトの1つは、ロゴのインタープリタを書くことでしたが、学校ではBBC Microコンピュータを使っていました。学校ではBBCマイクロコンピュータを使っていたのですが、ロゴのインタープリタを使っていました。ロボットのような偽物が出てきて、「100進む」「右に90度曲がる」などと言うと、スクリーンにシートを描いてくれるのです。私はこれが大好きなのですが、スペクトラムにはなかったので、自分で実装しました。私はこれが難しいことだとは思っていませんでしたし、時間もかかりましたが、信じられないほど満足のいくものでした。学校では三角法を見たことがありませんでしたが、スペクトラム・マニュアルは明確だったので、そこからロゴ・インタープリターを作るのに十分な知識を得ることができました。そして今思えば、そのコードをぜひ見てみたい。絶対に反則だと思いますよ。そしてもちろん、それは時の流れの中で失われてしまった。しかし、どんなにひどいコードであっても、振り返ってみると私は非常に誇りに思います。ロゴのリストを書けばいい。テープに保存できて、またロードできて、実行できて......すべてが最高にクールだった。

MARCIN:このスキルを身につけていく中で、もともとソフトウェアエンジニアとして働くことを考えていたのか、それとも他のことに興味を持っていて、何かのきっかけで指示されたのか、あるいは実際にこの分野に足を踏み入れるまでのプロセスはどのようなものだったのでしょうか。

JON:13歳か14歳の頃から、これが自分のキャリアになるだろうと考えていたと思います。そうですね。大学ではコンピュータサイエンスを専攻したわけではなく、数学の学位を取ったので、最終的には数学の研究をすることになるだろうと思っていました。結局、私は博士号などを取得できるほど数学が得意ではありませんでした。でも、コンピュータに関わることをするだろうとは思っていました。学生時代に人工生命に興味を持っていたので、数学の学位を取得した後、コンピュータサイエンスの修士課程を1年間受講し、休暇中に友人と一緒にデジタル・エレクトロニクス社で働くことになりましたが、基本的にはそこからスタートしました。私は昔から、自分のキャリアを方向付けるのが苦手で、自分が楽しいと思うところを転々としてきました。私にとっては、お金よりも楽しむことのほうがはるかに重要だと考えています。有名になるとか、そういう意図的な人生の目標はありませんでした。しかし、Stack Overflowで得られる奇妙なマイクロセレブリティとしての地位はとても楽しく、少し変な感じがします。しかし、仕事で楽しいことをすることの方が私にとってはずっと重要なので、質の高いワークライフバランスを確保し、家族にもよく会うようにしています。家族は私にとって非常に重要な存在ですが、おそらくもっと慎重な人たちがするであろう自分のキャリアにはほとんど注意を払ってきませんでした。

MARCIN:子供がプログラミングに興味を持つようになるには、親はどうすればいいのでしょうか?

JON: 私には3人の子供がいますが、一人はArduinoに興味を持ち、コーディングを少しして、Pythonも楽しんでいます。もう一人は最近Pythonを始めたのですが、以前はスクラッチをやっていました。私は自分の子供にPythonでプログラミングを教えようと、非常に段階的なアプローチを試みましたが、大人にはいいかもしれませんが、子供の興味を十分に引くことはできないと思います。少なくとも、私が訓練されたようなステップ・バイ・ステップではありません。私の教え方が悪かったのかもしれませんが、最も重要なのは、子供たちがやりたいと思うことを確認することだと思っています。だから、私が子どもたちにプログラミングを教えようとするのをやめたときから、子どもたちは自分でプログラミングをするようになり、はるかに多くのことを学ぶようになったのです。私の長男は、ArduinoやRaspberry Piを使っていろいろなことをやっています。私が見たこともないようなものを、たまに「この部品をください」と言って作るんですよ。私もそのようにして学びました。私の両親は、私が何をプログラミングしているかについて、私が知る限りでは見守ってはくれませんでした。ただ、私が幸せであることを喜んでくれて、外の世界に出ることを勧めてくれました。たまにですが、私が何かクリエイティブなことをして、自分自身から学んでいることを喜んでくれました。だから、子供たちを十分に励まして、自分でやってみて楽しいと思えることを見つけてもらい、助けを求めたときには喜んで手伝うが、無理強いはしないということを明確にしておけばいいのです。今は、30分ほどのプログラミングの時間です。それから、これが成功の秘訣だと思います。子供は学ぶことが大好きです。学校は好きではないかもしれませんが、学ぶことは好きですし、創造的なことをするのも好きです。ですから、彼らが思うようにその創造性を発揮できるようにしてあげれば、彼らはその能力であなたを驚かせることができるでしょう。

MARCIN:誰もがコードの書き方を学ぶべきだという考えは、特にカリキュラムにコードを導入しようとしていることを考えると、良い考えだと思いますか?これは良いアイデアなのでしょうか。それとも、不必要に人々に望まないことを学ばせようとしているのでしょうか。

JON:1つは、すべての人にコーディングを知ってもらうことです。というのも、コンピューター・プログラマーはこうあるべきだという不健全な固定観念が、この業界に悪影響を与えているからです。そこで、コーディングとはこういうものだということを人々に伝え、ポジティブな体験をしてもらうことができれば、これまで「自分もやってみようかな」と自然に思っていなかった人も、発見することができるかもしれません。実際、彼らはそれが好きなのです。それはとても有益なことだと思います。もう1つの側面は、ソフトウェアが世界の多くの部分を動かしているということです。たとえ最も粗いレベルであっても、何が関係しているのかをある程度知っておくことはとても有益だと思います。同じように、人々はファイナンシャル・プランニングのレッスンを受けるべきだと思います。年金とはこういうもので、ローンとはこういうもので、株式市場とはこういうものだ、という基本的なことだけです。銀行員になるためではありませんが、政治やあらゆることにも同じことが言えて、自分の世界に影響を与える現実の部分があるということを知っておくことで、金銭的に大きく左右される世界でうまく立ち回れるようになるのです。基本的な理解をしておくことは良いことです。私は政治や金融に詳しいわけではありませんが、自分が知っていることにとても満足しています。最近の子供たちは、先進国の中流階級出身者ばかりではありません。貧困などの理由で子供たちがコンピュータに触れることがない地域については、別の話をする必要がありますが、多くの子供たちはコンピュータと何らかの関わりを持つことになります。しかし、多くの子供たちはコンピュータに触れる機会があります。また、クラウドとは、GoogleやAmazon、Microsoftなどが管理するデータセンターで、どこか他の場所で稼働しているコンピュータのことであり、その基本的な知識を持っていることは、他のことをするときにも役立ちます。

MARCIN:例えばクロームのような開発者向けツールバーを使えば、インターネットを利用している人を対象に、このウェブサイトを利用している間にこのようなことが起こっていることを知っていますか?インターネットを利用している人であれば誰でも、このウェブサイトを利用している間に、このような活動が行われていることを理解していますか、と言うことができます。しかし、それはカーテンの向こう側にあるものを明らかにするようなものです。例えば、その話題に全く興味のない人に、「よし。あなたがこのウェブサイトを使っているときに、実際に何が起こっているのかをお見せしましょう。実際に何もしなくても、コンソールを開いてjavascriptをハックすることができるというのは素晴らしいことだと思います。

JON:その通りで、それをお互いに応用することができます。C#をはじめ、基本的なコードをブラウザ上で実行する方法は他にもたくさんあります。Tray.netを使えば、ブラウザ上でそれぞれのコードを書き始めることができ、裏ではどこかでクラウドコンテナが稼働しているはずです。しかし、無数の言語で書かれたコードをブラウザ上で見ることができるのは確かです。コンピュータサイエンスの分野では、このような経験をすることが重要だと思います。私は、カブスやガイド、地元のメソジスト教会のギルドなどで講演をしたことがありますが、そのほとんどが引退した人や引退間近の人で、コンピュータサイエンスをまったくやったことがない人たちでしたが、コンピュータをまったく使わずにコンピュータサイエンスを紹介する講演をしました。例えば、紙の切れ端が山積みになっていて、それをどうやって効率的に並べ替えるのか、使えるアルゴリズムをいくつか紹介しました。これはどういうことかというと、もし1人の人間が紙を並べ替えようとした場合、1つのアルゴリズムを使うかもしれません。もし10人の人がいたとしても、あなたが選んだ方法は、大勢の人が協力してもスケールアップするでしょう。アルゴリズムの複雑さのようなものは、いろいろなことをするのにどれくらい時間がかかるかという実例を示しています。もし、洗濯物にシャツを干すような入力が多ければ、それに抵抗がなければ、そのようなことにも興味を持てると思います。しかし、コンピュータと言い出した途端、多くの人はすぐに敬遠してしまうでしょう。だから、怖くない、ひいき目に見ない方法で物事を利用できるようにすることには多くの意味があり、それには私が持っていない分野でかなりのスキルが必要です。しかし、私はできる限りのことをしてきましたが、より優れた教育者であれば、きっともっと素晴らしいことができるでしょう。これはとても重要なことだと思います。

MARCIN:Let's keep going here.Stack Overflowの他に何をしていますか?気に入っているリソースはありますか?私はO'Reillyの本が好きなのですが、実際に何か新しい言語などを学びたいときに使うリソースとしては、何が好きですか?

JON最近では、適切に書かれている限り、オンラインチュートリアルにも同様のことが言えます。例えば、C#のチュートリアルを書いたとしても、ブレインダンプをしただけで、実際にはあまり良くないものになってしまうかもしれません。ですから、選択する必要がありますが、自分のために構成されているものは大きな違いがあります。 優れたAPIドキュメントは常に歓迎されます。.NETはドキュメントが充実している傾向にありますし、新しいAPIブラウザを使えば、ドキュメントを簡単に見つけることができますからね。私は、ライブラリを書いている人には、そのライブラリと一緒に良いドキュメントを書くことに力を入れるように勧めています。世界最速のJSONシリアライザーを持っていても意味がありません。誰もその使い方を理解できなければ意味がありません。しかし、他の人が使っているのと同じリソースを使うか、チュートリアルや本を使うか、あるいは正しい結果を検索するかです。何かをPDFにするとか、たまたま手にした作業をどうするか。インターネットで検索したり、Stack Overflowを利用したり、本やチュートリアルを利用したり、ライブラリやそのドキュメントを利用したりしています。そうですね、だいたいそんな感じです。

MARCIN:また、私たちの年齢層がほぼ同じであることから、この考え方についてはどう思われますか?ある年齢になると、人は管理職になるという考え方です。あなたはそれを見たことがありますか?それとも、まだソフトウェアを開発しているという点で、あなたはユニークな存在なのでしょうか、それとも。それについてはどう思われますか?

JON:確かに私は特別ではありません。私は自分のキャリアを積極的に管理してこなかったと言ってもいいでしょう。自分が楽しむことに最適化しているという事実から、私はかなり長い間、管理することに積極的に抵抗してきました。半年間管理職になってみて、いろいろなことがあることがわかりました。特に、私は自分が共感能力に長けていると思いたいし、意識的に共感能力を高めようとしています。しかし、これは明らかにマネジメントにも関連しています。私はマネジメントをやってみたら面白いだろうと思い、やってみたところ、より個人的な貢献者としての役割に戻るのが適切だと思いました。ソフトウェアエンジニアとしてリーダーシップを発揮するには、管理しなくてもできることがたくさんあります。例えば、設計書を書くことに多くの時間を割くことができますが、私は今でもそれなりに頻繁に、しかも非公式に文書を書いています。私は、誰にも関係のない断片的な情報を盛り込んだ巨大な文書を書くのはあまり好きではありません。むしろ、素早く本題に入っていく方が好きです。しかし、複数のチームに貢献するためにドキュメントを書くとなると、誰もがこの問題を抱えていると思います。自分がコードを書いて問題を解決するよりも、もっと広い範囲に影響を与えるような解決策を一緒に考えてみましょう。経験を積んでいく中で目指すべきことのひとつは、その経験が他の人の役に立つかどうかということだと思います。しかし、それはある程度はコードを書くことであり、ある程度はユーザーグループやカンファレンスなどで自分の知識を共有することです。また、社内で問題を解決することで、他の経験の浅い人やチームに参加したばかりの人よりも、より明確な判断ができるようになるかもしれません。しかし、マネージャーになるべきかどうかという点では、個人的には、必ずしも自分で仕事をしたことがなくても、すぐに管理職になっても構わないと思います。共感と学習によってその人が得意とする分野であれば、自分が仕事をしていないことを自覚していれば、仕事をしなくても仕事の内容を学ぶことができますし、直接の経験もありません。ですから、年齢と管理職の割合との間に直接的な相関関係があるとは思いません。私は定年を迎えてもコードを書き続けたいと思っていますし、おそらく大した量の管理をすることはないでしょう。もし、いつか管理職にならなければならなくなったら、自分の能力を最大限に発揮するつもりですが、通常、管理職になることを義務付けるべきではないと思いますし、多くの企業が、実際にはコーダーの方がはるかに幸せで生産性も高いはずの人を管理職に登用するという間違ったことをしていると思います。

MARCIN:15年もソフトウェアを作っていたら、マネージャーになったほうがいいというのは、おそらく何か間違った考えだと思います。ただ、少なくともカリフォルニアのシリコンバレーでは、例えば29歳の自分は年を取りすぎていて、22歳、23歳、24歳の人ばかりを採用することに執着している企業に採用されないのではないか、というプレッシャーがあることは知っています。

JON: 私は、22歳の若者を雇うことに固執する会社には雇われたくありません。むしろ、人を大切にする会社で働きたいと思っています......彼らが何を達成できるのか、そして彼らが一緒に何を達成できるのか。つまり、現在のスキルだけでなく、彼らの潜在能力を評価するのです。ですから、私自身はそのようなアジズムを経験したことはありません。失礼ですが、それが懸念材料であることは承知しています。確かに、私のコーディングスキルに関しては、私が知っている限りでは、劣化を経験していませんね。これまでと同様、楽しく生産的にコーディングしています。私の知る限りではですが。ですから、企業にはそのようなことに注意して、仕事ができる人を雇ってほしいと思います。

MARCIN:何か良いことがあると思いますか?例えば、他のすべての職業について話してみましょう。もし誰かが30年間物理学をやっていたとしても、誰かに「あなたはもう何をやっているのかわからない」と言われることはないと思われがちです。ソフトウェアエンジニアリングはテクノロジーと密接に結びついていて、テクノロジーは急速に発展しているので、人々は、何年もやっている人は、ある種、時代遅れだと思っているのでしょうか、それとも、ソフトウェアエンジニアリングを他のすべての分野から区別する何かがあるのでしょうか。

JON:そういうイメージがあるかもしれませんが、正確ではないでしょうね。新しいことを学ぼうとする姿勢は必要です。少なくとも、新しいエキサイティングな分野に進み続けたいのであれば、そうする必要があります。もしあなたが30年間COBOLをやっていて、COBOL以外のことは学ばないと決めているのなら、まだ生産性はあるでしょうし、それはそれでいいと思います。しかし、学び続けることに何の興味も示さずにJavaScriptなどの仕事に就けるとは思わない方がいいでしょう。というのも、C#には学ぶべき新しいことがたくさんあって、F#やD、Rust、Goなど、他の人がもっと広く、もっと深く学ぶための時間がないからです。しかし、どれだけのことをやりたいかは個人の自由ですし、もし学ばないと決めたら、もし学ばないと決めたら、時間の経過とともに自分の価値が下がってしまうということを認識する必要があります。しかし正直なところ、レガシーシステムが十分にあるため、ほとんどの言語では、たとえ学習をやめたとしても、それなりの価値を維持できるのではないかと思います。正直なところ、新しいことをするのはいつでも面白いので、学ぶのをやめたいと思う理由がわかりません。しかし、学習にはそれなりの時間がかかります。エンジニアが家族と過ごす時間を削ってまで学習しなければならないと思わないように、企業はその時間をエンジニアに投資するべきだと私は思います。ですから、仕事の一環として、かなりの量のアクティブな開発を行う必要があります。優れたSopherエンジニアであるためには、新しいことを学ぶことが大切です。ほとんどの開発者にとっては、レガシーな分野ではあまり関係ありませんが、新しいことを学び続けるCobol開発者であれば、Cobolのスキルを他の環境でどのように応用できるかを知ることができるでしょう。最近では、COBOLを実行するコンテナがあり、COBOLを実行できるクラウドベースのコンテナシステムが登場し、オンプレミスのマシンをすべてオフプレミスに移すことができるようになっています。古い言語を使っているからといって、すべてに古い技術を使わなければならないわけではありません。すべての技術的なスキルを新しい環境に適用したい人、新しいことを学ぶことにあまり価値を見いだせない人。ええ、特に共感はできませんが、ソフトウェアエンジニアリングはとても幅広い分野ですから、きっと役に立つ生産的な生活を送ることができると思います。既存のスキルをすべて適用して、常に新しいチャレンジをする。C# 7を一生使い続けて、実際の言語分野を新たに学ばなくても、新しいことをしているかもしれませんね。それは私がやりたいことではありませんが、他の人にとってはそうでしょう。きっと他の人にとっては、その方が行きたい道なのかもしれませんね。

MARCIN:それは、ほとんどの言語がチューリング完全であり、どんな言語でも何でもできるという事実があるからです。つまり、非常に広い意味で

JONたぶん、よくわからないですね。言語は進化するものだと思います。確かにC#は、使われるユースケースに合わせて確実に進化してきました。今追加されている機能の中には、クラウドコンピューティングが普及する前の10年前にはあまり意味をなさなかったものもありますし、ゲームのような分野では、UnityのようなプラットフォームでC#がほぼ独占的に使われています。このように、ゲームや低遅延ハイパフォーマンスコンピューティング向けに調整された言語機能があり、それは素晴らしいことだと思います。しかし、他の言語や以前のバージョンの言語でもできることはありますが、新しい機能を使ったほうが生産性が高く、面白いですよ。

MARCIN:あなたの好きなIDEは何ですか?

JON:ビジュアルスタジオ

MARCIN:何か方法論があるのでしょうか?

JON:Get Code Done」です。私はカンバンを使っていませんし、そのような特定の方法論を言いたいわけでもありません。私はテストを信じています。必ずしもテスト駆動の開発でなくても、少なくともテストを伴った開発は必要だと思いますし、状況に応じてテスト駆動にすることもあります。テストされていないプロダクションコードを大量に抱えることには抵抗があります。これはアジャイル開発の一つの側面ではありますが、個人的にはアジャイルの全てを使うわけではありません。私はあまりペアプログラミングをしません。過去にやったことがありますが、とても役に立ちました。私は過去にペアプログラミングをしたことがありますが、非常に役に立ちました。私は、同僚と良い関係を築くことが重要だと考えていますので、コードレビューは非常に重要であり、コードレビューは正直で率直なものでなければなりません。しかし、それは特定の方法論に縛られたものではありません。

MARCIN:例えば、3ヶ月から6ヶ月の間、言語を学んでいるような人にどのようなアドバイスをしますか?例えば、3ヶ月から6ヶ月間、言語を学んでいて、自分は賢くないと感じています。修正しなければならないエラーがあまりにも多すぎるからです。興味はあるけれど、どうしても乗り越えられないと感じている人に、どのようなアドバイスがあるでしょうか。

JON:もし、まだ興味があって、もっとうまくできれば楽しめると思うのであれば、人を探してみてください。ブログを読んだり、ユーザーグループを見つけたりして、交流できる人を探し、できれば1対1で授業を受けたいものです。一方で、もし誰かと1対1でプレゼンをすれば、あなたが間違った方法で何かを想像している、あなたのメンタルモデルの問題を理解してくれることが多いでしょうし、それを個々の小さな断片から得ることは非常に困難です。楽しくないのであれば、他の言語を探しましょう。

MARCIN:JavaとC#、どちらのプログラミング言語が優れているか?

JON:個人的には「C#絶対」です。今、私はJava 9の機能の詳細を見ていませんし、ジョブレート機能のようなものしか知りませんが、C#はJavaが犯した過ちのいくつかを受け継ぎ、自らも過ちを犯しているように感じます。しかし、一般的には、C#はより速く開発しているように見えますし、C#チームは素晴らしく賢く、言語の開発方法について本当に注意深く取り組んでいると思います。現在、C# 7.2がリリースされていますが、非常に良い方向に進んでいるように感じますし、非常によく管理されています。とはいえ、Javaはこれまで以上に良くなっていますし、もしあなたがJavaのコードベースで作業しているのであれば、それをすべて捨てて代わりにC#を始めるべきだとは思いません。しかし、もし私に選択肢があるならば、いつでもC#を選ぶでしょう。

MARCIN:最高ですね。Jon Skeetさん、Yellow Duck podcastのゲストとして参加していただきありがとうございます。もし私に送りたいリンクや、これから行うカンファレンスなどがあれば、すべての情報を送ってください。

JON:ありがとうございます。

MARCIN:うん、ありがとう、バイバイ

シェアポスト

技術者の採用についてはこちら

ラーニングハブに登録すると、有益な情報をメールで受け取ることができます。

シームレスにコーディングスキルを検証&開発

DevSkillerの製品をご覧ください。

セキュリティ認証とコンプライアンス。お客様のデータの安全性を確認します。