Lỗi thiết kế và đối phó với sự sỉ nhục từ nó [đóng]

Bạn đã luôn luôn đúng về cơ bản trong các thiết kế phần mềm bạn đề xuất? Khi bạn đưa ra một số thiết kế sai về cơ bản, bạn có xu hướng mất đi sự tôn trọng của các thành viên trong nhóm. Không có vấn đề gì bạn làm sau đó bạn cuối cùng bị kiểm tra chéo cho tất cả mọi thứ bạn đề xuất sau sự cố đó. Điều này đặc biệt tồi tệ hơn khi bạn mới tham gia vào một nhóm và họ không biết quá khứ của bạn nơi bạn đã có một số câu chuyện thành công tốt đẹp.

Có thể lý do bạn đưa ra một thiết kế tồi là vì thiếu kinh nghiệm hoặc kiến ​​thức hoặc cả trong lĩnh vực đó. Làm thế nào bạn đã phải đối mặt với một tình huống như vậy đối phó với nó? Đây có phải là một điều một lần trong sự nghiệp của bạn hoặc nó xảy ra và tắt? Liệu một người đặt điều này phía sau hoặc một trong tình huống như vậy cần phải tìm kiếm một dòng công việc mới? Một số phản hồi trung thực xin vui lòng ...

Cảm ơn bạn.

Một lần, vp của một tài sản 500 đã tiêu tốn của công ty 1 triệu đô la với một quyết định kinh doanh tồi tệ. Khi anh ta từ chức với CEO, câu trả lời mà anh ta nhận được là: "Tôi mới đầu tư một triệu đô la vào giáo dục của bạn và bây giờ bạn đang cố gắng rời đi? Tôi không chấp nhận."

Tôi trở nên mệt mỏi với những người quản lý và những người lao động khác, những người nhanh chóng đổ lỗi cho một ai đó là một tân binh hoặc cho rằng họ không đủ năng lực. Chỉ có một cách để trở thành một nhà thiết kế giỏi và đó là tăng thêm vài%. Tôi không quan tâm nếu nhân viên của mình phạm sai lầm, tôi quan tâm nếu họ làm cùng một lần nhiều lần. Câu hỏi là, bạn khiêm tốn và dễ dạy như thế nào? Khi ai đó trình bày lỗi của bạn với bạn, bạn có tự bảo vệ mình trước hay nghe họ nói không? Nếu bạn là một trong những người hiếm hoi có thể nuốt niềm tự hào của mình và học hỏi từ nó, thì bạn đáng để bám vào. Bất cứ ai mà bạn mất sự tôn trọng vì đã phạm lỗi một lần, không phải là người xứng đáng với sự tôn trọng của bạn.

Cá nhân tôi đã phải viết lại hai dự án đầu tiên tôi thiết kế ít nhất hai lần, nhưng bạn biết gì không? Tôi đã học được một tấn, và mặc dù các chủ nhân của tôi đã bị xáo trộn vào thời điểm đó, điều đó nhanh chóng được bù đắp bởi hiệu quả tôi đạt được theo thời gian bằng cách sẵn sàng học hỏi từ những sai lầm của tôi.

Về khía cạnh sỉ nhục và cách phục hồi, tôi có hai lời khuyên. Đầu tiên, mọi người quên theo thời gian. Ngoài ra, khi người khác chú ý đến họ, họ cũng sẽ làm hỏng việc. Rồi tất cả sẽ lại bình đẳng. Thứ hai, đừng là một lỗ đít cho người khác khi họ trung thực, học hỏi, sai lầm. Trong thực tế, bạn nên khuyến khích họ trừ khi họ thực sự cần một cú đá mạnh vào mông. Theo thời gian, bạn có thể giúp thay đổi văn hóa của nhóm bằng cách nhớ lại cảm giác của bạn khi bạn phạm sai lầm trung thực. Cuối cùng bạn sẽ truyền cảm hứng cho mọi người trở thành những lập trình viên, nhà thiết kế và con người tốt hơn.

Tôi đã làm điều này trong một thời gian dài (hơn 15 năm) và tôi vẫn không hiểu đúng ngay từ lần đầu tiên. Các thiết kế tốt nhất đến từ một quá trình hợp tác lặp đi lặp lại. Khi bạn đã làm việc trên một thiết kế trong một thời gian, rất dễ bị mắc kẹt trong suy nghĩ rằng đó là cách duy nhất mà nó có thể được thực hiện. Một viễn cảnh tươi mới là hữu ích để nhìn thấy những điều mà bạn bỏ lỡ.

Để làm việc này, nhóm cần phải tin tưởng lẫn nhau. Bạn không thể ngại cho mọi người thấy một thiết kế có thể thiếu sót, và cần phải có khả năng chấp nhận những lời chỉ trích về thiết kế. Đổi lại, phần còn lại của nhóm cần phải hiểu rằng những sai sót trong thiết kế không phải là sự phản ánh đối với nhà thiết kế. Nó là một phần dự kiến ​​của thiết kế. Đó cũng là cách các thành viên trong nhóm học hỏi và trở nên tốt hơn: từ sai lầm của chính họ và sai lầm của người khác.

Nếu bạn ở trong một nhóm rối loạn chức năng không hoạt động như thế này, bạn có hai lựa chọn:

1. cố gắng sửa chữa đội
2. tìm một nhóm mới (trong nội bộ hoặc tại một employeer mới).

Theo như tôi biết, tôi luôn luôn phòng thủ một cách cơ bản . Điều đó không hoàn toàn giống như về cơ bản là chính xác . Thường thì hoàn cảnh thay đổi giữa thời gian bạn phải đưa ra quyết định 'x' và thời điểm rõ ràng rằng 'x' là quyết định sai lầm trong nhận thức muộn màng .

Nó giống như chuẩn bị thuế thu nhập Hoa Kỳ của bạn. Rất nhiều người nghĩ rằng đó là một câu trả lời. Không có. Bạn có ý kiến ​​của bạn; kế toán thuế của bạn có ý kiến ​​của mình; IRS có ý kiến ​​của họ.

Khi tôi phạm sai lầm, tôi không mất đi sự tôn trọng của bất kỳ ai. (Theo như tôi biết.) Tôi nghĩ đó là bởi vì, một phần, tôi luôn thừa nhận sai lầm của chính mình. (Trên thực tế, tôi thường tìm thấy sai lầm của chính mình.) Ngoài ra, hầu như tất cả các quyết định thiết kế quan trọng đều có nhiều hơn một người ký vào chúng. Bất kỳ sai lầm nào trong các quyết định đó đều thuộc sở hữu của nhóm, không hoàn toàn do một người.

Theo như thừa nhận sai lầm, tôi nghĩ rằng điều đó trở nên dễ dàng hơn khi bạn có được năng lực và kinh nghiệm. Theo kinh nghiệm của tôi, bạn càng mới thiết kế và phát triển, bạn càng ít có khả năng thừa nhận sai lầm.

Nó xảy ra và không nên làm hỏng sự nghiệp của bạn. Không ai ở vị trí trách nhiệm quan trọng luôn đưa ra quyết định chính xác. Trong thực tế, không ai ở vị trí có trách nhiệm quan trọng luôn đưa ra quyết định phòng thủ.

Nhưng hầu hết thời gian, bạn nên có thể đưa ra quyết định phòng thủ dựa trên thông tin không đầy đủ. Như con gái tôi sẽ nói, "Đó chỉ là con người."

Mọi người đôi khi nhận được những điều sai trái. Những sai lầm là không thể tránh khỏi. Tự do thừa nhận khi bạn sai, học hỏi từ những sai lầm của bạn và thể hiện sự khiêm tốn đặc biệt nếu ban đầu bạn không tin rằng bạn thực sự sai.

"Nhục nhã" không bao giờ nên, bao giờ xảy ra. Nó hoàn toàn không có khả năng cải thiện hiệu suất của một người.

Tại công ty của tôi, chúng tôi đã phát triển văn hóa tôn trọng những người vẫn sẵn sàng chấp nhận những quyết định khó khăn nhưng có thể thừa nhận là sai và điều chỉnh hành vi của họ khi cần thiết.

Bạn đã luôn luôn đúng về cơ bản trong các thiết kế phần mềm bạn đề xuất?

Vâng, tôi là một siêu nhân! Vâng, tất nhiên là không.

Khi bạn đưa ra một số thiết kế sai về cơ bản, bạn có xu hướng mất đi sự tôn trọng của các thành viên trong nhóm.

Không! Nếu điều đó xảy ra, thì có gì đó không đúng với tinh thần đồng đội.

Mọi người đều phạm sai lầm. Một số giải pháp hóa ra là tốt, một số xấu, hầu hết một cái gì đó ở giữa. Cả thành công và thất bại nên được coi là một bài học, bởi bạn và bởi phần còn lại của nhóm.

Những sai lầm đầu tiên có thể cảm thấy tồi tệ, nhưng sau khi bạn mắc hàng trăm lỗi, đó giống như một phần của công việc.

Nó xảy ra với tất cả mọi người. Điều chính là học hỏi từ những sai lầm của bạn và cố gắng không để nó xảy ra một lần nữa. Ngoài ra, hãy chắc chắn thừa nhận rằng đó là một lỗi từ phía bạn. Chẳng hạn, tôi đã từng phạm sai lầm khi sử dụng Lớp truy cập dữ liệu kém hơn (SubSonic3). Vào thời điểm tôi đưa ra quyết định, tôi chỉ muốn thoát khỏi các truy vấn SQL thủ công. Vì vậy, tôi đã chọn những gì tại thời điểm đó có vẻ như là một trong những dễ dàng nhất để bắt đầu. Tôi cũng không có kinh nghiệm với DALs. Chà, sau khi giải quyết một vài vấn đề, tôi đã tự hỏi tại sao một số truy vấn mất quá nhiều thời gian và thấy SubSonic đang kéo xuống toàn bộ bảng mà không có lý do chính đáng.

Vì vậy, tôi đã nói với sếp của mình, giải thích rằng tôi đã phạm sai lầm và đưa cho anh ta kế hoạch sửa chữa nó. Tất nhiên ông chủ của tôi không nhiệt tình với tôi về một sai lầm khá lớn đòi hỏi một vài ngày di cư thuần túy. Nhưng, anh ấy cũng đảm bảo rằng tôi đã không phạm sai lầm tương tự một lần nữa. Anh ấy bắt tôi tạo một dự án bằng chứng cho lớp truy cập dữ liệu tiếp theo mà tôi đề xuất để di chuyển đến và chúng tôi đảm bảo rằng nó sẽ hoạt động với các yêu cầu của chúng tôi và nó không kéo xuống toàn bộ bảng. Nói chung, đó là một trải nghiệm học tập tốt với tôi và bây giờ tôi chắc chắn sẽ đảm bảo một phần quan trọng của dự án đáp ứng yêu cầu và không gặp vấn đề lớn.

Vì vậy, về cơ bản những gì bạn làm là đây:

1. Thừa nhận bạn đã làm sai
2. Lập một kế hoạch để sửa chữa nó
3. Hãy chắc chắn rằng kế hoạch của bạn sẽ thực sự hoạt động
4. Hãy chắc chắn một lần nữa.
5. Sửa nó!

Nếu bạn không chắc chắn cách khắc phục, đừng ngại đưa các thành viên khác vào nhóm.

Một điều cuối cùng, thư giãn! Ai cũng mắc sai lầm. Rất ít người có được nó hoàn hảo ngay lần đầu tiên

Đây là một cuộc thi bực bội táo bạo, và không phải là một tình huống tốt để tham gia. Không ai luôn đúng, và không có gì phải xấu hổ nếu ai đó nghĩ ra một cách tốt hơn để làm điều đó, hoặc nếu họ thấy có vấn đề với cách bạn đã làm nó.

Bạn cần phải tự thoái vốn khỏi giải pháp của mình và dành thời gian cố gắng tìm giải pháp tốt nhất , sau đó bạn có thể hài lòng khi vấn đề được giải quyết, ngay cả khi nó được giải quyết bởi người khác.

Có rất nhiều điều mà bạn không nói trong câu hỏi của bạn. Tôi không thể biết cài đặt của bạn là gì để "đưa ra một thiết kế". Đây có phải là cuộc thảo luận ban đầu với một đồng nghiệp về cách tiếp cận theo kế hoạch của bạn hay đó là việc phân phối những gì bạn hy vọng là mã cuối cùng?

Nếu trước đây, thì không có lý do gì để cảm thấy tồi tệ và không có lý do gì để đồng nghiệp nghi ngờ bạn trong tương lai.

Nếu bạn đang đợi cho đến khi giao hàng cuối cùng để thảo luận về thiết kế của bạn với người khác, thì tôi không trách họ đã nghi ngờ công việc khác của bạn.

Mọi người cần thảo luận về thiết kế của họ với người khác. Tùy thuộc vào mức độ phức tạp hoặc mức độ quan trọng, bạn có thể cần thảo luận với nhiều người nhiều lần. Mọi người đều có thể phạm sai lầm, hiểu sai một yêu cầu hoặc bỏ lỡ một trường hợp đặc biệt.

Những sai lầm được xác định sớm là dễ dàng hơn và rẻ hơn để sửa chữa. Họ nên được tha thứ trừ khi bạn lặp đi lặp lại những sai lầm tương tự. Đánh giá ngang hàng giúp dễ dàng bắt lỗi sớm.

Nếu bạn đang cố gắng trở thành một lập trình viên đơn độc trong môi trường nhóm, bạn đang phạm phải tội lỗi (gần như không thể tha thứ) khi nghĩ rằng bạn đủ hoàn hảo để bạn không cần sự giúp đỡ của ai khác. Thực tế là môi trường nhóm chứng minh rằng vấn đề đủ lớn để không ai có thể hiểu tất cả. Mọi người phải nói chuyện với nhau hoặc sai lầm sẽ khiến đầu ugle của họ quá gần để phát hành (hoặc sau khi phát hành).

Tôi luôn luôn phân biệt, một mặt, quyết định tốt hay xấu; và trên các quyết định chính xác và không chính xác khác. Một quyết định tốt là một trong những trường hợp tương tự, với cùng một thông tin, bạn sẽ đưa ra theo cùng một cách; một quyết định tồi tệ là một quyết định mà bạn sẽ đưa ra khác nhau. Một quyết định đúng là một trong đó, với lợi ích của nhận thức muộn và thông tin bổ sung, chứng tỏ đã đúng; và ngược lại với những quyết định không chính xác.

Người ta thường nói rằng người không đưa ra quyết định không chính xác không bao giờ đưa ra bất cứ điều gì. Quyết định không chính xác là cách người ta học Các quyết định tồi tệ thường trở nên trầm trọng hơn vì người ra quyết định tự đầu tư vào quyết định và cố gắng xem xét lại quyết định hoặc chứng minh rằng đó là một quyết định tốt sau tất cả (sự che đậy luôn gây tổn hại nhiều hơn quyết định ban đầu).

Hầu hết các quyết định thiết kế tôi đã đưa ra đã được chứng minh là đúng, nhưng tôi đã học được nhiều nhất và tiến bộ hơn với những quyết định không chính xác. Tôi hy vọng rằng rất ít quyết định của tôi là quyết định tồi, nhưng một phần của vấn đề với quyết định tồi của một người là nhận ra rằng quyết định đó là xấu và chấp nhận những bài học thường không hấp dẫn phát sinh từ họ.

Miễn là họ không phải là " Thứ hai buổi sáng thứ hai ." Tôi không có ích gì cho một người ngồi suốt tất cả các cuộc thảo luận về thiết kế mà không nói bất cứ điều gì chỉ để khẳng định rằng họ biết nó sẽ không hoạt động sau thực tế. Bạn phải có khả năng đưa ra lời chỉ trích ngay cả khi nó không được đặt trong một bối cảnh mang tính xây dựng.

Có lẽ một trong những tính năng tốt nhất của trang web SO là có thể chấp nhận rủi ro và đề xuất và giải pháp không chắc chắn. Đây là cách bạn học. Trải qua cuộc sống với một đống tào lao trong đầu là sai, nhưng bạn chưa bao giờ được nói với sự tương phản, là sự thiếu hiểu biết thực sự.

Họ có thể biết điều gì đó bạn không biết, nhưng họ sẽ không biết tất cả mọi thứ. Hãy vượt qua nó, đi làm và hoàn thành công việc. Hãy để họ lãng phí thời gian nghĩ rằng họ thật thông minh.

Tôi đã luôn luôn cung cấp thiết kế tốt? Không! Tôi cố gắng để làm điều đó, tôi cố gắng để trở nên tốt hơn, nhưng với mỗi dự án kế tiếp, điều tôi dường như luôn luôn làm là nhìn lại những gì tôi đã làm trước đây và chùn bước về cách tôi đã bỏ lỡ dấu ấn theo một cách nào đó.

Đối với một người đã đề xuất một thiết kế ít hơn sao, tôi sẽ không chống lại người đó nếu người đó chứng minh rằng anh ta hoặc cô ta sẵn sàng học hỏi từ sai lầm và cởi mở với những lời chỉ trích. Nếu tôi thấy bằng chứng cho thấy người đó đang phấn đấu tương tự để trở nên tốt hơn và có khả năng làm điều đó, thì một đề xuất thiết kế tồi chỉ là một cơ hội học tập.

Nó xảy ra với tất cả mọi người bây giờ và sau đó, vì vậy điều tốt nhất để làm là tìm ra lý do tại sao thiết kế sai và học hỏi từ đó. Nếu đó là một sự thiếu hiểu biết, thì thất bại trong thiết kế hy vọng sẽ cung cấp cho bạn một số kiến ​​thức mới mà bạn có thể sử dụng vào lần tới. Đừng để nó làm bạn nản lòng, mọi người đều trải qua điều này vào một lúc nào đó. Đó là cách tốt nhất để tích lũy kinh nghiệm và bắt kịp với một nhóm / môi trường mới.

Điều này sẽ xảy ra thường xuyên. Ngành công nghiệp của chúng ta đang thay đổi rất nhanh, cơ hội không bao giờ sai là có hiệu quả bằng không.

Tuy nhiên, bạn đã đẩy thiết kế xấu xuống thoat của họ trên sự phản đối của họ? Đó có thể là lý do tại sao họ phản ứng thái quá.

Nếu sai lầm là rất lớn, tất nhiên sẽ mất thời gian để lấy lại sự tôn trọng. Nếu một trong những đồng nghiệp của bạn đưa bạn đi theo hướng xấu và tạo ra vấn đề cho cả nhóm, bạn sẽ không cần anh ta chứng tỏ bản thân nhiều hơn trong thời gian tới chứ?

Tất cả những gì bạn có thể làm là thừa nhận bạn đã sai, cung cấp tín dụng cho bất cứ ai đúng và cố gắng lắng nghe tốt hơn và lựa chọn nghiên cứu tốt hơn trong tương lai.

Điều gì bạn đã không nghĩ rằng làm cho thiết kế là một sai lầm? (Không phải ví dụ ngẫu nhiên - thiết kế quy trình nhập để sử dụng dịch vụ web hiện có chạy từng hàng (sử dụng lại mã và chỉ cần thay đổi quy tắc kinh doanh ở một nơi) không nhận ra rằng một số nhập sẽ có hàng triệu bản ghi và sẽ mất nhiều ngày để kết thúc.) Học hỏi từ nó và xem xét những điều đó trong tương lai.

Sẽ luôn có những sai lầm. Để sai là trở thành một lập trình viên. Tiếp tục học hỏi từ những người khác trên internet và đặc biệt là từ đồng nghiệp của bạn. Sự xấu hổ duy nhất ở đây sẽ là từ bỏ, hoặc vùi đầu vào cát khi gặp phải những vấn đề như thế này từ đây trở đi.

Đặt nó phía sau bạn, đặt đầu của bạn xuống, và làm hết sức mình. Nếu bạn là một lập trình viên giỏi, bạn sẽ tỏa sáng nhờ những sai lầm của mình.

Nếu bạn không chắc chắn rằng ý tưởng của bạn nằm trên một nền tảng vững chắc, bạn nên thảo luận với một vài đồng nghiệp đáng tin cậy trước khi bạn đề xuất nó cho toàn bộ công ty hoặc bộ phận. Trên thực tế, ngay cả khi bạn chắc chắn, bạn vẫn nên thảo luận với những người bạn làm việc cùng và những người có khả năng hiểu bạn nhất. Họ sẽ giúp bạn phát hiện ra vấn đề sớm.

Nó xảy ra với tất cả chúng ta đôi khi. Sử dụng thiết kế đầu tiên như một nguyên mẫu. Tìm hiểu chính xác những gì đã làm việc và những gì không và tại sao. Sau đó, bạn có thể viết một sản phẩm cuối cùng tốt hơn nhiều.

Đừng cố gắng biện minh cho bản thân hoặc phòng thủ. Nhận lỗi và bước tiếp.

Vấn đề cơ bản dường như không được giải thích: đây là một vấn đề xã hội . Bạn có thể thấy hành vi như vậy trong hầu hết mọi ngành nghề: nếu bạn phạm sai lầm và họ thích "phân loại" bạn theo một thứ nhất định, đó là mãi mãi. Đó là một hành vi xã hội. Ngay cả những người thông minh và thông minh cũng sẽ có xu hướng đi theo mọi người.

Để tôi cho bạn một ví dụ không liên quan gì đến lập trình: trong công việc trước đây, tôi đã quên rửa bát nói một hoặc hai lần. Kể từ đó, tất cả các công nhân đều nghĩ tôi là kiểu đàn ông không bao giờ rửa chén. Và bây giờ ngay khi có một thứ bẩn thỉu trong bồn rửa, đó là tôi (người khác có thể là nó).

Ở mọi nơi đều giống nhau: đây là một hành vi xã hội , bất kể đó là vấn đề gì.

Bạn nói với tôi bạn muốn phản hồi trung thực? Giải pháp duy nhất là bỏ việc cho một công việc khác. Nếu tất cả mọi người trong nhóm nghĩ rằng bạn không giỏi trong công việc thì sẽ không thay đổi bất cứ lúc nào, xin lỗi khi nói theo cách này. Vì vậy, hãy tìm một công việc khác, bởi vì bạn sẽ không bao giờ thay đổi loại hành vi xã hội (ngu ngốc này tôi phải thú nhận) .

Điều quan trọng là làm thế nào để bạn nêu trường hợp của bạn và những loại thay đổi bạn thực hiện. Nếu bạn tự nhận là một chuyên gia lập trình không có gì sai và tuyệt vời hơn Jon Skeet, thì có khả năng đến một lúc nào đó bạn sẽ bị hạ bệ vì điều đó. Điều quan trọng là làm thế nào để bạn trình bày các giải pháp của mình để bạn có thể chỉ ra rằng đây là một giải pháp hợp lý cho vấn đề thay vì giải pháp hoàn hảo thậm chí không nên kiểm tra.

Ví dụ tốt nhất của tôi sẽ là khám phá các tác dụng phụ của việc có một lớp học statictrong một ứng dụng web nơi tôi đã làm việc một lần. Tôi không biết sẽ tệ đến mức nào khi một trường hợp đó tồn tại và được chia sẻ trên tất cả người dùng ứng dụng nhưng tôi đã học được từ đó và đã phục hồi kịp thời. Đôi khi nó có thể là một cái gì đó được tìm thấy và sửa chữa lớn phải được thực hiện. Tôi cũng đã ở trong trại đó, nơi tôi phải sàng lọc một loạt VBScript để giảm các chuỗi kết nối gây ra vấn đề về bộ nhớ nơi tôi làm việc một lần. Tôi thậm chí có thể nhớ việc viết mã dễ bị tấn công SQL vào năm 1998 khi tôi đang viết một đoạn mã tìm kiếm khách hàng phải tự động tạo SQL vì tôi có ~ 20 trường tùy chọn trong phần ứng dụng đó.

Cầu toàn có thể là một con dao hai lưỡi ở đây, đó là cách tôi thấy nhận xét thứ 3 đó cũng như là một cách mà đôi khi tôi cũng vậy. Điều xấu là thấy rằng có tất cả những sai lầm này và không có gì là đúng cả. Điều tốt là trong việc có được điều tốt nhất bạn có thể, bạn cũng có thể gặp gỡ nếu không vượt qua sự mong đợi của người khác về bạn. Cải tiến liên tục cũng có thể là cách PC để thấy sự hoàn hảo và nếu được kiểm duyệt, tôi thấy đây là một điều tốt. Đối với tất cả các lỗi đã làm, mã của bạn có được đưa vào sản xuất không? Nó có hoàn thành công việc không? Đó là những điểm cần suy ngẫm cũng như nếu ai đó luôn sửa chữa một cái gì đó trên đó hoặc thật tốt khi bạn muốn trở nên tuyệt vời đến mức bạn không muốn làm gì khác cho đến khi hoàn hảo? Thực hành có thể hữu ích để giúp tìm ra các mô hình để thực hiện công việc tốt hơn. Tuy nhiên,