Làm thế nào để hỏi một lập trình viên một câu hỏi mà không nhận được Why Why là câu trả lời

Chúng ta đều đã có kinh nghiệm này. Bạn đến một người mà bạn biết có câu trả lời cho một câu hỏi, hỏi người đó câu hỏi và họ trả lời với câu trả lời điển hình: "tại sao?" Bạn giải thích lý do tại sao bạn cần biết, và họ cố gắng giải quyết vấn đề của bạn.

Phải mất thời gian, vặn tay và kiên nhẫn để điều khiển cuộc trò chuyện trở lại câu hỏi ban đầu và chỉ nhận được câu trả lời chết tiệt đó.

Tại sao các lập trình viên liên tục làm điều này, và tại sao hành vi trở nên tồi tệ hơn khi lập trình viên càng trở nên cao cấp?

Làm thế nào bạn có thể hỏi một lập trình viên một câu hỏi theo cách hiệu quả nhất trong việc trích xuất câu trả lời cho câu hỏi ban đầu?

Tại sao các nhà phát triển hỏi "tại sao" khi ai đó hỏi họ cách triển khai giải pháp?

Bởi vì nó đòi hỏi nhiều kiến ​​thức hơn để đánh giá liệu một giải pháp có phù hợp hơn thực tế để thực hiện giải pháp đó hay không.

Thật khó để tin ai đó khi họ nói, "Tôi không biết làm thế nào, nhưng tôi biết chắc chắn đó là điều tôi cần làm." Các lập trình viên liên tục khăng khăng đòi thăm dò sâu hơn vì mọi người liên tục khăng khăng hỏi những câu hỏi sai. Vâng, đôi khi cuối cùng nó quay lại câu hỏi ban đầu của bạn, nhưng không phải lúc nào cũng vậy.

Tương tự như vậy, hãy tưởng tượng nếu ai đó đi đến một thợ máy và hỏi anh ta cách thay pin xe hơi. Thông thường nếu bạn đủ điều kiện để chẩn đoán pin bị lỗi, bạn đủ điều kiện để thay thế một pin, vì vậy thợ máy sẽ hỏi làm thế nào bạn biết nó cần thay thế.

Anh ta biết nếu anh ta không làm điều này, và hóa ra bạn không cần pin, sau đó bạn sẽ tiếp tục quay lại hỏi nhiều câu hỏi hơn nữa cho đến khi cuối cùng bạn nhận ra rằng bạn phải tắt đèn khi động cơ không chạy. Bằng cách hỏi bạn trước, có cảm giác như anh ta đang lãng phí thời gian của bạn, nhưng thực sự anh ta biết từ kinh nghiệm rằng anh ta có khả năng tiết kiệm cho cả hai bạn nhiều thời gian hơn.

Vì vậy, nếu bạn muốn tránh những câu hỏi, bạn cần thuyết phục anh ấy trước rằng bạn biết bạn đang nói về điều gì.

"Câu hỏi cụ thể là làm thế nào để một người tham gia với một lập trình viên khác đặt câu hỏi, nơi người kia có câu trả lời và bỏ qua cuộc tranh luận về lý do tại sao câu hỏi được hỏi."

Bạn không thể, ít nhất là không xác định. Lập trình viên khác là một người, không phải máy tính và không phải là đầy tớ của bạn. Nếu bạn hỏi họ một câu hỏi, họ sẽ chọn câu trả lời đúng nhất. Nếu họ nghĩ rằng họ cần nhiều bối cảnh hơn, họ sẽ yêu cầu nó.

Bạn có thể thử mở đầu câu hỏi của mình bằng một tuyên bố rằng bạn chỉ đang tìm kiếm một câu trả lời ngắn gọn, nhưng họ vẫn trả lời miễn phí khi họ nghĩ tốt nhất.

Câu hỏi cụ thể là làm thế nào để một người tham gia với một lập trình viên khác để đặt câu hỏi, nơi người kia có câu trả lời và bỏ qua cuộc tranh luận về lý do tại sao câu hỏi được hỏi.

Bạn không thể. Các lập trình viên, đặc biệt là những người giỏi, có dây để giải quyết vấn đề và hiệu quả . Khi một khách hàng hoặc một lập trình viên đồng nghiệp tìm kiếm câu trả lời - họ sẽ đảm bảo biết được vấn đề họ đang giải quyết, trước khi đưa ra giải pháp. Bằng cách đó họ hiệu quả (họ không lãng phí thời gian của bạn và họ bằng cách đưa ra câu trả lời sẽ không giải quyết được vấn đề của bạn) và họ đang giải quyết các vấn đề thực sự (bằng cách đưa ra giải pháp / câu trả lời cho câu hỏi mà bạn nên hỏi).

Ví dụ - khi một khách hàng đến với bạn và nói rằng anh ta muốn một tính năng X được triển khai. Đôi khi khách hàng thực sự cần một tính năng X và đôi khi bạn thực sự phải tìm hiểu và thẩm vấn khách hàng chỉ để biết rằng họ không muốn X nhưng điều gì đó hoàn toàn khác. Các lập trình viên càng lớn tuổi và có kinh nghiệm, càng có nhiều khả năng họ bị đốt cháy trong quá khứ do không đi vào trọng tâm của vấn đề trước khi trình bày một giải pháp.

Vì vậy, để tóm tắt - nếu bạn muốn câu hỏi của mình được trả lời chính xác, bạn cần chắc chắn rằng bạn:

• đặt câu hỏi đúng (do đó bạn cần nghiên cứu vấn đề trước)
• cung cấp bối cảnh cho vấn đề
• chia sẻ một số nghiên cứu của bạn để hướng họ nhanh hơn đến vấn đề

Hầu hết con người tôi biết chỉ là con người chứ không phải máy tính. Nếu bạn chỉ muốn câu trả lời hãy thử googling nó.

Tại sao các lập trình viên liên tục làm điều này, và tại sao hành vi trở nên tồi tệ hơn khi lập trình viên càng trở nên cao cấp?

Thật không may, đó là xa sự thật nói chung.

Hành vi đó được giới hạn trong thiểu số những người thực sự tốt. Và bạn tốt hơn nên học nó quá.

Chỉ cần trả lời câu hỏi chết tiệt bỏ qua các whys là một cách tốt để lái xe vào một vực thẳm, nhanh chóng và chắc chắn.

Nếu bạn thực sự muốn bỏ qua phần được giáo dục, bạn có thể đặt tiền tố cho câu hỏi của bạn với một vài câu về những hạn chế và mong muốn bỏ qua câu hỏi - bạn có thể nhận được một số câu trả lời hoặc chỉ cần gửi đi. Trình bày tóm tắt nghiên cứu của riêng bạn là một ý tưởng tốt hơn.

Mỗi câu trả lời ở đây là một câu trả lời tốt cho câu hỏi "tại sao", nhưng không ai thực sự trả lời câu hỏi của OP.

Làm thế nào bạn có thể hỏi một lập trình viên một câu hỏi theo cách hiệu quả nhất trong việc trích xuất câu trả lời cho câu hỏi ban đầu?

Câu trả lời rất đơn giản: hãy nói cho họ biết tại sao điều này cần phải được thực hiện trước khi bạn hỏi họ như thế nào.

Điều tốt nhất để làm là bao gồm các nhà phát triển trong một số cuộc họp cấp cao hơn xung quanh một sản phẩm - cung cấp cho họ một số bức tranh lớn hơn để họ có thể thấy lý do tại sao điều này đặc biệt cần phải được thực hiện. Họ thậm chí có thể làm bạn ngạc nhiên khi nghĩ ra cách đầu tiên.

Lập trình viên giỏi không chỉ muốn thực hiện bất kỳ giải pháp nào; họ muốn thực hiện giải pháp tốt nhất cho vấn đề cụ thể. Điều này đòi hỏi thông tin. Câu hỏi là cách để thu thập thông tin. Không có tất cả thông tin, lập trình viên biết rằng anh ta có nguy cơ thực hiện một giải pháp không phù hợp với tất cả các yêu cầu và sẽ bị mắc kẹt khi thực hiện lại. Đừng giấu thông tin từ các lập trình viên của bạn. Che giấu thông tin làm lãng phí thời gian, hủy hoại tinh thần và dẫn đến các giải pháp kém hơn.

Các lập trình viên "cứng cáp" để giải quyết vấn đề.

Các lập trình viên giỏi sẽ cố gắng giải quyết các vấn đề "đúng".

Chỉ cung cấp những gì ai đó đang yêu cầu là [thường] vấn đề sai cần giải quyết.

Trong những ngày mà tự động hóa MS Office là tất cả cơn thịnh nộ, bạn sẽ nhận được một chuỗi câu hỏi, thường là trong vài tuần, hỏi cách thực hiện "điều này" trong một sản phẩm Office, sau đó "điều đó" trong một số sản phẩm khác , sau đó một cái gì đó một lần nữa trong một cái khác. Mỗi vấn đề đều được xử lý nhanh chóng, nhưng "vấn đề" - chưa được nêu đầy đủ - chưa được giải quyết. Họ tiếp tục quay trở lại cho "liên kết" tiếp theo trong chuỗi của họ.

Nếu bạn ngăn họ lại và hỏi họ "Tại sao?" sau đó họ phải theo dõi lại và giải thích rộng hơn những gì họ muốn đạt được và không chỉ mô tả vấn đề ngay lập tức trước mặt họ. (BTW, Các lập trình viên phải chịu đựng điều này cũng giống như (nếu không nhiều hơn) bất kỳ ai khác, mà theo đó các diễn đàn như những di chúc gấu này).
Chuỗi của người dùng "Đưa dữ liệu từ Cơ sở dữ liệu lớn vào Access, sau đó vào Excel để xoa bóp dữ liệu một chút, sau đó chuyển sang Word để họ có thể hợp nhất thư kết quả và gửi email cho mọi người mỗi tuần" nhanh chóng được thay thế bằng công việc hàng loạt thực hiện tất cả điều đó, với kết quả được đặt trong hộp thư đến của mọi người vào sáng thứ Hai, không có sự tham gia của Người dùng thủ công nào cả.

Người dùng thích điều đó.

Chúng tôi cần biết nơi bạn đang cố gắng đến, trước khi chúng tôi có thể cung cấp cho bạn cách tốt nhất để đến đó.

Ngoài ra, (để diễn giải Monty Python): "Bạn có muốn câu trả lời trong 5 phút hoặc toàn bộ nửa giờ" không?

Không có điểm nào Lập trình viên xáo trộn tất cả các chi tiết vụn vặt của một chức năng cụ thể khi bạn chỉ muốn biết liệu nó có đối phó được không nếu bạn cung cấp cho nó một số có ba ba số thập phân.

Biết quan điểm của bạn thường có thể định hình lại một cách triệt để câu trả lời bạn nhận được.

Câu hỏi cuối cùng của bạn là "Làm thế nào bạn có thể hỏi một lập trình viên một câu hỏi theo cách hiệu quả nhất trong việc trích xuất câu trả lời cho câu hỏi ban đầu?"

Trước tiên bạn nhầm lẫn "hiệu quả" và "hiệu quả". Để hiệu quả nhất , chỉ cần viết "Câu trả lời là gì?" trên một tờ giấy và đưa cho lập trình viên. Đó là một cách rất hiệu quả để đặt câu hỏi. Nó cũng rất không hiệu quả khi nhận được câu trả lời.

Và thứ hai, bạn đang giả định rằng các nhà phát triển phần mềm là người trả lời câu hỏi. Họ không phải. Họ là những người giải quyết vấn đề. Thái độ của bạn cho thấy rõ rằng bạn không hiểu giải quyết vấn đề. Cách hiệu quả nhất để giải quyết vấn đề là tìm hiểu vấn đề đến mức bạn có thể mô tả nó cho người giải quyết vấn đề, sau đó trình bày nó cho người giải quyết vấn đề. Phương pháp khác là hiểu vấn đề một phần càng xa càng tốt, sau đó trình bày sự hiểu biết chưa đầy đủ của bạn cho người giải quyết vấn đề, người đầu tiên sẽ hỏi bạn những câu hỏi mà bạn sợ để biến vấn đề này thành vấn đề được hiểu đầy đủ, sau đó giải quyết nó.

Một cách rất không hiệu quả là phương pháp mà bạn đang thử: Tìm hiểu chưa đầy đủ về vấn đề, đoán xem vấn đề này có thể được giải quyết như thế nào và hỏi người giải quyết vấn đề làm thế nào để đạt được giải pháp này. Người giải quyết vấn đề đã thấy hành vi này trước đây. 10 lần nếu anh ta không có kinh nghiệm, ngàn lần nếu anh ta có kinh nghiệm. Vì vậy, người giải quyết vấn đề biết rằng bạn đang đi vào một hướng hoàn toàn sai lầm. Và người giải quyết vấn đề làm những gì cần làm để đi đúng hướng, đó là đặt câu hỏi để hiểu vấn đề thực tế. Câu hỏi đầu tiên để hiểu sự hiểu biết chưa đầy đủ của bạn về vấn đề, và câu hỏi thứ hai để hiểu vấn đề thực sự.

Bắt đầu câu hỏi bằng cách giải thích những gì bạn muốn đạt được và bối cảnh bạn đang làm việc là gì. Nếu bạn cung cấp đủ ngữ cảnh, bạn sẽ không nhận được "tại sao?" , bạn sẽ nhận được "điều này có thực sự cần thiết?"

Bởi vì, theo thống kê , hầu hết các tính năng được đề xuất đều hút và không đáng để thực hiện.

Một phản bác điển hình sẽ là "nhưng đó là công việc của anh ấy." Công việc của anh ấy là viết mã tốt và việc thêm các tính năng thường đi ngược lại điều đó, bởi vì hầu hết các tính năng đều yêu cầu thiết kế lại cơ sở mã hoạt động và "điều thiết kế lại:"

1. mất mãi mãi
2. thêm lỗi mới
3. phá vỡ những thứ đã từng làm việc
4. làm cho bảo trì không thấm

Đó không phải là mã tốt, mã tốt là tối thiểu.