Làm thế nào để bạn biết nếu lời khuyên từ một nhà phát triển cao cấp là xấu? [đóng cửa]

Gần đây, tôi bắt đầu công việc đầu tiên của mình là một nhà phát triển cơ sở và tôi có một nhà phát triển cao cấp hơn phụ trách tư vấn cho tôi trong công ty nhỏ này. Tuy nhiên, có nhiều lần anh ấy sẽ cho tôi lời khuyên về những điều mà tôi không thể đồng ý (nó đi ngược lại những gì tôi học được trong một số cuốn sách hay về chủ đề được viết bởi các chuyên gia, những câu hỏi tôi đã hỏi trên một số trang web Hỏi & Đáp cũng đồng ý với tôi) và đưa ra lịch trình bận rộn của chúng tôi, có lẽ chúng tôi không có thời gian cho các cuộc tranh luận dài.

Cho đến nay, tôi đã cố gắng tránh vấn đề bằng cách lắng nghe anh ấy, nêu ra một phản biện dựa trên những gì tôi đã học được như những thực tiễn tốt hiện tại. Anh ta tăng điểm ban đầu của mình một lần nữa (hầu hết thời gian anh ta sẽ nói cách thực hành tốt nhất, dễ bảo trì hơn nhưng chỉ không đi xa hơn), tôi lưu ý (vì anh ta đã không nêu ra một điểm mới để phản biện lại quan điểm của tôi), hãy nghĩ về nó và nghiên cứu tại nhà, nhưng không thực hiện bất kỳ thay đổi nào (tôi vẫn không bị thuyết phục). Nhưng gần đây, anh ấy lại tiếp cận tôi một lần nữa, thấy mã của tôi và hỏi tôi tại sao tôi không đổi nó thành gợi ý của anh ấy. Đây là lần thứ 3 trong 2--3 tuần.

Là một nhà phát triển cơ sở, tôi biết rằng tôi nên tôn trọng anh ấy, nhưng đồng thời tôi không thể đồng ý với một số lời khuyên của anh ấy. Tuy nhiên, tôi đang bị áp lực phải thực hiện những thay đổi mà tôi nghĩ sẽ làm cho dự án tồi tệ hơn. Tất nhiên là một nhà phát triển thiếu kinh nghiệm, tôi có thể sai và cách của anh ta có thể tốt hơn, đó có thể là một trong những trường hợp ngoại lệ đó.

Câu hỏi của tôi là: tôi có thể làm gì để đánh giá tốt hơn nếu lời khuyên của một nhà phát triển cấp cao là tốt, xấu hoặc có thể là tốt, nhưng đã lỗi thời trong bối cảnh ngày nay? Và nếu nó là xấu / lỗi thời, tôi có thể sử dụng chiến thuật nào để không thực hiện theo cách của mình mặc dù có 'áp lực' trong khi vẫn duy trì sự thật rằng tôi tôn trọng anh ấy như một đàn anh?

Đầu tiên, với tư cách là một nhà phát triển cấp cao, tôi hy vọng các đàn em mà tôi lãnh đạo trong các dự án sẽ mang lại mối quan tâm của họ cho tôi một cách thẳng thắn và trực tiếp. Nếu họ không đồng ý, điều đó hoàn toàn ổn với tôi. Trong một số trường hợp, tôi sẽ hành động về mối quan tâm của họ. Trong hầu hết các trường hợp, mối quan tâm của họ bị gạt sang một bên với một lời giải thích ngắn gọn về lý do , không phải là thiếu tôn trọng đối với nhà phát triển mà vì một số lý do khác như:

1. Thiếu niên không có tất cả thông tin trong tay để hiểu quyết định khi nó được đưa ra. Trong một số trường hợp, một lời giải thích nhỏ có thể giúp nhà phát triển vượt qua mối quan tâm và giải quyết một tình huống không có thực.
2. Các đàn em có thông tin BAD. Đừng quên rằng, trên thực tế, bạn là một thiếu niên. Điều đó tương đương với việc là một thiếu niên về phần mềm. Tôi chắc rằng bạn có rất nhiều ý tưởng tuyệt vời, nhưng có thể là bạn không biết tất cả mọi thứ. Tôi thấy các nhà phát triển cơ sở có sức đề kháng cao nhất là những người tin chắc rằng họ biết những gì tốt nhất cho mã, công ty, thế giới. Những nhà phát triển được phục vụ tốt hơn bằng cách có được sự khiêm tốn.
3. Quyết định làm một cái gì đó một cách cụ thể đã được đưa ra trên đầu của cấp cao. Các tiền bối vẫn làm việc cho người khác cuối cùng. Thực sự có thể có một cách tốt hơn để làm một cái gì đó, một cách hiệu quả hơn để viết một cái gì đó, hoặc phần mềm / phần cứng tốt hơn để giúp thực hiện công việc. Các doanh nghiệp vẫn lái các quyết định mặc dù. Các nhà quản lý doanh nghiệp, giám đốc, VP, v.v ... thường đưa ra các quyết định tác động đến quá trình phát triển. Những điều này nằm ngoài tầm kiểm soát của đàn anh, và khi đàn em phàn nàn về điều đó, tất cả những gì họ đang làm là làm tăng thêm căng thẳng cho đàn anh.
4. Các tiền bối chỉ thẳng thừng không có thời gian để đưa nó vào tài khoản. Có thời hạn, và đôi khi thay đổi mô hình, thực tiễn và hành vi giữa dòng là tốn kém cho thời hạn đó. Vì đó là phần cổ của anh ấy trên khối băm, điều quan trọng hơn là làm cho sản phẩm hoạt động đúng giờ và đúng giờ hơn là "được viết hoàn hảo".

Đây chỉ là những điều tôi có thể nghĩ ra khỏi đỉnh đầu của tôi. Có rất nhiều lý do tại sao một ý tưởng, thực hành, khái niệm có thể bị loại bỏ hoặc loại bỏ bởi một người nào đó cao hơn bạn. Nhiều người trong số họ khó chịu, nhưng tất cả đều sôi sục trước thực tế rằng tất cả chúng ta đều là con người và tất cả chúng ta đều có ý kiến. Ý kiến ​​của anh ấy chỉ là số lượng vượt trội so với bạn tại thời điểm này.

Ghi nhớ những khái niệm đó, bạn nên tiếp tục đưa mối quan tâm của mình đến nhà phát triển cao cấp. Tìm một nhà phát triển cao cấp khác có thể điền vào chỗ trống. Nhiều nhà phát triển cấp cao đang ở đó vì họ giỏi phần mềm hơn so với mọi người. Một số nơi họ đang ở vì họ biết ai sẽ hôn mông khi họ thực tập. Tìm một người thực sự hiểu ý nghĩa của nó để cố vấn ai đó và có được ý kiến ​​trung thực của họ. Họ có thể không đồng ý với bạn và điền vào chỗ trống mà bạn không có. Họ có thể đồng ý với bạn và giúp tập hợp nguyên nhân của bạn hoặc làm cho tình hình của bạn tốt hơn.

Không có thời gian bạn nên gắn kết bất kỳ cuộc nổi dậy. Ngay cả khi bạn tin vào trái tim mình rằng cách của bạn là đúng, bạn đã được hướng dẫn làm theo và bạn nên tuân theo nó (trừ khi rõ ràng là bất hợp pháp). Nếu bạn gặp khó khăn khi làm theo các hướng dẫn này, bạn có thể muốn cố gắng giải thích lý do tại sao vì bạn sẽ phát hiện ra mô hình hành vi này rất phổ biến ở rất nhiều công ty sản xuất bất kỳ loại phần mềm nào.

Lựa chọn tốt nhất của bạn là tiếp tục làm công việc của bạn một cách đạo đức và chuyên nghiệp. Nhận phần mềm bạn được yêu cầu hoàn thành một cách mẫu mực và thoát khỏi tình huống bằng cách được quảng bá ra khỏi nó. Nếu chương trình khuyến mãi không đến, bạn sẽ có nhiều tài liệu tham khảo và kinh nghiệm để theo đuổi các cơ hội ở các bộ phận hoặc công ty khác.

Tôn trọng các nhà phát triển cao cấp. Anh ấy hướng đến sự thành công của dự án nhiều hơn bạn. Vì anh ta có trách nhiệm nên anh ta cũng có được quyền. Nếu anh ấy nói thay đổi một cái gì đó thì làm điều đó.

Điều đó đang được nói, đừng ngần ngại trình bày mối quan tâm của bạn, khi bạn gặp phải một vấn đề như bạn đã có.

Cuối cùng, ngồi xuống với anh ta và giải thích cho anh ta câu hỏi tương tự bạn đăng ở đây. Có thể bạn đang thiếu một cái gì đó lớn lao, có thể anh ấy sẽ cởi mở hơn với những lời đề nghị của bạn, dù sao đi nữa, đừng giữ anh ta trong bóng tối nếu bạn nghĩ rằng lời khuyên của anh ta là kém.

Khi điều này xảy ra, điều bạn cần làm là có một cuộc trò chuyện với nhà phát triển cấp cao . Có lẽ anh ấy biết điều gì đó mà bạn không biết về mã hoặc các yêu cầu kỹ thuật / kinh doanh. Nếu vậy, bạn nên học nó.

Làm như vậy trong tư nhân. Nó có thể được coi là cơ quan đầy thách thức và những điều như vậy được thực hiện tốt nhất từng bước một. Thể hiện sự sẵn sàng thỏa hiệp và hợp tác bằng cách thừa nhận và tôn trọng thâm niên của anh ấy, nhưng hãy kiên trì nhận câu hỏi của bạn. Tiếp cận tình huống từ một khung hợp tác, không phải là một chiến lược. Bạn có thể xem xét yêu cầu anh ấy cố vấn cho bạn.

Vào cuối ngày, bạn phải cân bằng các ý tưởng của riêng bạn (mà công bằng mà nói, tương đối mới và chưa được thử nghiệm) với ý tưởng của mình. Có lẽ bạn thực sự đúng, nhưng bạn nên cố gắng hết sức để học hỏi từ những người có kinh nghiệm hơn để bạn có thể đưa ra quyết định sáng suốt hơn. Một nhà phát triển cấp cao giỏi hoan nghênh cơ hội hợp tác, cố vấn và học hỏi, ngay cả với các nhà phát triển cơ sở và hoan nghênh ý tưởng của họ bị thách thức theo cách xây dựng vì họ cũng biết rằng đôi khi họ sai.

Cách bạn thường nói là thông qua một cách tiếp cận thông thường. Hãy nhớ rằng nhà phát triển cao cấp có thể biết nhiều hơn về dự án, nhưng có thể không biết nhiều hơn về cách làm đúng đắn. Bạn phải đánh giá những gì anh ấy bảo bạn làm - anh ấy cho bạn lời khuyên tồi nếu những gì anh ấy nói sẽ đối mặt với những gì anh ấy yêu cầu (tức là những người cao cấp hơn anh ấy; không nhất thiết phải ở công ty bạn ... Tôi đang nói về các nhà phát triển "người nổi tiếng" nổi tiếng, những người thường đăng hoặc viết sách về cách chính xác để phát triển phần mềm, hoặc tại các thực tiễn tốt nhất được ngành công nghiệp chấp nhận ít nhất).

Đây là một ví dụ về "lời khuyên tồi" từ một nhà phát triển cấp cao (hoặc bất kỳ nhà phát triển nào): Nếu họ hoàn toàn không biết gì về khớp nối lỏng lẻo và tại sao đó là một điều tốt, và bạn được yêu cầu viết tất cả mã vào, giả sử, mã -Trong tập tin ASPX, rõ ràng nhà phát triển cấp cao không biết gì và không nên nghe lời khuyên của anh ta.

Mặt khác, nếu anh ấy nói cho bạn biết một mô-đun cụ thể trong hệ thống hoạt động như thế nào, thì tốt nhất là hãy lắng nghe miễn là một lần nữa, những gì anh ấy nói với bạn không nói ra khi đối mặt với các nguyên tắc phát triển đúng đắn.

Đây là quy tắc của tôi: Một nhà phát triển cao cấp tại một công ty có thể chỉ đơn giản là nhà phát triển có nhiệm kỳ dài nhất; anh ta có thể không có bất kỳ kỹ năng thực sự. Có phải anh ấy đang nói những điều đi ngược lại với những gì một số nhà phát triển được kính trọng nhất trong lĩnh vực của bạn nói (những người có nhiều kinh nghiệm hơn anh ấy, và những người có năng lực và được tôn trọng hơn rất nhiều)? Nếu là anh ta, rất có thể lời khuyên của anh ta là xấu trừ khi có những hoàn cảnh rất khắc nghiệt.

Hoàn toàn mong đợi downvote / bất đồng cho quan điểm cực kỳ thiên vị.

Có thể khó hiểu được quan điểm thuận lợi của nhà phát triển cao cấp, và vâng, anh ta có thể đang dẫn mọi thứ đi sai đường, tuy nhiên khi nói đến các dự án lớn, tính nhất quán là quan trọng hơn.

Có 50 một số nhà phát triển đều tuân theo các phong cách, tiêu chuẩn, phương pháp và mẫu thiết kế mã hóa của riêng họ sẽ là sự hỗn loạn hoàn toàn. Nếu mọi thứ đang được thực hiện sai, tốt hơn là luôn luôn sai so với nhiều loại sai khác nhau và một số điều đã được thực hiện đúng.

Khi đến lúc phải thực hiện bảo trì, thêm tính năng hoặc sửa lỗi "sai" thì sẽ dễ dàng hơn nhiều nếu các vấn đề với thiết kế hiện tại được biết trước.

Thật tốt khi tôn trọng không đồng ý nhưng cuối cùng, tốt nhất bạn nên xếp hàng. Bất cứ ai trong một đội đi lừa đảo đều không được xem là một người chơi trong đội.

Nếu cấp cao không thể cung cấp cho bạn lý do chính đáng tại sao họ lại bỏ qua thực tiễn tốt nhất trong ngành, thì đừng lãng phí thời gian của bạn ở đó. Bạn sẽ không bao giờ tiến lên vì bạn quá đe dọa, và dù sao, bạn có muốn dành thời gian để duy trì một đống mã xấu?

Hầu hết các nhà phát triển ngừng đọc khi họ rời trường đại học. Bạn chưa có, vì vậy bạn đã nằm trong top 10%. Có rất nhiều cơ hội những ngày này. Nếu không có thị trường việc làm trong thị trấn của bạn, thì hãy tìm một thị trấn tốt hơn.

Wow đó là một cơ hội tuyệt vời để bạn tỏa sáng và thể hiện kỹ năng của mình. Đầu sự nghiệp, tôi có một người là giám sát viên của mình, người không thể đưa ra quyết định, bất kỳ quyết định nào, vì vậy tôi đã sử dụng cơ hội đó để học cách làm công việc của cấp cao hơn tiếp theo. Nó đã cho tôi thăng chức. Bạn nên làm như vậy.

Là một nhà phát triển cấp cao, kiểu chọn nit tích cực thụ động này sẽ khiến tôi phát điên và sau khi đối đầu với bạn, tôi sẽ khiến tôi đánh giá không tốt. Giải pháp hoàn hảo là nhóm mà nhóm có thể sống cùng.

Đối với phong cách, điều này nên được quyết định bởi hướng dẫn phong cách của bạn và thực hành tốt nhất được xác định bởi nguồn gốc của bạn. Nếu bạn đam mê tranh luận về nó, nhưng một khi quyết định được đưa ra trực tiếp với nó và làm việc trong giới hạn của đội bạn đang ở.

Bạn đang ở trong một tình huống không mấy khả quan nhưng, như HLGEM đã chỉ ra, bạn có thể biến những vị trí này thành phước lành trong sự ngụy trang. Câu hỏi của bạn rất đa dạng, vì vậy tôi sẽ tiếp cận nó theo từng phần.

Tôi nghi ngờ, anh không biết. Đồng thời, anh ta cố gắng thể hiện cho tôi sự kiêu ngạo có thể để tôi không trả lời anh ta nhiều câu hỏi.

Điều này rất có thể đúng. Có một số lượng lớn các nhà phát triển đã ở trong ngành trong nhiều thập kỷ và không có khả năng dẫn đầu về phần mềm - từ quan điểm phát triển hoặc cố vấn (có một sự khác biệt). Kinh nghiệm đến từ việc giải quyết những thách thức mới và thử những ý tưởng mới và học các kỹ năng mới, nhưng phần lớn các lập trình viên dành cả cuộc đời của họ trong Văn phòng Công ty, làm việc trên Ứng dụng Biên chế với các công cụ Visual Basic và Java trung thành của họ, không bao giờ thấy thế giới đua xe bởi văn phòng màu xám lạnh lẽo của họ.

Không có gì sai với điều này . Đối với nhiều nhà phát triển, tất cả những gì họ muốn và hoàn toàn hài lòng với tình huống - tuy nhiên, đó không phải là một tình huống lý tưởng để thúc đẩy một thế hệ lập trình viên trong tương lai, chứ đừng nói đến việc dẫn dắt các nhà phát triển.

Bravado và kiêu ngạo có thể là một cơ chế phòng thủ, cố gắng che đậy cho những bất cập. Làm thế nào để bạn xử lý nó? Đừng đối đầu trực diện - nếu lãnh đạo của bạn không đủ năng lực và ông chủ không sẵn lòng khắc phục tình hình thì bạn sẽ phải sống với nó . Điều đó không có nghĩa là lăn lộn và chết, nhưng bạn không thể ép ai đó trở thành người dẫn đầu tốt.

Tuy nhiên, anh ta chỉ xem xét mã của tôi và hầu hết các bình luận của anh ta đều liên quan đến hướng dẫn mã hóa

Đây là điều khiến tôi nghĩ rằng bạn đúng khi nói rằng anh ta có thể không phải là một lập trình viên giỏi. Điều đó không có nghĩa là anh ấy không phải là một lập trình viên giỏi hơn bạn vào lúc này (ít nhất là anh ấy sẽ có nhiều kinh nghiệm và tiếp xúc với việc làm trong ngành quá lâu) nhưng một lần nữa, điều đó không biến thành một chì hiệu quả. Các hướng dẫn đều tốt và tốt, nhưng chúng đứng thứ hai về chức năng, hiệu lực và hiệu quả của mã.

Tôi nên làm gì trong tình huống như vậy?

Tôi đã thông báo cho người quản lý của mình về tình huống này và tôi đã yêu cầu anh ta thay đổi sự dẫn dắt của mình, mặc dù anh ta nói "có" mọi lúc, nhưng anh ta không có hành động nghiêm trọng nào.

Bạn đã liệt kê tất cả các điểm cụ thể này cho người quản lý và với các ví dụ cụ thể để sao lưu nó chưa? Nếu bạn chỉ đơn giản là đến gặp anh ấy và nói: "Tôi cần một người lãnh đạo mới", anh ấy sẽ không coi trọng bạn và coi đó là một "vấn đề giữa các cá nhân" chứ không phải là một vấn đề kỹ thuật. Phản ứng của rất nhiều ông chủ trong tình huống này là phớt lờ nó với hy vọng rằng nó sẽ "tự giải quyết".

Đây là một số gợi ý.

1. Đừng an toàn trong tình huống của bạn - thử nghiệm bằng lửa, trong khi không vui, dạy cho bạn một số kỹ năng nghiên cứu quan trọng để sau này trong sự nghiệp.
2. Bắt đầu đẩy khách hàng tiềm năng của bạn để được tham gia nhiều hơn. Làm điều này một cách cẩn thận và tôn trọng . Tiếp tục thúc đẩy và kiên trì cho đến khi anh ấy nhượng bộ (điều này thực sự có tác dụng cho rất nhiều tình huống trong cuộc sống).
3. Nếu khách hàng tiềm năng của bạn sẽ không tham gia, hãy xem nếu có những người khác có thể giúp bạn. Trừ khi bạn làm việc trong một cửa hàng mồ hôi chỉ quan tâm đến giờ vắt sữa thì công ty của bạn sẽ không bận tâm đến một nhà phát triển khác có nhiều kinh nghiệm chỉ cho bạn một số sợi dây và xem xét mã của bạn.
4. Bắt đầu để mắt đến một công việc mới. Tôi sẽ không nói rằng bạn đang ở trong một tình huống "phải rời đi" nhưng điều đó sẽ không ảnh hưởng đến sự nghiệp của bạn ở một nơi khiến sự phát triển của bạn trở thành một lập trình viên nghiêm túc hơn.

Nếu bạn có cách tốt hơn để giải quyết một vấn đề cụ thể, chỉ cần LÀM NÓ .

Hãy để mã / giải pháp của bạn là đối số tốt nhất của bạn. Nếu không thì dính vào những gì bạn đã được nói.

Trường hợp tại điểm

Khi tôi còn là một thiếu niên, tôi đã có một tình huống mà một phần mã cụ thể không phải là tốt nhất có thể. Thay vì chỉ tranh luận về nó, tôi chỉ đơn giản là cải thiện nó THEN cho thấy kết quả với tiền bối của tôi. Ông chấp nhận nó, bởi vì mã luôn luôn là vua.

Tất nhiên, là một nhà phát triển thiếu kinh nghiệm, tôi có thể sai và cách của anh ta có thể tốt hơn vì vậy câu hỏi của tôi là tôi có thể làm gì để đánh giá tốt hơn nếu một lời khuyên của nhà phát triển cấp cao là tốt hay xấu / lỗi thời.

Bạn có thể trở thành một nhà phát triển có kinh nghiệm. Cho đến khi bạn làm điều đó, bạn sẽ không được trang bị đầy đủ để đánh giá liệu trực giác của bạn khi còn là một thiếu niên có đúng hay không, và sau đó nó sẽ không thành vấn đề.

Trong lúc này, hãy đọc câu trả lời của Joel Etherton.

Tôi thực sự khuyên bạn không nên cố gắng "không thực hiện theo cách của mình".

Cho đến nay, có vẻ như bạn đã làm đúng. Bạn đã khiêm tốn và đưa ra một phản biện. Tôi không thể nói từ câu hỏi của bạn cho dù bạn chỉ đơn giản là không đồng ý với phương pháp của anh ta, hay bạn không đồng ý và đưa ra một phương án. Tuy nhiên, điểm mấu chốt là luôn đưa ra một giải pháp thay thế rõ ràng và có suy nghĩ khi bạn cố gắng bắn hạ cách tiếp cận của người khác . Như anh ấy có thể thấy, bạn có một ý tưởng tốt có thể hoạt động, và anh ấy có một ý tưởng hoạt động được.

Ở bất kỳ vị trí nào, chúng tôi buộc phải làm những điều tối ưu mọi lúc. Nếu bạn thực sự không thích nó, thì bạn có thể làm như bạn đã làm và đưa nó lên. Sau đó, theo cách của ông chủ hoặc đường cao tốc. Về mặt sáng sủa hơn, bạn được cách ly khỏi phần lớn rủi ro của những quyết định tồi tệ khi còn là một thiếu niên.

Chọn bạn chiến đấu. Nếu bạn nói về một giờ làm việc, bạn sẽ phải thay đổi mã của mình nhiều lần cho đến khi bạn làm việc theo cách của mình. Lần tới khi bạn nhận được một dự án lớn, hãy hỏi trước để có cơ hội trình bày ý tưởng của bạn trước khi bắt đầu. Đặt thêm thời gian và tạo một bản demo hoặc nguyên mẫu tuyệt vời.

Thật sốc, những gì tôi đã làm chỉ là ngừng hỏi. Khi được đưa ra một lựa chọn khác, tôi chỉ lạc đề và thực hiện theo cách của mình nhưng thêm sự tinh tế của riêng mình vào nó. Sử dụng nó như một kinh nghiệm học tập để xây dựng khả năng của bạn và vẫn bình định nhu cầu của mình để giữ cho trường học cũ.

Cuối cùng, không phải mọi nhà phát triển cấp cao đều chú ý đến những cách làm mới. Đôi khi, họ có những cách học cũ rất phù hợp với ngôn ngữ mà họ đã bắt đầu từ 20 năm trước nhưng bị coi là hack, hoặc "có mùi khó chịu" trong thế giới ngày nay.

Điều này có vẻ như là một cách khủng khiếp để tiếp tục, và nó là. Nhưng tôi cũng đã học được rất nhiều từ cách làm việc của người cao niên. Nhưng đây thực sự chỉ là ý kiến ​​của tôi. Cuối cùng, bạn phải hạnh phúc trong công việc của mình và giữ cho sự phân tâm và căng thẳng ở mức thấp. Và bằng cách không phản đối những điều bạn sẽ thấy căng thẳng đi xuống.

Đừng tin người cao cấp vì có thâm niên. Thách thức thẩm quyền càng thường xuyên càng tốt. Một cơ quan có thẩm quyền sẽ có thể trả lời một cách thuyết phục bất kỳ câu hỏi. Đó là điều khiến anh ta trở thành người có thẩm quyền ngay từ đầu, phải không?

Bởi vì ai đó giữ niềm tin mê tín trong suốt cuộc đời mình không có nghĩa là anh ta đúng. Hãy nhớ rằng, ở thời trung cổ, người ta tin rằng trái đất phẳng và một số những kẻ tự cho mình là đúng, thậm chí còn cảm thấy chính đáng khi giết chết những kẻ nghi ngờ. Hóa ra những nghi ngờ là đúng. Quá nhiều cho các đánh giá xấu.

Không bao giờ sợ một đánh giá xấu. Bạn có tin tưởng một người mù đánh giá màu sắc?

câu trả lời tốt ở trên, sẽ thêm rằng một câu trả lời như "thực hành tốt nhất" hoặc "dễ bảo trì hơn" là một cơ hội để tìm hiểu điều gì đó . Bạn nói, "Bạn có thể cho tôi một ví dụ về lý do tại sao cách đó là tốt nhất để tôi có thể hiểu sự khác biệt?" hoặc "Trong tình huống nào thì cách này sẽ dễ duy trì hơn bằng cách khác, vì vậy tôi có thể học cách lên kế hoạch trước như vậy?"

Nếu cấp cao là đúng, cho bạn một ví dụ sẽ dễ dàng. Nếu anh ta là một con vẹt ... hãy cho anh ta một cái bánh quy để ngăn chặn con mực ', và làm những gì bạn nghĩ là tốt nhất. Cho đến khi ra lệnh để khác.

Nếu vai trò của cấp cao là cố vấn, anh ta sẽ giải thích tại sao khi được hỏi.

Như HLGEM và Jarrod đã nói trước đây, đây thực sự là một phước lành trong việc ngụy trang. Cả hai câu trả lời của họ đều rất hay và tôi muốn thêm một số điểm.

Vì khách hàng tiềm năng của bạn không ở trong miền của bạn, bạn có thể đưa ra một số quyết định quan trọng cho phần ứng dụng của mình vì khách hàng tiềm năng của bạn không biết nhiều về phần mềm trung gian. Bạn cũng đã kết thúc với người quản lý của mình về cách ứng dụng sẽ hoạt động, người dùng sản phẩm muốn gì và người quản lý của bạn muốn giải quyết tình huống do nhóm sản phẩm trình bày cho anh ta như thế nào. Hãy cho tôi biết có bao nhiêu người sẽ có được loại kiến ​​thức đó trên một ứng dụng.

Khi bạn ở trong một nhóm lớn, bạn chắc chắn sẽ có sự giúp đỡ từ đồng đội và / hoặc người lãnh đạo của bạn nhưng bạn sẽ không có kiến ​​thức về cách người quản lý của bạn nghĩ hoặc nhóm sản phẩm nghĩ vì điều đó thường đi qua sự dẫn dắt của bạn và có thể một số nhà phát triển cấp cao trong một đội. Tôi đồng ý các dự án của một người rất khó thực hiện nhưng nếu mặt khác của đồng tiền quá lớn thì tại sao lại bỏ lỡ cơ hội. Tìm hiểu những gì bạn có thể học, tận hưởng trong khi bạn có thể và nếu quá khó để thuyết phục người quản lý của bạn như Jarrod nói hoặc tìm một công việc / dự án mới tùy thuộc vào tình huống.

Bạn sẽ đối phó với những người như thế trong toàn bộ sự nghiệp của bạn. Và sẽ có nhiều người mà bạn sẽ không đồng ý về cách tiếp cận tốt nhất cho bất kỳ vấn đề mã hóa nào. Điều tốt nhất tôi nghĩ rằng đã làm việc cho tôi trong nhiều năm qua là nếu họ tiếp tục nhấn mạnh vào một vấn đề, hãy thẳng thắn với họ và nói với họ rằng bạn đã xem xét giải pháp của họ trong số các giải pháp khả thi khác nhau và bạn cảm thấy rằng đó là giải pháp cho bạn giải quyết trên là một trong những bạn cảm thấy là cách tiếp cận tốt nhất trong tình huống này.

Bây giờ, nếu bạn chọn chống lại lời khuyên của họ mọi lúc, thì thỉnh thoảng bạn có thể cần phải từ bỏ và sử dụng "lời khuyên" của họ theo thời gian chỉ để làm phẳng một vài chiếc lông xù. Miễn là họ không cảm thấy bạn từ chối đầu vào của họ mỗi lần, thì điều đó sẽ đi một chặng đường dài để giữ hòa bình giữa bạn.

Cũng xem xét rằng họ là một nhà phát triển cao cấp và đã làm việc trong môi trường đó lâu hơn bạn có. Mã hóa thực tế thường không phù hợp với các thực tiễn tốt nhất hoặc các tiêu chuẩn được cộng đồng chấp nhận. Có thể có một lý do mà họ khuyên bạn nên làm một cái gì đó theo một cách nhất định mà họ không thể nói rõ. Vì vậy, ngay cả khi bạn không đồng ý với họ, hãy đảm bảo rằng bạn không gạt bỏ lời khuyên của họ ra khỏi tay chỉ dựa trên thực tế là bạn tin rằng giải pháp của bạn tốt hơn.

Đó là tất cả về sự cân bằng. Và không chỉ cân bằng mã hóa, mà còn cân bằng nhóm. Nhiều dự án đã thất bại không phải vì các nhà phát triển không có khả năng thực hiện nó, mà bởi vì họ không thể tìm ra cách để làm việc cùng nhau một cách thân thiện.

Tôi muốn cung cấp một số nội dung từ kinh nghiệm cá nhân của tôi, được coi là một câu trả lời bổ sung cho một bài đăng ở đây bởi jzd ...

1. Hỏi một nhà phát triển cao cấp khác,
2. Tự nghiên cứu.

Trong một cuộc hẹn chuyên nghiệp, tôi được cho là được cố vấn bởi một người cao cấp. Anh ta biết một số thứ nhưng thực sự không nhiều, tiếc là anh ta không biết nó, vì vậy anh ta cực kỳ tự tin vào câu trả lời của mình. Tôi bằng cách nào đó cảm thấy rằng những gì anh nói là sai. Tôi đã có một số bằng chứng khi những thứ anh ta làm là chống lại các thực tiễn tốt nhất được đề cập trong chứng nhận MS mà tôi đã thực hiện :-). Sau đó tôi bắt đầu hỏi những người khác làm việc trong các công ty khác (stackexchange không hoạt động và sau đó chạy lại) và bắt đầu đọc blog để so sánh câu trả lời.

Sẽ thật tuyệt nếu tôi sai, vì tôi chỉ thay đổi hành vi của mình, nhưng tôi đã không làm thế.

Tôi đã nhận thấy điều gì đó trong vài năm qua, gần như mọi công ty tôi đang làm, với gần như mọi dự án tôi làm, với gần như mọi người thuê mới (bất kể trình độ kỹ năng / kinh nghiệm) muốn làm điều gì đó 'khác biệt'.

Nó có thể là các tiêu chuẩn mã hóa hoặc kiến ​​trúc tổng thể hoặc ngôn ngữ hoặc phương pháp luận. Nhưng nó luôn luôn là một cái gì đó. Rất nhiều lần, đó chỉ là một điều hiển nhiên, 'Không phải mọi thứ sẽ được ghi nhận tốt hơn, cho người dùng cuối của chúng ta sao?'

Lời khuyên của tôi cho bạn là đừng là anh chàng đó .

Một ngày nào đó, bạn sẽ trở thành một anh chàng cấp cao, được thuê và trả tiền để đưa ra những quyết định đó. Khi ngày đó đến, hãy đến đó! Cho đến ngày hôm đó, nhận ra vị trí của bạn là gì. Tôi có một ông chủ, theo như tôi quan tâm thì toàn bộ công việc của tôi là làm cho ông chủ của tôi hạnh phúc. Đó không phải là quyết định đoán thứ hai được đưa ra ngoài mức lương của tôi. Nếu bạn thực sự không chắc chắn, hãy nói chuyện với sếp / người giám sát của bạn và tìm hiểu.

Tuy nhiên, nói chung, tốt hơn hết là để mọi người trên tàu có cách tiếp cận lỗi thời hơn một nửa nhóm theo cách tiếp cận lỗi thời, 1/4 của nhóm theo một cách tiếp cận mới và 1/4 của nhóm đang cố gắng phát triển một cách tiên tiến , cách tiếp cận hoàn toàn mới.

Có một dòng chảy ngầm cho tất cả những thứ mà tôi nghĩ nên được đưa ra rõ ràng: đừng mang tính chiến đấu . Giữ gìn mối quan hệ của bạn với anh ấy. Thật tuyệt khi nghe lời khuyên của anh ấy với một hạt muối và xác nhận nó trong sách và trên các trang web như thế này, nhưng đừng tấn công anh ấy. Nếu anh ấy là một nhà phát triển cao cấp và đã trải qua rất nhiều dự án, anh ấy không phải là một thằng ngốc và có rất nhiều điều để học hỏi từ anh ấy. Vì có vẻ như bạn đã hoàn thành, bày tỏ mong muốn hiểu quan điểm của anh ấy. Ngay cả khi bạn chắc chắn rằng mình sai và bạn đúng, hãy chấp nhận khả năng ngược lại (có vẻ như bạn đã hiểu điều này). Cố gắng làm rõ rằng bạn đang tranh luận vì bạn muốn hiểu rõ hơn quan điểm của anh ấy chứ không phải vì bạn đang cố chứng minh anh ấy sai.

Nếu anh ấy không quay lại với bạn ngay lập tức khi bạn hỏi anh ấy một câu hỏi, hoặc nếu câu trả lời của anh ấy mơ hồ và / hoặc không có ích, đừng cho rằng anh ấy thổi bay bạn. Như đã được đề cập ở đây, anh ấy có thể bận rộn và / hoặc căng thẳng.

Thật tuyệt khi kiên nhẫn. Giữ một danh sách những điều trong đầu mà bạn nghĩ nên được thực hiện khác đi, và trình bày chúng vào thời điểm thích hợp. Hãy chắc chắn rằng bạn có lời biện minh cho lời đề nghị bên cạnh "đó là cách thực hành tốt nhất". Và hãy cẩn thận để làm những điều đúng đắn và không phạm sai lầm, để bạn có uy tín khi bạn đưa ra lập luận của mình sau này.

Cho đến nay tôi đã cố gắng tránh vấn đề bằng cách lắng nghe anh ấy, nêu quan điểm, anh ấy lại nêu lên quan điểm ban đầu của mình (hầu hết thời gian anh ấy sẽ nói cách thực hành tốt nhất, dễ bảo trì hơn nhưng chỉ không đi xa hơn), tôi. .. nghĩ về nó ở nhà, nhưng ... tôi vẫn không bị thuyết phục. Nhưng gần đây anh ấy ... đã thấy mã của tôi và hỏi tôi tại sao tôi không đổi nó thành gợi ý của anh ấy. Đây là lần thứ 3 trong 2--3 tuần.

(Chỉnh sửa một chút cho các hành động.)

Phần này liên quan đến tôi. Một cách bạn có thể thấy nếu bạn đúng hay không là hiểu những gì anh ấy đang nói. Những gì tôi đọc (với lịch sử của riêng tôi, những người khác có thể khác) là một nhà phát triển cơ sở không hiểu những gì người cố vấn đang nói, và không yêu cầu làm rõ. Một cách bạn có thể tìm ra là yêu cầu anh ta làm rõ: làm thế nào đây là một thực hành tốt hơn thế? Hoặc tại sao điều này có thể duy trì nhiều hơn so với mã của chúng tôi? Nếu bạn không biết câu trả lời của anh ấy cho vấn đề này, bạn thực sự không biết liệu anh ấy có đưa ra lời khuyên tốt hay không.

Điều thực sự làm tôi lo lắng là anh ấy đã yêu cầu bạn thay đổi nó nhiều lần và bạn thì không. Đây là một cách nó có thể nhìn từ phía anh ấy: anh ấy yêu cầu bạn thực hiện thay đổi, bạn hỏi tại sao, anh ấy đưa ra lý do (hợp lệ, theo suy nghĩ của anh ấy) và bạn từ chối thực hiện thay đổi. Bạn không yêu cầu làm rõ, vì vậy anh ta cho rằng bạn hiểu lý do và quá lười biếng hoặc quá cứng đầu để thay đổi nó - không phải là một điều tốt cho nhà phát triển cấp cao nghĩ về bạn. Tin tôi đi, tốt hơn hết là đặt câu hỏi hơn là để có được danh tiếng theo cách này.

Một vài suy nghĩ:

1 / Nó có hoạt động không? Cách của anh ấy có làm việc hay không? Là bất kỳ lý do khách quan tại sao cách của mình sẽ kém hơn?

Theo lý do khách quan, ý tôi là thứ gì đó có thể đo lường được mà không có sự mơ hồ (hiệu suất, lỗi, độ dài mã ...) Nếu các giải pháp của anh ấy hoạt động và không có thước đo khách quan nào cho thấy đó là một giải pháp kém, hãy làm theo cách của anh ấy. Cách của anh ấy tốt hơn ... bởi vì nó có thể phù hợp hơn với phần còn lại của codebase và bởi vì anh ấy sẽ dễ dàng sử dụng / tái sử dụng công việc của bạn hơn. Bạn có thể không thích nó, nhưng đó không phải là những gì nó là về, phải không?

Nếu nó không hoạt động hoặc hoạt động kém trên các số liệu quan trọng, hãy triển khai nó, so sánh giải pháp của anh ấy với giải pháp của bạn, sau đó nói với anh ấy rằng bạn đã thử theo cách của anh ấy, nhưng bạn không thể làm cho nó hoạt động tốt (đưa ra số liệu) và hỏi anh ấy nếu bạn mắc lỗi trong quá trình thực hiện hoặc nếu có yêu cầu mà bạn không biết

2 / Lập trình viên ngôi sao nói ... Tại sao lại cho một thứ chết tiệt? Bạn sẽ tìm thấy các lập trình viên nổi tiếng mâu thuẫn với nhau về nhiều chủ đề cơ bản như lập kế hoạch, thiết kế, OOP so với thủ tục, kiểm tra đơn vị, xử lý ngoại lệ, kiểm soát nguồn, bật và tắt.

Nếu sự khác biệt duy nhất về khả năng làm việc giữa 2 giải pháp là ai thích nó, hãy bỏ qua nó. Bạn có thể được hưởng lợi từ việc tập luyện tinh thần cần thiết bằng cách làm việc trong một mô hình mà bạn không thích

Dựa trên ý tưởng rằng bạn chỉ nên nhận lời khuyên từ những người bạn muốn trở thành người thích, câu trả lời là lời khuyên cao cấp là tốt nếu bạn muốn trở thành như anh ấy / cô ấy.

Hầu hết các vấn đề của tôi, tôi đã sắp xếp bằng cách đăng lên các diễn đàn và nhận được phản hồi từ những người khác, và tôi đã sống sót được khoảng 1 năm như thế này.

Tôi nên làm gì trong tình huống như vậy?

Thành thật mà nói, đây là những gì rất nhiều công việc kỹ thuật là như thế. Bạn cần phải là người tự khởi nghiệp, người có thể tự mình giải quyết các vấn đề khó khăn (với sự trợ giúp nếu internet và đó là người từ chối) nếu bạn phải làm.

Từ quan điểm nhận đánh giá mã và nhận trợ giúp về thiết kế kiến ​​trúc, ngay cả khi tôi có người quản lý giỏi, tôi chưa bao giờ có nhiều đánh giá mã ngoài "biến tĩnh nên được đặt trước tiền tố s_".

Tận dụng cơ hội để học và học cách học; đó sẽ là những kỹ năng mà bạn có thể sử dụng trong tương lai.

Nếu bạn nghĩ trong một giây rằng quản lý không hiểu khả năng của bạn THỰC SỰ như thế nào để hoàn thành công việc, thì có lẽ bạn đã sai. Quản lý có lẽ cũng hiểu rằng sự dẫn dắt của bạn ngay bây giờ sẽ hoàn toàn vô dụng nếu anh ta thay thế bạn và tiếp quản công việc của bạn.

Những lý do THỰC SỰ họ không định vị bạn là vì mặc dù tất cả những thách thức của bạn mà bạn đưa ra cho họ, bạn vẫn là người tốt nhất cho công việc. Họ rõ ràng coi trọng công việc của bạn quá nhiều để mạo hiểm giao nó cho bất kỳ ai khác.

Đừng đánh giá thấp trí thông minh của quản lý ...

Họ thông minh hơn rất nhiều so với hầu hết các nhà phát triển cho họ tín dụng. Tôi đã không hiểu điều này cho đến khi tôi bắt đầu quản lý. Họ có thể cũng nhận thức được sự dẫn dắt của bạn thực sự vô dụng như thế nào nhưng có lẽ họ bất lực trong việc giải quyết vấn đề đó.

Hãy để tôi vẽ một bức tranh cho bạn, Dẫn A với 5 năm kinh nghiệm tại công ty là không đủ năng lực. Người quản lý biết điều này, đề nghị với người quản lý cấp trên của mình sa thải Trưởng nhóm A. Người quản lý cấp trên hỏi tại sao anh ta không bị xử lý nhiều năm trước nếu anh ta không đủ năng lực. Người quản lý bây giờ trông rất tệ, đặc biệt là khi Trưởng A có một mức lương cồng kềnh được trả mà không có lợi ích gì ...

Đây là một kịch bản tiềm năng khác, Trưởng A là bạn thân với ai đó quan trọng. Anh ấy quá nóng về chính trị để đảm nhận,

Dù bằng cách nào, với một sai lầm kéo dài như vậy, các tổ chức lớn sẽ dễ dàng quét sạch những người bất tài dưới tấm thảm, cho họ công việc bận rộn và sức mạnh giả phù hợp với "kinh nghiệm" trong nhiều năm mà họ không thể gây thiệt hại NHIỀU . Thật không may, nhiều tổ chức thà làm điều này sau đó thực sự giải quyết các vấn đề.

Tất nhiên lý do cho điều này là vì người quản lý trong loại tổ chức này luôn có lợi trong ngắn hạn để đối phó với tài năng xấu theo cách này hơn là giải quyết các vấn đề dài hạn mà những loại người này có thể mang lại cho tổ chức.

Vì vậy, trong khi nó thiển cận và có khả năng phi đạo đức, bạn phải thừa nhận rằng nó thông minh hơn một chút so với nhiều nhà phát triển thực sự cung cấp tín dụng.

ughh ahhh. Câu hỏi này làm tôi nhớ nhiều thứ. Đầu tiên tôi sẽ nói rằng tôi không thể hòa hợp với một trong những người quản lý tại nơi làm việc cuối cùng của tôi. Đó không phải là một vấn đề cá tính. Đó là một vấn đề truyền thông. Tôi đã nói XYZ và người quản lý cụ thể đó sẽ làm gián đoạn những gì tôi đang nói là ABC. Tôi sẽ không thể giao tiếp tốt trừ khi tôi làm việc với người quản lý đó hơn một năm.

Cuối tuần vừa qua. Một anh chàng tranh luận / không đồng ý với tôi về singletons. Tôi nói rằng chúng không tốt và KHÔNG BAO GIỜ được sử dụng và hoàn toàn không có lý do để sử dụng chúng. Tôi đã liên kết anh ấy với http://www.gmannickg.com/?p=24 và bài viết chuyên sâu hơn nó liên kết đếnVài ngày sau cuộc cãi vã. Ngày một lập trình viên khác (DudeB) đề cập đến việc anh ta chỉ sử dụng singletons khi thích hợp (mà tôi đã thêm vào với 'không bao giờ'). DudeB đã không nói bất cứ điều gì về điều đó nhưng DudeB đã nói rằng DudeB đang ở trong một dự án có sự tranh chấp về bộ nhớ vì tất cả các luồng đều truy cập vào singleton. Sau khi đề cập đến điều này, hiển thị bài báo và đề cập đến sự tranh cãi về trí nhớ mà anh chàng tôi đã tranh luận nói rằng chúng tôi sẽ phải đồng ý không đồng ý vì tôi không thích nói về singletons (nhưng tôi đang viết bài này)

Vấn đề là. Đôi khi bạn có thể chết sai như anh chàng này (có thể ai đó sẽ không đồng ý về những người độc thân với tôi trong một bình luận). Trong tình huống của tôi với người quản lý là lập trình viên cao cấp của tôi, tôi chỉ làm những gì tôi được yêu cầu rõ ràng và tôi đã không coi trọng chất lượng tại nơi làm việc đó một lần nữa. Tôi đã làm những gì tôi thích làm khi được phép nhưng luôn làm những gì tôi được yêu cầu nhưng nếu tôi không đồng ý tôi sẽ đưa nó lên ít nhất một lần.

Tôi có một ý kiến ​​hoàn toàn khác / gây tranh cãi về điều này.

Thông thường, mọi người thường theo dõi mục tiêu cuối cùng, đối với hầu hết các ngành, đó là về tối đa hóa lợi nhuận và giảm thiểu tổn thất. Tôi biết điều này nghe có vẻ vô tâm (do đó là những điểm tiêu cực) nhưng kinh nghiệm và sự khó hiểu rất ít nếu bạn không tạo ra kết quả.

Mọi người có thể bị cuốn vào những điều cực kỳ gián tiếp để ngụy biện về điều đó có rất ít ảnh hưởng đến kết quả trực tiếp của công ty.

Nếu bạn nghĩ rằng bạn đúng về điều gì đó thì cách tốt nhất của bạn là chỉ ra cách điều đó sẽ tạo ra kết quả có thể đo lường tốt hơn .

Ban đầu tôi sẽ cố gắng và thực hiện nó, vào cuối ngày kháng chiến với cấp cao có khả năng là vô ích ít nhất cho đến khi bạn có thêm một số kinh nghiệm và sự tôn trọng. Sử dụng điều này như một kinh nghiệm học tập và trong hơn 2 năm nữa nếu bạn vẫn cảm thấy như vậy - chuyển sang một công ty khác. Đó là khi bạn có thể sử dụng kết hợp các ý tưởng tốt của bạn và người cao niên để gây ấn tượng với chủ nhân mới của bạn. Tất nhiên bạn có thể bắt đầu nhận ra một số lý do cho những gì bạn cho là quyết định tồi tệ trước đó trong sự nghiệp và đến một lúc nào đó bạn có thể có một nhà phát triển cơ sở làm việc cho bạn.

[Repost: bởi vì tôi bằng cách nào đó đã tạo một tài khoản thứ hai ở đây]

Nhưng gần đây, anh ấy lại tiếp cận tôi một lần nữa, thấy mã của tôi và hỏi tôi tại sao tôi không đổi nó thành gợi ý của anh ấy .

Bạn nên rõ ràng về việc đây là những gợi ý hoặc đơn đặt hàng / hướng dẫn / chỉ thị / bất cứ điều gì.

Gợi ý = Tôi nghĩ sẽ tốt hơn nếu làm theo cách này; nhưng đó là sự lựa chọn của bạn.

Đặt hàng / vv = Tôi muốn nó được thực hiện theo cách này; và đó là lựa chọn của tôi.

Nếu đó thực sự là một gợi ý, hãy làm như bạn muốn và để mã của bạn đứng. Nếu đó là một mệnh lệnh (và người cố vấn này có thẩm quyền đối với bạn theo cách này) - hãy làm như họ nói.