Điều gì xảy ra nếu bạn không thể giải quyết vấn đề? [đóng cửa]

Tôi còn một năm nữa mới tốt nghiệp đại học và tôi rất mong được giải quyết những vấn đề thực tế. Đặc biệt là những thứ không tầm thường đòi hỏi một chút nghiên cứu và suy nghĩ nhiều.

Nhưng đồng thời, đó cũng là nỗi sợ lớn nhất của tôi - phải đối mặt với một vấn đề mà tôi không thể giải quyết, bất kể tôi có cố gắng thế nào. Và với áp lực phải cung cấp mã về thời hạn sắp tới, có vẻ hơi đáng sợ khi xem nó từ các sân chơi an toàn trên uni (nơi điều tồi tệ nhất có thể xảy ra là bạn phải làm lại một khóa học hoặc bài kiểm tra).

Vì vậy, đối với những người đã ở trong ngành trong thời gian dài hơn, điều gì sẽ xảy ra nếu bạn được yêu cầu giải quyết một vấn đề mà bạn không thể? Nó đã xảy ra, và nếu vậy, chuyện gì đã xảy ra? Có phải họ vừa thả nó xuống và nói "Ồ tốt, đoán chúng ta có thể làm gì với thứ khác"? Có hậu quả không? Bạn có bị khiển trách, hoặc thậm chí bị sa thải?

Trước hết, nỗi sợ của bạn rất khỏe mạnh, và bình thường. Đây là suy nghĩ của tôi sau khoảng 15 năm trong ngành công nghiệp phần mềm.
Dưới đây là một số câu hỏi để tự hỏi:

1. Bạn có hiểu vấn đề không?
2. Bạn có biết rằng vấn đề không thể giải quyết được (trong giới hạn thời gian / ngân sách của bạn) không?
3. Bạn chỉ không biết làm thế nào để giải quyết vấn đề?
4. Là khách hàng / sếp của bạn yêu cầu không thể.
5. Nó có đáng không? (ROI)
6. Nó có phải là một vấn đề THỰC SỰ ?

1) Trước hết, hãy chắc chắn rằng bạn hiểu vấn đề. Chưa có câu hỏi ngu ngốc. Bạn có hiểu khách hàng / sếp của bạn đang hỏi bạn những gì họ cần không?

2) Điều này sẽ xảy ra. "Xây cho tôi một cây cầu vào ngày mai" . Hãy chắc chắn rằng bạn biết rằng thực tế là một vấn đề không thể giải quyết được trong các ràng buộc của bạn. Khách hàng / sếp của bạn có thể linh hoạt về thời gian / ngân sách và những điều này có thể được sửa đổi để cung cấp cho bạn nhiều thời gian / ngân sách hơn.

3) Nếu vấn đề có thể hiểu được và các ràng buộc nằm trong lý do, và có công nghệ có thể giải quyết vấn đề, nhưng bạn không biết đủ ... đó là những gì StackOverflowvà Internet dành cho. Hãy chắc chắn rằng bạn làm nghiên cứu của bạn đầu tiên. Cố gắng đặt câu hỏi rõ ràng có câu trả lời định lượng. Hỏi bạn bè của bạn. Có một buổi thiết kế.

4) Đây là một biến thể của câu trả lời số 2. Có vẻ như khách hàng / sếp của bạn đang hỏi điều không thể. Làm một vài nghiên cứu. Không bao giờ nói rằng vấn đề là không thể giải quyết, trừ khi bạn biết chính xác tại sao và bạn có thể làm rõ.

5) ROI là viết tắt của lợi tức đầu tư. Điều này đề cập đến một khoản đầu tư trong thời gian. Thời gian của bạn!. Là vấn đề đủ quan trọng để giải quyết để đảm bảo lượng thời gian nó sẽ đưa bạn nghiên cứu và giải quyết vấn đề. Thảo luận về vấn đề này với khách hàng / sếp của bạn

6) Có phải là một vấn đề thực sự. Khách hàng, thường xuyên, hiểu những gì họ muốn, nhưng không nhất thiết phải hiểu những gì họ cần. Cố gắng hiểu những gì Khách hàng / Sếp của bạn thực sự cần và thảo luận điều này với họ.

Hy vọng những hướng dẫn này sẽ giúp bạn.

Hai điều cần nhớ nếu bạn gặp khó khăn với một vấn đề dường như không thể giải quyết:

• Hãy để những người khác biết bạn bị mắc kẹt càng sớm càng tốt. Nó sẽ giúp họ điều chỉnh dự toán kịp thời trước khi quá muộn.

• Nếu bạn thấy một cách giải quyết vấn đề không hiệu quả - hãy bỏ nó trước khi bạn lãng phí quá nhiều thời gian. Yêu cầu giúp đỡ hoặc thử một cách tiếp cận khác. Đó không phải là việc chứng tỏ bản thân chăm chỉ và thông minh, mà là hoàn thành công việc.

Tôi đi đến StackOverflow ;)

Nhưng tất cả đùa nhau sang một bên, đừng sợ những điều chưa biết. Toàn bộ sự nghiệp của bạn sẽ phải đối mặt với điều chưa biết, bởi vì nếu bạn đã giải quyết nó, nó sẽ không còn là vấn đề vào lần tới.

Tôi sẽ phải đi với một câu trả lời đơn giản: Tôi yêu cầu giúp đỡ. Giống như những người khác đôi khi yêu cầu tôi giúp đỡ khi họ bị mắc kẹt khi cố gắng tìm giải pháp cho điều gì đó.

Chỉnh sửa: Tôi nên đề cập rằng tôi thường tìm giải pháp chỉ bằng cách mô tả vấn đề cho đồng nghiệp hoặc đôi khi ngay cả khi tôi bắt đầu đăng câu hỏi trên các trang web như StackOverflow.

Nhìn từ các góc độ khác nhau

Tôi đã gặp điều này nhiều lần, thông thường những gì xảy ra là:

• Bạn có một vấn đề, ban đầu bạn có một ý tưởng trong đầu bạn sẽ giải quyết nó như thế nào.
• Khi thực sự thực hiện giải pháp của bạn, hóa ra đó không phải là công việc (có thể là do mô hình yếu của vấn đề thực tế).
• Sau khi đấu tranh để giải quyết vấn đề, có thể nghiên cứu thêm hoặc hỏi người khác. Không có nó hoạt động, sự thất vọng thuần túy!

Cuối cùng, bạn chọn cho những gì bạn không muốn làm ->

"Hack bẩn"

Nó hoạt động, nhưng bạn cảm thấy bẩn ...

Thông thường, tôi nhờ ai đó thông minh hơn tôi để sửa nó. Anh ấy làm và anh ấy là ông chủ của tôi. Tôi cảm thấy ngu ngốc. Chung ta se đi tiêp.

Nó phụ thuộc vào lý do tại sao bạn không thể ...

• logic không thể: Thảo luận với người đã viết các yêu cầu, có thể có một sự hiểu lầm. Ví dụ: tại một thời điểm, thông số kỹ thuật nói rằng ứng dụng phải trông và cảm nhận tự nhiên trên tất cả các nền tảng (Windows / Linux / Mac) và ở một nơi khác, nó nói rằng chương trình phải trông giống hệt nhau trên tất cả các nền tảng

• về mặt kỹ thuật là không thể: Đánh giá lại các công cụ bạn đang làm việc, có thể chúng không phù hợp. Thảo luận về vấn đề với các đồng nghiệp của bạn và người quản lý dự án. Ví dụ: yêu cầu thời gian thực cứng trong môi trường nơi bộ sưu tập rác có thể dừng thực thi trong thời gian không xác định

• hiệu suất không đủ: Có thể bạn đang sử dụng thuật toán sai hoặc có thể vấn đề quá khó (ví dụ NP-hard) và các yêu cầu không tính đến điều đó. Đánh giá lại thuật toán bạn đang sử dụng, có thể có một cách nhanh hơn. Thảo luận về vấn đề với các đồng nghiệp của bạn và người quản lý dự án. Cân nhắc chuyển sang một heuristic đủ tốt thay vì một kết quả hoàn hảo. Ví dụ: tối ưu hóa đường dẫn với hàng chục hoặc thậm chí hàng trăm nút

• bạn chỉ không biết làm thế nào để làm điều đó: Hỏi đồng nghiệp của bạn, hỏi stackoverflow, tìm kiếm trên internet. Liên hệ với bộ phận hỗ trợ của công cụ / lib bạn đang sử dụng. Thảo luận với người quản lý dự án.

• nó sẽ hoạt động, nhưng không, và bạn không biết tại sao: Tái cấu trúc chương trình để làm cho nó dễ kiểm tra hơn. Xem xét các điều kiện chủng tộc, chúng thường là lý do cho các lỗi khó tìm. Yêu cầu đồng nghiệp giúp đỡ, bốn mắt nhìn thấy nhiều hơn hai. Kiểm tra internet để biết các lỗi đã biết trong các công cụ / libs bạn đang sử dụng.

Tôi nghĩ rằng những người khác chỉ ra cách đối phó với nó một cách chuyên nghiệp. Tôi muốn nói làm thế nào để đối phó với cảm giác cá nhân như thất vọng, sợ hãi.

Điểm mấu chốt là bạn sẽ THỰC SỰ ngay cả khi bạn không giải quyết vấn đề kịp thời. Cuộc sống vẫn tiếp diễn.

Đôi khi, lịch trình sẽ được đẩy. Dự án sẽ thành công hoặc thất bại. Bạn có thể bị sa thải và sau đó có công việc tuyệt vời. Bạn chỉ không bao giờ biết.

Đừng hiểu lầm tôi. Điều đó không có nghĩa là không sao khi để vấn đề ở đó. Tất cả những gì chúng ta có thể làm là làm hết sức mình và để nó đi.

Đôi khi, tôi nghĩ rằng sự thất vọng, sợ hãi không giải quyết được vấn đề là cuộc sống của tôi như một nhà phát triển trung bình.

Tôi không chắc là tôi nói rằng tôi không thể giải quyết vấn đề, nhưng đã có trường hợp tôi từ bỏ việc cố gắng giải quyết vấn đề. Sau khi dành nhiều giờ để cố gắng sửa lỗi hoặc triển khai một số tính năng mà tôi không biết làm thế nào để làm điều đó, tôi có thể nói với ai đó trong nhóm của mình, trưởng nhóm hoặc người quản lý, "Tôi bị mắc kẹt về điều này. bạn có muốn tôi làm không? " để họ biết tôi đang ở đâu Họ có thể nói: "Hãy giữ lấy nó, chúng tôi nghĩ rằng bạn sẽ nhận được nó" hoặc "Chuyển sang một thứ khác không quan trọng" hoặc một vài điều khác và sau đó tôi sẽ biết tôi nên làm gì.

Tôi đã có lỗi mà tôi không giải quyết được và một số tính năng chưa được thực hiện, chắc chắn. Trong khi tôi có thể cố gắng hoàn thành công việc, không phải mọi thứ đều nằm trong khả năng của tôi để giải quyết trong một thời gian hợp lý. Một điểm quan trọng trong việc này là có sự giao tiếp để cấp trên biết bạn đang ở đâu.

Điều đó nói rằng, tôi đã có một vài lần tôi gặp phải một số trường hợp khá đặc biệt:

1. Khi làm việc tại một ngân hàng lớn của Canada ở Toronto, tôi sẽ được yêu cầu làm tất cả mọi thứ mà tôi không biết phải làm thế nào khi được giao nhiệm vụ. Ví dụ, tôi được yêu cầu thử nghiệm phương pháp này để bảo vệ máy tính xách tay trong đó các phím "Esc" và "Enter" được hoán đổi khi khởi động và với chuỗi phím bên phải, máy tính xách tay sẽ có thể sử dụng được một lần nữa mà dường như rất kỳ lạ. "Điều này có hiệu quả không? Làm sao tôi biết điều này sẽ hoặc không ổn với người dùng?" Có những nhiệm vụ khác mà tôi không có phần cứng hoặc tài nguyên khác để hoàn thành nó. Đồng thời nó khá giáo dục vì điều này mang lại cho tôi nhiều điều cần lưu ý về bất kỳ tình huống việc làm nào trong tương lai để ngăn ngừa rắc rối. Những điều như đảm bảo khi tôi được trả tiền, thời gian của tôi được theo dõi như thế nào,

2. Khi làm việc tại một nhà cung cấp dịch vụ ứng dụng ở Calgary, tôi đã được giao dự án này cố gắng tạo một bản sao của một trang web khác trong ứng dụng nội bộ của chúng tôi mà chúng tôi đã bán như một dịch vụ. Một điểm quan trọng ở đây là tôi đã không đưa ra một dòng thời gian hoặc gợi ý về phần nào nên làm trước, chỉ là nghiên cứu chung và một tháng sau tôi đã được yêu cầu một bản demo giống như tôi đang có phản ứng xấu với một loại thuốc giảm đau. Phản ứng đó kéo dài một tuần mà tôi nghỉ làm đột ngột và rồi tuần sau, tôi đến một sự kiện của Microsoft, đó là loại rơm cuối cùng khi tôi bị sa thải vào ngày hôm sau. Một điều cần lưu ý ở đây là làm thế nào tôi có một mối quan hệ khá kém với sếp của mình vì bất cứ khi nào anh ấy đến gần khu vực của tôi, suy nghĩ ngay lập tức của tôi là "Bây giờ có gì sai?"

Như những người khác đã nói, giao tiếp rất quan trọng - cho mọi người biết (người sẽ bị ảnh hưởng) khi bạn gặp khó khăn: sếp, thành viên nhóm, khách hàng, v.v.

Một đồng nghiệp sắc sảo đã từng truyền cho tôi rằng thành công bắt nguồn từ hai điều:

1. Các mối quan hệ
2. Kỳ vọng

Có một mối quan hệ tốt, tôi cho rằng, là một chức năng của giao tiếp tốt và đặt kỳ vọng lên phía trước.

Tôi theo hoàng tử Polya:

"Nếu có một vấn đề bạn không thể giải quyết, thì có một vấn đề dễ dàng hơn bạn không thể giải quyết: tìm ra nó."

George Polya

Cái hay của nguyên tắc là đến một lúc nào đó sẽ có một vấn đề đủ nhỏ và bạn sẽ có thể giải quyết được, hy vọng nếu bạn làm đúng, sẽ cho phép bạn khởi động một giải pháp cho vấn đề ban đầu. Nguyên tắc này chưa làm tôi thất bại.

Câu trả lời " tìm kiếm sự giúp đỡ " hoàn toàn chính xác. Rất khó có khả năng bạn là người đầu tiên gặp phải một vấn đề cụ thể.

Nhưng như một thử nghiệm mặc dù, nếu không có sự giúp đỡ thì sao? Điều gì nếu bạn phải tự giải quyết vấn đề? Khả năng giải quyết vấn đề quan trọng nhất là khả năng xác định và thách thức các giả định của riêng bạn . Nếu bạn có thể liệt kê các giả định của mình về từng vấn đề một và loại bỏ từng vấn đề, cuối cùng bạn sẽ gặp phải giả định sai lầm và kết quả là các khả năng mới cho một giải pháp sẽ mở ra.

(Nhân tiện, đây cũng là cách tiếp cận tốt nhất khi bạn không thể thấy câu trả lời cho vấn đề bạn gặp phải trong một cuộc phỏng vấn xin việc. Hãy liệt kê một cách chính xác các giả định của bạn và xác định xem cái nào sai và sau đó tấn công lại vấn đề. tất cả các "câu hỏi mẹo" đều dựa trên các giả định tự nhiên nhưng có lỗi).

Yêu cầu giúp đỡ thực sự là câu trả lời tốt nhất, nhưng đây là một chút có thể hữu ích.

Vì vậy, đối với những người đã ở trong ngành trong thời gian dài hơn, điều gì sẽ xảy ra nếu bạn được yêu cầu giải quyết một vấn đề mà bạn không thể? Nó đã xảy ra, và nếu vậy, chuyện gì đã xảy ra? Có phải họ vừa thả nó xuống và nói "Ồ tốt, đoán chúng ta có thể làm gì với thứ khác"? Có hậu quả không? Bạn có bị khiển trách, hoặc thậm chí bị sa thải?

Vâng, nó đã xảy ra với tôi, và không, tôi không bao giờ bị khiển trách hay sa thải vì nó, bởi vì ...

Trong công nghiệp, tất cả là về việc bạn có giải quyết vấn đề đúng hạn và trong ngân sách hay không, và các nhà quản lý đàng hoàng hiểu rằng điều đó không phải lúc nào cũng có thể.

Điều thực sự xảy ra là người quản lý của bạn nói, "Tôi muốn bạn làm X, bạn nghĩ nó sẽ mất gì?" Và bạn có thể đưa ra rất nhiều câu trả lời. Những cái tốt bao gồm:

• Tôi đã làm một cái gì đó thực sự tương tự như thế này, vì vậy tôi nghĩ rằng sẽ mất ba tuần và phần cứng trị giá $ 3.000.
• Tôi có một cái gì đó tương tự như thế này. Vì vậy, hãy để tôi suy nghĩ về nó và lấy lại cho bạn chiều nay.
• Tôi chưa bao giờ làm bất cứ điều gì như thế này. Vì vậy, hãy để tôi nghiên cứu nó và lấy lại cho bạn vào ngày mai.
• Không ai trên hành tinh này đã từng làm điều này. Nếu bạn muốn xem xét nó, tôi sẽ mất hai tuần để thực hiện đủ thử nghiệm để đưa ra ước tính.

Đó là công việc của người quản lý để quyết định xem có nên tiến hành hay không. Nếu họ chọn tiến hành, công việc của bạn là đáp ứng ước tính của bạn hoặc cho người quản lý biết nếu có trở ngại. Miễn là bạn làm điều đó, trong một công ty hợp lý sẽ không có hậu quả tiêu cực.

Tất nhiên, cũng có những công ty không hợp lý không cung cấp cho bạn thời gian hoặc nguồn lực để hoàn thành công việc của bạn. Tôi đã từng làm việc tại một số trong số đó và mọi người đều gặp phải những vấn đề không thể giải quyết được trong những hạn chế của công ty. Một trong số họ đã sa thải khoảng 98% nhân viên lập trình trong vòng 8 tháng, và đó chắc chắn là hậu quả, nhưng đó không phải là cá nhân tôi và tôi vẫn coi sếp và sếp của mình là bạn tốt.

Có rất nhiều loại vấn đề khác nhau mà bạn sẽ gặp phải, và nhiều cách có cách khác nhau để xử lý chúng.

Một loại vấn đề là triển khai thứ gì đó bạn chưa từng thấy trước đây như API âm thanh lạ hoặc thứ gì đó. Trong trường hợp này tôi sẽ hỏi về SO, nghiêm túc.

Một vấn đề khác là rất lớn để giải quyết. Loại vấn đề này có thể được tiếp cận lặp đi lặp lại. Họ nói với bạn "Thực hiện Humongous". Bạn nhìn nó và viết nhiều bước như bạn có thể tìm ra. Sau đó, bạn chia các bước phức tạp thành các bước nhỏ hơn. Khi bạn buộc phải suy nghĩ về các bước nhỏ hơn, chúng trở nên rõ ràng hơn. Nếu bạn gặp một khó khăn kỹ thuật, hãy thử thực hiện kiểm tra và hỏi ở đây nếu cần thiết.

Một trong những vấn đề khó chịu hơn là các yêu cầu được chỉ định kém. Họ chỉ muốn một thứ "x" và không cho bạn biết nên làm thế nào. Đối với những cách tiếp cận tốt này là nguyên mẫu một giao diện (thường là GUI) và cho phép ai đó chơi với nó.

Sau đó, có những hạn chế về thời gian không thể được đáp ứng. Điều này thường liên quan đến việc sửa đổi kỳ vọng và cung cấp các nguyên mẫu chức năng.

Bạn thường sẽ tìm thấy con đường của bạn thông qua mọi thứ bằng cách này hay cách khác. Điều đó thật đáng sợ nhưng một khi bạn đã ở trong đó, bạn có thể tìm thấy mọi thứ.

Đặt cược tốt nhất của bạn có thể là chỉ vẽ dòng chữ "Đừng hoảng sợ" ở bên ngoài máy tính xách tay của bạn. Và đừng quên khăn của bạn.

Trình tự giải quyết vấn đề của tôi (mọi spet tiếp theo chỉ được thực hiện nếu lần trước không hoạt động):

1. Cố gắng lên google
2. Hỏi ai đó
3. Tìm kiếm SO trực tiếp (bỏ qua Google)
4. Suy nghĩ
5. Khói (== đầu rõ ràng)
6. Đặt câu hỏi về SO
7. Đợi đến sáng (== rõ ràng hơn nữa)
8. Sử dụng bản hack bẩn đó và cảm thấy tồi tệ về bản thân :(

Các vấn đề khó chịu được giải quyết ở các bước 5-6.

Các vấn đề thực sự rất tồi tệ thường cần một chút thời gian (bước 7 là giải pháp cho hầu hết các vấn đề 'dường như-tôi-không thể làm được'). Và ý tôi là - chuyển sang một nhiệm vụ khác trong phần còn lại của ngày và cố gắng giải quyết vấn đề đầu tiên vào buổi sáng. Điều đó thật tuyệt vời.

Và chỉ sau đó đến bước 8.

Tôi chưa nghe thấy bất cứ điều gì xảy ra như thế này. Trước hết bạn không bao giờ được đưa ra một vấn đề mà không thể giải quyết được. Vấn đề có thể khó khăn và có thể mất thời gian để giải quyết. Khi đưa ra một vấn đề, bạn sẽ phải nói đây là thời gian tôi sẽ yêu cầu. Nếu trong nghiên cứu của bạn, bạn nghĩ rằng vấn đề này thực sự không thể giải quyết được, bạn phải giương cờ và nói với người quản lý của mình rằng vấn đề này sẽ mất thêm thời gian hoặc thực sự khó giải quyết. Đó là tất cả về lịch trình. Nếu bạn hứa điều gì đó và sẽ không thể cung cấp thì đó là vấn đề. Nhưng nếu bạn tiếp tục nói về tình trạng và mối quan tâm của mình, trách nhiệm của người quản lý là phải chăm sóc nó. Anh ấy nên chuyển hướng bạn đến người thích hợp có thể giúp đỡ, hoặc điều chỉnh lịch trình.

Có một số lời khuyên tuyệt vời ở đây! Giá trị hai xu của tôi là; Đừng bị choáng ngợp bởi vấn đề LỚN, đừng quên rằng phần thú vị và đầy thách thức của việc giải quyết vấn đề đang chia nhỏ nó thành một loạt các vấn đề phụ dễ hiểu và quan trọng hơn, lần lượt phá vỡ hết lần này đến lần khác vấn đề phụ. Bất kỳ lập trình viên giỏi nào cũng thường làm điều này trên cơ sở từng phút trong khi họ đang tạo mã (sử dụng hàm, phương thức, thói quen phụ, v.v ... để giúp giảm độ phức tạp chung của một phần mã) và phương pháp này thường áp dụng cho bất kỳ vấn đề LỚN nào bạn đối mặt trong cuộc sống (không chỉ trong công việc).

Nó phụ thuộc vào vấn đề cụ thể là gì, rõ ràng. Nhưng câu trả lời có thể là bất kỳ:

1. Tìm một cách giải quyết / thay thế
2. Mua một giải pháp thương mại gần đúng với những gì bạn muốn
3. Đừng từ bỏ và tiếp tục làm việc với nó miễn là bạn cần cho đến khi bạn thành công .

Số 3 có thể yêu cầu thời gian giải quyết vấn đề và xem xét lại vài tuần hoặc vài tháng sau đó. Điều đó thường giúp.

Theo kinh nghiệm của tôi, đôi khi có vấn đề mà bạn không thể giải quyết, ít nhất là trong giới hạn thời gian. Vì vậy, tìm kiếm sự giúp đỡ càng sớm càng tốt, sau một số nỗ lực giải quyết thất bại bạn .

Hãy nhớ quy tắc của ngón tay cái: luôn luôn nhìn vào lý do sếp thuê bạn. Làm bất cứ điều gì bạn nghĩ rằng bạn có thể làm để có kết quả công việc tốt nhất và đôi khi đó là một báo cáo thất bại sớm (tốt hơn nhiều so với báo cáo muộn).

Nói tóm lại, nếu bạn nghĩ rằng bạn có thể tìm ra giải pháp, hãy thử, nhưng hãy đưa ra ước tính của sếp về rủi ro và chi phí thời gian. Bây giờ là vấn đề của họ.

Nếu các dự án trăm triệu đô la có thể thất bại ngay cả với những người có kinh nghiệm, bạn không nên lo lắng về việc bạn thất bại vì bạn vẫn còn là một sinh viên. Tôi đã có một vấn đề cần giải quyết và tôi thấy rằng nếu đó là vấn đề bạn gặp khó khăn - bạn phải ghi lại mọi nỗ lực bạn đã thực hiện để giải quyết nó.

Những sự giúp đỡ đó:

1. Bằng chứng về những nỗ lực được thực hiện để giải quyết một vấn đề.
2. Ghi lại loại thất bại này rất quan trọng để bạn học hỏi từ nó và đừng làm điều đó một vài ngày sau đó nghĩ rằng nó sẽ hoạt động.

Kinh nghiệm của tôi là một sinh viên mới tốt nghiệp không bị ném xuống vực sâu. Thay vào đó, bạn có thể sẽ là một phần của một nhóm cũng bao gồm các nhà phát triển có kinh nghiệm.

Lời khuyên của tôi sẽ là: sử dụng chúng. Khi bạn không chắc chắn làm thế nào để giải quyết vấn đề, hoặc nếu bạn muốn biết liệu giải pháp của bạn có đi đúng hướng hay không, hãy thảo luận vấn đề này với họ. Và nếu bạn cảm thấy mình bị mắc kẹt ở đâu đó, hãy tóm lấy một trong những người có kinh nghiệm và giải thích vấn đề của bạn và yêu cầu giúp đỡ.

Thông thường, chỉ cần giải thích vấn đề của bạn sẽ tiết lộ một giải pháp và giải thích giải pháp của bạn cũng có thể tiết lộ những sai sót trong đó.

Thường thì điều này xảy ra vì bạn chưa xác định đúng vấn đề và chính xác. Có lẽ bạn đang cố gắng giải quyết một giải pháp định sẵn thay vì chính vấn đề thực tế.

Vấn đề chỉ là những gì bạn quan sát, không phải những gì bạn tưởng tượng.

"Chiếc xe đẫm máu của tôi sẽ không khởi động" là một vấn đề. "Pin yếu." là một giải pháp định sẵn cho vấn đề khởi động xe. Ngay cả việc kiểm tra pin cũng không chứng minh được đó là nguyên nhân duy nhất của vấn đề. Trừ khi bạn đã thực sự sạc hoặc thay pin và khởi động xe thành công thì bạn không có bằng chứng nào cho thấy pin là nguyên nhân của vấn đề.

Đơn giản hóa và tiếp tục đơn giản hóa. Chia nó thành các phần nhỏ. Nếu bạn không thể giải quyết những phần đó, hãy đập vỡ chúng. Bạn sẽ cảm thấy tốt hơn. Sau đó chia nó thành các phần nhỏ khác nhau. Mỗi một trong những phần đó phải là hiện tượng quan sát được.