Tôi gần đây hay ngồi tâm sự với ông anh có tuổi lẫn kinh nghiệm trong nghề, thông thường, theo lý thuyết học chung chung, đây là những cấp độ trải qua trong việc tiếp thu, nhận thức 1 vấn đề
1. Nhớ (Remembering) 2. Hiểu (Understanding) 3. Vận dụng (Applying) 4. Phân tích (Analyzing) 5. Đánh giá (Evaluating) 6. Sáng tạo (Creating).
Thông thường, mọi điểm được đánh giá theo mức độ, từ thấp đến cao, từ ngu đến giỏi, nghĩa là nó sẽ thể hiện ra theo kiểu hình thang hoặc hình tháp, cụ thể theo ý tưởng ở trên
Tuy nhiên trong môi trường công việc, cụ thể hơn trong việc học lập trình, ta vẫn thường đặt ra những câu hỏi kiểu như sau:
- Anh A code rất tốt, nhưng lại chém gió quá kém, nói nhiều khi chả hiểu anh đang muốn truyền đạt cái gì. - Anh B chả biết con mẹ gì cả, nhưng nói cứ như đúng rồi
Đương nhiên ở đây thì mỗi anh có một thế mạnh riêng, anh code được vẫn hay bỉ môi chê bai anh nói lắm, nhưng cơ bản là công ty rõ ràng vẫn cần cả 2 anh, chứ anh code không thôi thì công ty nó hơi tối. Mà thôi tôi không lạc đề nữa....
Câu hỏi là: Thế rốt cục anh A và anh B đang ở đâu trong các cấp độ đó, anh B có nằm ở trên anh A không?
Câu trả lời là không.
I. Lý thuyết ba cạnh về học ứng dụng trong lập trình
Để trả lời cho câu hỏi trên, và thật ra nó đã được thể hiện từ ngay tiêu đề bài, có các yếu tố như sau:
- Worker - học lập trình như một người thợ. - Teacher - học lập trình như một giáo viên. - Business man - và cuối cùng là học dưới góc độ như một doanh nhân.
Tôi gọi gọn nó là WTB.
Thế rốt cục nó là cái gì và tại sao lại phải học như thế.
Trước khi đi vào cụ thể, đại loại nó sẽ như thế này
1. Hãy làm được
Điều này thật không gì đơn giản hơn để giải thích, khuyến khích cho yếu tố này là bạn phải làm được, cho dù có đọc bao nhiêu articles, theo dõi bao nhiêu youtube video, cuối cùng hãy bắt tay vào làm một tutorial, rồi tích hợp nhiều thứ lại với nhau, copy and paste, làm dự án và đạt đến mức độ làm nó với mức độ thành thục và độ tự tin cao.
Làm cho nó chạy được và xuyên suốt là yếu tố rất quan trọng
Thông thường, rất nhiều người trong lúc đi làm đánh giá quá cao bước này , thật sự nó là một bước rất quan trọng, và cũng may mắn vì có đủ trình độ và nhận thức cũng như kỹ năng để biến mình là một người làm được việc Đương nhiên, nếu được như thế nghĩa là mới được 1 phần thôi.
2. Tìm cách truyền đạt cho người khác hiểu
“Nếu bạn không thể giải thích cho đứa trẻ 6 tuổi hiểu được, thì chính bạn cũng không hiểu gì cả”.
Cứ kiếm 1 cây đa cây đề trích dẫn thế cho chắc ăn.
Bây giờ tôi nói về clean code, bạn biết thừa rằng code mà if...else... quá nhiều, lồng 7 8 cấp, thế thì thật là khó đọc, khó chịu, khó bảo trì.
Thế tại sao nó lại thế.
Giả định rằng bạn có thể biến một function đang có, làm cho nó trông thật dễ hiểu, nhưng nó sẽ thật sự gây khó khăn cho bạn khi cần xem xét một pullrequest (PR) cho người khác.
- Bạn sẽ giải thích cho họ thế nào để họ thay đổi code tốt hơn? quăng cho họ 1 cái và nói nó tốt hơn-> cũng tốt thôi, nhưng sẽ tốt hơn nếu giải thích được cho họ tại sao.
Kỹ năng này khi được kết hợp với (1) sẽ đưa tầm bạn lên trưởng nhóm, SA hay là một Senior thực thụ, tôi nhấn mạnh là senior thực thụ chứ không phải dev được 3 tháng đã lên senior như ở ViệtNam
Chia sẻ và truyền đạt là yếu tố rất quan trọng trong làm việc nhóm, nó cũng giúp kết nối với mọi người, đôi khi có những vấn đề chỉ cần nói ra được, cũng đã là một bước xa tiến tới việc hiểu cặn kẽ vấn đề hơn.
3. Và phải nghĩ đến business (tiền)
Và đây là vấn đề nữa, khi phải đứng trước những con người móc hầu bao cho bạn, bạn sẽ phải làm gì. Hay khi cần làm một proposal, làm sao để nó trở nên thuyết phục nhất, ở đây, tôi chỉ tập trung về mặt technical, chỉ đứng ở góc nhìn của technician thôi, hãy bỏ những xảo thuật của business qua một bên, nó hoàn toàn không nằm trong giới hạn của bài viết này.
Đây là lúc bạn sẽ khuyên nên dùng kafka hay sns? streaming hay pub/sub? queue, rabbitmq, sqs, etc... hay không. Thông thường rơi vào một vài vấn đề chung chung như sau:
- Đưa ra những thứ xịn sò nhất, cái gì cũng xịn, cái gì cũng ngon, và vì bạn cũng không hiểu cụ thể là mỗi công cụ nó nên ứng dụng vào tình huống nào, hay quá rối rắm để diễn đạt một thứ gì đó, cứ kiếm cái gì full option mà chiến, thật ăn chắc, đôi khi chỉ cần format đơn giản và bạn đề xuất mua luôn microsoft word, ăn chắc, dư xài, ...và đương nhiên là nó đắt đỏ nặng nề.
- Silver bullet: nói chung là chúng tôi có như thế, bạn có làm cái gì, ở đâu, chúng tôi có những món này, hãy bắt đầu.
Kỹ năng so sánh, bao quát, tổng hợp là cần thiết cho việc này.
Trở lại 2, nếu trong bài toán thực tế ta thấy dùng queue SQS là giải quyết được vấn đề về performance rất tốt, lại rất dễ sử dụng, ta có thể hiểu rõ vấn đề và giải thích nó tốt thế nào, tuy nhiên trong bài toán kinh tế việc đưa ra lựa chọn cho bên thứ 3 là 1 yếu tố mấu chốt dẫn đến thành công, cách tốt nhất là bạn ko chỉ đưa ra SQS, mà còn đưa thêm kafka, kinesis, sns.... để so sánh đối chiếu những cái hay cái dở mà hệ thống sẽ gặp phải, khi chốt kèo, nó tạo trâm trạng khá thoải mái cho người đứng ra chọn và hiểu được chúng ta đang chọn được cái tốt nhất (ko phải nhanh nhất, hay rẻ nhất....)
II. Thế nó là 3 cấp độ hay 3 yếu tố?
Sẽ rất dễ nhầm lẫn để bạn biến 1, 2 và 3 thành 3 nấc thang cho việc học, nhưng nó hoàn toàn không phải vậy.
Giờ ta để cho nó độc lập ra
Thông thường new coder theo góc nhìn hiện nay sẽ thường tập trung nhiều vào (1), ở đó hiện lên hình tượng 1 anh chàng đầu xù tóc rối rất kinh điển, hơi lầm lì chờ thử thách từ đâu đó và trở thành anh hùng.
(2) sẽ là 1 tay chuyên đi làm training, cứ em nào mới vô sẽ bốc em nó vô phòng rồi dũa dự án hiện tại, thường thì buổi training sẽ có slide rất đẹp, hiệu ứng tốt.
Dần dần không biết có nhảy qua làm BA hay scrum master không nhỉ?
(3) một người vẫn gần sếp, hay được giao làm proposal
Nhưng nếu giả định với những con người trong tay không tương xứng với những gì được nói ra, outdate sẽ rất nhanh, dự án có chất lượng nằm ở mức độ rất thấp so với những gì được nói.
III.
WTB là một nguyên tắc tốt để học và nắm một vấn đề trong lập trình, trong cuộc sống với quỹ thời gian có hạn ta có thể bỏ qua nhiều thứ và chỉ lựa chọn 1 vài nhánh, điểm để hoàn thiện kỹ năng, nó cũng là chốt chặn khi một vấn đề trở nên phức tạp và dàn trải với nhiều vấn đề.
Việc học lập trình cũng không nhất thiết phải theo đúng process W->T->B, nó cũng không nhất thiết phải học đều như hình tam giác cân, tùy vào cấp độ và chiến lược ta có thể chọn 1 điểm, mở rộng nó ra, rồi kéo dãn một cạnh, rồi tìm cách làm cho nó cân lại.
