Về chúng tôi

Chúng tôi là Media Max Japan (Việt Nam), 1 công ty phát triển sản phẩm phần mềm. Chúng tôi sẽ chia sẻ một series bài viết về việc làm thế nào để trở thành Developer giàu kinh nghiệm (Senior Developers) có tư duy đúng. Chúng tôi thực sự mong muốn được làm việc cùng những Developers như thế này. Hiện tại, MMJ (Việt Nam) đang open vị trí Front End Developers. Hãy gửi CV vào địa chỉ hr@mmj.vn nếu bạn quan tâm nhé.

Giới thiệu

Chúng ta làm việc trong ngành phần mềm (software industry) và hàng ngày, tạo ra các phần mềm mới. Không giống như các công việc chân tay, công nghiệp phần mềm yêu cầu chúng ta cần phải dành rất nhiều thời gian để suy nghĩ. Có thể nói bạn đã dành nhiều ngày, nhiều giờ để suy nghĩ, và vì thế, đã khi nào bạn nghĩ mình có thể là một "Chuyên gia suy nghĩ" chưa? Nếu có 1 người giới thiệu họ là Vận động viên bơi lội chuyên nghiệp, khi đó chúng ta sẽ tự động hiểu rằng người đó biết cách bơi và có thể dạy bạn bơi. Đối với một Chuyên gia suy nghĩ hay một người giỏi tư duy, bạn có biết thế nào là cách nghĩ đúng và có thể chỉ cho mọi người làm thế nào để nghĩ cho hiệu quả không?

Nếu câu hỏi trên vẫn khá là rộng, bạn có thể thử trả lời 3 câu hỏi dưới đây:

1. Mục đích của suy nghĩ này là gì?
2. Thông tin đầu vào để suy nghĩ là gì, kết quả mong muốn của quá trình suy nghĩ này là gì?
3. Làm sao mình tự biết được suy nghĩ này đã rõ ràng, rành mạch hay chưa?

Trước khi đọc tiếp, bạn có thể thử tự trả lời 3 câu hỏi trên xem sao.

Tôi đã có những câu hỏi về cách suy nghĩ, cách tư duy khi tôi bắt đầu làm việc với vị trí Software Developer. Tôi đã nghĩ rất nhiều về việc làm thế nào để mình có thể tăng được hiệu quả của bản thân, và tôi biết được rằng việc tăng chất lượng của quá trình suy nghĩ sẽ có hiệu quả đáng kể bởi vì tôi dành rất nhiều thời gian để nghĩ. Sau đó tôi đã rất bất ngờ khi tôi không thể tự trả lời 3 câu hỏi bên trên. Tôi đã thật sự shocked. Không có ai chỉ cho tôi về việc nghĩ hiệu quả cả. Tôi cũng chẳng bao giờ tự đặt câu hỏi cho bản thân. Vậy làm thể nào để tôi có thể tự tin tư duy khi tôi không thể trả lời các câu hỏi?

Sau 1 thời gian suy nghĩ, tôi cũng tìm ra được câu trả lời hài lòng. Kể từ khi đó, tôi cảm thấy quá trình tư duy của mình thực sự rõ ràng hơn trước rất nhiều, đặc biệt đối với các tình huống tôi phải đối diện với những vấn đề không rõ ràng hay thậm chí những vấn đề không xác định. Đây chính là Khám phá có ích nhất trong cuộc đời tôi Có thể điều này khá là hiển nhiên với nhiều người, tuy nhiên, tôi cũng rất mong muốn được chia sẻ lại cho các bạn.

"SUY NGHĨ" là gì?

Theo định nghĩa của tôi về "suy nghĩ", quá trình suy nghĩ bao gồm 3 bước:

1. Bắt đầu đặt 1 câu hỏi về sự việc
2. Chia nhỏ câu hỏi trên ra thành nhiều câu hỏi nhỏ hơn, rõ hơn
3. Tiếp tục bước 2 cho đến khi bạn có câu trả lời cho câu hỏi nhỏ đó.

Để tôi giải thích rõ hơn. Bất kỳ khi nào bạn suy nghĩ, bạn đều đã có 1 câu hỏi trong đầu. Luôn luôn là như vậy. Ví dụ:

• Nghĩ xem bạn nên đặt class này vào thư mục nào?
• Nghĩ xem Bug nào mình nên fix đầu tiên?
• Nghĩ về trưa nay mình nên ăn gì nhỉ?

Như bạn thấy, "Nghĩ" luôn đi kèm với câu hỏi. Tuy nhiên, trong rất nhiều trường hợp, chúng ta "nghĩ" mà không có câu hỏi rõ ràng trong đầu. Chúng ta cùng xem cuộc hội thoại dưới đây giữa leader và team member nhé:

Hội thoại 1:

• Leader - Tiến độ công việc tìm kiếm Database phù hợp của cậu đến đâu rồi?
• Staff - Dạ em vẫn đang nghĩ.
• Leader - Ok, cậu đang nghĩ như thế nào, cụ thể hơn xem nào?
• Staff - Hiện tại em vẫn đang tiến hành nghiên cứu ạ.
• Leader - Nghiên cứu về vấn đề gì?
• Staff - Về việc làm sao có được dữ liệu tốt nhất cho dự án ạ.

Từ cuộc nói chuyện ngắn trên, có thể thấy rằng bạn nhân viên suy nghĩ khá mông lung. Những gì bạn nhân viên nói chỉ là nhắc lại câu hỏi của sếp, không có thông tin gì cụ thể về việc tại sao công việc bị chậm trễ, gặp khó khăn hay sếp có thể giúp đỡ được gì.

Hội thoại 2:

• Leader - Tiến độ công việc tìm kiếm Database phù hợp của em đến đâu rồi?
• Staff - Em vẫn chưa tìm ra cách. DB workload của chúng ta bao gồm 90% insert và 10% read. Vì thế, chúng ta cần tìm DB nào mà có hiệu suất insert cao.
• Leader - Ừ, đúng vậy.
• Staff - Nên em tìm ra được 2 Databases: Cassandra và MongoDB. Nhưng em không biết làm sao để so sánh 2 loại này. Theo như tài liệu, cả 2 loại này đều rất nhanh.
• Leader - Ok, kiến trúc của 2 loại này hoàn toàn khác nhau. Anh có thể có 1 buổi chia sẻ nhanh về sự khác nhau này với cậu. Đừng tin hoàn toàn vào tài liệu của các nhà phát hành, đôi khi họ marketing hóa nó lên.

Rõ ràng trong cuộc nói chuyện thứ 2 này có nhiều thông tin chất lượng hơn. Bạn nhân viên này cũng đã suy nghĩ về vấn đề rõ ràng hơn bạn đầu tiên. Câu hỏi đầu tiên của bạn ý là "Điều kiện để tìm Database phù hợp trong trường hợp này là gì?". Và trả lời được là "90% insert và 10% read". Sau đó, bạn ý tìm được 2 lựa chọn có thể phù hợp và bạn ý biết được rằng cần phải tìm hiểu sự khác nhau giữa 2 loại database này.

Bạn dev thứ nhất có thể chưa có câu hỏi cụ thể nào trong đầu. Có thể bạn ý đã tiếp cận bằng cách tìm hiểu ngẫu nhiên "good database", "fast database" và dành nhiều thời gian đọc những tài liệu, thông tin không liên quan.

Vì thế, việc suy nghĩ hiệu quả đến từ việc đặt câu hỏi đúng. Bạn đầu tiên bắt đầu giải quyết vấn đề với không có câu hỏi cụ thể nào trong đầu. Bạn thứ 2 thay vào đó, tự đặt các câu hỏi cho mình và tìm câu trả lời theo đó. Nói 1 cách khác, bạn đầu tiên có con dao trong tay và tìm xem mình cắt được cái gì. Bạn thứ 2 biết mình phải cắt thứ gì và tìm con dao phù hợp. Những người thông minh luôn bắt đầu với câu hỏi. Những người kém cỏi luôn bắt đầu sự việc bằng cách đi tìm câu trả lời. Và rõ ràng là giải pháp mà không dành cho câu hỏi nào thì là giải pháp vô dụng.

Vì vậy, khi bạn muốn suy nghĩ về 1 vấn đề nào đó 1 cách rõ ràng, điều đầu tiên bạn cần phải làm là đặt những câu hỏi rõ ràng. Đặc biệt là, khi bạn bắt đầu với những câu hỏi đúng, bạn sẽ dễ dàng tìm ra câu trả lời cho vấn đề cần giải quyết. Vì thế, việc đật câu hỏi đúng luôn là việc quan trọng nhất trong quá trình suy nghĩ. Khi có câu hỏi đúng rồi, hầu như ai cũng có thể tìm ra câu trả lời. Kỹ năng đặt câu hỏi cũng là kỹ năng quan trọng nhất. Nếu bạn có thể đặt các câu hỏi đúng trong mọi tình huống, bạn có thể suy nghĩ nhanh hơn và chính xác hơn. Nếu không, hầu hết các suy nghĩ của bạn sẽ là ngẫu nhiên và phụ thuộc vào may mắn.

Vì thế, tôi xin nhắc lại, quá trình suy nghĩ hiệu quả như sau:

1. Bắt đầu đặt 1 câu hỏi về sự việc
2. Chia nhỏ câu hỏi trên ra thành nhiều câu hỏi nhỏ hơn, rõ hơn
3. Tiếp tục bước 2 cho đến khi bạn có câu trả lời cho câu hỏi nhỏ đó.

Ở trường, chúng ta được học về cách giải quyết vấn đề, chứ không phải cách tìm ra vấn đề. Trong các trường học ở Nhật, giáo viên thường nêu lên các vấn đề, các bài toán và học sinh là người đưa ra câu trả lời. Nếu học sinh không biết đáp án, bạn đó là học sinh kém. Bạn nào giải quyết được càng nhiều vấn đề, bạn đó được đánh giá là học sinh giỏi. Tôi nghĩ giáo dục ở Việt Nam cũng tương tự vậy. Chúng ta đều quá quen thuộc với vấn đề này đến nỗi coi đó là hiển nhiên. Tuy nhiên, thực tế là những gì chúng ta gặp ở trường đời lại khác hẳn những gì chúng ta học ở trường. Trong cuộc sống, vấn đề thường không rõ ràng và chẳng ai đưa vào tận tay mình cả.

Những vấn đề ở trường sẽ là:

• Rất rõ ràng
• Đã có cách giải
• Chỉ có 1 đáp án.

Còn những vấn đề thực tế của cuộc sống sẽ như sau:

• Đó là những vấn đề rất mơ hồ như "chúng ta nên sử dụng cơ sở dữ liệu nào?".
• Chưa ai có câu trả lời rõ ràng cho các vấn đề này cả. Bạn không thể tìm thấy trên Google.
• Có thể vấn đề này không có câu trả lời, hoặc có rất nhiều đáp án khả thi. Bạn phải lựa chọn lấy phương án phù hợp nhất.
• Khi chúng ta phải lựa chọn 1 phương án trong rất nhiều phương án được đưa ra, phương án phù hợp nhất sẽ là phương án cân bằng được các yếu tố quan trọng cần thiết (hiệu suất, bảo mật, năng suất, khả năng phát triển, tính ổn định...) tùy thuộc vào từng trường hợp cụ thể.

Vì thế, công việc khó, mang lại giá trị cho bạn, được trả nhiều tiền đó là việc tìm ra đâu là vấn đề. Còn việc giải quyết vấn đề (kỹ năng codes, kiến thức về các phần mềm...) là việc rất nhiều người có thể học và làm được, sẽ không khẳng định giá trị của bạn.

Xác định đúng vấn đề

Dưới đây là 1 vài ví dụ về những vấn đề không rõ ràng:

• Database Software/ Application Framework nào mình nên sử dụng?
• Làm thế nào để chúng ta tăng được hiệu quả?
• Công nghệ nào mình nên học bây giờ? Mình nên dành bao nhiêu thời gian cho nó?

Rõ ràng những vấn đề trên khác hẳn với những bài toán được giải trong trường. Và thường đều là những câu không dễ trả lời, bởi vì:

• Câu hỏi quá rộng
• Câu hỏi quá chung chung
• Câu hỏi cũng có thể chưa đúng. Vì thế, trước khi bắt đầu trả lời câu hỏi, bạn cần đặt câu hỏi tốt đã. Điều này có nghĩa bạn sẽ chia nhỏ câu hỏi lớn thành nhiều câu hỏi nhỏ, chi tiết hơn, và từng câu hỏi đều rất rõ ràng. Bên cạnh đó, bạn cũng cần hiểu được đúng tình huống của mình và có những dữ liệu chính xác.

Vậy các bước để Xác định, tìm ra đúng vấn đề là:

Bước 1: Viết ra giấy

Bước đầu tiên và rất rất quan trọng là bạn cần viết câu hỏi đầu tiên, nảy ra trong đầu bạn ra giấy. Có thể bạn thấy không cần làm thế khi mình đã có câu hỏi rất rõ ràng trong đầu, nhưng, thực tế, đây là bước vô cùng quan trọng. Một trong những lý do vì thực ra bộ não của chúng ta không đáng tin cậy (hay dễ bị tổn hại). Mỗi lần bạn đọc hay viết, bạn đều có 1 vài sai sót nhưng bộ não không nhận ra. Hoặc bạn có thể tưởng tượng bộ não của bạn như 1 chiếc ổ cứng SSD bị lỗi nhưng vờ như hoạt động bình thường. Nếu bạn có 1 chiếc SSD bị lỗi, bạn sẽ không bao giờ lưu giữ liệu vào đó phải không nào? Vì vậy, đừng bao giờ lưu bất kỳ thông tin nào trong đầu, mà hãy viết ra.

Điều này thực sự đúng với việc bạn nhớ những câu chữ ở trong đầu. Não của chúng ta không thiết kế để lưu thông tin dạng văn bản, chữ viết. Câu hỏi là một dạng văn bản. Vì vậy, bạn cần phải viết câu hỏi ra giấy.

Bước 2: Xác định rõ 5W1H

Khi bạn viết câu hỏi đầu tiên ra giấy, hãy kiểm tra xem đó có phải dạng câu hỏi 5W1H không (Why - tại sao, What - điều gì, When - khi nào, Who - ai, Where - ở đâu và How - thế nào). Ví dụ: Câu hỏi đầu tiên: "Mình có làm được 1 sản phẩm tuyệt vời không?" Thì bạn có thể chia thành các câu hỏi nhỏ như:

• Tại sao mình muốn làm sản phẩm này? Vì sẽ kiếm được thật nhiều tiền? Vì mình thực sự đam mê?
• Khi nào thì mình muốn bắt đầu?
• Ai sẽ là người làm? Mình hay ai khác?

Bước 3: Có định nghĩa rõ ràng

Bước tiếp theo là xác định rõ định nghĩa cho từng từ trong câu hỏi của bạn. Ví dụ: Câu hỏi: "Database nào tốt nhất cho dự án?" - Vậy bạn cần hiểu "Như thế nào là Tốt Nhất?" Trong trường hợp này, có lẽ bạn cần lựa chọn 1 vài yếu tố quan trọng như: performance, scalability, maintainability, durability, security, linh hoạt data, phát triển dễ dàng... Câu trả lời thì tùy vào từng trường hợp cụ thể. Nếu bạn làm trong dịch vụ tài chính với hàng triệu người dùng, có thể performance, scalability và security là 3 điều quan trọng nhất. Nếu bạn phát triển 1 ứng dụng vẽ cho lượng nhỏ người dùng, thì linh hoạt data và dễ dàng phát triển có thể sẽ là những điều bạn cần lưu ý nhất. Vì thế, hiểu được việc mình làm một cách tổng thể và rõ ràng cũng là điều rất quan trọng. Bạn có thể tiếp tục dùng 5W1H cho bước này:

• Tốt nhất cho ai? Người dùng? Khách hàng? Sếp? hay tất cả?
• Tại sao lại là tốt nhất? Tiết kiệm tiền? Tiết kiệm thời gian? Vui vẻ?

Bằng cách này, bạn có thể tiếp tục hỏi các câu hỏi chi tiết hơn:

• Tìm Database với high performance và khả năng scalable?
• Tìm Database với tính bảo mật.

Bạn có thể tiếp tục đặt câu hỏi, thế nào là "high performance" và thế nào là "scalable"? Sau 1 vài phép tính, bạn có thể có những câu hỏi như:

• Liệu hệ thống có thể xử lý được 10,000 write/ second và 100,000 read/ second không?
• Chúng ta có thể dễ dàng thêm Cluster Node mới mà không có thời gian chết không?

Bạn cần lặp đi lặp lại bước này cho đến khi câu hỏi của bạn thật sự rõ ràng với mọi từ ngữ.

Bước 4: Trả lời

Khi bạn đã có những câu hỏi đủ chi tiết và rõ ràng, sẽ không quá khó để tìm ra câu trả lời. Nếu câu hỏi là "liệu chúng ta có xử lý được 10,000 write/ second không?", bạn có thể tìm câu trả lời trên 1 vài tài liệu hoặc bạn có thể chạy thử nghiệm luôn.

Khi có câu trả lời cho tất cả các câu hỏi (chi tiết) của bạn, thì bây giờ bạn đã có cái nhìn thật sự rõ ràng về vấn đề ban đầu. Và dự trên đó, bạn có thể lựa chọn phương án tốt hơn (hoặc tốt nhất).

Một bước nữa: Hỏi các câu hỏi xác minh

Trong 1 số trường hợp, bạn có câu hỏi đầu tiên không đúng. Để tránh gặp phải lỗi này, bạn nên đặt càng nhiều câu hỏi xác minh càng tốt.

• Liệu điều này có khả thi không? Sẽ cần bao nhiêu thời gian để thực hiện?
• Liệu có đúng không? Có căn cứ rõ ràng không?
• Nếu đó là dễ dàng, vì sao ít người làm thế?
• Liệu chúng ta có thực sự cần giải quyết vấn đề này không? Nếu chúng ta không giải quyết thì ảnh hưởng sẽ như thế nào?
• Trường hợp xấu nhất là gì?

Case study: Đánh giá 1 phần mềm

Nghĩ về tình huống bạn cần đánh giá 1 phần mềm để team quyết định xem có nên sử dụng nó cho dự án sắp tới hay không?

Khi không có câu hỏi rõ ràng:

• Hmm, tôi không biết nên bắt đầu từ đâu. Hãy thử cài phần mềm này xem nào.
• Oh nó chạy rồi này. Thử 1 vài sample code xem sao.
• Tôi cảm thấy nó khá là nhanh, và dễ dàng. Có vẻ tốt đấy.
• Tôi xem phần documents. Nhiều phết. Tôi chỉ đọc vài trang 1 cách ngẫu nhiên. Tôi nghĩ chúng ta có thể giải quyết bất kỳ vấn đề gì từ chỗ tài liệu này.
• Hmm, tôi không biết phải làm gì tiếp theo. Có lẽ thời gian nghiên cứu như vậy là đủ rồi.
• Từ nghiên cứu của tôi, tôi thấy đây là phần mềm khá tốt. Tôi còn thấy rằng nó đang rất là hot. Tôi nghĩ rằng nó phù hợp với dự án sắp tới của chúng ta.

Bạn có thể thấy cách làm trên khá là ngẫu nhiên, kết quả phụ thuộc vào may mắn, không đáng tin cậy và chuyên nghiệp chút nào.

Nhưng khi bạn dành thời gian đặt các câu hỏi rõ ràng:

• Đầu tiên hãy xác định đâu là những yếu tố quan trọng nhất. Đó chắc chắn là scalability và durability của phần mềm đó.
• Để hiểu được tính scalability của phần mềm, chúng ta cần hiểu rõ về thiết kế của nó. Vì thế, hãy đọc kỹ phần thiết kế trong tài liệu nào. Chúng ta có thể kiểm tra trên github xem phần mềm này có lỗi gì nghiêm trọng liên quan đến khả năng scalability không?
• Để biết được về durability của phần mềm, chúng ta có thể xây dựng một cluster và tiến hành thử nghiệm để kiểm tra durability thực tế như là tắt nguồn cluster khi đang chạy;
• Có vẻ như phần mềm này đáp ứng được 1 trong 2 yêu cầu trên. Vậy hãy thử xem độ phù hợp của nó với các yêu cầu khác xem sao, như là: performance, backup, replication mà phần lớn các database đều cần.
• Chúng ta đã tìm hiểu xong. Bước tiếp theo là bàn với team về 2 rủi ro mà chúng ta tìm thấy.

Cách suy nghĩ từng bước thế này thực tế còn rất tốt cho sự phát triển của bạn.

Mối quan hệ giữa sự thông minh và các câu hỏi

Như các bạn thấy trên các ví dụ trên, nếu bạn luôn có các câu hỏi rõ ràng, việc tìm thông tin sẽ chính xác hơn và những kiến thức của bạn cũng rất hữu ích và thực tế. Bạn sẽ rất tự tin giải thích với mọi người về phương án lựa chọn của mình. Nhưng nếu bạn không có câu hỏi rõ ràng trong quá trình tìm kiếm giải pháp, bạn sẽ chỉ có sự hiểu biết mơ hồ, bề mặt. Câu trả lời của bạn khi được hỏi sẽ là: "Vì nó chạy khá mượt". Thành thật mà nói, những người thông minh thì hay đặt rất nhiều câu hỏi, trong khi những người kém thì lại không hay hỏi gì. Những người thông minh là do họ rất hay hỏi và những người ít kiến thức lại thường rất ít hỏi. Và vì hỏi nhiều nên những người giỏi học rất nhanh và có những kiến thức thực tiễn. Nói 1 cách khác, bạn càng có nhiều câu hỏi, bạn càng nhìn mọi việc một cách sâu sắc và hiểu biết hơn. Còn nếu bạn thường thờ ơ và không mấy khi thắc mắc, trí tuệ và bộ não của bạn sẽ khó phát triển được.

Những thói quen xấu

Đến đoạn này, có lẽ chúng ta đã hiểu được rằng "suy nghĩ đúng" sẽ như thế nào. Để hiểu thêm, tôi muốn đưa thêm 1 vài ví dụ về thói quen xấu làm ảnh hướng đến cách tư duy mà ít nhiều chúng ta đang mắc phải.

Thói quen xấu 1: Suy nghĩ về giải pháp trước khi đề cập đến vấn đề

Như tôi đã nói ở phần đầu, giải pháp mà không cho vấn đề cụ thể thường vô nghĩa. Theo kinh nghiệm cá nhân của tôi, có đến 98% mọi người thích nói về giải pháp trước vấn đề. Trong buổi họp, thỉnh thoảng, mọi người hay nói: "Chúng ta nên làm thế này, thế kia.". Những lúc như thế, tôi thường hỏi "Để làm gì?", kể cả khi tôi biết đó là đề xuất để cải thiện sản phẩm. Thời gian và nguồn lực của chúng ta có hạn. Vì thế, để lựa chọn vấn đề nào cần giải quyết, chúng ta phải xác định được đâu là vấn đề quan trọng nhất và tìm giải pháp hợp lý nhất cho vấn đề đó. Nhưng thường thì mọi người hay đưa ra những giải pháp ngẫu nhiên cho những vấn đề ngẫu nhiên. Nếu chúng ta làm như vậy, chúng ta sẽ không hiệu quả và dành thời gian vào những việc không cần thiết.

Tôi hiểu rằng chúng ta rất thích nói về cách giải quyết vấn đề bởi vì nói về giải pháp thì thường dễ hơn và vui hơn. Nhưng bạn cần phải hiểu rằng giải pháp cho những vấn đề không xác định thường không có giá trị cao.

Thói quen xấu 2: Thảo luận khi không có câu hỏi chung

Tương tự như thói quen xấu thứ nhất, khi một nhóm người ngồi thảo luận về 1 vấn đề, việc đầu tiên là chúng ta nên viết vấn đề lên trên bảng để mọi người đều biết vấn đề chúng ta cần giải quyết là gì. Một khi đã xác định được câu hỏi, mọi thảo luận sẽ cần tập trung cho câu hỏi đó.

Một buổi họp không hiệu quả sẽ như thế này: Người phụ trách hỏi: "Ý kiến của các bạn thế nào?" mà không đề cập đến vấn đề cần trao đổi là gì. Sau đó mọi người bắt đầu đưa ra những ý kiến cá nhân mà không liên quan gì đến chủ đề chính. Đây thường là những buổi họp kéo dài nhưng lại không có kết luận hữu ích nào được đưa ra. Mọi người nói về bất kỳ điều gì đang xảy ra và buổi họp kết thúc khi mọi người không còn gì để nói nữa, chứ không phải vì cả nhóm đã có 1 kết luận cụ thể. Hoàn toàn không hiệu quả phải không nào?

Thói quen xấu 3: Lo lắng mà không có câu hỏi

Khi chúng ta gặp phải những khó khăn trong công việc cũng như cuộc sống, một số người thường chỉ mãi lo lắng và suy nghĩ về những vấn đề đó, không tháo gỡ được cả tháng hay cả năm trời. Họ vắt óc suy nghĩ, buồn chán và luôn hỏi một câu "tôi nên làm gì bây giờ?" mà không có 1 hành động cụ thể. Sau nhiều tháng, họ than phiền về đúng 1 chủ đề mà không có gì thay đổi hay tiến triển cả. Cuối cùng, khi phải đưa ra quyết định, họ sẽ dựa vào cảm xúc chứ không phải suy nghĩ logic.

Bạn có thấy mình cũng có lúc giống như thế không? Điều này xảy ra khi bạn không có câu hỏi rõ ràng. Bạn cần xác định được 2 vấn đề:

• Vấn đề ở đây là gì?
• Có những giải pháp nào cho việc này?

Những câu hỏi bạn có thể hỏi là:

• Vì sao mình cảm thấy không thoải mái với hoàn cảnh hiện tại? Hành động nào của ai làm mình thấy phiền lòng?
• Mong đợi của mình là gì? Mong đợi này có hợp lý không?
• Để giải quyết được tận gốc vấn đề, cần phải làm gì và ai làm điều đó?
• Mình đã nói chuyện với mọi người chưa? Hay mình hy vọng ai đó sẽ nhìn ra được vấn đề mà không cần mình phải nói ra? Hay hy vọng rằng một ngày nào đó vấn đề sẽ được giải quyết?

Đây là 1 cuộc hội thoại chúng ta thường thấy giữa mẹ và con gái đang khóc:

• Mẹ: Sao con khóc thế? Con đang buồn à?
• Con: Dạ không.
• Mẹ: Vì con đang tức giận chuyện gì à?
• Con: Vâng
• Mẹ: Điều gì làm con tức giận thế? Có phải vì con không nhận được Socola không?
• Con: Dạ không phải, bởi vì mọi người cười con.
• Me: Oh khổ thân em bé. Con muốn các bạn làm gì? Mình cùng nói chuyện với các bạn đó nhé.

Trong cuộc hội thoại này, người mẹ cố gắng giúp con gái nói ra được cảm xúc của mình. Đặc biệt, qua câu hỏi của mẹ, mẹ còn biết được thêm nhiều thông tin cụ thể:

• Con đang cảm thấy thế nào mà lại khóc?
• Ai đã làm cho con có cảm xúc đó?
• Con mong đợi điều gì?
• Con nên nói với các bạn điều gì?

Đây thường là quá trình để giúp ai đó thoát ra khỏi tâm trạng không tốt. Bạn cũng có thể áp dụng 4 câu hỏi trên khi bạn đang bị vướng mắc và cảm xúc về vấn đề nào đó.

Thói quen xấu 4: Phấn khích với giải pháp

Trong quá trình làm lập trình phần mềm, tôi đã gặp rất nhiều lập trình viên quan tâm đến giải pháp hơn là vấn đề. Các giải pháp như là dùng ngôn ngữ mới, công cụ mới, frameworks nào: React, Angular, Typescript, Rust, MongoDB, Redis... Những dev này rất thích học nhiều công nghệ khác nhau. Họ muốn dành thời gian cho công cụ, thay vì học lý thuyết hay tư duy. Họ nói rất nhiều về những công nghệ đang hot và những gì họ biết không thực sự sâu sắc và vững chắc. Đối với họ, phát triển lên có nghĩa là có thêm kiến thức và hard skills. Vì thế những gì họ biết sẽ tăng theo chiều rộng chứ không phải chiều sâu.

Cái chính là, chúng ta có rất nhiều công nghệ khác nhau trong thế giới này, để phục vụ giải quyết rất nhiều vấn đề khác nhau. Mỗi vấn đề có những giải pháp khác nhau. Vì thế, để có kiến thức tốt về công nghệ, chúng ta cần hiểu được công nghệ này được tạo ra nhằm giải quyết vấn đề gì. Khi bạn hiểu được điều đó, bạn sẽ lựa chọn được công nghệ phù hợp cho vấn đề của mình. Nếu bản thân không lựa chọn được công nghệ phù hợp, thì việc hiểu biết về nhiều công nghệ cũng không có ý nghĩa gì.

Bên cạnh đó, học công nghệ mới sẽ không giúp bạn nổi bật hơn trên thị trường bởi vì học công nghệ mới không quá khó và những kiến thức này sẽ bị lỗi thời sau vài năm. Thay vào đó, hãy dành thời gian để học lý thuyết về khoa học máy tính, thiết kế kiến trúc của từng công nghệ, điểm tốt điểm yếu của công nghệ đó, có tư duy đúng và kỷ luật.... những điều này sẽ giúp bạn trở này những lập trình viên giỏi và có giá trị. Điều bạn cần làm là xác định được đâu là vấn đề cần giải quyết. Việc giải quyết như thế nào (framework nào, database nào....) thì không khó.

Kết luận

Có thể nói quá trình suy nghĩ chính là quá trình đặt ra các câu hỏi. Một khi bạn có câu hỏi đúng, bạn sẽ tìm được câu trả lời đúng. Chúng ta nên dành thời gian để tìm ra đâu chính là vấn đề cần giải quyết. Chúng ta cũng nên đặt ra càng nhiều câu hỏi càng tốt. Kể cả khi bạn hỏi nhiều, có người nghĩ là bạn không biết gì hay thật ngốc nghếch, thì bạn cũng không cần quan tâm về điều đó.

Link bài viết gốc bằng tiếng anh: https://viblo.asia/p/do-you-know-how-to-think-yMnKMzBDZ7P