EE対コンピューターサイエンス：開発者のアプローチ、スタイルへの影響？[閉まっている]

ソフトウェア開発者（SWエンジニア、アーキテクト、職種など）と、電子工学やその他のエンジニアリングのバックグラウンドとの間に、コンピューターサイエンスを通じて専門職に就いた人と体系的な違いはありますか？

電子工学の背景とは、EEの学位、または独学の電子工学の修得者、他の種類のエンジニア、実験物理学者を意味します。

フリップフロップ、トライステートバッファー、クロックエッジの立ち上がり時間などの強力な知識からソフトウェア作成の専門家になると、通常、特定の専門分野と欠如の問題、考え方、または優れたスキルへの明確なアプローチにつながるかどうか疑問に思っています抽象データ型、オブジェクト指向、データベースの正規化、プログラミング言語で「クロージャー」を話すような概念に満ちたコンピューターサイエンスタイプと比較した場合、他のスキルのスキル-はんだごての群衆にとってほとんど意味をなさないもの十分なプログラミングを学びます。

現実の世界では、個々の例外が広範囲にわたっていると確信していますが、ほとんどの場合、全体的な違いがあると言えますか？これらは、たとえば「何かを構成するために」「データベース設計を行うために電子ラングラーを雇うな」という雇用への影響があるでしょうか？違いを知ることは、求職者がより適切な何かをより効果的に見つけるのに役立ちますか？または、特定の職務で自分が不適当であると感じる人に、啓発や実践的なアドバイスを提供しますか？

（ところで、私はコンピュータサイエンスの授業を受けたことがありません。それらがカバーするものの正確な印象はあいまいです。私はエレクトロニクス/物理学/アートタイプです、私です。）

EEマイナーとCSメジャーを持って、私は両方のグループと学術的に仕事をしました。EEスタイルの製品を設計した仕事をしたことはありませんが、PLCのような企業で仕事をしているので、その多くを消費しているので、何が起こっているのかを（学歴から）理解できました。したがって、職場の行動と特性について100％知っているとは言えませんがacademic、この2つの違いをある程度説明することはできます。

EEの人々は詳細に集中する傾向があり、正確な実装を知っている傾向があります。100％マップ可能でない場合、彼らはそれを好まない。EEの人々は、可能であれば、不要な詳細を削除するために最適化します。

SEの人々は、レイヤーと論理の区分化を好む傾向があります。SEの人々は肥大化したプロジェクトを気にしません。SEの人々は非常に数学志向である傾向があります。彼らは方程式の観点と、パターン概念から問題を解決する方法について考える傾向があります。データベース作業のように、結合はこのグループに対してより直感的です。SEをさらに進めると、関数型プログラミングなどに堪能な人に会う傾向があります。それは、EEの人にとって安全な根拠ではありません。

両方の人がカルノーマップのようなものを知っているので、それらの領域には多くの重複があります。ロジック削減、そのようなこと。

わかりました、それは私の主観的な答えです。それが役に立てば幸い。

一般化する必要がある場合、私の経験は次のとおりです。

• エンジニア（またはEEのみ）は、「小さなものの完成度」でより良くなる傾向があります。小さなプログラミングタスクを考えると、彼らはすべてのエッジケースについて非常に長く難しいと考え、非常に堅牢なソフトウェアを構築する可能性が高くなります。通常、ハードウェアで慣れているため、トップダウンの設計から全面的なアプローチに基づいています。通常、ステートマシンはハードウェア用に設計するために使用されるため、ステートマシンの使用を伴い、「ビッグデザイン」アプローチに適合します。反対に、彼らはスケーラビリティや保守性についてあまり考えていません。

• 従来の開発者は、大規模な複雑さの管理に優れています。これは主に、トレーニングが問題をより小さな管理しやすいビットに分解するためです。彼らは大きなデザインを避け、懸念を分離し、テストを書き、テストに合格するように教えられています。通常、複雑さと時間のために、見逃されたエッジケースがたくさんありますが、それらは最終的に隠されます。開発者は、それが単なるソフトウェアであり、変更する必要がある（または変更しやすい）という事実を利用する傾向があります。EEがハードウェアで動作する場合、EEにはこの利点はありません。移行を行うには時間がかかると思います。

私が言ったように、それは私の一般的な経験です。すべての場合に当てはまるわけではありません。

私の経験では、EEタイプは線形プログラムを設計しているようで、CSタイプが快適であると思われる抽象化レイヤーを組み込んでいないようです。

品質の違いや不足についてのコメントはありません。

両方とも数年の経験があると、ほとんどの人が最終的に取り組んでいる通常の種類のビジネスアプリやWebアプリに大きな違いがあるとは思いません。「はんだごての群衆」を混乱させるものとしてリストするものはすべて、通常のプログラミングスキルです。本質的にあなたはあなた自身の質問に答えています-プログラミングのバックグラウンドを持たない人はプログラミングを学ぶことができますが、彼らがやるまで彼らはプログラマーではありません。論理的かつ分析的な精神を持つ人は、そうでない人よりもプログラミングを学ぶことの方がはるかに簡単だと思うでしょう。

コンピューターサイエンス（コンピューターエンジニアリングとは対照的に）は、物理学などのさまざまな他の科学と同じように（より高いレベルで）圧倒的に数学です。あなたが別の科学をやったなら、数学もやったことになるので、数学のバックグラウンドを持っていない人とは違って、スピードを上げることができるはずです。もちろん、集合理論、ビッグO、またはその他のことを本当に必要とするプログラマーはほとんどいません-とにかく高レベルではありません。

私はBSEEから始め、大きな電話のR＆Dラボ用の論理回路の設計に取り組み、（これは約40年前でした）私が構築していたもののほとんどが最終的にコンピュータープログラムで実行できることに気付きました。それで私は戻って、MSCSの学位を取得しました。

私は常にコンピューターアーキテクチャと、ハードウェアレベルで何が起こるかに興味がありました。私のキャリアのほとんどは、組み込みマイクロコントローラシステムの設計に費やされ、ハードウェアで行われていることとファームウェアで行われていることの間で最適な一致を見つけることを試みています。しかし、私はかなりの量のWebプログラミングとデータベースの設計を行いました。

CSのバックグラウンドがなければ、より抽象的な概念を把握するのにもっと苦労すると思います。多くの異なるアセンブラー言語に加えて、C、C ++、C＃、Pascal、Delphi、Perl、PHP、およびいくつかのLispを使用しました。現在、RubyとPythonを学ぼうとしています。オブジェクト指向の設計はかなり快適です。関数型プログラミング私は（まだ）そうではありません。

データベースについても同じです。正規化を理解しています。難解なJOINのいくつかに問題があり、それらを回避します。ボンネットの下で何が起こっているのか理解していない限り、私は何かに本当に快適ではありません。

コンピューターが私の頭の中でプログラムをどのように実行するかを「見られる」ようにしたい。