"下手に考えると、プログラミングとはコード文を一行ずつコンピュータに打ち込んでいくだけのことだと思うかもしれません。ウォード・カニンガムは、『』の序文でこう述べています。
ソフトウェア開発には、設計、問題解決、最適なアルゴリズムの発見、新しい言語の学習、乱雑なコードをリファクタリングしてすっきりとエレガントにするなど、多くの深い思考が必要です。
自分がやったことのないこと、あるいは誰もやったことのないことをやろうとしているとき、あるいはやったことはあるけれども同じようなミスを犯したくないのは間違いなく、より良い方法を考える必要があるとき、あるいは他の人が書いたコードを変更するために理解しようとしているとき、あるいは厄介なバグを探しているとき、こうしたことはすべて多くの時間を費やしますが、最終的には多くのコードにはなりません。
また、ソフトウェア開発には、タイピングが多く、あまり考える必要のない仕事がたくさんあります。例えば、あなたが何をする必要があり、どのようにそれを行うかを正確に知っているにもかかわらず、仕事の終わりには、似たようなことを行ったので、別のスクリプトで、別の画面、別のレポート、別の全てに適応させ、もう一度行う必要があるだけで、たくさんのコードを書く必要がある場合、あるいは、考える必要がある仕事のほとんどは、プログラムがどのように見え、どのように感じ、どのようにデータが流れるかを正確に記述したワイヤーフレーム図をあなたに提供した誰かによってすでに行われている場合、あるいは、詳細なAPIの説明を提供した誰かによってすでに行われている場合、あるいは、考える必要がありすぎるアプリケーションをあなたに提供した誰かによってすでに行われている場合です。あるいは、プログラムの外観や操作感、データの流れを正確に記述したワイヤーフレーム図を提供してくれたり、詳細なAPIの説明を提供してくれたりした人が、その仕事に必要な思考のほとんどをすでにあなたのために行ってくれているかもしれません。
プログラムのデバッグは思考作業です。バグを修正し、テストを経てリリースするのは、主に入力作業です。初期の設計と開発、使用する技術の決定とフレームワークの設計は難しい思考作業であり、それに基づいて3つ、4つ、あるいは100の画面やレポートの適合を開発することは入力作業です。ユーザーエクスペリエンスとプロトタイピングは思考作業であり、それを実現するのは入力作業です。モバイルアプリのクールなアイデアを見つけるのは思考作業であり、それを実現するのは入力作業です。一般的なビジネス上の問題を解決するには多くのコーディングが必要ですが、ソフトウェアを通じてビジネスプロセスを最適化するには多くの難しい思考が必要です。
つまり、仕事について考える人は、仕事をインプットする人とは異なる仕事をしており、異なる方法で管理する必要があるのです。
プログラミングは入力を打ち込むだけ
「最初はタイピスト、次にプログラマー。ジェフ・アトウッド『 Programming Horror
多くのビジネスプロセスは本質的に浅いものです。多くの要素やデータで満たされた多くのデータベーステーブルやファイル、互いに類似点の多い多くの追加/削除/レビューページやレポート、制約を満たし、運用上独立するように異なる属性の違いをマッピングし調和させるための多くの統合作業。機能要件の長いリスト、全員が要件を理解していることを確認するための多くの質問、メモや追跡のための多くの詳細な説明。これは、銀行、保険、政府、会計、財務諸表と請求、在庫管理とERPシステム、CRMシステム、オンプレミス・アプリケーション、簿記システム、記録管理システムなどに当てはまります。多くのオンラインポータルやショップも同様です。プラットフォームのアップグレード、システムの統合や移行、税制の変更など、保守的な作業も同様です。
家を建てる、橋を架ける、デパートを建てる、あるいはそのいずれかを改装する......。大規模なプロジェクトでは、多くの場合、解決に多くの時間を要する問題が絶え間なく発生します。多くの入力作業が必要ですが、その中には過去に何度も行われたことがあるものもあり、その作業には似たような問題が含まれるため、使い慣れたパターンや実績のあるツール、作業方法を適用することができます。
設計が確定し、作業の大部分が完全に理解され、細部まで検討されたら、あとはプログラマーを管理・調整してコードを書き出すだけです。これは古典的なプロジェクト管理プロセスです：予算、計画、コストと調整の追跡、プログラムの管理。論理性、規模、一貫性、効率性を重視し、仕事が正しい軌道に乗るようにします。
考える考える考えること
ゲームエンジンの設計、取引アルゴリズム、ロジスティクスやオンラインリスク管理システム、リアルタイム制御システムの最適化など、その他の問題は、入力コーディングよりも思考が必要です。これらのシステムには、高い基準、非技術的な要件、複雑なロジックがありますが、緊密に結合した一連の問題を解決することに集中しています。そのような問題を考え、実装できるのは、ごく一部の賢いプログラマーだけです。もちろん、特に "周辺 "の部分、フレームワーク、配管、配線方法などのコーディングはまだ必要ですが、特に失敗した実験やプロトタイプを捨てた後では、核となるコードは通常非常に少量です。
著作権や特許で保護されたアルゴリズムや設計の洞察が、成功するシステムの核心となる、ソフトウェアの神秘がここにあります。この種の仕事には、研究に費やした多くの時間、数え切れないほどのプロトタイプ、問題解決能力、そして強力な技術スキルか深いドメイン知識のいずれか、または両方が必要です。
コード入力と思考は異なる種類の作業
仕事の性質がコーディングベースか思考ベースかは、チームに必要な人数やタイプに影響します。そうすることで、従業員同士の働き方や、チームの管理方法も変わってきます。コーディングは外注できますが、思考は外注できません。コーディングで解決できる問題とそうでない問題を認識し、思考ベースの仕事がコーディング入力ベースの仕事に移行するタイミングを見極める必要があります。
考える仕事は、少人数でも専門のチームに任せるか、天才に任せるべきです。デザインを考え抜いたり、複雑で反復的な問題を考えたりする段階では、大勢は必要ありません。この種の仕事をする人は、その仕事に完全に没頭する必要があります。この間、彼らは探索的な調査を行い、間違いを犯し、学び、行き詰まったときには、ただ呆然と画面を見つめているかもしれません。
この段階は非常に重要です。なぜなら、ここで犯したミスはたいてい致命的だからです。例えば、誤った技術プラットフォームを選択すること、リアルタイムシステムの許容レイテンシを誤って想定すること、高信頼性ソリューションの探索に多くの時間を費やすこと、誤った人材を選ぶこと、あるいは誤った問題を解決しようとすること、プロジェクトのリズムを狂わせることなどです。
この種の仕事を管理するには、優秀な人材を見つけ、彼らが集中できるよう適切な情報とツールを用意し、外部からのリスクに気を配り、邪魔が入らないようにすることが必要です。
考える仕事は予測不可能。どこから「コピー＆ペースト」すればいいのかわからないので、「コピー＆ペースト」の方法はありません。この種の仕事は、わからないことがどれだけあるかわからないので、見積もることはできません。しかし、制限時間を設定し、その時間内に最善の解決策を見つけようとすることはできます。
コード入力タイプの仕事は予測可能です。この種の仕事は、同時に見積もることができますし、そうしなければなりません。そのコツは、コーディングが必要なすべての作業のリストを作成し、その作業で発生する可能性のあるエラーやバリエーションをすべて見積もることです。プログラマーの不注意、要件の誤解、テストの省略、単純な「コピー・アンド・ペースト」など、プロジェクトが進むにつれて、これらのエラーは通常すぐに積み重なり、現在および将来のコスト増につながります。
コーディング入力は労働者の仕事です。飽きる前に大きなチームで働ける上級開発者もいますが、専門家である必要はなく、言語と使用するツールの基本を理解し、注意深く進んで指示に従うことができ、忍耐力のある人であれば、この種の仕事をこなすことができます。タイピスト」のグループを管理するには、政治家、外交官、ロジスティシャン、標準化担当者、管理者、エコノミストなど、さまざまなアプローチやスキルが必要です。あなたが管理するのは、技術ではなく、プロジェクトや人のリスクなのです。
しばらくして、「何をどうすればいいのかわからない」という苦労がほとんど解消され、未知の部分がマスターされると、考える作業はインプット作業となり、細部を埋めてプロセスを機能させる時間になります。
システムがユーザー数を増やし、より多くのインターフェイス、ロケーション、ローカライゼーション、Eメール、サマリー、サポート、コミットメントに対応しなければならなくなると、より多くの入力ベースの作業が必要になります。システムは成長し続けますが、ほとんどの問題は身近で解決可能です。膨大な量のコードを見つけ、学び、コピーしなければなりません。その中から必要なものを選び、素早く入力できるプログラマーが必要です。
思考とコーディング／入力
考えることとコーディングすることは、どちらもソフトウェア開発の重要な要素です。
』でブレンダン・エンリックは、結び目がプログラミングに役立つ理由を説明しています。
「どちらも考えてはいるのですが、考えていることが違うのです。開発者はキーボードを持ち、それに没頭するあまり、アプリケーション全体の構造ではなく、現在のコードのロジックに従ってコーディングします。しばらくすると、コーディングのスピードが上がります。
ペアプログラミングで実際にコーディングしない人は、考えることにすべての時間を集中します。コーダーの仕事の流れは頭に入っていますが、実際のプログラミング言語のシンタックスには関心がありません。コーダーの後ろに座るこの種の人は、作業が正しい道筋で進んでいるかどうかを確認し、それを達成するために最も効率的な方法を使用しなければならないガイドのようなものです。"
優れた開発者であることは、単にコードを打つことよりも、有能なコーダーであることは、単にキーボードを打つことよりも優れています。つまり、十分なプログラミング言語の機能を備えていること、どのツールをどのように使うべきかを知っていること、コードを読むことができること、そしてもちろんコードを書く方法を知っていること、ツールをコントロールすることを学ぶこと、より柔軟に対応できるようにどのようなコーディングが速いかを知っていること、これらすべてが開発者として引き継ぐために必要なことなのです。最後に、コーディングのインプットを軽視せず、インプットすべき作業を考える作業にしないことです。
