Thuyết phục nhà phát triển sử dụng IDE [đã đóng]

Có một nhà phát triển, hãy gọi anh ta là John (hiện đang trong thời gian thử việc) trong công ty (công ty nhỏ khoảng 10 người, 3 nhà phát triển, một trong số họ làm việc lâu năm trong công ty này biết về quy trình kinh doanh và có thể được coi là Trưởng nhóm) hoàn toàn không muốn sử dụng bất kỳ IDE nào (anh ấy đang sử dụng một số trình soạn thảo văn bản).

Ứng dụng mà nhóm này làm việc là ứng dụng Java kích thước trung bình với ngăn xếp công nghệ Spring Hibernate và tái cấu trúc / thêm các tính năng mới để khởi chạy phiên bản mới của ứng dụng đó trong tương lai gần.

Hiệu suất của John làm việc mà không có IDE trên ứng dụng này thì thấp hơn mong muốn, giả định của nhóm trưởng (hãy gọi anh ta là Bill) là điều này xảy ra vì John không sử dụng IDE.

Bill cố gắng thuyết phục John sử dụng IDE, nhưng ý tưởng này gặp rất nhiều sự phản kháng và lý do chính là "Tôi muốn kiểm soát hoàn toàn những gì tôi đang làm, vì vậy tôi cần phải tự viết tất cả mã".

Làm thế nào Bill có thể thuyết phục John thử sử dụng IDE? (xem xét thực tế những gì Bill đã bảo vệ John khỏi chủ sở hữu công ty một số khiếu nại về hiệu suất của John)

Đã cập nhật: Bill quyết định thử và thuyết phục John thêm một lần nữa nếu nỗ lực đó không thành công thì anh ta sẽ không cố ép John sử dụng IDE và xem xét các tính năng mà John hứa có được giao kịp thời hay không.

Bạn đã ít nhiều trả lời câu hỏi:

1. Anh ta đang bị quản chế
2. Anh ấy không đủ năng suất

Vì vậy, anh ta cần phải được nhận thức rõ ràng rằng:

1. Anh ta cần phải làm việc hiệu quả hơn nếu không anh ta sẽ không bị quản chế.
2. Anh ta có trách nhiệm làm việc hiệu quả hơn với một IDE phù hợp hơn là với một trình soạn thảo văn bản tốt.
3. Một IDE tốt không phải là từ bỏ quyền kiểm soát mã bạn viết về việc cung cấp cho bạn các công cụ để cho phép bạn tạo mã làm việc nhanh hơn bất kể bạn có chọn sử dụng các phương tiện tạo mã và tạo khuôn mẫu có thể có trong IDE hay không .

Thiếu sẵn sàng thích nghi với môi trường của anh ta cũng có thể là một mối quan tâm.

Bill nên nói với John rằng anh ta đúng về việc thích trình soạn thảo văn bản đơn giản, nhưng thật không may, với ngôn ngữ + khung như Java + Hibernate + Spring, anh ta cần sử dụng IDE nếu muốn hiệu quả.

Tôi hơi giống John. Tôi không thích sử dụng IDE.
Khi tôi viết mã bằng ruby ​​/ python / bash / lisp, tôi không sử dụng bất kỳ IDE nào.

Nhưng khi tôi đang xử lý một ngôn ngữ dài / mức độ thấp như Java và các khung làm cho mã của bạn rất khó duyệt mà không có sự trợ giúp, tôi sử dụng IDE. Điều đó cũng đúng nếu tôi không biết rõ về ngôn ngữ / khung.

• Bạn càng sử dụng nhiều trừu tượng / mẫu / khung, bạn càng cần một IDE có khả năng giúp bạn điều hướng qua mã của mình.
• Ngôn ngữ càng thấp / dài dòng / không biết đối với bạn là ngôn ngữ, bạn càng cần một IDE có khả năng giúp bạn tạo / tìm mã bạn cần.

Nói với anh ta rằng nếu anh ta muốn hiệu quả với các công cụ bạn sử dụng, anh ta phải sử dụng IDE. Bill cũng nên kết hợp chương trình với John để cho anh ta thấy anh ta có thể hiệu quả như thế nào với IDE.

Tôi nghĩ rằng đẩy một IDE, là một ý tưởng tồi. Tôi nghĩ rằng có một danh sách các công cụ mà mọi người có thể sử dụng, và hơn là để anh ta chọn những gì anh ta sử dụng, là một giải pháp tôn trọng hơn.

Sau đó tập trung vào hiệu suất thực tế và năng suất, đưa ra số liệu thống kê thực về việc các dự án nhất định đã mất quá nhiều thời gian.

Đừng để sự tập trung là công cụ mà anh ấy sử dụng để viết mã, hãy để anh ấy tự tìm giải pháp, miễn là mục tiêu có năng suất tốt hơn.

Tôi đã đến nhiều công ty, 90% không quan tâm, miễn là họ không phải trả tiền cho bất kỳ công cụ nào, 10% chăm sóc và yêu cầu họ sử dụng các công cụ của họ.

Nếu bạn làm cho IDE trở thành trọng tâm thực sự của cuộc thảo luận của bạn, thì bạn hoàn toàn không tôn trọng anh ấy và phương pháp của anh ấy.

Thay vì tập trung vào vấn đề chính thực sự, năng suất, chất lượng và hiệu suất.

Bản thân tôi, đã sử dụng một trình soạn thảo văn bản trong hơn 6-7 năm và không có gì sai với hiệu suất của tôi.

Một IDE có thể giúp, nhưng nó phải là lựa chọn của lập trình viên để sử dụng nó, miễn là nó không ảnh hưởng đến hiệu suất.

Cá nhân tôi ghét IDE sẽ không bao giờ sử dụng em, càng nhiều người đẩy chúng vào tôi, tôi càng cảm thấy không được tôn trọng. Tôi không có vấn đề gì với việc mọi người sử dụng công cụ nào, nhưng nó giống như một tôn giáo và truyền giáo, họ cảm thấy cần mọi người khác phải suy nghĩ / làm mọi thứ theo cách họ làm.

Và đó là một cách tiếp cận rất thiếu chuyên nghiệp đối với vấn đề thực sự, năng suất của anh ta.

Nếu anh ta giao công việc chất lượng, theo phương pháp của anh ta, ai quan tâm anh ta sử dụng công cụ nào? Miễn là nó không có lỗi, chất lượng công việc và kịp thời.

Tôi không biết rằng chúng tôi đã xác nhận IDE là vấn đề của John. Tôi nghĩ Bill nên làm việc với John một chút và quan sát anh ta: Điều gì đang làm giảm năng suất của anh ta. Nếu anh ta dành hàng giờ để định dạng mã của mình và cố gắng di chuyển mọi thứ hoặc tìm kiếm các chức năng ... các loại mà IDE cung cấp cho bạn, thì bạn nên cho anh ta thấy anh ta có thể tìm thấy các chức năng mình muốn và định dạng mã nhanh hơn bao nhiêu IDE. Nếu đây là sự thất vọng, tôi chắc chắn một khi anh ấy thấy bạn tự động định dạng một khối hoặc nhanh chóng tìm thấy một số chức năng tối nghĩa, anh ấy sẽ nhảy qua mái nhà trong niềm vui sướng.

Tuy nhiên, nếu hiệu quả là do anh ta lướt google hoặc gặp khó khăn khi đưa ý tưởng của mình vào cấu trúc mã hóa, một IDE sẽ không giúp anh ta. Trong trường hợp đó, bạn cần phải phá vỡ kỷ luật của anh ấy, hoặc giúp anh ấy học cách lập sơ đồ ý tưởng của mình thành một luồng chương trình để anh ấy có thể tấn công vấn đề hiệu quả hơn

EDIT: Đại diện của tôi quá thấp để bình luận, vì vậy tôi phải đăng ở đây. Tôi không đồng ý với những người nói rằng "hãy để anh ta bị đuổi việc, sau đó anh ta sẽ học." Đối với một số người, công việc này; mất việc làm họ bị sốc và họ thực sự thức dậy và hình thành. Những người khác sẽ xoắn ốc thành một vòng xoắn tự hủy thường kết thúc trong trị liệu hoặc phúc lợi. Bill rõ ràng quan tâm đến John hoặc anh ta sẽ không hỏi làm thế nào để giúp anh ta, vì vậy tôi nghĩ rằng những bình luận và câu trả lời về việc chỉ để anh ta bị sa thải chắc chắn không phải là điều Bill đang tìm kiếm.

Thất bại là một giáo viên tuyệt vời. Bill có thể ngừng bảo vệ John và để anh ta đứng trước quyết định của chính mình. Nếu John bị sa thải vì điều đó, hy vọng điều đó sẽ khiến anh ta trở thành một nhân viên tốt hơn cho công ty tiếp theo thuê anh ta.

Bạn có thể cố gắng thuyết phục anh ta rằng nếu anh ta hiểu IDE và những gì nó làm, anh ta vẫn hoàn toàn kiểm soát.

Đây là củ cà rốt.

Cây gậy là anh ta đang bị quản chế.

Tôi phải nói rằng tôi đã sử dụng và IDE (aptana cho javascript), và tôi ghét nó, nó chậm và làm những điều kỳ lạ với định dạng. Tôi chuyển sang gvim với rất nhiều công cụ dòng lệnh và hạnh phúc hơn nhiều.

tất nhiên tôi là kiểu người sẽ viết mã tạo ra trong elisp cho vui.

Tôi khó có thể tin rằng hiệu suất của John có liên quan đến trình soạn thảo mà anh ta đang sử dụng. Tại nơi làm việc của tôi, khá nhiều người sử dụng một trình soạn thảo mã khác nhau (Visual Studio, Source Insight, vim, SlickEdit ...) và không có mối tương quan rõ ràng nào giữa trình soạn thảo / IDE và hiệu suất công việc.

Nếu có một IDE tiêu chuẩn của công ty, thì hãy nói thẳng với anh ấy "IDE này là tiêu chuẩn của công ty, SỬ DỤNG CNTT".

Nếu không có IDE tiêu chuẩn của công ty và mong muốn anh ta sử dụng IDE chỉ nhằm mục đích tăng hiệu suất, thì đó là:

1. Giả định sai lầm để đưa ra lựa chọn môi trường phát triển đó sẽ là một yếu tố quan trọng trong hiệu suất
2. Cách tiếp cận sai để bảo anh ta sử dụng IDE

Nếu bạn thực sự muốn anh ấy sử dụng IDE, tôi nghĩ cách tiếp cận tốt nhất là nói với anh ấy rằng hiệu suất của anh ấy không ngang bằng, sau đó cho anh ấy thấy việc sử dụng IDE có thể giúp cải thiện hiệu suất đó như thế nào. Hiển thị bằng ví dụ là một động lực tốt hơn nhiều theo ý kiến ​​của tôi.

Điều đó đang được nói, tôi nghĩ rằng các giả định là sai ở đây. Hầu hết các nhà phát triển phong nha có thể làm việc hiệu quả trong hầu hết mọi môi trường phát triển. Nếu anh ta không thực hiện theo mong đợi, thì có lẽ nguyên nhân sâu xa là do nhà phát triển chứ không phải IDE.

Nếu Bill, mặc dù giữ vị trí trưởng nhóm, không thể khiến John sử dụng IDE khi Bill muốn mọi người sử dụng nó, thì có điều gì đó không ổn với công ty ở chỗ trưởng nhóm không có đủ thẩm quyền.

Và không, tùy thuộc vào công việc được giao cho một người, người đó có thể làm việc hiệu quả mà không cần IDE, tùy thuộc vào công cụ sử dụng, trải nghiệm của người đó với các công cụ đó và năng lực chung của anh ta (và môi trường tổng thể, nếu John phải lấy từng nguồn từ máy chủ ứng dụng, tải nó vào IDE của mình, chỉnh sửa nó, tải lên lại, v.v., anh ta sẽ nhanh chóng hơn chỉ cần chỉnh sửa trực tiếp trên máy chủ ứng dụng bằng cách sử dụng VI (giả sử anh ta biết rõ trình soạn thảo đó) .

Không sử dụng IDE là rất tốt vì anh ta sẽ học được rất nhiều. Nhưng nó không nên trên chi phí của dự án. Anh ta nên sử dụng nó khi anh ta nghĩ rằng anh ta có thể hoàn thành công việc mà không ảnh hưởng đến dòng thời gian.

Tôi sẽ đề nghị anh ấy làm cả hai, để anh ấy có thể học nhanh và đồng thời không gặp vấn đề gì.

Sau khi tất cả bạn cần bánh mì để tồn tại thì chỉ có bạn mới có thể nghĩ về việc trở thành một người xây dựng cơ thể.

Tôi nghĩ rằng giá trị chính của bất kỳ IDE nào không phải là trình soạn thảo, mà đó là trình gỡ lỗi. Có một số người không có khái niệm về trình gỡ lỗi. Họ gỡ lỗi với báo cáo in.

Nếu các tính năng khác là những gì được cho là làm cho IDE hiệu quả hơn, như kết nối kiểm soát phiên bản hoặc kiểm soát phiên bản, tôi có thể thấy mình đồng ý với John, vì nhiều lý do chúng ta có thể tranh luận.

Nhưng gỡ lỗi với các câu lệnh in tôi thấy khó để mò mẫm (mặc dù tôi đã từng làm điều đó).

Nghe này, có người dùng đồ, có người khác dùng đồ khác. Tôi thích cả IDE và trình soạn thảo văn bản, chúng chỉ là 2 loại ứng dụng khác nhau, nhưng cuối cùng, nhiệm vụ được thực hiện là hoàn toàn giống nhau.

Đó chỉ là Cam và Táo, cuối dòng, nếu bạn muốn sa thải anh ta cãi lại "anh ta sử dụng trình soạn thảo văn bản" hoặc nếu không "anh ta quá chậm, BECAUSE anh ta sử dụng trình soạn thảo văn bản", tiếp tục, nhưng bạn có thực sự phải âm mưu không cho một số chiến lược về cách bạn có thể thuyết phục anh ta?

Bạn biết đấy, tự do không phải là "chỉ người mạnh nhất mới thắng thế", mà là "Làm những gì tôi muốn".

Không phải vì bạn sống trong một nền dân chủ mà bạn nên áp đặt thực tiễn của đa số. Nó gần giống như một cuộc bức hại của một số loại