プログラミングは、底辺への競争における職業としてですか？[閉まっている]

プログラミング業界は底を争っているように思えます。私たちが次の慣行をとる場合：

1. ベストプラクティスの実装に時間をかけない
2. 他の人のコードを可能な限り使用する（責任としてのカスタムコード）
3. ますます高レベルの言語を使用して生産性を向上させる
4. 「プログラミング」を大幅に簡素化し、コードの背後にある配管を理解する必要のないGUIベースの開発「ツール」

これらのことは、私たちが他のオフィスワーカーのようになろうとしていることを暗示しています。スキルを必要としないこと（交換がより簡単）、事前に構築されること（プロジェクト時間の短縮）が雇用主の利益になります。

ここでの私のポイントは、a）スキルと雇用主の経済的利益との間にずれがあるということです。b）存在する場合、それをどのように緩和して専門的な基準を実施しますか？

あなたは非常に心を打つ質問をしたと思います。

GUIコーディングツールを作成すると、ロボットが組立ラインの作業者を仕事から外すのと同じくらいプログラマが仕事から外されます。私の意見では、仕事の損失がありますが、次の仕事がどこにあるかというシフトもあります。

タスクを完了するための技術は変わりますが、タスクはまだ完了する必要があります。車を運転する前に、まだ車を作成/組み立てる必要があります。アプリケーションが機能するためには、コード/ビジネスロジックをまとめる必要があります。

技術の変化は、プログラマーに選択肢を提供します。GUIベースのプログラミングまたはGUIツールのプログラミング...または...まったく別のものを学びます。

従業員のスキルと雇用主の利益との間に不整合が生じる可能性がありますが、特に雇用主が精通している場合は長くはなりません。したがって、雇用主と従業員の双方にとって最大の利益となるのは、相互に利益をもたらすものを追求することです。しかし、必然的に一方が他方より先になります。うまくいけば、それはあなたです（-：

ご多幸を祈る、

KM

あなたが言及したトレンドに、私はもう一つ追加します、私見はそれらを説明します：

これまでよりも非常に多くの（必要な）プログラマーがいます。

プログラミングを必要とする、または含むタスクの量は増え続けており、プログラマーの数よりもさらに高い割合で増加しています。現在、平均的な車にはいくつかのマイクロチップが搭載されています。5年後には、冷蔵庫とトースターにチップが入っているかもしれません。10年後、あなたの下着は？...そして、誰かがこれらのソフトウェアを作成してこれらを機能させる必要があります。そのため、自動化可能なものをすべて自動化し、「生産性」（定義されている場合でも）を改善するために、あらゆる努力が払われています。そして、ますます多くの新鮮な脳が採用されています。

これは、今日のアクティブなプログラマーの大半が経験が浅い、および/または自分の仕事に対する準備ができていないことを意味します。適切なレベルの経験を得るには数年かかり、そこに留まるには絶え間ない学習が必要です。一番下の行は、ますます多くのプログラミングの仕事がますます挑戦的になっています。しかし、彼らを探している人にはまだ十分な挑戦があります。

上記のあなたのポイントに対して悪魔の擁護者を演じさせてください：

ベストプラクティスの実装に時間をかけない

多くの人はそうではなく、多くの人がそうです。10年前、ユニットテストとアジャイルアプローチを初めて発見したとき、同僚は誰もそれが何であるかを少しも知りませんでした。今日では大学のほぼ標準的な資料であるため、多くの新卒者がすでにそれを理解しています。

他の人のコードを可能な限り使用する（責任としてのカスタムコード）

何とは対照的に？車輪の再発明？または、他の人のコードを使用してそれを回避しますか？

問題を解決するために（ほとんど）支払われていることに注意することが重要だと思います。1行のコードを書くことなく問題を解決できる場合でも、クライアントは満足します。特に、このようにすれば、より信頼性の高いソリューションをより迅速かつ安価に作成できます。私はそれについて何の問題も見ていません。

ますます高レベルの言語を使用して生産性を向上させる

アセンブリですべてをコーディングするのではなく、;-)

「プログラミング」を大幅に簡素化し、コードの背後にある配管を理解する必要のないGUIベースの開発「ツール」

私見どのツールも悪用される可能性があります。これは、GUIビルダーが必ずしも完璧または優れていたと言っているわけではありません-それらのほとんど（または少なくとも一部）は制限内で使用可能です。しかし、誰かがこれらの制限を知らない場合、それはツールまたはユーザーの問題ですか？

一般的に、私は（それを証明する証拠はありませんが）パンチカードとマシンコードの時代に、既存のコードのほぼ同じ割合が現在と恐ろしいものであったと信じています。

• コードの全体量
• 部外者がそのようなコードを見ることの可能性

はるかに少なかった。

現在、インターネットとDaily WTFにより、最悪の例に日々さらされています。テロや地震、離婚したセレブに関するすべてのニュースを見て、この世界がどれほど危険で不道徳になったかを叫ぶようなものです。

状況を正確に要約しますが、意味を完全に誤解します。

ソフトウェアがより強力になるにつれて、ソフトウェアがそれに伴ってスケールするタスク。確かに、今日では、Accessを使用できるときにデータベース連絡先データベースを作成して電話連絡先データベースを作成する必要はないかもしれません。そして、あなたがただワードプレスに行くことができるとき、ブログをセットアップするためにウェブプログラマーである必要はないかもしれません。しかし、15年前にはこうしたことを行うにはプログラマーである必要がありましたが、現在プログラマーがしていることは、15年前にできることよりも桁違いに大きいです。

このように言えば、今から100年後、facebookやgoogleのような複雑なシステムをセットアップするのは簡単です。私は彼らのウェブページについて話しているのではなく、彼らのデータセンターを意味しています。誰でもできるようになります。まだ使用していれば、携帯電話に組み込まれます。しかし、プログラマはまだ存在し、100年後にはそのような「些細な」システムに取り組んでいないかもしれませんが、はるかに複雑で洗練されたシステムに取り組んでおり、ここでは誰もその範囲を理解し始めることさえできません規模。そして、現在のようなシステムは、プログラマーと呼ばれる人々がその時代の技術を極限まで押し進めることに特化することを選択するため、平均的なオフィスワーカーの手の届かないところにあります。

私はこの種のことを今40年間読んでおり、予測の始まりにはいませんでした。まだ起きていません。

COBOLは、ビジネスプログラマの必要性を取り除くことを目的とした元の開発ツールであり、アセンブラよりもはるかに高レベルの言語でした。コードライブラリ（独自のコードを記述する必要を避けるため）は、同様の古代のものです。

プログラマーではない人がプログラミング作業のようなことをできるようにすることがしばしばあります。1980年代の「第4世代言語」、Excelのような派手なスプレッドシート、レポートジェネレーターなどがありました。成功した場合、彼らが一様に行ったことは、プログラミングから一部の枠組みを取り除き、プログラマが他のより興味深いことを行えるようにすることです。

このパターンは永遠に続くことはありませんが、プログラミングが実際に下り坂になっていることを確信させるには、理論的な議論や予測以上のものが必要になります。

COBOLから最新の開発ツールまでの問題は、不正確な仕様を採用して、それを正確で有用なものに変える機能を置き換えないことです。それがプログラマの基本的な能力であり、なぜ私たちが長い間立ち去らないのか。

アセンブリプログラミングとFORTRANプログラマは、構造化プログラミングと広範なインタープリターが登場するときに、おそらく同じことを言っていました。

結局のところ、ソフトウェアは、以前は手作業で行われていた何かを自動化することを意図した作成物です。中規模企業の経理部門では、以前は数十人が必要でしたが、今ではすべての作業を1人または2人の作業で行うことができます。その結果、目標の投稿が移動し、会計士からの追加の能力基準が期待されるようになりました。

ムービーのレンダリングにこれまでにないほど時間がかかります。コンピューティング速度が大幅に向上しているにもかかわらず、アニメータはシーンの複雑さとディテールの増加を要求しています。トイストーリーのキャリバーアニメーションは、1995年のように2010年には受け入れられません。ツールが進歩するにつれて、機能も期待も高まります。

ドラッグアンドドロップまたはその他のプログラミング方法が一般的である場合、世界はさらに困難で複雑な問題に対するソリューションを要求し、それらを解決するためにそれらの新しい派手なツールを使用するプログラマが必要になります。目標の投稿が移動します。

私はまだやるべきことがたくさんあると指摘する答えの大部分に同意しますが、私はあなたが考慮すべき別の答えを与えます：

はい、そうです、そうすべきです

私は他の人ができない問題の解決策を設計するためにここにいます。ツールセット内の問題を解決するのに時間を費やして、設計を実装する方法の細かい部分をすべて処理することは無駄です。

高レベルの言語や、よりシンプルでより抽象化されたツールに行くことを恐れる唯一の理由は、それらのツールがしばしば邪魔になる仮定を行い、望ましい実装を得るために仮定を回避するために時間を必要とすることです。

良い問題解決者がいるよりも、解決すべき問題が常に多くあります。開発者チェーン全体が非常にシンプルになったとしても、ほとんどの人はすべてのエッジケースの問題に対する正しい解決策を見るのが苦手なので、設計されたソリューションのほとんどは不十分であるか、人々がより良いソリューションにお金を払うほど十分に非効率です優れたソリューションを作成するために考慮する必要があるwhat-if。

私たちの仕事は、他の大部分よりも問題を解決することです。ツールチェーンの複雑さは、邪魔にならないように、あなたが構築し、何か良いものを構築できる限り、全体像ビューにはそれほど関連しません。

プログラミングテクノロジーは変化する可能性がありますが、ソフトウェア製品の根底にある複雑さは依然として存在しています。ダイアグラムまたはフローチャート（または他の「単純な」方法）を使用してソフトウェアを完全に作成できる場合、ソフトウェアの複雑さをすべて理解し、対処する必要があります。そのため、会社の製品を完全に知っているプログラマーを雇って、それらを更新したり新しい機能を追加したりすることが重要です。また、従業員がソフトウェア製品を習得するにはかなり時間がかかる場合があります。

何を自動化または棚上げすることができるかに関係なく、ほとんどのパッケージソフトウェアは2つのカテゴリに分類されます。

1. 使い方は簡単ですが、ビジネスが本当に必要とするものとは完全には一致しません
2. 高度にカスタマイズ可能ですが、カスタマイズを理解して活用するには専門家が必要です

標準の生産性ソフトウェア（メール、ブラウザ、ワードプロセッサなど）を忘れたのではないかと思います。カテゴリ1のソフトウェアは、市販ソフトウェアをカスタマイズするためにソフトウェア開発者を雇う企業につながります（可能な場合）。カスタマイズ可能なシステムの内部と外部をよく知っている人は（SAP、PeopleSoftなどを考えて）強く求められているか、死にかけている（SAPやPeopleSoftに似ていないシステムを考えて）同じ市場浸透がある）。

開発者には常にニーズがあります。私が見ているのは、以前は手作業で退屈で繰り返し作業だった作業の多くが自動化されたことです（O / RMを使用するよりも手作業でデータにアクセスするためのコードを書くことを考えてください）。これにより、開発者は少ない労力でより多くの価値をビジネスに提供できます。

私はあなたの主張を受け入れません：

1. ベストプラクティスの実装に時間をかけない

それ以外で。

1. 他の人のコードを可能な限り使用する（責任としてのカスタムコード）

コードの再利用はベストプラクティスです。使用済みコードがテストされます。もちろん、多くの人によって維持され使用されている優れたソースのコードを使用する必要があります。

1. ますます高レベルの言語を使用して生産性を向上させる

生産性自体は悪くありませんか？

1. 「プログラミング」を大幅に簡素化し、コードの背後にある配管を理解する必要のないGUIベースの開発「ツール」

ツールがジョブを実行する場合：使用します。そうでない場合：拒否します。約束が成り立ち、人々が本当にコードを理解する必要がないなら-よくやった！あなたはこれが成り立たない約束だと言っているようですか？

（ここの数字は自動的に間違って表示されます。:)）

ビジュアルプログラミングは、テキストベースのプログラミングと同じくらい有効または軽orに値します。

視覚的にプログラミングする場合、特定の欠陥と課題がありますが、無視されると潜在的に危険な基礎となるコンポーネントの配管は、視覚コンポーネント、より適切には視覚デザイナーによって独占されません。基礎となる配管が無視されることは、開発のリスクです。

Labviewを試してみる機会があれば、その可能性（またはLego NXT環境の特殊なバリアント）が見つかるかもしれません。欠陥や欠点がないわけではありませんが、継承のメリットがあります。百聞は一見に如かず。

プログラミングの実践は、生産性を高め、特定のタイプの開発（下から下への競争）のコストを削減するだけでなく、アプリケーションの機能と顧客の期待を高めます（したがって、上への競争を促進します）。GooleとFacebookが最高の技術者を獲得するために払っているボーナスを目撃してください。

プログラミングと同じくらい変化に向かって努力する存在工学を扱う他の職業はありません。何かを単純化するとすぐに、新しいアイデアを生み出す新しい問題に缶を開けるだけです。

だから私は、個人の実践者の悪い慣行、悪い習慣、そしてヒューマニズムのないマナーで新しい挑戦、アイデア、ユーザー体験に向かって進むのを助けるために、コードと解決策を共有する他の人々の努力を汚しません。

私たちが次の慣行をとる場合：

WTF？このリストが矛盾しているということですか？リストは、警告なしに前後に切り替えるのではなく、各要素の同じ側から取得する必要があります。したがって、リストは次のようになります。

私たちが次の慣行をとる場合：