偉大なソフトウェア開発者になるには何が必要か 99
ストーリー by headless
and-the-best-that-you-can-hope-for-is-to-die-in-your-sleep 部門より
and-the-best-that-you-can-hope-for-is-to-die-in-your-sleep 部門より
本家/.「Ask Slashdot: What Makes a Great Software Developer?」
偉大なソフトウェア開発者(単に優れたソフトウェア開発者でもいい)になるには何が必要だろうか。Michael O. Church氏のQuoraへの投稿では長いリストになっている(LifeHackerにも転載されている)。偉大な開発者は仕事を通じて学ぶことを恐れず、キャリアを積極的に管理し、ソフトウェア開発の政治(彼は「CS666」と呼んでいる)を知り、可能であれば仕事を早く切り上げ、長期にわたって使われるテクノロジーと一時的な流行を見分けることができる。これらは彼の挙げたポイントの一部に過ぎない。一方、Salsita Softwareのブログで同社の創設者でCEOのMatthew Gertner氏が、結局は「経験を積んだプログラマーと開発者はゆっくりすべき時を知っている」という点に収束されると指摘している。皆さんの場合、偉大な開発者とそれほどでもない開発者をどうやって区別するだろうか。
Matthew Gertnerの要点をちょいと補足 (スコア:3, 参考になる)
「ゆっくりすべき時を知っている」
というのがピンとこなかったので少し補足。
The corollary is that the market rarely moves as fast as you expect. With rare exceptions, if you create something with a solid foundation that is usable, maintainable and meets a real need, it will be as relevant when you finally bring it to market as it was when you came up with the idea, even if it took you much longer than you anticipated.
結局マーケットは開発者が思っているほど早くは動かない。だから、急いでメンテナンスできない製品を作るよりも、時間をかけてでもしっかりしたものを作ることが重要、らしいです。
あせっても良いことはない -> ゆっくりやることが大事
ということでしょうか。
偉大な開発者は偉大な問題を見つけ、それを解く (スコア:3, すばらしい洞察)
ソフトウェアとは、問題が何かを定義できた時点で、技術的な問題の大半はクリアされている。
偉大な開発者はフォースを信じて、愚かな開発者は人力ブルートフォースを信じる。
問題を技術で解決するのではなく、科学的に分析し、技術的に解くことだ。
技術でなく、科学技術を信じることが最低ラインだと思うなー。
誰でも解ける問題を解いても仕事にはなるが、誰でも解ける問題を解いているうちは偉大にはなれない。
答えが分かっている問題を解いても偉大にはなれない。
偉大な問題に出会えなければ、どんなに技術があっても偉大な開発者にはなれない。
そういう意味では、最先端の分野に触れる仕事でキャリアを積むことが、偉大な問題に出会う第一歩。
偉大な問題に出会って、誰よりも早く解けばよい。そのための努力を惜しまないことだ。
その人が偉大な開発者かどうかは、少し一緒に仕事をすれば、直ぐに分かる。
仕様書にないユースケースを想定しているかどうか (スコア:2)
ユーザーは常に想定外の使い方をする。
Re:仕様書にないユースケースを想定しているかどうか (スコア:2)
究極的には真っ白な仕様書から、ユーザが何をしようとしているのか読み取れる超能力者か……。
冗談はさておき、具体的には、日々ユーザの使用法を研究・分析していて、
それから想定外の使い方のエッセンスを簡潔にまとめることができ、
仕様書をチェックするプロセスの中で、想定外の使い方に対して、プログラム、あるいはマニュアルに
どんな修正をすべきか、適切に不備を指摘できるエンジニアが偉大ということなんでしょうね。
つまり、……という行間を読める開発者が偉大で、一方で行間を生み出す開発者は……(野暮なので以下略※まるでブーメラン)。
Re:仕様書にないユースケースを想定しているかどうか (スコア:1)
> 究極的には真っ白な仕様書から、ユーザが何をしようとしているのか読み取れる超能力者か……。
まあ当方、立場的にはユーザー側なのですが、日曜プログラマーです。
システム開発の現場にユーザー側で立ち会っていると、(うちの職場は)仕様書なんかほとんど作れないユーザーばかり。
エンジニアの方が一生懸命聞き取りをして、頑張って設計をしていますが、ユーザー側で自分がやっていることをほとんど
言葉で説明できず、結果、ほんとエンジニアには超能力が要求されますね。
Re:仕様書にないユースケースを想定しているかどうか (スコア:1)
元のコメントが仕様書に限定していましたから、その流れでコメントしました。
白紙から作る立場の人から、そういうコメントもあるかなと思っていました。
ユーザーから、要件を聞き取り仕様を起こす場合、ヒアリング能力、
工数見積もり能力、仕様調整能力、それと設計書の作成能力etcなど、
複数のスキルに明るい人材(いわゆるスーパーマン)が必要でしょう。
そういう人材が、ゼロから仕様書を作る場合、目の前にユーザーが
いるのでしょうから、「想定外の使い方」について聞き取る場ぐらいは
あるはずで、いわゆるスーパーマンが最終的に「想定外の使い方」が
明文化されていない仕様書を作るんですよね?
逆に作れるなら、わざわざ行間を読む必要もないし、ヒアリングするのですよね?
「ほんとエンジニアには超能力が要求されます」というより、
「ヒアリング能力」が要求されるといった方が、しっくり来ます。
「ヒアリング能力」なら磨けば誰でも伸ばせますが、「超能力」は誰でもは無理でしょう。
本当に「超能力」と形容したい何かがある現場なのでしょうか。
Re:仕様書にないユースケースを想定しているかどうか (スコア:1)
「偉大なソフトウェア開発者」というストーリーなのですから、
「誰でもできるもの」と「誰でもはできないもの」を分けて説明する必要がありました。
その対比のため、ヒアリングなど名前のある技術は誰でもできるもの、
誰もができるわけではない得体の知れない技術を超能力として使い分けています。
なお「超能力」という言葉は、思考を止めてしまうストップワードだと考えています。
例えば、プロのスポーツ選手が神業的なプレイを見せたりして、
天才だとかの一言で片付けたりしますが、当の本人は、
他の選手がコントロールできるとも思っていない風の流れだとか、弾の回転だとか、
制御不可能だと思われているものを、つぶさに観察して、試行錯誤しながら、
一つずつ自分の制御下に置いていくのです。テクノロジーの分野でも、
昔は月まで辿りつくなんて考えもしなかったのが、
物理現象を一つずつ制御下に置いて、月までたどり着いた訳です。
他人から超能力に見えて、自分の中では一つずつ名前のある能力に
していくこと、制御可能にしていくこと、それを続けることで、
ありふれた開発者から外れて、偉大なソフトウェア開発者に
近づくのではと考えています。
思うに「誰でもできること」と「誰でもはできないこと」があったら、
基本は「誰でもはできないこと」をみんながやって、
「誰でもできること」は誰かに任せればいいかな。
「誰でもはできないこと」は、真似できないし、長く飯を喰う種になるでしょうから。
だから、強みというか自分だけの刃がなにかを明確にする意味で、
それらの境界を曖昧にしない方が良いと思うのです。
Re:仕様書にないユースケースを想定しているかどうか (スコア:1)
長々と書きましたが、簡潔にいうと「フォースを信じよ [srad.jp]」という訳です。
要するに「成功するには何が必要か」って質問? (スコア:2)
この手の質問って、「成功するには何が必要か?」って訊いてるのと同じでは?
"成功する理由"はないけど(成功する条件は絞り込めないけど)失敗の原因は、割と楽に発見できる。
失敗する要素を可能な限り取り除くリストを作成すると…際限なく長いリストが出来上がる。
# やってはいけない事のリストと評価条件の検討に時間をかけると、肝腎の開発作業(事業)が進まなくなって失敗するというオチかしら?
notice : I ignore an anonymous contribution.
Re:要するに「成功するには何が必要か」って質問? (スコア:1)
それはリストの先頭に
「やってはいけない事のリストと評価条件の検討に時間をかけると失敗する」
と書いてあるんじゃないかと。
まあ、「時間をかけないやり方を検討する」ために際限なく時間をかける人達もいるんですけど。
#存在自体がホラー
健全な食事と睡眠かな (スコア:2)
Re:健全な食事と睡眠かな (スコア:1)
偉大な開発者になるよりも
健全な食事と睡眠のほうが
大切だと思う
Re:健全な食事と睡眠かな (スコア:1)
胃腸の健康は大事という事か。
#存在自体がホラー
先ずは天性 (スコア:2)
逆に考えるんだ (スコア:1)
偉大になんてならなくてもいいさと考えるんだ
Re:逆に考えるんだ (スコア:1)
偉大になるにはソフトウェア開発者にならない方がいいさと考えるんだ
Re:逆に考えるんだ (スコア:1)
別の開発者から「開発者としての脳ミソついているのか?」と罵られる。
実際、そんな台詞を言われている場面に出くわしたことがある。
Re:逆に考えるんだ (スコア:3)
自分で言うのもアレだけど (スコア:1)
ここ見てるようじゃあちょっと厳しいんじゃないかなぁ...
Re:自分で言うのもアレだけど (スコア:2, おもしろおかしい)
某所が神にも悪魔にもなれる人が集う所なら
ここは、毒にも薬にもならない人たちが集う所ですから
この生ぬるさが心地いいのです
ゼフラム・コクレーン (スコア:1)
「偉大な男になろうとするな、ただの男であれ。いずれ歴史が判断してくれる。」ってワープ航法技術の発明者が今から約60年後におっしゃいます。
運 (スコア:1)
作ったものがたまたま流行ったら、他人から偉大だと言われる。
能力はあんまり関係ない。たまたま。
ヒゲ (スコア:0)
ヒゲをはやしているかどうか。
Re:ヒゲ (スコア:1)
いや、怠け者で癇癪持ちで生意気なこと。
Re: (スコア:0)
リコーダーを吹くかどうか。
根気 (スコア:0)
ひとつのプロジェクトをこつこつとやっていけるか
Re:根気 (スコア:1)
成功するまで続ける根気が必要だと思いました
Re: (スコア:0)
1人・約20年間で、主にC++で数十万行のコードを書いたという話を聞いた事があるけど
やはり体力と根気は外せないと思った
Re:根気 (スコア:1)
一人で二十年間数十万行のコードを保守し続けた、なら生ける伝説になれるかも。(一線級で稼働しているコードなら)
信者 (スコア:0)
信者かな……
基本 (スコア:0)
なかったら作ろうとする姿勢。
繰り返して入れば技術力上がるし、無いものを作るわけで利用者も増えてそのうち必須になる可能性がある。
基本中の基本
Re: (スコア:0)
http://hrnabi.com/2015/01/30/5463/ [hrnabi.com]
「作れば使ってもらえるというのは良くある勘違い」
Ruby on Railsの生みの親の言葉は味わい深いでぇ
それを目標にしてもな (スコア:0)
その望みに俗っぽい響きが否めない。
ベスト3に絞った方がネタとしては面白そう。
はたして (スコア:0)
偉大なソフトウェア開発者の定義に、某systemdや某pulseaudioの作者とかは含まれているんだろうか、
広く使われるソフトウェアor使わざるおえないソフトウェア作る以外に偉大なソフトウェア開発者とやらになる方法はないだろう。
プログラマ個人の経験やら能力には再利用性がないから。大多数の人間には何を作ったか以外どうでもいい事でしかない。
Re: (スコア:0)
1万人で1億行のソフトを書くことにこそ価値があるのだ
一個人の技量なんてどうでも良い
偉大な・優れたの定義 (スコア:0)
また、この形容詞は「ソフトウェア」と「開発者」のどちらに係るのか。
# この一文を読んだだけで、少なくともプログラマとしては優れていないと感じる…
Re: (スコア:0)
日本語に不自由な方ですか?
Re: (スコア:0)
「偉大なソフトウェア開発者」を、「偉大なソフトウェア」の開発者と解釈する奴は
日本語の勉強をやり直してこないと、まともな仕様書さえ読めないぞ
Re: (スコア:0)
Re: (スコア:0)
まともじゃない仕様書を書く奴を教育するのと、
まともじゃない仕様書を解釈する能力を身につけるのと、
どっちが可能でどっちが不可能か、まさか知らないわけじゃないだろ?
Re: (スコア:0)
自分がある程度知識のある分野ではこういうことに悩むことって少ないですけど、出てくる語出てくる語が初耳なときには、自分もこういう修飾関係に悩まされます。
一通りの意味にしか解釈できないような文章だと、そういうときに助かりますよね。
結果論 (スコア:0)
初志貫徹が成功の秘訣です!なんて言ったところで
その影には無数の"頑迷で頭の固い無能"と呼ばれてしまった失敗例が潜んでいるわけで
ジョブズやゲイツが悪どいことを何度も重ねていながら、
最終的には"機転の効いた""抜群のセンス""したたか"という言葉に飾られるのもまたしかり
金で解決 (スコア:0)
10億くらい使ってステマさせたら偉大ってことにしてもらえませんかね。
適当に消息不明のプロジェクトとかに名前ねじ込んで貰うとか。
あとはゴーストライターに発言考えて貰う。
Re:金で解決 (スコア:1)
10億くらい使ってステマさせたら偉大ってことにしてもらえませんかね。
ステマで偉大になれるだけの金を用意できるくらいに稼げるなら、十分偉大だと思いますよ。
Re:OSS系では (スコア:1)
なるほど、あなたの経験則ですか。
貴重な体験談はありがたいですが、あなたのようになりたくはありませんね。
Re:天才プログラマーってどんなコード書くの? (スコア:1)
http://local.joelonsoftware.com/wiki/%E3%82%BD%E3%83%95%E3%83%88%E3%82... [joelonsoftware.com]
から引用
----------------
芸術における高音域が、ソフトウェアでも問題になるのだろうか? 「場合によってはそうなのかもしれないが、私はただ医療廃棄物業界向け会計システムのユーザインタフェースを作っているだけだ」。それは結構。ここで議論しているのはパッケージソフトを作るソフトウェア会社のことであり、そこではコードのクオリティが直接、会社の成功失敗に結びつくのだ。
----------------
古くからある議論ではあるね。
Re:天才プログラマーってどんなコード書くの? (スコア:1)
Java並行処理プログラミング
http://www.amazon.co.jp/dp/4797337206 [amazon.co.jp]
って本に書いてあったロックフリーを実現するためのコード、何やってるかは辛うじて読みとれたんだけど、どうやったらそれに到達できるのかさっぱりわからんかった。
Re:天才プログラマーってどんなコード書くの? (スコア:1)
考えるとは、知っているもの同士を結びつけること。
そもそも、知っているものが少なければ、どんな風に結び付けようと答えにはたどり着かない。
「考える」という行為の前に、本当は情報収集と分析が必要になる。
※ 最近流行の、ビックデータ解析が成果を上げていることから、情報収集と分析の重要性はわかるでしょう。
天才と呼ばれる人は、本を読み漁ったり、四六時中研究テーマのことを考え続けている。
そういう意味で、凡人は天才と比較して考える前段階にも達していないのではないでしょうか。
天才プログラマーが敢えて無駄なコードを書くとはないでしょう。
そうすると、凡人にとっての天才プログラマーのコードは、
凡人の異業種の分野(その分野特有の技術や取り決めがある)で、
その道のベテランが書いた無駄のないコードと大して変わらないと考えて差し支えないと思います。
Re:天才プログラマーってどんなコード書くの? (スコア:2)
stackoverflowで、Javascript logical xor で検索しても、(!X ^ !Y) の式が出てくる記事が見当たりませんでした。
(というか、Xが0001で真, Yが0010で真のときに真になっちゃう気がする)
よく出てくるのは、こっちの式で、こっちはちゃんと動きそうな感じですね。
((boolean1 && !boolean2) || (boolean2 && !boolean1))
Re:天才プログラマーってどんなコード書くの? (スコア:2)
そもそも、私のコメントでは、! をビット否定と勘違いしていましたが、論理否定なので、一応辻褄は合うんですね。
(javascriptでの整数->boolean変換は、0が偽で非0が真。boolean->整数変換は真が1で偽が0。!は論理否定なので、xが10だろうと100だろうと、xが真なら !xは、0。xが0ならxが偽なので、!xは1になるため、ビット排他的論理和を取っても、正しく動作する)
(!x ^ !y) だと、戻り値が0/1になるので、!!(!x ^ !y)みたいに、頭に!!をつけて、booleanへ変換できるみたいなことも書いてあって興味深かったです。
まあ、おっしゃるとり、「(x && !y) || (!x && y)」 の方が素直で読み間違いが無いので、私も書くならこっちで書きますが。