Làm thế nào chúng ta có thể cải thiện Giáo dục & Đào tạo Lập trình viên tổng thể? [đóng cửa]

Tuần trước, tôi vừa xem cuộc phỏng vấn tuyệt vời này của Kevin Rose của Phillip Rosedale, của Cuộc sống thứ hai.

Và họ đã có một cuộc thảo luận tuyệt vời về cách tìm kiếm, thuê và xác định lập trình viên giỏi, và việc tìm những người giỏi khó đến mức nào.

Điều đó đã khiến tôi thực sự nghĩ về cách chúng ta học lập trình viên, được dạy. Đối với đa số chúng ta, bao gồm cả bản thân mình, chúng ta tự học. Đó là điều tuyệt vời khi trở thành một lập trình viên, bất cứ ai cũng có thể học và phát triển các kỹ năng.

Nhưng điều này cũng có nghĩa là, không có tiêu chuẩn thực sự về việc lập trình viên giỏi là gì và loại môi trường nào khuyến khích sự phát triển của các kỹ năng lập trình.

Đây không phải là một câu hỏi quá lớn, nhưng chỉ là một mong muốn trong tôi, để xem làm thế nào chúng ta có thể thay đổi văn hóa lập trình và người quản lý lập trình, để khuyến khích giáo dục và tự cải thiện.

Có rất nhiều con đường để tiếp tục giáo dục, video youtube, sách, hội nghị, nhưng vì tính chất kinh nghiệm của những gì chúng ta làm, không phải lúc nào cũng rõ ràng những gì quan trọng để học và thành thạo.

Hãy nhìn vào 12 bước Joel.

Bài kiểm tra Joel

Bạn có sử dụng kiểm soát nguồn?

Bạn có thể thực hiện xây dựng trong một bước?

Bạn có thực hiện xây dựng hàng ngày?

Bạn có một cơ sở dữ liệu lỗi?

Bạn có sửa lỗi trước khi viết mã mới không?

Bạn có một lịch trình cập nhật?

Bạn có một thông số kỹ thuật?

Các lập trình viên có điều kiện làm việc yên tĩnh?

Bạn có sử dụng các công cụ tốt nhất tiền có thể mua?

Bạn có người kiểm tra?

Các ứng viên mới có viết mã trong cuộc phỏng vấn của họ?

Bạn có làm kiểm tra khả năng sử dụng hành lang?

Tôi nghĩ tất cả những thứ này đều có giá trị quan trọng, nhưng vì thứ gì đó tôi gọi là Khoảng cách kinh nghiệm, nếu một lập trình viên hoặc người quản lý chưa bao giờ gặp phải bất kỳ hậu quả tiêu cực nào khi không thực hiện các mục trong danh sách, họ sẽ không bao giờ thấy cần phải làm gì của họ.

Khoảng cách kinh nghiệm, là lý thuyết cơ bản của tôi, rằng mỗi chúng ta đều có những công việc khác nhau và những trải nghiệm khác nhau. Vì vậy, đối với một số người trong chúng ta, người luôn làm việc với hàng tá lập trình viên, kiểm soát nguồn là điều bắt buộc. Nhưng đối với những người luôn là lập trình viên duy nhất, họ không thể tưởng tượng được sự cần thiết phải kiểm soát nguồn.

Và đó là do lỗ hổng lớn trong cách chúng ta học, rằng chúng ta đánh giá mọi người bằng những thực hành tốt nhất họ làm hoặc không làm, và lý do cho một trong hai có thể bắt đầu một cuộc chiến rực lửa.

Chúng tôi luôn đánh giá mọi người trong lĩnh vực của mình bằng những gì họ làm và nghĩ rằng "Ồ, nếu anh chàng / cô gái này không thực hiện xyz tốt nhất, anh ấy / cô ấy không thể là một lập trình viên giỏi, vì vậy, đừng lãng phí thời gian hay năng lượng để nói chuyện với họ . "

Đây chính xác là lý do tại sao chúng ta có quá nhiều cuộc chiến ngọn lửa lập trình, đến nỗi, vì Khoảng cách kinh nghiệm, chúng ta không thể tưởng tượng mọi người không đưa ra quyết định mà chúng ta phải đưa ra.

Vì vậy, điều này khiến tôi suy nghĩ, rằng chúng ta hoàn toàn cần phải suy nghĩ lại về cách chúng ta đào tạo, giáo dục và quản lý lập trình viên.

Ví dụ, bao nhiêu phần trăm bạn đã được người quản lý của mình khuyến khích đi dự hội nghị và thậm chí họ có trả tiền cho nó không?

Đối với tôi, và rất nhiều người, điều này cực kỳ hiếm, rất nhiều người trong chúng ta thích đi dự hội nghị, để tìm hiểu thêm, nhưng tiền không ở đó để làm điều đó.

Vì vậy, vấn đề của câu hỏi này là thực sự khơi dậy rất nhiều cách chúng ta có thể đào tạo, học hỏi và quản lý tốt hơn?

Làm thế nào chúng ta có thể tạo ra một văn hóa học tập mới mà không xúc phạm mọi người vì không có cùng kinh nghiệm làm việc.

Vâng, tất cả chúng ta đều có công việc và công việc phải làm, nhưng khả năng làm tốt công việc của chúng ta, phụ thuộc vào mong muốn, sự quan tâm và hỗ trợ của chúng ta trong việc cải thiện khả năng làm chủ các kỹ năng của mình.

Ngay bây giờ, tôi thấy văn hóa của chúng ta khá vô tổ chức, chúng tôi ủng hộ giới thượng lưu, nhưng những người trong chúng ta muốn cải thiện, chỉ cần không có đủ hỗ trợ để học hỏi và cải thiện bản thân.

Ý tôi là, chúng ta là một ngành công nghiệp, muốn được coi là chỉ là bánh răng thay thế?

Cảm ơn bạn...

Wow, câu hỏi tuyệt vời để suy nghĩ, khó trả lời. Bởi vì tất cả chúng ta đều có những trải nghiệm và mong muốn khác nhau, thật khó để đưa ra một kích thước phù hợp với tất cả các giải pháp. Nhưng tôi sẽ đưa ra một số ý kiến tôi đã có trong nhiều năm về cùng chủ đề này.

1) Ngừng xem công việc nhảy là xấu và khuyến khích nó. Thay đổi công ty cứ sau vài năm. Lập trình viên được tiếp xúc với rất nhiều công nghệ, phương pháp và doanh nghiệp khác nhau trong quá trình phát triển sự nghiệp. Các doanh nghiệp có được một luồng ý tưởng mới ổn định.

2) Ngừng xem mình là lập trình viên tại công ty X và xem mình là một chuyên gia cung cấp dịch vụ cho công ty X. Nếu bạn nghĩ như một chuyên gia, bạn sẽ được đối xử như một chuyên gia. Nếu chúng ta được xem như là bánh răng thay thế, thì đó là vì chúng ta hành động như bánh răng thay thế.

3) Các trường đại học cần thay đổi. Họ nên có một thời gian 2 năm ban đầu của giáo dục cơ bản trong máy tính theo sau là một sự lựa chọn. Khoa học máy tính hoặc Kỹ thuật máy tính. Và theo dõi kỹ thuật cần các chuyên gia làm việc trong lĩnh vực này mỗi ngày, không phải là người chỉ viết báo. Và những gì được dạy cần phải thực tế, để bạn có thể bắt đầu công việc ngay sau khi tốt nghiệp. Có thể có một chương trình học nghề cho những người không trải qua chương trình cấp bằng.

4) Chỉnh sửa: Đây là một chút rant-ish. Ý tôi là tất cả chúng ta có rất nhiều điều để học hỏi lẫn nhau bất kể tuổi tác và kinh nghiệm.

5) Hơi liên quan đến điểm 2. Ngừng xem chủ nhân của bạn có trách nhiệm với sự nghiệp của bạn. Bạn là. Và chỉ có bạn. Nếu bạn muốn đi đến một hội nghị, hãy tự trả tiền nếu công ty của bạn không. Đặt tiền sang một bên mỗi năm đặc biệt cho sách và đào tạo và phát triển chuyên nghiệp. Nếu bạn chờ đợi nhà tuyển dụng của bạn đưa bạn đi đào tạo, bạn sẽ chờ đợi rất lâu. Thời gian xem kỹ năng của bạn trở nên không liên quan. Không làm đủ để đủ khả năng đó? Thay đổi công việc.

6) Chúng ta cần trung thực với chính mình và với các lập trình viên đồng nghiệp. Lập trình rất khó. Rất vất vả. Tôi vẫn thấy quảng cáo cho đào tạo máy tính với sự giàu có được đảm bảo khi tốt nghiệp. Điều đó mang lại rất nhiều người vào lĩnh vực đơn giản là không đủ điều kiện hoặc tệ hơn không có lợi ích thực sự ngoài tiền. Chúng ta cần tìm cách khuyến khích họ suy nghĩ lại về kế hoạch nghề nghiệp của họ.

Lúc này tôi nghĩ đầu mình sắp nổ tung, nên tôi sẽ kết luận.

Câu hỏi tuyệt vời! Tôi rất mong được đọc phản hồi nhiều hơn.

Tôi không nghĩ rằng nó vô tổ chức chỉ là kết quả của việc thiếu giảng dạy. Tôi nghĩ rằng nó thực sự phản ánh rằng "thực tiễn tốt nhất" sẽ khác với công việc. Các "thực tiễn tốt nhất" luôn luôn được dựa trên bối cảnh cụ thể.

Có rất nhiều tình huống xảy ra đối với một số lĩnh vực phổ biến nhất của công việc tức là. phát triển web. Tuy nhiên, tôi nghĩ là sai lầm khi tin rằng chỉ vì tham gia vào một thực tiễn cụ thể trong hầu hết các công việc nên được sử dụng trong tất cả các công việc.

Các thực hành bạn tham gia nên xuất phát từ một phân tích và thử nghiệm những gì làm cho bạn làm việc tốt hơn. Họ không nên được lựa chọn thông qua niềm tin mù quáng. Chỉ vì một cái gì đó được lặp lại thường xuyên trên mạng không biến nó thành sự thật trong tình huống của bạn, cũng không phải là Sự thật (cho tất cả các tình huống).

Câu hỏi tuyệt vời để rèn luyện trí óc, tôi đồng ý cần phải làm gì đó, nhưng tôi nghĩ không thể trả lời. Tôi thử

Đầu tiên Đừng giết sự sáng tạo nói chung Tôi phải nói rằng tôi đồng ý với Ngài Ken Robinson, hãy xem cuộc nói chuyện TED tuyệt vời này . Hệ thống giáo dục của chúng ta đang giết chết sự sáng tạo và điều đó phải được sửa đổi. Đặc biệt là đối với các lập trình viên.

Thứ hai Dạy như mẫulĩnh vực chuyên môn của chúng tôi không đủ trưởng thành. Chúng tôi có rất nhiều điều khác nhau mà chúng tôi nghĩ là sẽ đi nhưng chúng tôi không thể thực sự đồng ý với chúng. (nghĩ rằng TDD, BDD, Agile vs Waterfall, số lượng tài liệu cần thiết, Java hoặc .Net) Trong suy nghĩ của tôi, điều này là do thảo luận mà không có ngữ cảnh và chuyên môn hóa nhiều. Bạn không thể đưa ra lựa chọn đúng mà không biết trong bối cảnh nào câu hỏi được hỏi và bạn không thể đưa ra lựa chọn đúng nếu bạn chỉ biết một lựa chọn. Khi bạn mang điều này trở lại giáo dục dường như không thể giải quyết. Bạn không thể mong đợi ai đó biết tất cả các bối cảnh có thể và tất cả các giải pháp có thể. Nhưng với các mẫu bây giờ họ có một số giải pháp chung và bối cảnh áp dụng và bối cảnh khi các giải pháp bị phá vỡ. IMHO đây là cách chúng ta cần dạy,

Thứ ba từ chối các ví dụ về các ví dụ Tôi nghĩ rằng có một vấn đề với các ví dụ chúng tôi hiển thị trên MSDN, trên Blog, trong sách, v.v. Nhưng trong các ví dụ cơ bản nhất đã có quyết định ở nhiều cấp độ. Những ví dụ này dạy tất cả những quyết định khác sai. Tôi nghĩ rằng mọi ví dụ cần phải đi kèm với tuyên bố từ chối trách nhiệm cho biết quan điểm là gì và những gì bạn không nên làm nói chung. Một ví dụ tuyệt vời về điều này đã được viết blog ngày hôm nay ở đây .

Bài Đỗ Đỗ Đỗ Tôi nghĩ có cần phải làm nhiều hơn nữa. Tôi đã học được hầu hết chỉ làm, thất bại, sửa chữa và thảo luận.