Hãy quên đi về thuật toán và mô hình — học cách giải quyết vấn đề trước tiên

Hầu hết mỗi tuần, một người bạn hoặc một người quen hỏi tôi, “Tôi muốn học lập trình; nên bắt đầu với ngôn ngữ nào?” Khoảng mỗi hai tuần, tôi nhận được một tin nhắn trên LinkedIn bắt đầu bằng, “Con trai tôi nên bắt đầu lập trình; ngôn ngữ tốt nhất cho anh ấy là gì?”

Điều này không chỉ xảy ra với những người chưa từng lập trình. Thường xuyên, tôi nhận được những tin nhắn này từ những người đã có nhiều năm kinh nghiệm lập trình.

Tôi không nói điều này để phàn nàn.

Tôi kiếm được một nửa cuộc sống bằng cách đề cập đến ưu và nhược điểm của các ngôn ngữ lập trình, framework, và mô hình AI khác nhau ở đây trên Medium. Tôi hưởng lợi lớn từ những người có những câu hỏi như vậy.

Những câu hỏi này khá hợp lý. Sau tất cả, ai cũng muốn làm việc với những công cụ tốt nhất có thể và phát triển kỹ năng phần mềm của họ một cách nhanh chóng nhất có thể.

Khi bạn quan sát rằng mỗi nhà phát triển dường như sử dụng một ngăn xếp công nghệ khác nhau, đó là lúc hoàn toàn hợp lý để tò mò về cái nào là đúng nhất.

Điều đó phụ thuộc hoàn toàn vào vấn đề cụ thể.

Không có công nghệ nào tốt hoặc xấu cả; nó chỉ phụ thuộc vào loại vấn đề bạn muốn giải quyết. Cuối cùng, lập trình chỉ đơn giản như vậy: giải quyết vấn đề bằng cách sử dụng máy tính.

Vì vậy, đối với những người muốn bắt đầu lập trình hoặc nâng cao kỹ năng trong phát triển phần mềm hoặc khoa học dữ liệu, câu hỏi không nên là, “Tôi nên sử dụng, Python hay Julia?” Câu hỏi nên là: “Làm thế nào để giải quyết vấn đề phần mềm một cách tốt hơn?”

Cách giải quyết vấn đề

Để công bằng, tôi không phải là một nhà khoa học máy tính theo nghề. Tôi là một nhà vật lý hạt nhỏ sử dụng các khái niệm từ lập trình và khoa học dữ liệu vì tôi xử lý lượng dữ liệu lớn từ các trạm va chạm hạt nhân.

Tuy nhiên, những người vật lý cũng được đánh giá cao giống như các nhà khoa học máy tính. Điều này không phải vì kiến thức về các hạt neutrino hoặc lỗ đen của họ; mà là vì khả năng giải quyết vấn đề của họ.

Abraham Lincoln được trích dẫn nói, “Hãy để tôi có sáu giờ để đốn một cây và tôi sẽ dành bốn giờ đầu để mài rìu.”

Đối với các lập trình viên và nhà khoa học dữ liệu, điều này có nghĩa là dành thời gian hiểu vấn đề và tìm giải pháp cấp cao trước khi bắt đầu viết mã. Trong cuộc phỏng vấn lập trình bình thường, dự kiến ứng viên sẽ chiếm ít hơn một nửa thời gian thực sự viết mã, và phần còn lại để hiểu vấn đề.

1. Hiểu vấn đề

Không bao giờ bỏ qua bước này!

Chìa khóa để biết bạn có hiểu vấn đề là liệu bạn có thể giải thích nó cho ai đó không quen biết với nó hay không. Hãy thử viết ra bằng tiếng Anh đơn giản hoặc ngôn ngữ mẹ đẻ của bạn; vẽ một sơ đồ nhỏ; hoặc kể cho một người bạn nghe. Nếu người bạn không hiểu bạn nói gì, bạn cần quay lại tuyên bố vấn đề.

Câu hỏi chính cần đặt ra là:

• Input là gì? Output mong muốn là gì?
  Ví dụ, input có thể là một mảng dữ liệu, và output có thể là một hồi quy tuyến tính trên dữ liệu.
• Các giả định nào đang làm nền cho vấn đề?
  Ví dụ, bạn có thể đang giả định rằng không (hoặc rất ít) lỗi đo lường trong dữ liệu của bạn.
• Tại sao vấn đề này trở nên phức tạp?
  Ví dụ, dữ liệu bạn có thể không đầy đủ hoặc bộ dữ liệu có thể quá nhỏ để đưa ra kết luận rõ ràng.

2. Phân chia vấn đề

Mọi vấn đề lớn đều bao gồm nhiều vấn đề nhỏ. Dựa trên ví dụ trước đó với hồi quy tuyến tính, bạn có thể xem xét các vấn đề con sau:

• Làm sạch dữ liệu
• Xác định các biến nào trong dữ liệu quan trọng cho hồi quy, và những biến nào có thể bị bỏ qua một cách an toàn
• Tìm kiếm công cụ phù hợp để thực hiện hồi quy (đây là nơi câu hỏi cũ về ngôn ngữ lập trình và framework xuất hiện)
• Đánh giá kết quả và kiểm tra lỗi

Phân chia vấn đề giúp bạn lập kế hoạch công việc một cách đúng đắn.

Điều này cũng động viên hơn, vì bạn sẽ đạt được các mốc nhỏ nhưng quan trọng trên đường đi. Điều này thú vị hơn nhiều so với việc ngồi trước một ngọn núi công việc và cảm giác như bạn không tiến triển.

3. Bắt đầu bằng một ví dụ

Quỉ thường ẩn trong chi tiết.

Thay vì bắt đầu với toàn bộ dự án, hãy lấy một phần nhỏ của nó. Thử nghiệm xem kế hoạch của bạn có hoạt động không, hoặc bạn có phải điều chỉnh nó vì các khó khăn không thể dự đoán được.

Điều này giúp bạn hiểu rõ hơn về những phần khó khăn. Nhiều vấn đề nghe có vẻ đơn giản, nhưng khi bạn bắt đầu xây dựng chúng, có một rào cản sau một rào cản.

Trong ví dụ của chúng ta, thay vì sử dụng tất cả các biến liên quan, bạn có thể thực hiện một hồi quy tuyến tính trên một vài biến đầu tiên. Điều này không đem lại điểm cho việc hoàn thành dự án; tuy nhiên, việc tìm ra lỗi trong kịch bản của bạn khi bạn vẫn đang xử lý một lượng dữ liệu nhỏ có thể cứu mạng.

Khi bạn đưa tất cả dữ liệu của mình vào máy, chạy nó suốt giờ đồng hồ, và sau đó quay lại nhận ra rằng kịch bản bị treo giữa chừng, bạn sẽ rất nản lòng.

Hãy tin tôi, điều này xảy ra rất nhiều lần!

Chạy các bài kiểm tra nhỏ trước, và đảm bảo rằng giải pháp của bạn hoạt động như bạn đã tưởng.

4. Thực hiện

Đây là phần quan trọng. Bây giờ bạn có thể xây dựng giải pháp cho vấn đề lớn của mình.

Đưa tất cả dữ liệu của bạn vào mã. Chạy một mô hình phức tạp. Làm bất cứ điều gì bạn muốn.

Sau ba bước trước đó, việc này nên diễn ra khá mượt mà!

Nếu có lỗi, bạn có thể cần quay lại các bước 1–3 để xem liệu bạn đã hiểu mọi thứ chưa và có bỏ sót bất kỳ lỗi nào không.

5. Phản ánh

Chỉ vì bạn đã tìm ra một giải pháp không có nghĩa là bạn đã tìm ra giải pháp tốt nhất. Đừng chạy đi và coi đó là một ngày; hãy suy nghĩ về cách bạn có thể tối ưu hóa giải pháp của mình và cách bạn có thể tiếp cận nó một cách khác biệt.

Bạn có thể muốn trao đổi với đồng nghiệp và hỏi họ cách họ sẽ giải quyết vấn đề. Phương pháp của họ có khác biệt so với của bạn không?

Bạn cũng có thể cố gắng xác định các chướng ngại lớn nhất trong giải pháp của mình, tức là các phần mất nhiều thời gian và tài nguyên nhất để thực hiện. Làm thế nào bạn có thể cải thiện chúng?

Cuối cùng, suy nghĩ về cách giải pháp của bạn có thể phát triển trong tương lai. Liệu các framework phần mềm mới hoặc việc sử dụng trí tuệ nhân tạo có thể làm cho giải pháp của bạn tốt hơn không? Giải pháp của bạn có thể đóng góp vào việc giải quyết các vấn đề khác, thậm chí là những vấn đề phức tạp hơn không?

Những lời cuối nổi tiếng

Mọi người, kể cả bản thân tôi, thường mải mê với các ngôn ngữ lập trình khác nhau và framework mới nhất có thể làm mọi thứ hiệu quả hơn 1000 lần.

Đáng giá khi tự nhắc nhở mình rằng điều này chỉ là chưa đến một nửa những gì cần thiết để trở thành một lập trình viên xuất sắc. Nửa còn lại là giải quyết vấn đề.

Bạn sẽ không có kỹ năng giải quyết vấn đề qua đêm.

Nhưng nếu bạn áp dụng những bước này, đặt câu hỏi đúng và thực hiện điều này thường xuyên, bạn đang trên đúng đường để nâng cao sự nghiệp từ tốt đến xuất sắc.

Bài viết này được đăng trên Medium ban đầu. Bạn có thể đọc nó tại đây.