Đối phó với Fanboys [đã đóng]

Có lẽ tất cả chúng ta đã gặp một người như thế này, nhà phát triển chỉ biết rằng ngôn ngữ của anh ta là ngôn ngữ thực sự và sẽ không im lặng về nó. Làm thế nào để bạn đối phó như một người như thế này? Tôi không muốn xúc phạm bất cứ ai (đặc biệt là vì fanboy ở nơi làm việc của tôi là nhà phát triển cao cấp). Nhưng tôi muốn có thể sử dụng lựa chọn ngôn ngữ kịch bản của riêng mình khi tôi phải viết một kịch bản bỏ đi mà không bao giờ có trong kho lưu trữ và không ai cần biết tồn tại.

Những suy nghĩ mà tôi đã phải đối phó với điều này:

1. Cười lên đi - "Haha vâng, có lẽ ngôn ngữ X dễ hơn một chút, tôi đoán tôi là một masochist!"
2. Đi với nó - Tôi thực sự muốn tránh điều này vì tôi không đủ khả năng giảm năng suất liên quan đến việc chọn một ngôn ngữ mới.
3. Ẩn ngôn ngữ của tôi - Trở thành một lập trình viên trong tủ quần áo và ẩn màn hình của tôi bất cứ khi nào tôi viết kịch bản hoặc tự động hóa một cái gì đó.

Bạn sẽ đề nghị gì cho tình huống này?

Vài điều đang nhảy ra khỏi câu hỏi.

• Nó thực sự là một kịch bản ném đi? Nếu có, thật lạ khi nó được thảo luận.
• Bạn có chắc chắn kịch bản ném đi sẽ vẫn như cũ? Nhiều thứ sản xuất đã trở thành một kịch bản vứt đi một lúc nào đó.
• Bạn sẽ viết lại kịch bản nếu nó được quảng bá và cần tích hợp trong hệ thống?
• Là sự lựa chọn ngôn ngữ hoàn toàn cú pháp hay nó là một ngôn ngữ từ một lĩnh vực khác?

Tôi hơi hiểu phần fan-boy, bởi vì từ một phía, đôi khi tôi cư xử giống như một fan-boy, trong khi bảo vệ một vài ngôn ngữ mà tôi lựa chọn. Và tôi cũng đã đối phó với những người hâm mộ khác, những người cố gắng mang những thứ mới vào.

Quan điểm của tôi về tình huống này là như thế này:

• Nếu đó là một ngôn ngữ mới, nó thuộc về thùng rác.
• Nếu đó là ngôn ngữ đã được chứng minh trong ngành, nó có thể được sử dụng nếu nó chuyên dùng cho nhiệm vụ.
• Nếu đó là một ngôn ngữ rất phổ biến, nó thuộc về thùng rác, ngay cả khi nó cực hay và siêu nhanh.

Đó là bởi vì không ai biết cách viết phần mềm an toàn và nhanh chóng bằng một ngôn ngữ không xác định và nó có tất cả các nhà phát triển gotchas phải học. Kịch bản ngu ngốc sẽ phải được hỗ trợ hơn 20 năm hoặc viết lại. Trong 20 năm, ít nhất 50 nhà phát triển thay đổi trong một cửa hàng trung bình. Nếu mỗi người viết một vài tập lệnh ưa thích bằng một ngôn ngữ mới, bạn cần 50 thời gian chạy ngôn ngữ, 50 chuyên gia khác nhau trong nhóm và cơ sở mã có mã lỗi bằng 50 ngôn ngữ. Và một số ngôn ngữ không còn được hỗ trợ trên Windows hoặc Linux. Và cần máy chủ tùy chỉnh 10 năm chưa từng có, không có phụ tùng thay thế, 24/7.

Ngoài ra, không ai thực sự muốn hỗ trợ các ngôn ngữ chết như VB, Silverlight, D, v.v., khi cơ sở mã có thể sẽ tồn tại lâu hơn chính ngôn ngữ đó.

Anh ấy có quyết định những gì bạn sử dụng dựa trên chính sách của công ty? Kháng cáo trường hợp của bạn cho anh ta; nếu anh ta vẫn quyết định chống lại nó, hãy im lặng và thực hiện công việc của bạn với các công cụ mà sếp của bạn nói rằng bạn nên sử dụng.

Bạn làm việc ở đó, không chơi ở đó. Cuối cùng, nó nằm ngoài tầm tay của bạn.

Ngay cả khi anh ấy không phải là ông chủ của bạn, tôi sẽ xem xét tất cả các góc độ ở đây. Bạn có muốn nó nếu anh ta biết Fortran và một ngày nào đó bạn thừa hưởng tất cả mã của anh ta. Bạn sẽ phải học một ngôn ngữ thương hiệu mới từ đầu một cách nhanh chóng , đó là khủng khiếp căng thẳng. Bây giờ hãy hình dung về phía anh ấy, bạn có thể viết kịch bản của mình bằng Cobol và anh ấy có thể không biết Cobol.

Sử dụng một cái gì đó mà phần lớn nhóm của bạn biết.

"2. Đi với nó"

Đây là câu trả lời hợp lý duy nhất. Bạn có một cơ hội tuyệt vời ở đây.

• Sử dụng ý kiến ​​của lập trình viên cao cấp để khuyến khích công ty của bạn trả tiền cho thời gian và / hoặc một khóa học và / hoặc chứng nhận để học ngôn ngữ mới. Trường hợp xấu nhất: chứng chỉ và ngôn ngữ sẽ cải thiện hồ sơ của bạn, bạn có thể nhận được một đề nghị tốt để trở thành một người chơi nhóm và bạn có thể cười mọi cách để có một công việc tốt hơn ở nơi khác.

• Tôi đã đạt được những hiểu biết có giá trị về lập trình từ mọi ngôn ngữ tôi đã học. Ngay cả ngôn ngữ ít thực tế nhất ( ho XSLT ho ) cũng có điểm ngọt ngào và có rất nhiều cơ hội học tập thú vị (và đã thanh toán hóa đơn của tôi trong vài năm). Học hỏi không ngừng là một trong những lợi ích tuyệt vời của việc trở thành một lập trình viên.

• Tất cả các dự án tuyệt vời có thể sử dụng ngôn ngữ yêu thích của nhà phát triển cao cấp. Biết rằng ngôn ngữ đưa bạn vào nhóm tài năng có thể làm việc trong các dự án đó.

• Ai đó có lẽ đang trả tiền cho bạn để làm một số công việc nhất định. Bất kỳ phản ứng nào khác có lẽ là không phù hợp và có khả năng kết thúc tồi tệ.

Nhà phát triển / kiến ​​trúc sư cao cấp thường chọn ngôn ngữ chính được sử dụng tại cửa hàng và đảm bảo rằng mọi người đều sử dụng ngôn ngữ đó. Bằng cách này, một công ty xây dựng một nền tảng kiến ​​thức trong một số công nghệ nhất định để một nhân viên (bạn) có thể đi nghỉ và người khác có thể lấy mã của bạn và sửa nó trong khi bạn đi. Ngoài ra, công ty có thể mang lại tài năng đào tạo có liên quan và bộ phận nhân sự sẽ biết những từ thông dụng nào cần tìm trong hồ sơ xin việc.

Bằng cách học ngôn ngữ của anh ấy và sử dụng nó cho công việc, bạn tích lũy được vốn chính trị mà bạn cần để vận động hiệu quả cho ngôn ngữ yêu thích của bạn . Nhiều công ty có ngôn ngữ cơ sở hạ tầng chính thức và ngôn ngữ kịch bản chính thức cho các báo cáo. Chuẩn bị một danh sách ưu và nhược điểm cho thấy ngôn ngữ của anh ấy vượt trội và nơi bạn làm, cũng là nơi mỗi ngôn ngữ bị thiếu. Bạn cần giữ danh sách này trong ngữ cảnh của một ứng dụng cụ thể, chẳng hạn như các báo cáo bạn đang viết. Lên kế hoạch thời gian với anh ấy để riêng tư và tôn trọng cho anh ấy xem danh sách và thảo luận với anh ấy. Viết ra những phản đối của anh ấy, nghiên cứu chúng sau cuộc họp và nếu bạn có những phản biện tốt, hãy lên kế hoạch cho một cuộc họp tiếp theo.

Chúc may mắn!

Cho thấy rằng trong một bối cảnh cụ thể, một ngôn ngữ khác là một lựa chọn thực dụng hơn.

Nếu người đó đam mê C ++ và bạn đang làm việc trong một dự án ứng dụng web, điều đó sẽ không quá khó khăn. Theo cùng một cách, một số bối cảnh rất nghiêng về lập trình chức năng và sử dụng một ngôn ngữ phi chức năng sẽ không phải là rất khôn ngoan.

Ghi chú:

• Tránh các tình huống mà cả ngôn ngữ ưa thích của bạn và anh ấy rất giống nhau.

  Ví dụ, tôi khó có thể tưởng tượng một bối cảnh trong đó Java sẽ "tốt hơn" so với C # hoặc C #, "tốt hơn" so với Java.

• Hãy nhớ rằng việc lựa chọn ngôn ngữ thường rất chủ quan và được giải thích nhiều hơn bởi kinh nghiệm trước đây của nhà phát triển hơn là một số yếu tố dựa trên bằng chứng.

  Ví dụ: nếu tôi được yêu cầu làm một ứng dụng liên quan đến lĩnh vực tài chính, tôi vẫn sẽ sử dụng C # thay vì Haskell, ngay cả khi tôi thấy Haskell phù hợp hơn và thực sự thú vị. Lý do của sự lựa chọn này là tôi có nhiều năm kinh nghiệm với C #, nhưng khi nói đến Haskell, tôi chỉ đọc một vài hướng dẫn và không bao giờ sử dụng nó một cách chuyên nghiệp.

Câu trả lời là 2) Đi với nó.

1. Cách duy nhất để khiến fanboy im lặng là trở nên thông thạo (ở một mức độ nào đó) trong ngôn ngữ mà anh ta lựa chọn.
2. Mất năng suất không phải là một vấn đề. Bạn đang làm theo yêu cầu của cấp cao của mình, vì vậy dự án phải thay đổi năng suất.
3. Học một ngôn ngữ mới sẽ làm cho bộ não của bạn hoạt động tốt hơn.
4. Học cách cởi mở về việc học ngôn ngữ mới sẽ giúp bạn tốt hơn nữa.

Đó là thắng-thắng-thắng-thắng. Thưởng thức!

Câu trả lời là bạn không đối phó với nó. Tranh cãi với họ chỉ cần kéo người tranh luận xuống cấp độ của họ (nơi họ đánh bại bạn bằng kinh nghiệm) và cuối cùng là không có kết quả vì họ có đầu óc gần gũi.

Bỏ qua mọi tranh luận họ đưa ra hoặc chống lại ngôn ngữ của họ và tạo nên tâm trí của riêng bạn. Sử dụng các kỹ thuật thông thường như tránh giao tiếp bằng mắt, trả lời đơn âm và chuyển sang một chủ đề mới khi sự im lặng đảm bảo. Thay vào đó hãy huấn luyện họ để làm phiền người bên cạnh bạn.

Thách thức ở đây là fan boy liên kết ngôn ngữ với danh tính của mình và bất kỳ tiêu cực nào liên quan đến ngôn ngữ đó là cá nhân. Đừng tấn công hoặc phòng thủ. Chỉ cần bỏ qua.

Rất ít điều trong một công việc là kịch bản thực sự vứt bỏ. Tôi kết thúc việc đưa nhiều thứ như vậy lên wiki hoặc trong kho lưu trữ trong trường hợp cần thiết một lần nữa.

Ngay cả những điều tôi nghĩ là dưới mức chia sẻ, đồng đội của tôi thường cảm thấy khác biệt. Ví dụ: tôi có một bí danh rgrep trong .profile của mình. Đó chỉ là một tuyên bố tìm kiếm với một tham số vì tôi không có quyền truy cập vào rgrep thực trên máy chủ đó. Một đồng đội đã đón gió và muốn nó trên wiki .. Vâng, tuyên bố một dòng. Rõ ràng là chúng tôi đã không có một cuộc tranh luận về ngôn ngữ thực hiện - nó phải là UNIX. Nhưng nó nhấn mạnh sự cần thiết phải làm những điều mà những người khác trong nhóm có thể hiểu.

Một vấn đề khác là có thể nhà phát triển cấp cao có lý do mà bạn không biết về việc sử dụng ngôn ngữ đó. Bạn đã hỏi chưa?

Có thể thử tạo cùng một tập lệnh trong cả hai ngôn ngữ một lần để cho thấy lý do tại sao ngôn ngữ của bạn tốt hơn.

Bạn nên thử sương mù . Điều này có nghĩa là đồng ý với tất cả những gì fanboy nói (một phần hoặc toàn bộ), nhưng hãy làm việc của riêng bạn trừ khi được hướng dẫn rõ ràng để làm khác.

Tùy chọn hung hăng thụ động 1,3 dẫn đến đau khổ cảm xúc nhiều hơn, vì vậy hãy cho tôi 2) đưa nó vào cằm.

Một số lời khuyên chung cho con đường: 4) Nếu bạn không nhận được bất kỳ thông minh nào hơn khi nghe đàn anh, hãy tự học về thiết kế ngôn ngữ / trình biên dịch. Chọn một ngôn ngữ và tìm hiểu những suy nghĩ đã đi vào nó. Sự đánh đổi là gì giữa các tính năng, hiệu suất và sức mạnh biểu cảm. Tùy chọn khác là gì ở đó. Điều này một mình sẽ cấp cho bạn siêu năng lực lập trình vô nhân đạo. Tìm hiểu NBL thậm chí, nó sẽ rất lớn.

Khẳng định bản thân bằng cách đẩy ý kiến ​​về người khác ức chế năng suất và giao tiếp. Mọi người có thể nghĩ rằng từ bỏ sự thôi thúc cảm xúc là hữu ích, nhưng đó chỉ là một sự trợ giúp ban nhạc cho sự bất an của họ.

Khiêm tốn và tử tế với lời khuyên, và cải thiện bản thân sẽ làm nên điều kỳ diệu để thể hiện cảm xúc ruột thịt của bạn ở mức độ kỹ thuật. Bạn sẽ cảm thấy tốt hơn và thấy mọi thứ cho những gì họ đang có, bởi vì bạn sẽ có thể lý luận. Khó có thể nổi điên khi bạn đưa ra những lời chỉ trích đến bối cảnh kỹ thuật.