Như đã nêu trong tiêu đề, sự khác biệt về số năm kinh nghiệm trong ngôn ngữ nhất định về mặt nhà phát triển là gì? Ví dụ: nếu một nhà phát triển đã có năm năm làm việc với ngôn ngữ A và nhà phát triển khác đã có hai năm làm việc với ngôn ngữ B sau đó là ba năm làm việc với ngôn ngữ A, liệu có sự khác biệt rõ ràng giữa họ không?
Câu trả lời:
"nó phụ thuộc"
Kinh nghiệm <> kiến thức hoặc hiểu biết.
Lập trình viên 1 có thể rất giỏi, thậm chí là một bậc thầy, hoặc họ có thể là người dò dẫm ngôn ngữ trong 5 năm qua.
Lập trình viên 2 có thể là người hiểu các khái niệm độc lập với ngôn ngữ họ đang sử dụng. Hoặc ai đó thấy ngôn ngữ B quá khó và hy vọng A dễ hơn.
"Những năm kinh nghiệm huyền thoại" của Coding Horror đáng để đọc
Nó phụ thuộc.
Tôi có một người bạn có xu hướng gắn bó với một ngôn ngữ, vì vậy nếu bạn coi anh ta là "lập trình viên A" thì anh ta đã có 1 năm kinh nghiệm với ngôn ngữ đó, năm lần.
Ngôn ngữ khác nhau cho phép bạn làm những điều khác nhau. Một bài luận tôi đặc biệt thích là " Đánh bại mức trung bình " của Paul Graham. Trong đó anh ta đang cố gắng thuyết phục mọi người học lisp, nhưng anh ta cũng đưa ra một số điểm rất hữu ích:
Các lập trình viên rất gắn bó với ngôn ngữ yêu thích của họ và tôi không muốn làm tổn thương cảm xúc của bất kỳ ai, vì vậy để giải thích điểm này tôi sẽ sử dụng một ngôn ngữ giả định có tên là Blub. Blub rơi ngay giữa sự liên tục trừu tượng. Nó không phải là ngôn ngữ mạnh nhất, nhưng nó mạnh hơn Cobol hoặc ngôn ngữ máy.
Và trên thực tế, lập trình viên Blub giả định của chúng tôi sẽ không sử dụng một trong số họ. Tất nhiên anh ta sẽ không lập trình bằng ngôn ngữ máy. Đó là những gì trình biên dịch dành cho. Và đối với Cobol, anh ta không biết làm thế nào bất cứ ai có thể hoàn thành mọi thứ với nó. Nó thậm chí không có x (tính năng Blub bạn chọn).
Chừng nào lập trình viên Blub giả định của chúng ta đang nhìn xuống sự liên tục sức mạnh, anh ta biết mình đang nhìn xuống. Ngôn ngữ kém mạnh mẽ hơn Blub rõ ràng là kém mạnh mẽ hơn, vì chúng thiếu một số tính năng mà anh ấy đã từng sử dụng. Nhưng khi lập trình viên Blub giả định của chúng tôi nhìn theo hướng khác, tiếp tục sức mạnh, anh ấy không nhận ra mình đang nhìn lên. Những gì anh ta nhìn thấy chỉ là những ngôn ngữ kỳ lạ. Anh ta có lẽ coi họ có sức mạnh tương đương với Blub, nhưng với tất cả những thứ lông lá khác cũng bị ném vào. Blub là đủ tốt cho anh ta, bởi vì anh ta nghĩ trong Blub.
Tuy nhiên, khi chúng tôi chuyển sang quan điểm của một lập trình viên sử dụng bất kỳ ngôn ngữ nào cao hơn tính liên tục sức mạnh, chúng tôi thấy rằng anh ta lần lượt xem thường Blub. Làm thế nào bạn có thể hoàn thành mọi thứ trong Blub? Nó thậm chí không có y.
Nói chung, lời khuyên của tôi là học nhiều hơn một ngôn ngữ và tìm hiểu điểm mạnh và điểm yếu của ngôn ngữ đó là gì.
Tất nhiên, nhà phát triển có nhiều năm kinh nghiệm trong một ngôn ngữ sẽ hiểu rõ hơn về các thư viện cốt lõi và đặc điểm riêng của ngôn ngữ đó. Nếu các ngôn ngữ chấp nhận cùng một mô hình (bắt buộc so với chức năng) thì chúng sẽ không gặp khó khăn gì hơn khi chọn ngôn ngữ đó ngoài việc học ngôn ngữ đó.
Khó khăn lớn nhất của tôi khi chọn một ngôn ngữ mới đến từ việc cố gắng chuyển từ C # sang Erlang, bởi vì nó không chỉ thể hiện một cú pháp mới mà còn là một cách nghĩ mới về lập trình.
Đây là những gì tôi mong đợi / hy vọng:
Ngôn ngữ không phải là vấn đề. Bạn có thể học toàn bộ ngôn ngữ trong một vài ngày. Những gì cần nhiều thời gian hơn để hấp thụ là các quy ước, API và các khung của bên thứ ba khác nhau. Khi mọi người yêu cầu năm năm X, họ không quan tâm đến ngôn ngữ, họ muốn ai đó có nhiều kinh nghiệm giải quyết vấn đề và với ngôn ngữ đó để họ không phải trả tiền cho bất kỳ đường cong học tập nào.
Chuyên môn và thực hành có chủ ý.
Nếu bạn không thực hành có chủ ý, bạn sẽ không đạt được chuyên môn. (Bạn phải kiểm tra lỗi của mình và sửa lỗi, thực hành những gì bạn yếu và có một chuyên gia để cho bạn biết những gì bạn đang làm sai cũng giúp.)
Nếu bạn không cố gắng cải thiện, bạn có thể là người mới mãi mãi!
Sau mười nghìn giờ thực hành có chủ ý, bạn sẽ đạt được chuyên môn. (Phát hiện này từ giáo dục / đào tạo là tất cả trên mạng.)
Nếu lập trình viên của bạn A không cố tình thực hành, họ sẽ không bao giờ tốt hơn.
Nếu lập trình viên B của bạn không cố tình thực hành, họ sẽ không bao giờ tốt hơn.
Một phát hiện khác từ cùng một nghiên cứu: rằng nếu tôi có 15000 giờ và bạn có 10000, và tôi tiếp tục luyện tập và bạn cũng vậy, bạn sẽ không bao giờ tốt hơn tôi.
Biết hai ngôn ngữ có thể sẽ làm cho B trở thành một lập trình viên tốt hơn (tuân theo các quy tắc thực hành).
Và tôi đang sử dụng chúng cho ngôn ngữ A, tôi giả sử? (Rõ ràng, sẽ có một sự khác biệt trong ngôn ngữ B.)
Nó một phần phụ thuộc vào sự khác biệt giữa A và B (đặc biệt nếu chúng tôi rút ngắn trải nghiệm của nhà phát triển thứ hai với A). Nếu chúng khá giống nhau, về cơ bản sẽ không có sự khác biệt về kinh nghiệm. Nếu A có các khái niệm khác nhau đáng kể, ba năm vẫn có khả năng đủ để tìm hiểu chúng. Với một thư viện rất lớn và các công cụ phức tạp, có thể có sự khác biệt giữa ba và năm năm.
Tất nhiên, điều quan trọng nhất ở đây là cá nhân. Một nhà phát triển giỏi có thể tìm hiểu một nền tảng mới một cách triệt để trong ba năm và vì vậy đây không phải là một vấn đề.
Tôi đồng ý rằng ngôn ngữ là ngôn ngữ và khái niệm là khái niệm.
Vấn đề của tôi là có một số lượng lớn lập trình viên ngày nay mà không có IDE tinh vi thì họ không thể lập trình được. Họ thực sự không phải là lập trình viên nhưng thực sự giống các nhà thiết kế hơn.
Tôi biết từ kinh nghiệm cá nhân rằng có rất nhiều người đã bị quyến rũ bởi môi trường phát triển lôi cuốn của Microsoft. Không phải là họ thả một hộp văn bản lên màn hình rồi đặt các thuộc tính bằng trình hướng dẫn và kéo dữ liệu từ một hình ảnh của cơ sở dữ liệu, nhưng chúng có thực sự là lập trình viên trong bất kỳ ngôn ngữ nào không nếu tất cả những gì chúng làm là thiết lập các bài kiểm tra đẳng thức cơ bản?
Những người đó sẽ không bao giờ có thể lấy các Khái niệm mà họ đã học và áp dụng chúng vào ngôn ngữ khác.
Khi tôi phỏng vấn mọi người, tôi quan tâm nhiều hơn đến cách họ phát triển và những khuôn khổ họ đã sử dụng. Tôi thích đặt các câu hỏi như: "Làm thế nào để bạn viết một trình xử lý sự kiện?", "Làm thế nào chính xác để bạn đưa dữ liệu vào DB?", Hoặc thậm chí "Làm thế nào để tôi biến nút đặc biệt này thành màu tím khi tôi nhấp vào nó?" điều này sẽ nhanh chóng loại bỏ các nhà thiết kế và rời khỏi các lập trình viên. Tôi đã thấy rằng 3 hoặc 4 năm thực sự lập trình với một năm bằng ngôn ngữ mà tôi chọn là đủ cho những gì tôi cần.
Chỉ là một ý kiến khác,
Tài năng
"Nhiều năm kinh nghiệm trong ngôn ngữ / nền tảng X" phần lớn là một bệnh lý tuyển dụng ...
Nó mở để giải thích và không phải nơi nào cũng hữu ích như thoạt nhìn. Như đã nói, Năm kinh nghiệm huyền thoại là một tác phẩm hay.
Ngoài ra, quan trọng là, việc đo lường "năm kinh nghiệm" tự nó có thể rất không chính xác. Đây là một ví dụ từ hợp đồng biểu diễn hiện tại của tôi: nhiệm vụ chính của tôi là phát triển và duy trì một ứng dụng web Java. Tuy nhiên, điều này chạy ra một mặt sau là MFC / C ++ / SQL Server. Do đó, tôi cũng đang xử lý mã C ++ trên cơ sở hầu như hàng ngày. NHƯNG - trải nghiệm C ++ này tương đối hời hợt và hướng đến bảo trì và tôi thực sự không viết toàn bộ các thành phần hoặc chương trình lớn từ đầu trong MFC / C ++ nữa (mặc dù tôi đã từng sử dụng các vai trò trước đây).
Tôi vẫn có thể tính 5 năm qua là "5 năm kinh nghiệm về C ++" chứ? Có lẽ. Có thể không. Tùy thuộc vào cách tôi muốn bán nó để đảm bảo vai trò cụ thể, tôi có thể dễ dàng vượt qua nó mà không nói dối hoàn toàn, hoặc tôi có thể thừa nhận rằng đó thực sự không phải là "5 năm kinh nghiệm C ++" vững chắc. :) Tôi chắc chắn có rất nhiều trường hợp tương tự như vậy đối với loại vấn đề "không chính xác của phép đo" này. Độ sâu của kinh nghiệm có thể làm mờ đi chất lượng của trải nghiệm. Vì vậy, "X lượng thời gian dành cho C ++" không có nghĩa gì nhiều.