プログラミングではなく、タスクに必要なプログラマとして何をしているのか (例: ローカル セットアップ、サーバー セットアップ、展開など)。人々が実行しているプログラミング以外のタスクの数を知りたいです。
たとえば、Web 開発プロジェクトでは、次のことがよくあります。
Web 以外のプロジェクトでは、次のことがよくあります。
一部のタスクは他のタスクよりもプログラミングに関連していますが (ビルド スクリプトの作成など)、他のタスクは私の専門分野から外れています (ドメインのセットアップが思い浮かびます)。プログラミングに関係のない仕事で何人の人がタスクを実行しているかを知りたいだけです。
悲しいことに、非技術者は技術者を見て、技術に関連するすべてのことを彼らが知っていることを期待しており、技術には私たちが何も知らないかもしれない専門分野があることを理解していません。
特定の分野を専門とする医師のようなものだと思うことがよくあります。すべての医師は、医療分野の知識のベースラインを持っていますが、他の専門分野の詳細を知りません (心臓専門医は麻酔学についてあまり知りませんし、その逆も同様です)。
したがって、技術者がすべてを知っていると人々が期待するのは不合理だと思いますが、技術に関して私たちが何かを知っていると人々が期待するのは合理的だと思います.
この質問のより重要な側面は、自分のスキルを適用する特定の領域 (金融、製造など) について、どれだけ知っていることが期待されるかということだと思います。その分野の知識を持つことで、プログラマーとしての問題をより深いレベルで理解できるようになり、その結果、より包括的なソリューションを提供できるようになるため、これは非常に重要だと思います。
期待される？ほとんど何もありませんが、あなたがもっと知っているとき、誰もがいつも本当に幸せです。
プログラミングの狭い範囲の外であなたが知るほど、あなたはあなたの雇用者にとってより価値があります。
私のために思いついたもの：
私がプログラミングの仕事で最もよく使う非プログラミングスキルは書くことだと思います。アイデア、デザイン、アルゴリズムなどを説明できることは非常に重要であり、実際にそれを行うこと（または時間があること）を期待することはできません。私は、他のエンジニアが私のコードとアルゴリズムに頭を悩ませることができるように、設計ドキュメントやその他のドキュメントの作成にかなりの時間を費やしています。ですから、学校で良いライティングのクラスがあり、文章をまとめることができて本当に感謝しています。:-)
勤めている会社の規模にもよると思います。主に中小企業で働いてきた私は、以下の業務も担当してきました。
内部アプリケーションをサポートするデータベースの作成、管理、および調整 Web サイト証明書の管理を開始する 外部ホスティングを設定します。他にもあると確信しています。
私は実際の仕事のために雇われているのではなく、問題解決者として雇われていることに気付きました。何が起こっているのかを理解し、それをコード、ソフトウェア、またはネットワーク上の何かで修正するかどうかにかかわらず、これがクライアントが何を望んでいるのかについての主な認識のようです.
プログラマーの主要なツールはコンピューターなので、ある程度の専門知識があると想定しても問題ないと思います。あなたが説明したようなことのほとんどは、コンピューターに不慣れな人にとっては難しいことですが、ドメインを理解し、ドキュメントを見つけて読む方法を知っている人にとっては (経験がほとんどなくても) 非常に簡単です。
組織化された大規模なビジネスやプロジェクトでは、この種の管理業務に精通した人物が担当することを期待しています。ただし、フルタイムの仕事を保証するのに十分な数がいない場合は、有能な人に仕事をさせるのは不合理ではないと思います。プログラマーはおそらくその点で先頭に立っています。
ユーザーが発見した「バグ」の大部分は、アプリケーションがインストールされているシステムの構成の問題です。一般的なマシンとネットワークのセットアップ エラーを理解している開発者がいることは、非常に望ましいことです。
たとえば、アプリケーションが操作の一部として電子メールを送信する場合、開発者に DNS および SMTP 構成の知識があると便利です。
もちろん、ビジネスの規模にもよりますが、大規模な組織では、他の専門家を利用することで、おそらく開発者をこの問題から守ることができます。
多くの場合、会社の規模によって異なります。小さな会社では、たとえあなたの仕事がプログラミングに集中しているとしても、システム管理者やネットワーク管理者を含むすべてを行う方法を知っている必要があります。
大企業では、宇宙の小さな断片を見ることができますが、彼らはあなたが箱の外を覗くのを嫌うことがよくあります。あなたがすべてを学ぶ必要がないだけでなく、あなたが試みた場合、彼らはしばしばあなたに不満を抱きます。
ただし、マシン、マシンの動作、および運用環境での機能について理解を深めるほど、問題の診断とより優れたソフトウェアの作成が容易になります。アプリケーションを作成しているドメインについて理解を深めるほど、ユーザーのニーズとユーザーの要望をよりよく区別できるようになります。
ソフトウェア開発者であることの最もクールなことの1つは、テクノロジーとさまざまなビジネスドメインの両方に鼻を突っ込むための生涯にわたる言い訳があることです。いくつかの異なる業界にシフトした場合、あらゆる種類の興味深い情報が満載になる傾向があります。学ぶべきことは常にたくさんあります...
ポール。
他のテクノロジーに触れることは良いことですが、あなたがそれらの分野（特にドメイン設定）の専門家ではないという事実を完全に開示しないことは本当に悪い考えだと思います。私は、すべてを実行できると思っていたが、それらのタスクを実行するのが非常に貧弱だったため、それを正しく行うために費やしたすべての時間（およびお金）で、コンサルタントに数回の支払いがあっただろうと思っていた人々と協力しました。 。
私は、ドメイン、PC、データベース、カスタムソフトウェア、ビルド、MS Office、PowerPoint、Quickbooksなど、「コンピューターに関連する」すべてを担当している会社で働いてきました。開発と構築を行っていた中堅企業。そして、私がプロジェクトの.Netコードのみに焦点を当てている大企業（他の誰かがデータベースを処理し、別の誰かがレポートを処理します）。
中堅企業はこれまでのところ最高の経験であり（大企業ではかなり新しい）、私は有用であると感じるのに十分な責任を与えられ、他のすべての人に簡単にアクセスして他のタスクについて質問することができました。
【暴言モードON】 はぁ、エクセルとワードの呪い。
社外の仕事 - 特に友人や家族ですが、コンサルティングやソフトウェアの配布の際にも、技術者以外のすべての人がこれらを理解することを期待しています。誰かが Office のいくつかの面で抱えている小さな問題を見てほしいと頼まれたとき、その内部のうめき声があります。そして、それはクライアントであり、あなたは役に立ちたいと思っているので、あなたは同意します.
あなたが開発者であるため、スプレッドシートの構成、Word テンプレートの修正、およびその他すべてのオフィス技術者のタスクに関する生来の知識があり、さらに、不適切に構成された Office の混乱に目を向け、即座に診断できるという、この漠然とした期待があります。問題は何ですか。
スプレッドシートをまとめて繰り返し発生する請求書をスケジュールし、それらを作成するための Word テンプレートを設定することしかできません。私も定期的にそう言っていますが、誰も聞いてくれません。
これは、あなたがどこにいるかによって大きく異なります。私は、このようなことをまったく知らない人や専門家と一緒に仕事をしてきました。
これを知っておくと大いに役立ちます。一般に、コードが実行されている環境を理解することは常に良いことです。コンテキストを理解していないと、いくらか無力になります。
さらに、多くの場合、コード関連ではなく構成関連のバグがあります。たとえば、Apache 構成が原因でページが表示されないなどです。環境を理解していないと、デバッグに非常に不利です。
個人的には、より多くのことを知ることは常に良いことであり、次のレベルへの道を開くものだと思います. 人生で最も難しいのは統合点です。文字通り。人々は専門化することに重点を置いていますが、両方の領域にまたがることができる人が必要であることを忘れないでください。
あなたは一人ではありません。私がサインアップしたポジションは「ASP.NET Web 開発者」でした...ただし、私の仕事は次のとおりです。
最高の「運用効率」を常に追求している会社にいるため、私のタスク リストは日に日に増えていきます。私もそのリストを作りませんでした。上記のすべての項目について、私はこの会社で働いてきた過去 3 年間に触れたりサポートしたりしました。
そうは言っても、優れた開発ショップでは、特定のタスクが 1 つあるはずです。ことわざにあるように、すべての取引のジャック...誰のマスターでもありません。
これは、プログラミングする内容に大きく依存します。低レベルのデバイス ドライバーを作成している場合は、基盤となるハードウェアを理解することが重要です。スタンドアロンの Java アプリケーションを実行している場合は、使用している JVM とライブラリについて理解を深めるほど効果的ですが、厳密に多くを知る必要はありません。
一般に、システム環境について理解すればするほど良くなります。同僚や経営陣があなたにどの程度の知識を期待するかは、彼ら次第です。
無知は最終的に罰せられます。あなたの同僚や経営陣によるものでなければ、世界がそれを行うでしょう. システム環境の無知がソフトウェア障害を引き起こす例については、週の見出しまたは RISKS ダイジェストを確認してください。
職場の人々はおそらく、プログラマーが IT ヘルプデスクの担当者であることを期待しています... 私にはそれが起こります。ああ。
私が働いている場所では、すべての開発者が Subversion を使用できることが期待されており、自分の PC で Apache と Tomcat をセットアップおよび構成できる必要があります。
最大の課題は、環境を立ち上げて実行することに関連する技術的な問題ではなく、小さなショップでソフトウェアを効果的に開発するために必要なドメインの知識です。私は、ほぼ隔離された開発環境で、さまざまなソースからさまざまなプロジェクトに取り組んでいます。これは、ソリューションを効果的に開発するために、プロジェクトのドメインについてかなり迅速に理解する必要があることを意味します。過去には、印刷会計ソリューション、アクティブ ディレクトリ管理、研究調査データベース、そして現在は慈善団体向けの準 CRM ソリューションに取り組んできました。開発環境とビルド環境をセットアップする基本的なことだけを知っていればよかったのにと思います。
現在開発しているソフトウェアの種類に大きく依存します
たとえば、地方自治体のソフトウェアを担当していたとき、次のようなことを学ばなければなりませんでした。
これは、2 年間のプロジェクトで学んだ、プログラミング以外のことのほんの一部です。ここで最も残念なことは、私が別の会社に引っ越した今、私がこの知識を使用する可能性はほとんどないということです.
私の肩書は「シニアソフトウェアエンジニア」です。実際のところ、過去数年間のほとんどの間、私はソフトウェア開発をほとんど行っていませんでしたが、多くのことを行いました。
システムとウェブ管理
HTML を使用した静的 Web ページの開発 (PHP、CGI、および JavaScript を行ったことはありますが、プログラミングは考慮していません)。
他の人が言ったように、ヘルプ デスクは以前ほどではありませんが、一種のものです。
「タスク リーダー」として、私はある程度の人員/管理スキルを持っていることが期待されますが、通常は月次レポートを書くことになります。また、CMMi の話にもときどき夢中になります。これは、理想的な世界ではある程度関係があるかもしれませんが、通常は、雇用主がそれを必要とする新しい契約に入札できるように記録を保持するだけです。
科学研究所で働いていると、特に科学計算を行うコードに取り組みたい/必要がある場合は、科学の一部を知る必要があります。
(米国) 政府機関で働く場合、多くの事務処理があり、多くの政府規制 (情報公開法など) を知る必要があります。
幸いなことに、私は最近社内異動を行い、開発作業を増やし、他の作業を減らしました。