「理論家」プログラマーになることを避ける

私はこの記事をSOに関するいくつかの投稿で見つけました。私は自分が6番目の原型に陥ることに気づきました。「理論家」。

「理論家」を次のように定義します。

理論家は、プログラミングについて知っておくべきことをすべて知っています。あいまいなプログラミング言語の歴史について講義したり、作成したコードが完全に最適ではないことの証明を提供したり、実行するのに3ナノ秒かかることがあります。問題は、理論家はソフトウェア開発に関することを知らないことです。理論家がコードを書くとき、それは非常に「エレガント」であるため、単なる人間はそれを理解できません。彼または彼女のお気に入りの手法は再帰であり、コードのすべてのブロックは、適時性と読みやすさを犠牲にして最大限に調整されます。

理論家も気が散りやすい。理論家は既存のツールでは不十分であり、新しいツールを作成して新しいライブラリを作成し、高い基準を満たすまったく新しいシステムを作成する必要があると判断するため、1時間かかる単純なタスクには3か月かかります。理論家は、プロジェクト自体の境界内でプレイして、究極の並べ替えアルゴリズムの作業に時間を費やすのをやめることができれば、最高のプレイヤーの1人になります。

単純なプロジェクトであるべきものに取り組んでいるときでさえ、私はすべてをゼロからやり直そうとすることで動揺する傾向があります（これはおそらく、私がゼロからオペレーティングシステムを作ろうとして約2年を無駄にした理由です。最終的に無意味だった）。

これを避けるのに何が役立ちますか？そしてKISSの原則に固執しますか？

ありがとう

私自身、理論家である私は、アジャイルショップで働くことで、こうした傾向をすべて迅速かつ断固として治すことができます。特に、ペアプログラミング（理想的には頻繁に回転）、テスト駆動開発、タイムボクシング、および境界スプリントを使用したeXtremeプログラミング操作は、同僚全員がすぐに見ることができるようになり、作業を開始して共同作業を行う必要があります分単位で。これは、理論家スタイルの仕事が盛んな孤立したオフィス環境での個別のタスクからの大きな変化です。誰もが継続的に他のすべての人に積極的に依存しているため、完全な正直さと完全な整合性が必要です。

私はいまだにへそを注視することを大切にしていますが、自宅で、またはメインライン開発の一部ではないオンザサイドのプロジェクトに取り組むことができるまれな機会にそれを満喫する必要があります。

1. あなたが開発することになっているものの目標を持っています。

2. これらの目標を近い将来に実現可能なものに絞り込みます。

3. 次に、それらの目標に焦点を当て、他のすべての考慮事項を排除します。背景なし。履歴はありません。拡張機能はありません。一般的または抽象的なものはありません。

4. 次に、可能な限り最小限に絞り込み、成果物を提供します。良くない。柔軟ではありません。メンテナンスできません。ただ許容できる。

5. それから、あなたができる最低限のことを達成するために必要な絶対的な最小値に優先順位を付けます。ポイントは、約1週間で日付を選択し、その日付に向けて構築することです。1週間以内に何かをお届けできない場合。狭い。フォーカス。トリム。減らす。

6. その後、綿毛を除去します。あなたは一週間しかありません。カットし続けます。

7. その後、できるだけ早く行われる実装の削減に焦点を当てます。理想的には、1週間以内であるため、ドキュメントを作成する時間があります。

私は理論家と仕事をしました。「エクストラ」は、失敗とラベル付けされる可能性のある何かを実際に行うことを避けるための言い訳だと思います。

することと失敗することは困難です。何かをすることについて話すことは、何かをするよりも簡単です。多くの研究と思考は、ユーザーが嘘をついたことを知ってから間違ったことをし、それをやり直すことを避ける方法です。

それらの前にコードを置くだけです。彼らはコードを失敗と呼びます。それは起こります。しかし、失敗する過程で、実際の要件が何であるかを学習します。そして、あなたは彼らが嘘をついたことを知るでしょう。

これがこんなに悪いことなのかはわかりません。明らかにあなたは生産的である必要があるか、仕事をしていませんが、分野に興味を持ち、芸術の学生であるため、いわば悪いことではありません。

私はあなたの強みを生かし、あなたのスタイルと好みが有利な機会を探します。

Erlang（またはおもしろいと思うもの）でMVCフレームワークを作成しながら、生産性を維持するために、おそらく1日1時間など、より難解な作業を制限する必要があります。残りの日は、うんざりした仕事に集中し、仕事を終わらせてください。気を散らすような何か面白いものを見つけたら、それをブックマークするか、メモを作成してから先に進み、割り当てられたタイムスロットに戻ってください。

個人的には、面白そうなURLがたくさんあり、図書館の本も山ほどあります。おそらく最終的にこれらのURLの10％に到達し、最終的には書籍の50％を読むかもしれませんが、それでも日中の仕事は完了しています。

私は自分でこの問題を抱えています。次の2つの手法が役立ちました。

1. Pomodoroテクニック、または一連の非常に短期的な目標を設定する他の時間管理テクニックを使用します。次の25分間で達成できることを把握する必要がある場合、有用な作業に集中できます。
2. テスト駆動開発。コードを記述する前に具体的なテストを作成する必要がある場合、空想を最小限に抑えます。（「優雅な」テストを書く方法はありません。）何かが機能するようになったら、リファクタリングするよりも多くの時間を費やすかもしれませんが、少なくとも想像上の理想ではなく実際のコードに取り組んでいます。

打ちすぎないでください。理論家に集中して有益な仕事をさせるのは、気にしない人に視野を広げるよりも簡単です。

stackoverflow.comを避けます。誤解しないでください-私は大ファンです-しかし、SOや他のプログラミング指向のフォーラムは、善の敵を完璧にします。しばらくすると、何千人もの賢い人が肩越しに見ているように感じ始めるかもしれません。何かを機能させて、理解できるようにしてください。改善が必要な場合は、いつでも再訪できます。

また、リンクしたような記事は避けてください。10種類のプログラマーがいると本当に信じていますか？または、あなたが知っている誰かが、説明されているカテゴリの1つに完全に当てはまると思いますか？このような記事には、少し真実が含まれているため、特定の魅力があります。自分自身や同僚の一部をステレオタイプで見ることができます。しかし、カテゴリーには占星術の兆候と同じくらいの水が含まれています。次回、会議後のミキサーに参加するときは、「こんにちは、私はコードカウボーイです！あなたのタイプは何ですか？」

それはあなたの質問が有効ではないということではありません-物事を考えすぎているなら、その傾向を避ける方法を学ぶことは良いことです。しかし、この懲罰にあなた自身をピジョンホールするように言わせないでください。

完全に展開したときに、このシナリオを回避する方法を完全に説明する1つの簡単なガイドラインがあります。

おそらく動作する可能性のある最も単純なことを行います。

-ケント・ベック

頭をクラウドから締め出す方法の1つは、理論的なAPIやフレームワークを書くことに加えて、実際のアプリケーションを最初から最後まで書くことを強制することだと思います。何かの周りにタイムボックスを配置して、その時間内にそれを「仕上げ」ようとします。フレームワークを書くには、設計パターンとアーキテクチャを十分に理解する必要がありますが、一定の時間内に完全なアプリケーションを書くには、非常によく設計されたフレームワークを書くこととは異なるスキルが必要であることがわかりました。

アプリケーションをこれまでに完成させたい場合は、ある時点で自分自身を現実のものにし、ただそれを成し遂げなければなりません。これには、デザインに犠牲を払うか、何らかの制約のために満足できない方法で機能を実装することを余儀なくされる場合があります。私はあなたのようなものです-何百万回も物事を書いたり書き直したりしますが、一定の時間内に実行しなければならないタスクに直面した場合、私は自分の戦いを選択し、最も重要なこと。

シンプル：

1. 実用的であること。

理論家の反対側（プログラミングドメインの情報/知識側に利点がある）は実用的です。

この回答で説明されているように、KISS、DRY、SOC、およびその他の考え方を適用することは、実用的であることを意味します。

この本を読むことで、実用的であることを学ぶこともできます：

http://www.amazon.com/Pragmatic-Programmer-Journeyman-Master/dp/020161622X/ref=sr_1_1?ie=UTF8&qid=1302893763&sr=8-1

理論と実践は、単独ではなく連携することを忘れないでください。多くの練習がなければ、知識は何もありません。多くの知識がなければ、すぐに練習を改善することはできません。

だから、たくさん練習してください。そして、多くを学びます。しかし、一方が他方を乗り越えないようにしてください。

プロジェクトで、期限を設定します。それに固執。次に、その締め切り前にプロジェクトを終了する方法について実用的に考えます。（実際に本を読んでください）次に、コーディングを開始し、知っておくべきことを読んで、読書からコーディングに切り替えて、読書時間を制限します。

Hrm ...たぶん、タイムラインの下でアプリケーションを書くことを必要とするビジネスに就職してみてください。私は、少なくとも仕事では、おそらくあなたができる限り理論家であるということから遠く離れていると思います。そのような仕事をすることには場所と時間があり、自分自身を成長させるために重要です。ただし、この種の能力は高く評価されていますが、ビジネスの世界、特に私が働いている場所にはありません。時々数週間でアプリケーションを作成し、クライアントが昨日それらを望んでいるペースの速い開発環境！私は素晴らしい開発者に恵まれており、全員がチームとして働くのに時間がかかりました。

私はできる限り優秀な人がいましたが、あなたのように、コードがうまく機能していても、本質的にはカスタムコントロールを書き始めた時点でさえ、常にコードの最後の少しを絞らなければなりませんでした環境によって提供されるものと同じ。とてもクールでしたが、時間通りに物を出す必要があったのは時間の無駄です。多くの場合、これらのサイドプロジェクトがチームをバックアップし、最終的に彼は他のチームからのプレッシャーを感じ始め、形を整えました。製品をプッシュしなければならない他の優秀な開発者とチーム環境で作業を開始することをお勧めします。事物をリファクタリングしてやり直したり、今までで最もけっこうなMergeSortを書いたりする時間はいつでもあります。ただし、製品が機能するポイントに到達してクライアントに提供する必要がある場合があります。

言葉の通常の意味で「理論家」であることには何の問題もありません。背景知識を持ち、最新のCS研究を理解できることは、優れた独創的なアイデアの宝庫であるため、持つことができる優れた能力です。

ここでの「本当の質問」は、記事の後半でより明らかになります。特定のプロジェクトの目標を把握し、他の目的ではなく、その目的に向かって作業します。この場合、それは本当に自制心の問題です。これについて詳しくは、S。Lottの回答を参照してください:)。

プログラミングから物事の達成、さらには動作するソフトウェアの提供まで、あなたの心を再集中させます。それはあなたの優先順位を正しく設定します。

これを達成する方法は別の話です。最良の方法は、いくつかのプロジェクトを考え出し、すべてのステップを経て、それを実稼働に投入することです。その後、以前とは異なる考え方を持つようになります。

この投稿をありがとう。それは私の仕事をさらに価値あるものにします。ソフトウェア開発者として働いている情報アーキテクチャの教育を受けているのと同じことを感じています。多くの場合、「何を変えるか」ではなく「どこを変えるか」に苦労しています。リレーションが多すぎて、スマートで汎用的なものが多すぎて、その仕組みを見つけるのに時間がかかりすぎています。

だから私は質問をし始め、それが実際にどのように構築されているかを知るまで、さらに質問をし始めます。教えてください-それは動作します。火事の質問が多ければ多いほど、元のアーキテクチャを維持することの重要性は低くなり、最終的に基本に戻る

if (weWantToMakeChangesToCodeLaterOnAndProbablyBySomeOtherProgrammer)
{
    Console.Writeline("We need to keep the code readable and simple enough ");
    Console.Wrietline("to make it easy for him/her to understand it!");
}

上司にメンターを獲得してもらい、メンターの言うとおりにします。

難しい部分は焦点を維持することであり、「ちょっと、オペレーティングシステムを書き直そう」があなたが与えられたタスクを終えるのに実質的に利益をもたらさないことを認識することです（これがプロジェクトマネージャーがしない理由です）。

また、コーディング前にメンターにすべての設計をレビューさせ、コーディング後に実際のコードをレビューさせます。これにより、何をする必要があるかに集中できます。

私は物事をオーバーエンジニアリングするのと同じ誘惑があり、それを乗り越えるには自制心と組織が必要です。他の人のためにコーディングするとき、ここに私がそれをする方法があります：

1. 個別のタスクを開始するときは、機能、品質、納期などに関して実際に必要なことを数分間考えてください。
2. コードの顧客の目標を念頭に置いて、それを行う方法を計画し、サブタスク、サブサブタスクなどに分解するために、もう少し時間をかけてください。
3. 各アイテムの時間を見積もり、不明なものを最大50％加算します。アイテムに4時間以上かかる場合は、さらに分解してください。（大学のプロジェクトをしている場合、スプレッドシートを使用しますが、複数のクライアントとのコンサルタントとして、Redmineと呼ばれる問題追跡システムを使用します。）
4. 最も重要なこと：私が思いついたアイテムのみを実行します。

もちろん、何かが起こります。時々、もっとやることが必要だと思うので、最初からやり直します。タスクが思ったよりもはるかに時間がかかる場合があります-最初からやり直してください。設計には後で詳細が必要になることが事前にわかっている場合があるため、再推定サブタスクを計画して、1番目からやり直します。

私がこれをやればやるほど、私はそれでより良くなる。自己鍛錬は運動によって強化される精神的な筋肉であり、物事にかかる時間の見積もりや技術的なトレードオフの改善も行っています。そして、パットン将軍からの引用を覚えておくと役立つと思います：「今すぐ激しく実行された良い計画は、来週実行された完璧な計画よりも優れています。」

一人の開発者として、私のワークフローはこれをカンバンボードなどのアジャイルの側面と組み合わせています。私は時々接線に出ますが、偏差を週に数時間に制限しようとしますが、それはかなりうまくいきます。

民間企業で働くことを計画している場合、「理論家」の衝動を制御することは本当に重要です。私が知っている最も優秀なプログラマーはシリコンバレーに住んでいますが、完璧なコードを手に入れるのが遅すぎるという評判があるので、長年仕事をしていません。