EE vs Khoa học máy tính: Ảnh hưởng đến cách tiếp cận, phong cách của nhà phát triển? [đóng cửa]


11

Có sự khác biệt nào về hệ thống giữa các nhà phát triển phần mềm (kỹ sư sw, kiến ​​trúc sư, bất kỳ chức danh công việc nào) với một nền tảng điện tử hoặc kỹ thuật khác, so với những người bước vào nghề thông qua khoa học máy tính?

Theo nền tảng điện tử, tôi có nghĩa là một bằng cấp EE, hoặc một thợ sửa điện tử tự học, các loại kỹ sư và nhà vật lý thực nghiệm khác.

Tôi tự hỏi nếu tham gia vào các ngành nghề làm phần mềm từ một kiến ​​thức mạnh mẽ về dép xỏ ngón, bộ đệm tristate, thời gian tăng tốc cạnh đồng hồ, v.v., thường dẫn đến một cách tiếp cận khác biệt đối với các vấn đề, tư duy hoặc kỹ năng vượt trội ở một số chuyên ngành nhất định và thiếu về các kỹ năng ở người khác, khi so sánh với các loại khoa học máy tính có đầy đủ các khái niệm như kiểu dữ liệu trừu tượng, định hướng đối tượng, chuẩn hóa cơ sở dữ liệu, người nói về "sự đóng cửa" trong ngôn ngữ lập trình - những điều ít có ý nghĩa đối với đám đông hàn sắt cho đến khi họ học đủ lập trình.

Thế giới thực, tôi chắc chắn, cung cấp một loạt các trường hợp ngoại lệ riêng lẻ, nhưng đối với hầu hết các phần, bạn có thể nói có sự khác biệt tổng thể không? Liệu những điều này có ý nghĩa tuyển dụng, ví dụ (để tạo ra một cái gì đó) "không bao giờ thuê một người sắp xếp điện tử để thiết kế cơ sở dữ liệu"? Có thể biết về bất kỳ sự khác biệt giúp người tìm việc tìm thấy một cái gì đó phù hợp hiệu quả hơn? Hoặc cung cấp sự giác ngộ hoặc một số lời khuyên thiết thực cho những người thấy mình không phù hợp trong một vai trò công việc cụ thể?

(Btw, tôi chưa bao giờ tham gia bất kỳ lớp học khoa học máy tính nào; ấn tượng của tôi về chính xác những gì họ thể hiện là mờ nhạt. Bản thân tôi là một loại điện tử / vật lý / nghệ thuật.)

Câu trả lời:


5

Có chuyên ngành EE và chuyên ngành CS, tôi đã làm việc với cả hai nhóm về mặt học thuật. Tôi chưa bao giờ làm một công việc mà tôi đã thiết kế các sản phẩm theo phong cách EE, nhưng tôi đã tiêu thụ rất nhiều trong số họ làm việc cho các công ty với những thứ như PLC, và vì vậy có thể hiểu (từ một nền tảng giáo dục) những gì xảy ra là tốt . Vì vậy, tôi không thể nói rằng tôi biết 100% về hành vi và đặc điểm nơi làm việc, nhưng tôi có thể mô tả sự academickhác biệt giữa hai mức độ này.

Dân EE có xu hướng tập trung vào các chi tiết, và họ có xu hướng biết thực hiện chính xác. Nếu nó không thể lập bản đồ 100%, họ sẽ không thích nó. Người dân EE sẽ tối ưu hóa để loại bỏ các chi tiết không cần thiết nếu họ có thể.

Những người SE có xu hướng thích các lớp và ngăn cách logic. Mọi người đừng bận tâm đến những dự án cồng kềnh. Những người SE có xu hướng rất toán học. Họ có xu hướng suy nghĩ về các phương trình và cách giải quyết các vấn đề từ một khái niệm mẫu. Tham gia trực quan hơn vào nhóm này, như cơ sở dữ liệu làm việc. Càng đi xa, bạn càng có xu hướng nhìn thấy những người thông thạo những thứ như Lập trình chức năng. Đó không phải là nền tảng an toàn cho một người EE.

Cả hai người đều biết về những thứ như bản đồ Karnaugh nên có nhiều sự chồng chéo trong các khu vực đó. Giảm logic, loại đó.

Ok, đó là câu trả lời chủ quan của tôi. Hy vọng nó giúp.


Câu trả lời này cho tôi cái nhìn sâu sắc về dự án hiện tại của tôi. Tôi cần chuyển đổi nghề nghiệp!
DarenW

1
Tôi gần như 100% đồng ý với bạn, ngoại trừ phần về lập trình chức năng. Ví dụ, tôi tin rằng logic bậc thang thuần túy là cú pháp khai báo gần như 100%. Sơ đồ khối chức năng cũng phổ biến với EE, cũng rõ ràng là chức năng.
Scott Whitlock

@Scott W. ~ 2 suy nghĩ ... ;)đó là một câu trả lời chủ quan, tôi được phép sai ... liên quan đến logic chức năng Tôi có nghĩa là như mã lisp này ((lambda (arg) (+ arg 1)) 5)... họ thực sự sẽ sử dụng một cái gì đó "tương tự" nhưng sẽ logic có giống với EE không? Không phải theo kinh nghiệm cá nhân của tôi. Cấp, tôi không biết rằng nhiều EE thiết kế chip chuyên nghiệp, hầu hết những người tôi biết là nhân viên phục vụ nhiều hơn. Và logic thang họ khóa vào một thiết bị đầu cuối máy tính trông giống như một cái thang theo nghĩa đen trên màn hình của họ. Đi hình.
jcolebrand

1
Tôi nghĩ rằng bạn đang nói về các cấu trúc chức năng như lambdas, v.v., và tôi đang nghĩ về các khái niệm chức năng như tính bất biến và cú pháp khai báo. Tôi đồng ý rằng những thứ như monads và tương tự là khá trừu tượng. Tôi không nghĩ EE thường sẽ chạy vào những thứ như vậy.
Scott Whitlock

Tôi nghĩ rằng EE chạy vào các đơn vị thường xuyên hơn so với người SE. Haskell thậm chí còn có một phần mở rộng đơn nguyên cho phép các đơn vị được mô hình hóa thành các khối I / O, bánh mì và bơ của các kỹ sư DSP.
Aditya

12

Nếu tôi phải khái quát, đây là kinh nghiệm của tôi:

  • Các kỹ sư (hoặc chỉ EE) có xu hướng làm tốt hơn trong "sự hoàn hảo của nhỏ". Với một nhiệm vụ lập trình nhỏ, họ suy nghĩ rất lâu và chăm chỉ về tất cả các trường hợp cạnh, và nhiều khả năng cuối cùng sẽ xây dựng một phần mềm rất mạnh mẽ. Nó thường được điều khiển từ phương pháp tiếp cận từ trên xuống dưới, vì đó là những gì chúng được sử dụng trong phần cứng. Nó thường liên quan đến việc sử dụng các máy trạng thái, bởi vì chúng được sử dụng để thiết kế chúng cho phần cứng và nó phù hợp với phương pháp "thiết kế lớn". Mặt khác, họ không nghĩ nhiều về khả năng mở rộng hoặc khả năng bảo trì.

  • Các nhà phát triển truyền thống của bạn giỏi hơn trong việc quản lý sự phức tạp lớn, chủ yếu là do việc đào tạo đẩy việc phá vỡ các vấn đề thành các bit nhỏ dễ quản lý hơn. Họ được dạy để tránh thiết kế lớn, và chỉ tách các mối quan tâm, viết bài kiểm tra và làm cho bài kiểm tra vượt qua. Thông thường có rất nhiều trường hợp cạnh bị bỏ lỡ, chỉ vì sự phức tạp và thời gian, nhưng cuối cùng chúng được che đậy. Các nhà phát triển có xu hướng lợi dụng thực tế rằng đó chỉ là phần mềm và nó nên (hoặc) dễ thay đổi. Khi EE làm việc với phần cứng, họ không có lợi thế này và tôi nghĩ rằng cần có thời gian để thực hiện chuyển đổi.

Như tôi đã nói, đó là kinh nghiệm tổng quát của tôi. Điều đó không đúng trong mọi trường hợp.


Câu trả lời tốt đẹp, với sự tương phản giữa hai. Bây giờ để xem có bao nhiêu người khác đồng ý rằng điều này là chính xác hoặc đến gần, bằng cách nâng cao.
DarenW

3

Theo kinh nghiệm của tôi - các loại EE dường như thiết kế các chương trình tuyến tính và không kết hợp các lớp trừu tượng mà các loại CS có vẻ thoải mái.

Không có bình luận về sự khác biệt chất lượng hoặc thiếu đó.


1

Tôi nghi ngờ bạn sẽ thấy nhiều sự khác biệt trong các loại ứng dụng kinh doanh hoặc web thông thường mà hầu hết mọi người đều làm việc, một khi cả hai có một vài năm kinh nghiệm dưới vành đai của họ. Tất cả những điều bạn liệt kê là khó hiểu với "đám đông hàn sắt" là những kỹ năng lập trình bình thường. Về bản chất, bạn đang trả lời câu hỏi của riêng mình - một người không có nền tảng lập trình có thể học lập trình, nhưng cho đến khi họ không phải là lập trình viên. Một người có đầu óc logic và phân tích sẽ thấy việc học lập trình tốt dễ dàng hơn nhiều so với người không - đó sẽ là lợi thế duy nhất tôi có thể nghĩ cho một người tin học điện tử tự học.

Khoa học máy tính (trái ngược với Kỹ thuật máy tính) chủ yếu là toán học, vì (ở cấp độ cao hơn) là các ngành khoa học khác như vật lý - nhưng nó là một loại toán học rất khác. Nếu bạn đã làm một môn khoa học khác thì bạn cũng sẽ học toán và vì vậy bạn có thể đạt được tốc độ không giống như một người không có nền tảng toán học. Tất nhiên, rất ít lập trình viên thực sự cần biết về lý thuyết tập hợp, big-O, hoặc bất cứ điều gì khác - chắc chắn không phải ở mức cao.


Câu trả lời thú vị. Tôi có thể đã hạ thấp kỹ năng lập trình của những người điện tử - những người có kinh nghiệm có thể ở bất cứ đâu trên quy mô từ hình nộm đến ngôi sao nhạc rock. Bạn có nói rằng các EE có thể học lập trình đến một mức độ chuyên nghiệp, dễ dàng hơn một người làm phần mềm thuần túy có thể nhận điện tử không?
DarenW

1

Tôi bắt đầu với một BSEE, đi làm việc thiết kế các mạch logic cho một phòng thí nghiệm R & D điện thoại lớn và (đây là khoảng 40 năm trước) nhận ra hầu hết những gì tôi đang xây dựng cuối cùng có thể được thực hiện bằng một chương trình máy tính. Vì vậy, tôi đã quay trở lại và có một mức độ MSCS.

Tôi luôn quan tâm đến kiến ​​trúc máy tính, và những gì xảy ra ở cấp độ phần cứng. Hầu hết sự nghiệp của tôi đã được dành để thiết kế các hệ thống vi điều khiển nhúng, nơi tôi cố gắng tìm ra sự phù hợp nhất giữa những gì được thực hiện trong phần cứng và những gì được thực hiện trong phần sụn. Tuy nhiên, tôi đã thực hiện khá nhiều chương trình web và thiết kế cơ sở dữ liệu.

Không có nền tảng về CS, tôi nghĩ rằng tôi sẽ gặp nhiều rắc rối hơn khi nắm bắt các khái niệm trừu tượng hơn. Bên cạnh nhiều ngôn ngữ trình biên dịch khác nhau, tôi đã sử dụng C, C ++, C #, Pascal, Delphi, Perl, PHP và một số Lisp. Tôi hiện đang cố gắng học Ruby và Python. Thiết kế OO tôi khá thoải mái. Chức năng lập trình tôi chưa (chưa).

Tương tự cho cơ sở dữ liệu. Tôi hiểu bình thường hóa. Tôi gặp rắc rối với một số THAM GIA bí truyền hơn và tránh chúng. Tôi không thực sự thoải mái với một cái gì đó trừ khi tôi hiểu những gì đang diễn ra dưới mui xe.

Tôi muốn có thể "xem" máy tính sẽ chạy chương trình trong đầu như thế nào.


1
"Tôi không thực sự thoải mái với một cái gì đó trừ khi tôi hiểu những gì đang diễn ra dưới mui xe." - đó là dấu hiệu của kỹ thuật có trách nhiệm. +1 cho bạn.
luis.espinal 21/03
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.