良いときは悪い

私は物語から始めたいと思います：

陶芸の先生は初日、クラスを2つのグループに分けると発表しました。 「左側に座っている人は、行われた作業量によってのみ評価され、右側にいる人は、その品質によってのみ評価されます。」 彼の方法論はシンプルで、最終日に彼はスケールをもたらし、グループ「作業量」の仕事の重さを量ります。50ポンドのポットは「5」、40ポンドのポットは「4」などです。 ただし、「品質」によって判断される人は、「5」を獲得するために、完璧ではあるがポットを1つ作る必要があります。 締め切りが近づき、奇妙な事実が発見されました。数量で推定したグループで最高品質の作業が行われました。 「量」グループは彼らの作品に執stampにスタンプを押し、彼らの過ちから学びましたが、「品質」グループは理想について理論化し、最終的には理想についての努力と壮大な理論だけでなく多くの役に立たないものを示すことができたようです粘土。

この物語はArt＆Fearからです。



まだ読んでいませんが、この話に一度出くわしました。

うまくいけば試すほど悪くなります。

ソフトウェア開発は難しい職業です。 プログラミングの方法を学ぶのは非常に簡単ですが、完全なソフトウェアシステムを実際に構築する方法を学ぶには、何年ものトレーニングと練習が必要です。



私が気づいたことの1つは、ソフトウェア開発者は生産性が非常に高い傾向があることです。



作業したさまざまなプログラムが入ったフロッピーディスクを持っていた日々を思い出します。 それから、ソフトウェア開発をよりよく理解し始めたようで、実際、生産性が低下し始めました。



なぜこれが起こったのですか？



私はいくつかの理論を持っていますが、主なものは、私たちが何をしているかわからないとき、私たちはただタスクを完了しようとしているということです。



覚えて、あなたは子供だった？ おそらくあなたはたくさん描きました。 そして、確かにこれらの図面はあなたの現在の基準から判断するとそれほど良くはないでしょう、あなたはそれらを恐ろしいとさえ呼ぶことができます。



なぜ今そんなに描くのをやめたのですか？ （たぶん、あなたはまだやっていませんが、ほとんどがやめています。） 「なぜそんなに描いたの？」という質問をする方がいいでしょう。



多くの答えがありますが、私たちのほとんどは、子供たちが単に学び、学ぶだけであり、制限によって制約されていないという理由の1つを決定すると思います。



ある時点で、私たちは年をとり、芸術とは何か、そしてそれがどのように見えるべきかを理解します。 正しく描画する方法さえ学ぶことができました。 最後に、私たちは良い絵が何であるかというアイデアを得ます。そして、それはこの鉛筆を拾うのが非常に難しいという事実につながります。

それで何が起こったのですか？

私は、私ができる限り生産的ではなかったし、できるだけ生産的ではなかった開発段階を経たことを知っています。



私は多くの時間を「タスクを賞賛」し、さらに「単純なものを複雑なものに変える」ことに費やしました。



ソフトウェア開発者として、私たちは限界を設定し、問題の完全な解決策を模索する傾向があります。



行き過ぎるまで：govnokodを書いて配布することは決して勧めません。 これをしないでください！



最適なソリューションを90パーセントだけ探してみることをお勧めします。最適なソリューションを見つける必要がある場合は、問題に再び戻ることができることを知って、最適なソリューションに95パーセント以上の時間を費やすのではなく、これを実行してください。



これは、これが私が苦労した中で最も難しいことであると以前に書きました。そして、それは多くの開発者に関係があると思います。



問題は、開発者として始めたとき、「正しい方法」がわからず、その行動があまり制限されないことです。 ただ先に進んでください。



「正しい」ことを学ぶようになると、この知識とそれに関連する制限を窒息させることがよくあります。 これにより、生産性が低下し、問題の冗長な解決策が発明されます。

だから、私は恋人がプロよりも優れていると思いますか？

あらゆる意味でそうではありませんが、多分彼らは何かが上手です。 多分それは彼らがもっと生産するということでしょう。



私の理解では、解決策は恐れることをやめ、制限をなくすことですが、知識と経験の知恵で自分を和らげることです。



私は自分でそれを適用し、ここ数年で私の生産性は信じられないほど成長しました。



開発者としての生産性を向上させた実用的なヒントをいくつか紹介します。

• 周りを見回す前に襲いかかります。 テクノロジーに飛び込む前に、テクノロジーに関する多くの理論を読むのをやめました。 最初にそれを読んでからそれを行う代わりに、私はそれを適用し始めてから知識を磨き始めました。
  
  
• どのように心配するのを止めてください。 多くの場合、特定の作業の方向または新しいプロジェクトを検討するとき、まず最初に実装方法を検討します。 これはやる気を殺し、時間の無駄です。 いつ 何 がより重要かはそれほど重要ではありません。 どのようにして詳細を掘り下げますか。 私は自分自身を信じ始め、必要なときにどのように見つけるかを信じました。
  
  
• 初めてずさんなことをすることを恐れないでください。 多くの場合、問題に対するクリーンなソリューションから始めたいと思いました。 多くの場合、時間の無駄です。問題を解決し始めるまで、適切なソリューションを開発するのに十分な知識がないためです。
  
  
• コードを書き直すことを恐れないでください。 これは私の最後の声明に近いものですが、それ自体が重要なので強調しました。 何かを書き換えることは、見た目ほど悪くなく難しくありません。 コードの一部を完全に書き直すことを恐れない場合は、動けなくなることなく前進するのに役立つほぼ最適な方法で問題を解決する可能性が高くなります。
  
  
• 完全なソリューションは存在せず、1つ以上のパラメーターに対して最適化されたソリューションのみが存在することを認識してください。 一部のソリューションは他のソリューションよりも妥協点が少なくなりますが、すべてのソリューションは、いくら努力しても妥協することはできません。
  
  
• 失敗することを恐れないでください。しかし、あなたがgaveめたからではなく、最善を尽くしたからです。 初めて解決できる小さな問題を解決するよりも、20回大企業に20回挑戦して成功を収める方が良いでしょう。 あなたが落ちる準備ができているまさにそのような高さに達することができます。 失敗の主なものは、あなたが倒れた場合、あなたは常に上昇することができるということです。
  
  

この物語の教訓...

私たちを混乱させ、麻痺させるので、良いことは悪いことです。 思考者ではなく、実行者によってはるかに多くのことが行われていることがわかりました。



ソフトウェア開発の「クラフト」に関する知識を生産性の障害にしないでください。さもないと、スキルや知識の少ない人が常に自分より優れていることを観察せざるを得なくなります。