Là khoa học của Khoa học máy tính đã chết? [đóng cửa]

Câu hỏi: Khoa học và nghệ thuật của CS đã chết? Ý tôi là, những yêu cầu thực sự để suy nghĩ, lập kế hoạch và giải quyết vấn đề một cách hiệu quả dường như đang giảm dần khỏi CS ngày nay. Lĩnh vực này dường như đang hạ thấp rào cản gia nhập để nhiều người có thể 'lập trình' hơn mà không phải học cách lập trình thực sự.

Bối cảnh: Tôi mới tốt nghiệp với bằng Cử nhân Khoa học Máy tính. Tôi đang làm việc ở một vị trí bắt đầu tại một công ty có quy mô khá trong bộ phận CNTT. Tôi chủ yếu làm .NET và các công nghệ khác của Microsoft trong công việc của mình, nhưng trước đó tôi đã thực hiện các công cụ Java thông qua thực tập và tương tự. Cá nhân tôi là một lập trình viên C ++ cho các dự án vui chơi của riêng tôi.

Trong chiều sâu: Thông qua công việc tôi đã làm, dường như các môn học mãnh liệt của một ngành khoa học thực sự không còn tồn tại trong CS nữa. Trước đây, các lập trình viên phải giải quyết vấn đề một cách hiệu quả để các hệ thống trở nên mạnh mẽ và nhanh chóng. Nhưng bây giờ, với các công nghệ phổ biến như .NET, Java và các ngôn ngữ script, có vẻ như tính hiệu quả và mạnh mẽ đã được giao dịch để dễ phát triển.

Hầu hết các đồng nghiệp mà tôi làm việc thậm chí không có bằng về Khoa học Máy tính. Hầu hết tốt nghiệp với bằng Kỹ sư điện, một số ít với Kỹ thuật phần mềm, thậm chí một số người đến từ các trường công nghệ không có chương trình 4 năm. Tuy nhiên, họ vẫn ổn khi không có nền tảng kỹ thuật về CS, không cần nghiên cứu lý thuyết và thuật toán, mà không quan tâm đến việc đưa ra một giải pháp tao nhã (họ chỉ tìm giải pháp đơn giản nhất, rẻ nhất).

Công ty thúc đẩy chúng tôi sử dụng các công nghệ của Microsoft, loại bỏ mọi suy nghĩ thực sự ra khỏi vấn đề và thay thế nó bằng các thư viện và công cụ có thể tự động xây dựng dự án của bạn cho bạn một nửa thời gian. Tôi không cố gắng ghét ngôn ngữ, tôi hiểu rằng chúng phục vụ mục đích và thực hiện nó tốt, nhưng khi nhân viên của bạn không biết cách bảng băm hoạt động và sử dụng các phương pháp sắp xếp sai hoặc chạy các lệnh SQL là không hiệu quả khủng khiếp (nhưng hoàn thành công việc trong một thời gian chấp nhận được), có cảm giác như có nhiều nỗ lực hơn để phát triển các công nghệ mã hóa các 'lập trình viên' mới thay vì thực sự dạy mọi người cách làm đúng.

Tôi quan tâm đến việc làm cho hiệu quả và, theo tôi, các chương trình đẹp. Nếu có một cách tốt hơn để làm điều đó, tôi thà quay lại và cấu trúc lại nó hơn là để nó trượt. Nhưng trong thế giới doanh nghiệp, họ thúc đẩy tôi hoàn thành nhiệm vụ một cách nhanh chóng hơn là thanh lịch. Và điều đó thực sự làm tôi bực mình.

Đây có phải là những gì tôi sẽ mong đợi cho đến cuối đời? Vẫn còn những vị trí ngoài kia cho những người yêu thích khoa học và nghệ thuật của CS chứ không chỉ là tiền lương?

Và trên cùng một lưu ý, đây là một cuốn sách đáng đọc nếu bạn chưa từng thấy nó trước The Perils Of Java School

Có và không

Câu hỏi hay, nhưng giả định xấu.

Phần Khoa học của giáo dục dường như còn thiếu, nhưng giả định rằng khoa học ở đó chỉ đơn thuần là làm cho các chương trình hiệu quả là sai lầm.

Khoa học là cần thiết để dạy mọi người cách xác định và giải quyết vấn đề.

Đáng buồn thay, phần này của một số giáo trình "CS" (giáo trình?) Dường như bị bỏ qua hoàn toàn, thay thế bởi các vấn đề đồ chơi với các giải pháp tầm thường hoặc đã biết, và chỉ nhằm mục đích dạy làm quen với các công cụ

Thất vọng; nhiều sinh viên tốt nghiệp trường Java đã bị trao đổi, không bao giờ được dạy cách phân tách một vấn đề, thiết kế một thuật toán, chỉ định một bài kiểm tra hoặc thậm chí gỡ lỗi một cách hiệu quả.

Khoa học máy tính có chết không? "..." Tôi mới tốt nghiệp với bằng Cử nhân Khoa học Máy tính. Tôi đang làm việc ở một vị trí bắt đầu tại một công ty có quy mô khá trong bộ phận CNTT .

Thành thật mà nói, hai xu của riêng tôi: Bạn sẽ không tìm thấy "khoa học" về khoa học máy tính làm việc trong một bộ phận CNTT tại một công ty có quy mô tốt, bởi vì đó là bộ phận CNTT, không phải bộ phận CS. Hãy thử quay lại trường học để lấy bằng tiến sĩ, hoặc làm việc trong các bộ phận kỹ thuật của công ty với trọng tâm là khoa học máy tính (ví dụ: xử lý hình ảnh, mạng hiệu suất cao, hệ thống đại số máy tính, hàng không vũ trụ, v.v.). Đây là nơi bạn sẽ tìm thấy những vấn đề khó khăn, thú vị trong đó thiết kế cẩu thả [nói chung] sẽ không được dung thứ.

"Vẫn còn những vị trí ngoài kia cho những người yêu thích khoa học và nghệ thuật của CS chứ không chỉ là tiền lương?"

Vâng, hoàn toàn, nhưng có lẽ không phải ở bộ phận CNTT của các công ty cỡ trung bình.

Nếu bạn là một lập trình viên, đừng coi mình là "nhà khoa học máy tính"; các nhà khoa học máy tính là những người tạo ra thế hệ máy tính tiếp theo, một số trong đó vẫn là khoa học viễn tưởng cho đến khi kết hợp chính xác các vật liệu, thu nhỏ và lý thuyết tính toán được rút ra. Họ chỉ là sự khởi đầu của đường ống. Những người phát triển phần mềm ở đây và bây giờ là "kỹ sư phần mềm"; họ lấy các lý thuyết và công cụ, đôi khi đặt lý thuyết thực tế và các công cụ trong thế giới thực lên hàng đầu, để khai thác sức mạnh của tiềm năng của trò ảo thuật điện phức tạp này và khiến nó làm những gì chúng ta muốn. Đến lượt nó là một chuyên ngành của lĩnh vực "kỹ thuật máy tính", lấy lý thuyết của các nhà khoa học máy tính và áp dụng chúng, phần cứng và phần mềm, cho các giải pháp điện tử của người dùng cuối thế giới thực.

Đây là IMO, nơi kinh doanh đáp ứng lý thuyết. Trong những trường hợp này, câu ngạn ngữ cũ "kẻ thù tốt hơn là đủ tốt" có thể dễ dàng quay lại để đọc "kẻ thù đủ tốt là tốt hơn". Xem xét bản thân một "kỹ sư" thay vì "nhà khoa học" và đặt những gì bạn làm song song với các ngành kỹ thuật khác, sẽ ném sự khác biệt vào sự nhẹ nhõm.

Giả sử một khách hàng đến với bạn, một kỹ sư xây dựng / dân dụng và yêu cầu bạn xây dựng một cây cầu. Cây cầu cần kéo dài 20 feet, tự hỗ trợ và tải trọng một tấn, nó sẽ kéo dài 10 năm với bảo trì thường xuyên và họ muốn nó trong một tháng với giá 20.000 đô la. Đó là những hạn chế của bạn; đáp ứng mức tối thiểu trong khi không vượt quá mức tối đa Làm điều đó là "đủ tốt", và giúp bạn nhận được tiền lương. Sẽ là kỹ thuật kém cho bạn khi xây dựng Cầu Cổng Vàng, vượt xa cả thông số kỹ thuật thiết kế và ngân sách theo một số đơn đặt hàng lớn. Bạn thường kết thúc việc ăn vượt chi phí và trả tiền phạt cho thời gian quá hạn. Nó cũng sẽ là kỹ thuật kém cho bạn để xây dựng một cây cầu dây được xếp hạng cho trọng lượng của 5 người đàn ông trưởng thành mặc dù nó chỉ tốn 1000 đô la về thời gian và vật liệu; bạn không nhận được đánh giá và lời chứng thực tốt của khách hàng,

Quay trở lại phần mềm, giả sử bạn có một khách hàng cần một hệ thống xử lý tệp được xây dựng để tiêu hóa các tệp đến và đưa thông tin vào hệ thống. Họ muốn nó được thực hiện trong một tuần và nó phải xử lý năm tệp một ngày, dữ liệu trị giá khoảng 10 MB, vì đó là tất cả lưu lượng truy cập mà họ hiện có. Lý thuyết quý giá của bạn phần lớn đi ra ngoài cửa sổ; Nhiệm vụ của bạn là xây dựng một sản phẩm đáp ứng các thông số kỹ thuật đó trong một tuần, bởi vì bằng cách đó, bạn cũng đáp ứng ngân sách chi phí của khách hàng (vì các vật liệu thường giảm trong một hợp đồng phần mềm có kích thước này). Dành hai tuần, thậm chí cho mười lần tăng, không phải là một lựa chọn, nhưng rất có thể, không phải là một chương trình được xây dựng trong một ngày chỉ có thể xử lý một nửa thông lượng, với hướng dẫn để có hai bản sao chạy.

Nếu bạn nghĩ rằng đây là một trường hợp bên lề, bạn đã sai; đây là môi trường hàng ngày của hầu hết mọi người. Lý do là ROI; chương trình ban đầu này không tốn nhiều chi phí và do đó sẽ tự chi trả rất nhanh. Khi người dùng cuối cần nó để làm nhiều hơn hoặc đi nhanh hơn, mã có thể được cấu trúc lại và thu nhỏ.

Đó là lý do chính đằng sau tình trạng lập trình hiện nay; giả định, được đưa ra bởi toàn bộ lịch sử điện toán, là một chương trình KHÔNG BAO GIỜ tĩnh. Nó sẽ luôn cần phải được nâng cấp và cuối cùng nó sẽ được thay thế. Song song, sự cải tiến liên tục của các máy tính chạy chương trình cho phép giảm sự chú ý đến hiệu quả lý thuyết và tăng sự chú ý đến khả năng mở rộng và song song hóa (một thuật toán chạy trong thời gian bình phương N nhưng có thể song song để chạy trên lõi N xuất hiện tuyến tính và thường chi phí cho phần cứng nhiều hơn rẻ hơn so với các nhà phát triển để đưa ra giải pháp hiệu quả hơn).

Trên hết, có một nguyên lý rất đơn giản rằng mỗi dòng mã nhà phát triển là một thứ khác có thể sai. Càng ít nhà phát triển viết, càng ít có khả năng những gì anh ta viết có vấn đề. Đây không phải là một chỉ trích về "tỷ lệ lỗi" của bất kỳ ai; đó là một tuyên bố thực tế đơn giản. Bạn có thể biết cách viết MergeSort ngược và chuyển tiếp bằng 5 ngôn ngữ, nhưng nếu bạn chỉ cần một mã định danh trong một dòng mã thì toàn bộ Sắp xếp không hoạt động và nếu trình biên dịch không bắt được thì nó có thể đưa bạn đi hàng giờ để gỡ lỗi nó Tương phản với List.Sort (); nó ở đó, nó hiệu quả trong trường hợp chung, và, đây là điều tốt nhất, nó đã hoạt động.

Vì vậy, rất nhiều tính năng của các nền tảng hiện đại và nguyên lý của các phương pháp thiết kế hiện đại, đã được xây dựng với ý tưởng này:

• OOP - xây dựng dữ liệu và logic liên quan vào một đối tượng và bất cứ nơi nào khái niệm về đối tượng đó là hợp lệ, do đó, nó là đối tượng hoặc một dẫn xuất chuyên biệt hơn.
• Các mẫu dựng sẵn - 60% mã trở lên là cú pháp cú pháp và những điều cơ bản để chương trình hiển thị một cái gì đó trên màn hình. Bằng cách tiêu chuẩn hóa và tự động tạo mã này, bạn giảm một nửa khối lượng công việc của nhà phát triển, cho phép tăng năng suất.
• Thư viện thuật toán và cấu trúc dữ liệu - Như ở trên, bạn có thể biết cách viết Stack, Queue, QuickSort, v.v., nhưng tại sao bạn phải, khi có một thư viện mã có tất cả những thứ này được tích hợp? Bạn sẽ không viết lại IIS hoặc Apache vì bạn cần một trang web, vậy tại sao lại triển khai thuật toán QuickSort hoặc đối tượng cây đỏ đen khi có nhiều triển khai tuyệt vời?
• Giao diện trôi chảy - Dọc theo cùng một dòng, bạn có thể có một thuật toán lọc và sắp xếp các bản ghi. Nó nhanh, nhưng có lẽ không dễ đọc lắm; nó sẽ khiến nhà phát triển cơ sở của bạn mất một ngày chỉ để hiểu nó, chứ đừng nói đến việc thay đổi phẫu thuật cần thiết để sắp xếp trên một lĩnh vực bổ sung trong đối tượng thu âm. Thay vào đó, các thư viện như Linq thay thế rất nhiều mã rất xấu, thường dễ vỡ bằng một hoặc hai dòng lệnh gọi phương thức có thể định cấu hình để biến danh sách các đối tượng thành các đối tượng được lọc, sắp xếp, chiếu.

CNTT dường như với tôi rằng bạn đang làm CNTT chứ không phải CS và điều đó không có nghĩa là CS đã chết. CS không chết, chỉ là hầu hết các công việc đều đang phát triển Phần mềm. Vì hầu hết sinh viên CS học lập trình, cuối cùng họ thường thuê làm lập trình viên chứ không phải là nhà khoa học máy tính. Công việc Khoa học Máy tính là rất nhỏ so với công việc lập trình. Bạn thậm chí có thể làm một ứng dụng phức tạp bằng các kỹ thuật khoa học máy tính, nhưng theo ý kiến ​​của tôi (và tôi không thích câu trả lời ý kiến ​​vì chúng chủ quan), điều đó rơi vào trại kỹ sư hơn là trại khoa học.

Ngoài ra, mã đẹp và thanh lịch nằm trong mắt của kẻ si tình , nhưng đối với hầu hết các công ty / người quản lý, có một thiết kế đủ tốt về thời gian quan trọng hơn nhiều so với mã đẹp nhưng không bao giờ hoàn thành đúng hạn.

Cuối cùng, có thế giới thực và vùng đất lala. Thật không may, chúng tôi nhận được tiền lương từ trước đây và đó là nơi "khoa học / nghệ thuật" phát triển phần mềm xuất hiện trong cách sản xuất chất lượng phần mềm cao với những hạn chế về thời gian / ngân sách. Tôi cảm thấy cùng một loại cảm xúc mà bạn có khi bắt đầu sự nghiệp của tôi. Tôi luôn muốn tạo ra "thứ tốt nhất", nhưng ngay sau đó tôi nhận ra rằng "thứ tốt nhất" không phải là thiết kế hiệu quả hay thanh lịch nhất, mà là thiết kế tiết kiệm chi phí nhất.

Trước hết, bạn đã hiểu sai. "Nghĩ, lập kế hoạch và giải quyết vấn đề hiệu quả" không phải là khoa học, đó là kỹ thuật. Khoa học là nhiều hơn về khám phá các lĩnh vực mới. Và thực sự trong thế giới học thuật, mọi người quan tâm ít hơn về hiệu quả của mã ít hơn nhiều so với trong ngành công nghiệp. Trong giới hàn lâm, nó nói nhiều hơn về các khái niệm bằng chứng, v.v.

Không, những gì bạn đang mô tả, là cần ít kiến ​​thức chuyên sâu để phát triển phần mềm. Điều này có thể đúng, nếu các yêu cầu sẽ giống nhau. Nhưng ngày nay, kỹ sư phần mềm dự kiến ​​sẽ biết cách xử lý đa luồng, điện toán phân tán, nhân rộng, v.v ... Họ được kỳ vọng sẽ biết cách dẫn dắt dự án hiệu quả. Hầu hết những điều này hoàn toàn không có trong chương trình giảng dạy vài thập kỷ trước.

Tôi không nghĩ rằng những gì bạn đã nói là hoàn toàn đúng, nhưng bạn có một cái gì đó của một điểm nào. Cụ thể, tôi nghĩ theo thời gian, khoa học máy tính và công nghệ phần mềm đã phát triển.

Công nghệ phần mềm (giống như kỹ thuật khác) là về ứng dụng khoa học để xây dựng sản phẩm, giải quyết vấn đề, v.v. Khoa học máy tính chủ yếu nghiên cứu về thuật toán và (mặc dù phần này thường bị lãng quên) làm thế nào để thực hiện các thuật toán đó (ít nhất là trong một số ý nghĩa lý thuyết - ví dụ, có lẽ coi tất cả các máy PRAM là tương đương).

Giữ những điều đó trong tâm trí, tôi nghĩ lý do đằng sau sự phân chia trở nên rõ ràng: hầu hết các vấn đề thuật toán liên quan đến một cái gì đó như một trang web điển hình đã được giải quyết - hầu hết trong số đó, từ lâu . Có lẽ quan trọng hơn, hầu hết những điều đó đã được giải quyết đủ tốt cho các nhà phát triển web trung bình, vấn đề đã biến mất gần như hoàn toàn. Ví dụ, thực hiện cập nhật nguyên tử cho cơ sở dữ liệu phân tán chắc chắn là một nhiệm vụ không hề nhỏ - nhưng một nhà phát triển web điển hình chỉ viết một số SQL và không có manh mối (hoặc quan tâm) về việc cần bao nhiêu nghiên cứu để tìm ra cách thực hiện công việc đáng tin cậy

Tại một thời điểm, về cơ bản không thể tách khoa học máy tính khỏi công nghệ phần mềm. Vì vậy, một số vấn đề đã được giải quyết rằng việc viết ngay cả một chương trình tương đối tầm thường cũng cần nghiên cứu về các nguyên tắc cơ bản. Nếu bạn muốn làm một việc đơn giản như sắp xếp một loạt dữ liệu vào cuối thập niên 50 hoặc đầu thập niên 60, thì rất có thể bạn sẽ phải phân tích dữ liệu của mình và cố gắng thiết kế một thuật toán phù hợp nhất có thể với những gì nó cần để sắp xếp dữ liệu cụ thể đó - không nơi nào gần với nhiều thuật toán sắp xếp được biết đến như ngày nay, và thậm chí các thuật toán được biết đến gần như không được biết đến ngày nay .

50 năm nghiên cứu và phát triển đã được đền đáp - sự phát triển điển hình nhất có thể sử dụng không chỉ các thuật toán đã biết, mà cả các triển khai được viết sẵn. Hầu hết các vấn đề điển hình có thể được giải quyết khá hợp lý dựa trên kiến ​​thức hiện có (và thậm chí là các triển khai hiện có) của các thuật toán.

Điều đó không có nghĩa là khoa học máy tính đã chết - vẫn còn nhiều thuật toán để nghiên cứu và những người thực hiện nghiên cứu về chúng. Tuy nhiên, điều đó có nghĩa là hầu hết các nghiên cứu chuyên sâu hơn và chỉ có khả năng áp dụng cho các lĩnh vực khá chuyên biệt. Có lẽ cũng có một "khoảng cách" lớn hơn giữa việc tiếp thu và áp dụng kiến ​​thức. Tại một thời điểm, bạn đã tìm ra một cách tốt hơn để sắp xếp trong quá trình viết một chương trình sắp xếp, và nó đã được viết thành mã thực gần như ngay lập tức. Bây giờ rất nhiều khoa học máy tính được dành cho những thứ như làm thế nào để sử dụng số lượng bộ xử lý cơ bản vô hạn - có thể sẽ hữu ích vào một ngày nào đó, nhưng ngay cả các bộ lạc nguyên thủy cũng sẽ không coi lõi kép trong máy tính của tôi là "nhiều" ... :-)

Phát triển phần mềm và khoa học máy tính không giống nhau, và tôi thấy rằng hầu hết các bạn cùng lớp của tôi trong B.Sc. Chương trình Comp Sci đã bị thất vọng bởi điều này.

Tôi nghĩ phần mềm là một sản phẩm của khoa học máy tính ... giống như tranh vẽ là một sản phẩm của nghệ thuật thị giác.

Tôi nghĩ rằng hầu hết những người có bằng CS được thuê vào các công việc để thực hiện phát triển phần mềm, đặc biệt là trong giai đoạn đầu của sự nghiệp. Tôi nghĩ rằng rất nhiều người trong vai trò này ở lại đó và không tiến xa hơn.

Tôi nghĩ rằng sự khác biệt bắt đầu xuất hiện khi các vấn đề hoặc mô thức mới xuất hiện hoặc khi "vỗ nó cùng nhau" là không đủ. Ai xây dựng các khuôn khổ hoặc ngôn ngữ mới? Ai ngồi xuống và đập ra các chi tiết của một động cơ vật lý mới? Ai sử dụng lý thuyết đồ thị / biến đổi đồ thị để tìm ra một vài chu kỳ cho mỗi lần lặp hiệu suất từ ​​một thuật toán?

Tôi sẽ kết thúc nơi tôi bắt đầu, đồng ý rằng có rất nhiều nhà khoa học máy tính trong vai trò phát triển phần mềm / kỹ thuật, có lẽ không sống đúng với tiềm năng của họ.

Bạn dường như đang nhầm lẫn giữa khoa học máy tính với lập trình và phát triển phần mềm nói chung. Hai người không giống nhau, thậm chí không thân thiết. Bất kể bằng cấp của chúng ta có thể nói gì, đại đa số chúng ta là lập trình viên, không phải nhà khoa học máy tính. Trừ khi bạn tích cực tham gia vào học viện ở cấp độ cao, thì tôi sẽ cá rằng bạn không thực sự có ý tưởng nào về những gì đang diễn ra trong khoa học máy tính.

Tôi có thể nói với bạn rằng Khoa học Máy tính còn sống và tốt. Tôi phải giải quyết vấn đề mới hàng ngày và đưa ra giải pháp hiệu quả và thanh lịch cho những vấn đề đó. Tôi phải sử dụng các kỹ năng của mình như một kỹ sư hàng ngày và sử dụng kiến ​​thức của bản thân và các đồng nghiệp để giải quyết những vấn đề đó cho khách hàng.

Tôi không cố gắng ghét ngôn ngữ, tôi hiểu rằng chúng phục vụ mục đích và thực hiện nó tốt, nhưng khi nhân viên của bạn không biết cách bảng băm hoạt động và sử dụng các phương pháp sắp xếp sai hoặc chạy các lệnh SQL là không hiệu quả khủng khiếp (nhưng hoàn thành công việc trong một thời gian chấp nhận được), có cảm giác như có nhiều nỗ lực hơn để phát triển các công nghệ mã hóa các 'lập trình viên' mới thay vì thực sự dạy mọi người cách làm đúng.

Điều này nghe có vẻ như là một vấn đề với nhân viên và chắc chắn không đúng với mọi lập trình viên.

Chỉ vì các công cụ giúp công việc của chúng ta dễ dàng hơn tồn tại không có nghĩa là chúng ta không nên hiểu công nghệ gạch chân, nếu chúng ta không giúp đỡ ai và chắc chắn sẽ không thực hiện công việc của mình trong việc giải quyết vấn đề một cách chính xác.

Bạn chưa hiểu vấn đề trong tay. Vấn đề không phải là hiệu suất tối đa - nó có đủ hiệu suất để ứng dụng của bạn phản hồi nhanh và đủ nhanh. Học lập trình là để giải quyết vấn đề, với số tiền nhỏ nhất.

Tôi ghét phải diễn đạt nó theo cách này, nhưng bất kỳ ấn tượng nào về cái chết của CS chỉ là những quan niệm trước của bạn về những gì một lập trình viên "thực sự" phải làm.

Chà, chết hay không là tranh cãi!

Thực tế là trong thời đại công nghệ ngày nay, hầu hết các công ty đều thuê người để giải quyết các nhiệm vụ loại công việc trong thế giới thực thông qua tự động hóa phần mềm. Họ không quan tâm đến việc bạn có thể viết chương trình thanh lịch hay nhanh hơn như thế nào, miễn là nó cho phép doanh nghiệp thực hiện nhanh hơn với sản lượng cao hơn.

Sự căng thẳng là đầu ra nhiều hơn trong thời gian ít hơn. (Nghĩ rằng thương mại hóa cây trồng / thực phẩm; tăng trưởng nhanh hơn và nhiều hơn với chi phí ít hơn). Điều tương tự đang xảy ra trong thế giới công nghệ (ý tưởng mới tiếp theo).

Hãy nhớ rằng, trong thời đại ngày nay, mọi thứ đang chuyển động nhanh hơn bao giờ hết do số lượng và quyền truy cập vào kiến ​​thức so với trước đây. Ngày xưa, sản lượng nhỏ và tốt hơn, lợi nhuận cao hơn. Bây giờ, trò chơi đã thay đổi hoàn toàn. Chỉ cần nhìn vào những thứ như chất lượng dịch vụ khách hàng và nói chung những thứ không tồn tại lâu hơn.

Sự thanh lịch và hiệu quả là vấn đề đối với các công ty công nghệ như Google, v.v., trong khi ngay cả những nơi đó không hoàn hảo nhưng bạn có thể đến gần với nó bằng cách làm việc một trong những công ty đó trong những năm tới.

Luôn có một sự đánh đổi trong cuộc sống. Bạn có thể tìm thấy một công việc trả ít hơn, nơi bạn có tất cả thời gian và sự chú ý. Hoặc, bạn chọn bơi cùng những người còn lại để được trả lương cao hơn và bỏ qua những thứ không hoàn hảo. Nhận thức này càng nhanh chìm trong bạn, bạn có thể chuẩn bị cho thế giới thực. Tôi không nói bạn nên bỏ qua chất lượng và thanh lịch nhưng biết động lực. Bạn sẽ hạnh phúc hơn :)

Theo tôi, một số điều thú vị nhất mà tương lai có thể nắm giữ chắc chắn sẽ dựa trên phần khoa học của khoa học máy tính, cụ thể là cải thiện thị giác máy tính / học máy và các thuật toán sematisizing khác. Những điều này có thể sẽ được thúc đẩy trong ngành công nghiệp (ví dụ như lấy Microsoft Kinect) nhưng là những vấn đề cực kỳ khó khăn, chúng chắc chắn sẽ dựa trên cơ thể lớn của nghiên cứu và tiến bộ được thực hiện trong các học giả (một lần nữa, lấy Microsoft Kinect).

Tôi nghĩ rằng lập trình hàng ngày tiêu chuẩn là một môn nghệ thuật không kém gì khoa học nhưng chắc chắn tồn tại những lĩnh vực quan tâm sâu sắc đến các khía cạnh khoa học của khoa học máy tính. Ví dụ các nhà nghiên cứu cho các công ty và trường đại học. Nếu bạn thực sự muốn tham gia vào các ngành khoa học một cách chuyên nghiệp thì bạn nên tìm kiếm một phd. Tuy nhiên, tôi đã thấy các phần khoa học trong giáo dục của mình liên tục có giá trị, mặc dù cũng cần phải dựa vào khía cạnh sáng tạo hơn của tôi trong thực tế!

Những người không biết những gì họ đang làm có thể hack mọi thứ bằng một số công cụ bạn đã đề cập nhưng họ thường thuê những người CS thực sự để tạo ra các công cụ đó, bạn chỉ cần phải trừu tượng hơn để thực sự thúc đẩy bản thân.