Đồng nghiệp của tôi là một chàng trai tốt, nhưng hiệu suất của anh ấy là ngang bằng. Tôi có nói với sếp không? [đóng cửa]


24

Tôi đã được đặt vào một dự án khoảng ba tháng trước, cho đến lúc đó đang được phát triển bởi một nhà phát triển mới được thuê bởi vì nó bị tụt lại phía sau. Công bằng mà nói, dự án là một giao diện cho một thiết bị y tế có nhiều sự tinh tế và tương đối phức tạp, vì vậy việc đặt một người vào dự án không có kinh nghiệm tại công ty có lẽ là một quyết định tồi từ góc độ quản lý.

Dù sao, một khi tôi bắt đầu làm việc với nó, tôi nhận ra rằng ... tốt, nó hoàn toàn không hoạt động. Giao diện người dùng trông đẹp, nhưng thực tế nó không làm được gì nhiều, và những gì nó đã làm là làm sai. Một lần nữa, công bằng mà nói, phần lớn điều này là do thực tế là nhà phát triển này đã không chuẩn bị đúng cách để viết giao diện cho thiết bị của chúng tôi. Tuy nhiên, tôi cũng nhanh chóng nhận ra rằng mã được đặt đúng chỗ rất dễ vỡ và cực kỳ khó bảo trì.

Bây giờ tôi không tự nhận mình là lập trình viên giỏi nhất thế giới. Tôi làm việc với rất nhiều người rất thông minh, những người phát triển tốt hơn tôi. Tuy nhiên, tôi rất cố gắng để viết mã đơn giản như nó có thể và mạnh mẽ. Tôi kiểm tra checkin của tôi. Nếu tôi thấy rằng mã của tôi đang trở nên lộn xộn và khó có thể làm việc sớm, tôi sẽ thay đổi nó. Tôi đã có một vài cuộc nói chuyện với đồng nghiệp của mình trong nỗ lực giúp anh ta viết mã tốt hơn. Điều này hơi khó vì a) anh ta có hơn 20 năm kinh nghiệm trong lĩnh vực này và tôi chỉ có 5, và b) anh ta được thuê như một "chuyên gia UX" và những người khác xem anh ta như một cá nhân có kinh nghiệm.

Điều đó nói rằng, tôi chỉ không nhìn thấy nó. Anh ấy là một chàng trai rất tốt và anh ấy rất hợp lý, nhưng hết lần này đến lần khác anh ấy kiểm tra mã rất mong manh, chỉ hoạt động trong trường hợp lạc quan nhất, và 9 trong số 10 lần tôi kết thúc việc sửa lỗi trong công việc của anh ấy. Mã của anh ta có vẻ nghiệp dư và rõ ràng anh ta không có mức độ kinh nghiệm mà anh ta tuyên bố là có khi anh ta được thuê. Đã đến lúc tôi dành thêm giờ để tái cấu trúc mã của anh ấy và sửa lỗi của anh ấy đã gây tổn hại cho tôi. Cách tôi nhìn thấy tôi có hai lựa chọn:

  1. Không làm gì cả, hãy chổng mông lên để đảm bảo sản phẩm này ra mắt đúng giờ và mạnh mẽ và chờ đợi anh ấy thất bại trong tương lai (tôi sẽ không làm việc với anh ấy trong dự án này sau khi phát hành lần đầu.)
  2. Nói với sếp của tôi về hiệu suất của anh ấy. Sếp của tôi là một người đàn ông hợp lý, nhưng tôi chỉ cảm thấy lúng túng khi thực hiện phương pháp này. Tôi không thích 'bash' (vì không có thuật ngữ tốt hơn) đồng nghiệp của tôi và tôi không biết anh ấy sẽ nhận nó như thế nào.

Vì vậy, đó là về nó. Tôi đã cố gắng giải quyết vấn đề này với đồng nghiệp bằng cách giải thích lý do tại sao việc triển khai của anh ta không hiệu quả hoặc làm thế nào mã của anh ta có thể được duy trì nhiều hơn, nhưng anh ta vẫn tiếp tục mắc lỗi tương tự. Tôi rất thích nghe người khác xử lý các tình huống tương tự như thế nào, đặc biệt là những người trong ban quản lý. Cảm ơn trước cho bất kỳ lời khuyên bạn có thể cung cấp cho tôi.


3
Sẽ không dễ dàng hơn nhiều nếu anh ta không phải là một chàng trai tốt? Nó thực sự rất hấp dẫn trong tình huống của bạn ... Đừng có lời khuyên thực sự nào, tôi đã thấy mình trong một tình huống tương tự nhưng anh ấy không có ý nghĩa gì của từ "tốt đẹp". Vì vậy, những gì cần làm là vô cùng rõ ràng và ngay lập tức được hỗ trợ bởi ban quản lý, như thể họ chỉ tìm kiếm một cái cớ. Nhưng một người mà bạn thực sự thích, đó là khó khăn. Chúc may mắn.
yannis

1
@Yannis Rizos: vâng, vâng chắc chắn là như vậy. Tôi thích anh chàng này, và tôi ghét đóng góp cho anh ta có thể mất việc, nhưng anh ta dường như không bị cắt đứt vì những kỳ vọng đặt ra cho một nhà phát triển trong một công ty nhỏ làm rất nhiều. Tôi chỉ có 5 năm kinh nghiệm và tôi chưa bao giờ được giao nhiệm vụ cấp "thiếu niên" ở đây. Tôi đã viết giao diện phần cứng từ ngày đầu tiên và nó thật tuyệt.
LostInCode

UX là gì? .....

@ Thorbjørn Ravn Andersen: UX thường có nghĩa là Người dùng hiệu quả
Matt Ellen

Câu trả lời:


24

Ít nhất tôi sẽ xem xét khả năng rằng nếu anh ta được thuê như một anh chàng UX, thì có lẽ không ai thực sự mong đợi mã thực sự tuyệt vời từ anh ta - họ có thể hy vọng rằng mã của anh ta về cơ bản chỉ là một nguyên mẫu phác thảo UX, và tùy thuộc vào các lập trình viên khác để viết mã sản xuất dựa trên điều đó.

Bây giờ, tôi chắc chắn không nói đó trường hợp, nhưng nó sẽ không gây ngạc nhiên cho tôi. Ít nhất theo kinh nghiệm của tôi, người UX không hiếm khi chủ yếu sản xuất những thứ như nguyên mẫu và bảng phân cảnh. Nếu bất cứ điều gì, nếu anh chàng thực sự được thuê làm chuyên gia UX, tôi sẽ bị sốc về khái niệm kiểm tra mã của anh ta. Tôi khá chắc chắn rằng tôi chưa bao giờ thấy điều đó được thực hiện.

Nếu anh chàng thực sự là một chuyên gia về UX, cách chữa trị có thể không phải là cố gắng khiến anh ta tạo ra mã tốt hơn, mà là đưa anh ta ra khỏi mã hóa (ít nhất là bất cứ thứ gì ngoại trừ nguyên mẫu). Nếu anh ta thực sự giỏi về thiết kế UX, thì sai lầm thực sự có lẽ là ngay cả khi yêu cầu anh ta viết mã sản xuất. Thay vào đó, anh ta có lẽ nên (nhiều nhất) làm việc trong một hộp cát tạo mẫu UX nơi kết quả của anh ta được sử dụng để hướng dẫn vòng mã tiếp theo được tạo ra, nhưng không bao giờ được kiểm tra dưới dạng mã sản xuất.


Tôi nghĩ về điều này một chút và nó làm tôi tự hỏi. Tôi đã không tham gia vào quá trình tuyển dụng, và anh ấy chắc chắn sẽ được mã hóa, nhưng có lẽ là một anh chàng UX, anh ấy đã không có nhiều kinh nghiệm trong tất cả các chương trình. Điều đó nói rằng, hơi khó tin khi anh ta đã phát triển phần mềm trong hơn 20 năm và không có nhiều "UX" đang diễn ra trong thập niên 80.
LostInCode

Không, nhưng nếu anh ta thực hiện ít mã hóa trong 10 năm, anh ta có thể khá yếu đuối (đặc biệt là nếu anh ta thậm chí còn hơi yếu trong việc viết mã). OTOH, khi bạn làm việc hơn 90 tuần, bạn chắc chắn có lý do chính đáng để nói chuyện với sếp của mình, mặc dù tôi nghĩ rằng tôi tập trung nhiều hơn vào việc khắc phục vấn đề đó hơn là điểm yếu của đồng nghiệp này.
Jerry Coffin

18

Tôi cố gắng có một quy tắc rằng tôi luôn thông báo cho sếp về những điều ảnh hưởng đến dự án. Tích cực và tiêu cực ... và trong những trường hợp như thế này, tôi cố gắng đổ lỗi cho những thứ như trái ngược với người đã viết nó. Nghe có vẻ ít giống như bạn đang đánh đập đồng nghiệp và giống như bạn đang cố gắng cải thiện chất lượng sản phẩm.

Từ quan điểm quản lý, có 3 cách phổ biến để đối phó với nhân viên trong tình huống này:

  1. Kiểm soát điểm yếu của họ
  2. Chơi theo sở trường của họ
  3. Loại bỏ chúng (không thực sự là lựa chọn của bạn)

Kiểm soát điểm yếu của họ bằng cách tìm kiếm sự giúp đỡ từ bên ngoài.

Này ông chủ, tôi hơi lo lắng về tình trạng của mã ... nó khá dễ vỡ và phá vỡ rất nhiều. Sẽ mất một số công việc để đưa nó vào trạng thái mà tôi cảm thấy rằng nó có thể được tin cậy. Có khả năng tôi có thể mượn một trong những kiến ​​trúc sư trong một hoặc hai ngày để xem liệu chúng tôi có thể đưa ra một thiết kế tốt không?

Bạn không yêu cầu người khác tham gia dự án, bạn đang yêu cầu thêm 'đầu vào chuyên gia' trong một khoảng thời gian ngắn. Tạo bất cứ tài liệu nào họ cần, sơ đồ UML và đoạn mã nếu đó là những gì kiến ​​trúc sư muốn. Họ sẽ thấy mã ở trạng thái nào và sau đó sếp của bạn sẽ có người khác lặp lại ý kiến ​​của bạn.

Từ cuộc họp, hy vọng bạn sẽ có được một thiết kế tốt hơn mà cả bạn và nhà phát triển khác có thể làm theo mà không cần anh ấy làm hỏng nó. Đây là những gì thiết kế và thông số kỹ thuật cho rất nhiều trường hợp: giảm thiệt hại mà các nhà phát triển xấu có thể làm.

Chơi theo sở trường của họ

Chào ông chủ, tôi đang làm việc với mã cho dự án x, và nó thật tuyệt vời. Mã, mặt khác, có thể sử dụng một chút công việc. Tôi nghĩ rằng dự án sẽ tốt hơn nếu [anh chàng ux] có thể tập trung nhiều hơn vào UX, trong khi tôi thực hiện một số tái cấu trúc để đưa nó vào trạng thái ổn định hơn. Khi UX đã ổn định, dự án b có thể sử dụng cảm ứng Midas của anh ấy.

Ở đây, ông chủ của bạn có thể sẽ nhìn thấy ngay qua nó; rằng bạn đang nói với anh ấy rằng các nhà phát triển khác không tốt lắm ... nhưng ít nhất bạn không phải là một kẻ khốn nạn về điều đó. Và nếu anh ta thực sự giỏi trong công việc UX, thì anh ta có thể tìm thấy một vị trí ổn định nhảy vào từng dự án và làm cho chúng tuyệt vời từ quan điểm khả năng sử dụng. Tôi tưởng tượng rằng anh ấy cũng thích nó theo cách đó.


+1 Đối với thông số kỹ thuật và sơ đồ công nghệ giảm thiệt hại mà các nhà phát triển xấu có thể gây ra. Nó đúng như thế nào.
maple_shaft

+1 để tập trung vào mã xấu thay vì chơi trò chơi đổ lỗi. Xung đột quốc tế luôn có tác động tiêu cực đến lịch trình và chất lượng mã nói chung.
TMN

9

Ngừng liên tục sửa chữa lỗi lầm của mình. Anh ấy sẽ không học; Tôi biết tôi sẽ không.

Lập trình phần lớn là một nhiệm vụ hợp lý, nhưng nó cũng liên quan đến hồi ức bộ nhớ. Khi bạn thường viết mã chung, bạn nhớ lại cách bạn đã triển khai giải pháp lần trước , thay vì tìm lại tất cả. Nếu anh ta không bao giờ thực hiện mã chính xác, tôi có thể thấy lý do tại sao anh ta cứ lặp lại sai lầm tương tự.

Chỉ cho anh ta những gì anh ta đã làm sai, và có lẽ sửa nó lần đầu tiên. Đối với bất kỳ sự cố nào khác xảy ra với cùng một sự cố, hãy yêu cầu anh ấy thực hiện bản sửa lỗi mà bạn chỉ cho anh ấy.


5

Tôi thực sự cẩn thận vì một vài lý do:

  1. Làm thế nào bạn chắc chắn bạn sẽ không làm việc với anh ta sau khi phát hành ban đầu? Quản lý của bạn có thể nghĩ, "Thật là một đội, hãy nhìn cách họ giao sự tuyệt vời này cùng nhau!" và muốn giữ bạn lại với nhau.

  2. Nếu bạn đến gặp sếp, bạn muốn làm thế nào để giải thích vị trí của mình? Bạn có bao nhiêu tài liệu về hiệu suất kém của đồng nghiệp?

Đó sẽ là những vấn đề tôi muốn ghi chú từ những gì bạn hỏi. Tôi đề nghị bạn hỏi anh ta về mã và xem liệu anh ta có một số biện minh cho lý do tại sao nó là như vậy. Có lẽ anh ta đang chạy trong vòng tròn trong khi mã hóa nó gây ra một số vấn đề. Vòng tròn là nơi bạn mã hóa một cái gì đó sau đó thông qua một loạt các thay đổi kết thúc tại gần như chính xác điểm mà bạn đã bắt đầu khi danh sách thay đổi của ai đó hủy bỏ cuối cùng. Tôi đã ở trong những tình huống mà nó đang thay đổi và hoàn tác thay đổi sau khi thay đổi trở nên mệt mỏi khá nhanh.


Vâng, tôi đã có suy nghĩ tương tự. Tôi thực sự sợ số 1 nếu tôi không nói gì với sếp của mình vì thật lòng tôi không phải là người hâm mộ của hơn 90 tuần mà tôi đã tham gia để làm cho điều này trở nên đúng đắn. Tôi sẽ không gặp vấn đề gì khi chỉ cho sếp biết ý của tôi và anh ấy sẽ nhận ra vấn đề, nhưng ... tôi chỉ không biết mình sẽ ra sao nếu tôi làm thế. Tôi đã cố gắng làm việc này với đồng nghiệp của mình một cách lịch sự, hữu ích, nhưng anh ta cứ phạm phải những sai lầm tương tự. Cảm ơn các đầu vào.
LostInCode

5

Hậu quả là gì nếu bạn không làm lại tất cả công việc của anh ấy và chỉ để dự án thất bại? Hậu quả đối với bạn, ý tôi là.

Chắc chắn ai đó ở cấp độ kinh nghiệm và vị trí của anh ta đã không đến đó một cách tình cờ nên công việc của anh ta không tệ như bạn nhận thấy hoặc toàn bộ sự nghiệp của anh ta bao gồm những người như bạn mang anh ta theo.

Nếu bạn đang làm việc hơn 50 giờ một tuần cho bất kỳ dự án nào thì đó là một cái gì đó sai nghiêm trọng và bạn tự làm phiền mình bằng cách không gọi nó đến sự chú ý của Thủ tướng hoặc bằng cách rời đi. Tôi là một người ủng hộ mạnh mẽ để làm việc THÔNG MINH chứ không phải CỨNG.

Làm việc thông minh 50 và nếu dự án không thành công thì NÓ KHÔNG PHẢI LÀ CỦA BẠN. Nếu nó thất bại vì sự bất tài của anh ấy và họ đổ lỗi cho bạn thì đó có lẽ không phải là môi trường mà bạn muốn làm việc.

Vì vậy, nhiều người bạn của tôi đã làm việc trên 40 / tuần thông thường trong một dự án bị quản lý bởi vì họ sợ thất bại khi họ không nhận ra sự thất bại nhỏ như thế nào HOẶC thành công ảnh hưởng trực tiếp đến toàn bộ sự nghiệp của bạn.

Hơn 80% dự án thất bại, không có sự xấu hổ trong đó.


+1 cho cách tiếp cận đáng yêu và cho 69% số chỉ số được phát minh
cregox

@Cawas, LOL, tôi đoán theo thống kê đó nhưng từ bộ nhớ. Tôi đã đọc được ở đâu đó rằng gần 80% dự án được coi là thất bại ở chỗ họ 1) Ran vượt quá 2) Đã giao hoặc 3) Bỏ lỡ thời hạn và kết thúc muộn.
maple_shaft

Tôi đã thấy các nhà phát triển với 20 năm kinh nghiệm không thể viết mã được. Và đừng làm việc thông minh 50 giờ một tuần trừ khi bạn có một số vốn chủ sở hữu nghiêm túc hoặc được trả lương cao trên thị trường. Làm việc một cách thông minh 40 và nếu nó không đủ để họ bắt đầu tìm kiếm việc làm.
kevin cline

4

Nó được gọi là một đánh giá ngang hàng. Người quản lý của bạn mong đợi điều đó từ bạn và phải được thông báo thời gian dành cho nhà phát triển có giá trị của anh ấy. Tôi ngạc nhiên khi anh ta không biết về điều này rồi - nhưng một lần nữa, tôi lại thấy tồi tệ hơn.

Đừng nói chuyện với anh ta về mặt anh chàng kia, hãy nói chuyện với anh ta về công việc hàng ngày bạn làm. Nếu điều đó có nghĩa là giải mã mã của anh ta, vì vậy hãy là nó. Đi vũ trang với các liên kết checkin, vv để đưa ra một số bằng chứng về công việc hàng ngày của bạn. Người quản lý của bạn có thể muốn chính xác điều này từ bạn btw - anh ấy mang UX 20 năm vào và bạn có được mã mạnh mẽ. Thay vì làm khung dây, anh ta chỉ viết mã cấp nguyên mẫu. Nói chuyện với người quản lý của bạn.

Và hy vọng bạn không được thuê làm người trông trẻ của anh ấy. Chúc may mắn.


3

Dự án sẽ khởi động sớm hơn nếu bạn không phải viết lại / làm lại công việc của mình? Nó sẽ giúp đến trong ngân sách? Bạn không cần phải bash, để riêng tư nêu lên mối quan tâm của bạn. Đây là nơi mà hầu hết mọi người mắc lỗi, họ phàn nàn mà không đưa ra giải pháp.

Có những khuyến nghị cụ thể mà bạn có thể cung cấp cho sếp của bạn sẽ cải thiện kết quả. Tài liệu tốt hơn? Kiểm tra người dùng mạnh mẽ? Mục tiêu của bạn là làm cho công ty, dự án, đồng nghiệp và bản thân thành công. Giả vờ rằng không có vấn đề gì đảm bảo thất bại cho cả ba trong số bốn --- và bạn không phải là người may mắn.


1

Bạn cần phải đi đến sếp của bạn càng sớm càng tốt và nói thẳng với anh ấy những gì bạn nói ở đây.

Trước hết, đây là một thiết bị y tế. Ai đó có thể bị thương hoặc chết nếu có lỗi? Mã mà cuộc sống hoặc sức khỏe của người dân phụ thuộc vào nhu cầu phải mạnh mẽ nhất có thể, không phải là lỗi rác được viết bởi một người lạc quan cho trường hợp tốt nhất.

Được rồi, đội mũ quản lý cũ của tôi lên ... bạn không biết liệu sếp của bạn có biết về điều này không, hoặc phản ứng của anh ấy sẽ là gì nếu đó là tin tức với anh ấy. Nhưng nếu anh ta không biết, anh ta cần phải, và bạn không nên đoán anh ta bằng cách giấu thông tin này. Nếu anh ấy ổn với đồng nghiệp của bạn mã hóa theo cách này, anh ấy sẽ cho bạn biết.

Tôi đã gặp phải một tình huống như thế này nhiều năm trước. Một "bậc thầy mạng" và tôi đang nghiên cứu một bằng chứng về khái niệm là nhà thầu. Trên thực tế, anh ta hầu như không làm được gì, và chủ yếu là ngớ ngẩn. Một ngày nọ, ông chủ của chúng tôi nói với chúng tôi rằng chúng tôi có một bản demo sắp ra mắt. Chẳng mấy chốc, "bậc thầy mạng" bắt đầu nhận được rất nhiều cuộc điện thoại im lặng, và cuối cùng anh ấy nói với tôi rằng anh ấy sẽ rời đi trước bản demo để thực hiện một hợp đồng biểu diễn khác. Ngay khi tôi có thể có được ông chủ của chúng tôi một mình, tôi đã nói với anh ta về điều đó. Anh ta bỏ rơi "bậc thầy mạng" và mang đến một người mà tôi giới thiệu, người đã tìm ra nhiều mã hơn trong ba ngày mà "đạo sư" đã làm trong ba tháng. Bản demo là một hit thành công - nhưng nếu tôi giữ im lặng, dự án sẽ hoàn toàn thất bại.


1
Tôi cũng sẽ đề nghị tác giả nói với người quản lý của mình về những gì họ đang dành thời gian cho nó.
Ramhound

0

Vâng, hãy nói với sếp của bạn. Sau đó, bạn sẽ thấy nếu đó không phải là bạn ở ngoài đó. Đó là công việc của người quản lý để biết nhóm làm việc ra sao và nếu ông chủ chưa nhận thấy thì có lẽ họ không quan tâm nhiều như bạn làm cho việc viết mã đúng - như nhiều nơi, nhiều nơi tôi đã từng đến.

Và trong số tất cả những nơi làm việc khác nhau, nếu tôi có một số bạn bè đầy đủ (nghĩa là 5) trong số họ thì đó đã là một con số lớn. Tất cả họ đều có những anh chàng và cô gái tốt bụng nhưng bạn sẽ không mất đi tình bạn khi làm công việc của mình - nếu bạn mất họ thì đó là một điều tốt. Trong trường hợp của bạn, anh ấy sẽ định giá công việc nhiều hơn bạn.

Cấp, đó không phải là một nỗ lực để khiến anh ta bị sa thải. Nó chỉ thể hiện sự quan tâm của bạn đối với sức khỏe của dự án, đó là lý do tại sao tất cả các bạn đều (hoặc nên) ở đó.

Rốt cuộc, bạn đã cố gắng nói chuyện với anh ấy, và nếu bạn không làm gì thì bạn thực sự mạo hiểm với công việc của mình ở đó.


2
Tôi đã không đề cập đến việc tôi đã cố gắng, nhiều lần bây giờ, để giải thích tại sao mã của anh ta không hoạt động hoặc làm thế nào nó có thể tốt hơn. Anh ấy cứ lặp đi lặp lại những sai lầm tương tự.
LostInCode

Tôi đã có cùng một vấn đề với một thành viên khác trong nhóm, mặc dù may mắn thay, đó là một dự án lớp "nhỏ". Trong khi bạn làm việc với mã, hãy cố gắng dạy anh ấy bằng cách cho anh ấy cặp chương trình với bạn. Điều này hy vọng sẽ cho anh ấy thấy một số sai lầm của anh ấy thay vì bạn nói điều này là sai. Ngoài ra anh ta có thể thấy một người nào đó từ công ty làm việc.
Jonathan

Hãy cẩn thận về việc dường như quá quan tâm đến dự án. Nhiều nơi bị quản lý cố thủ và nhiều lần họ quan tâm nhiều hơn đến sự trung thành của bạn với bản thân đối với dự án. Bản thân họ có thể không xem dự án quan trọng như bạn làm, đó có thể là lý do tại sao họ không bao giờ bận tâm đến việc giải quyết hiệu suất kém của các nhà phát triển khác.
maple_shaft

@LostInCode Vâng, và lời khuyên của tôi đã không tốt hơn nhiều ngay cả sau khi tôi đã chỉnh sửa nó hoàn toàn để phù hợp với thông tin mới. Tôi đoán tôi là Chandler.
cregox
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.