Make it works, make it right and make it better

Ba levels của hard skills: make it works, make it right, make it optimization - Trần Duy Thịnh

Trong một lần bàn về vấn đề hard skills, soft skills trong công ty, thì có một anh đồng nghiệp có nói câu này và mình sửa lại là make it works, make it right and make it better. Tự nhiên hôm nay nổi hứng nên mình viết cái bài này nói lên ý kiến của mình. Mình chắc rằng sẽ có nhiều bạn sẽ không đồng ý với mình, đặc biệt là chắc sẽ có một số bạn từng làm chung với mình cũng không đồng ý. Không sao, ý kiến của mình thôi và mình cũng hi vọng sau này các bạn có dịp đọc lại sẽ nghĩ khác.

Make it works

Trong cái lĩnh vực công nghệ thông tin của mình, trong cái thời gian mấy năm gần đây thì số lượng của các buổi workshop, sharing, conferences, summit, hoặc cái bài blog chia sẻ của các blogger xuất thân từ ngành công nghệ thông tin, hoặc là các bài viết trên Medium chẳng hạn tăng dần, được chia sẻ nhiều dần. Điểm chung của các buổi, bài viết trên theo mình là luôn ca ngợi một công nghệ, một thiết kế nào đó, có khi là thần thánh hóa nó lên và rất rất ít các tác giả, diễn giả đề cập đến mặt tiêu cực, cái giá phải trả của chúng hoặc là xem nhẹ nhược điểm đi.

Có rất nhiều lý do:

• Người tư vấn thì tư vấn theo hướng của họ, khi doanh nghiệp hoặc tổ chức áp dụng không được, thì lại kiếm họ để tư vấn thêm và tất nhiên cũng phải trả tiền thêm. Kiểu như Downloadable Content (DLC) trong game vậy.

• Những "chuyên gia" nghiên cứu thì cảm thấy thích nó, tìm hiểu những đặc tính tốt của nó thôi mà quên đi việc tìm hiểu khuyết điểm. Theo mình thì vậy không còn là nghiên cứu nữa. Hồi còn là sinh viên, mình vẫn nhớ câu nói của thầy hướng dẫn luận văn mình là

  "Nghiên cứu khoa học là phải nói được ưu điểm, nhược điểm, nói được lợi ích, giới hạn; sau khi nghiên cứu phương pháp và ứng dụng vào vấn đề không phù hợp, thì kết luận phương pháp A không thế áp dụng cho vấn đề B cũng là kết quả nghiên cứu khoa học"

• Tác giả, diễn giả bị miễn cưỡng chia sẻ. Đại loại là cái kiểu tao bị công ty bắt mỗi năm phải có ít nhất một bài chia sẻ nên ráng kiếm gì đó nói; tao bị công ty kêu đi chia sẻ, chém cho mạnh tay vào để quảng cáo công ty.

Có một lần, mình tham gia về một workshop về Big Data, sau khi diễn giả trình bày xong, mình đặt một câu hỏi cho một vài vấn đề mà mình từng gặp & giải quyết rồi để xem có cách giải quyết hay hơn hay không? Thì các diễn giả đều không trả lời được, giống như là họ chưa từng gặp phải chưa từng nghĩ đến. Hay là một buổi chia sẻ gần đây mình có tham gia thì TDD là một cách mới luôn đấy, khi diễn giả đó show kết quả mấy tháng làm được ra, thì mình muốn kêu một vài đồng đội trẻ tuổi của mình ra show hàng ghê.

Lời khuyên thứ nhất: đừng "đao to, búa lớn" làm gì, cứ giải quyết được vấn đề đã, làm sao đó cho thật sạch, thật đơn giản là được.

Make it right

Mình còn nhớ cách đây vài năm, khi cấp trên cần xuất báo cáo cho sản phẩm thì anh quản lý trực tiếp của mình giao cho mình làm. Mình đã viết những dòng code cực kỳ đơn giản để đọc database lên, biến đổi này nọ để ra được một bản báo cáo chính xác, cuối ngày mình giao cho anh ấy thì ảnh nói là "Anh nộp lên hồi sáng rồi", thế là mình xin file code anh ấy đã làm để học hỏi kinh nghiệm thì bất ngờ thứ hai là "Code gì? Anh làm bằng excel mà".

Lời khuyên thứ hai: có thể bạn biết rất nhiều thứ nhưng cách sử dụng chúng đúng đắn thì lại không biết.

Mình là dạng người hay xem lại những thứ đã làm, nếu lâu lâu mình rất hay hỏi đồng nghiệp là "mình làm vậy có đúng không nhỉ?" thì không phải là mình đang nghi ngờ cái dự án đang làm có vấn đề đâu mà là mình đang thật sự thấy nó có vấn đề. Có những dự án được thiết kế, triển khai bằng những thứ đang "hot" hay là "thời thượng" nhưng nặng nề, cồng kềnh, muốn phát triển thêm hay bảo trì cũng khó. Thêm một cấu hình nhỏ thôi mà có khi mất 74 phút bao gồm code, test, chạy pipeline CI/CD,...

Có những dự án được thiết kế theo một đối thủ cùng ngành, họ mới chia sẻ cách làm vài tháng gần đó, thế là bưng về để giải quyết vấn đề A trong khi họ dùng để giải quyết vấn đề B. Đến khi mình phỏng vấn bên họ, họ có hỏi mình ứng dụng thế nào, có gặp rắc rối gì không thì mình chia sẻ hết, họ nói:

• Bên em cũng đang gặp vấn đề tương tự vậy, chưa biết giải quyết thế nào, nên hỏi anh thử xem có ý tưởng gì không?

• Ủa? Vậy sao trong bài viết của bên bạn mình không thấy chia sẻ mặt downside?

• Lúc đó tụi em chưa gặp.

• !!!

Lời khuyên thứ ba: giải pháp để giải quyết vấn đề thì nhiều, quan trọng là phải đúng vấn đề mới đúng giải pháp. Đừng áp dụng một thứ chỉ để làm màu; hào nhoáng, bóng bẩy, rực rỡ không phải lúc nào cũng tốt.

Hơi buồn cười là mình từng bị nhận xét là outdate công nghệ chỉ vì mình nghĩ một thứ gì đó chỉ để làm màu, chẳng giúp ích gì được cho dự án. Và rồi nó cũng được áp dụng vì mình là số ít outdate, và rồi nó đã được bỏ đi, và... không chỉ mình nó. =))

Make it better

Tiếp về cái công ty nọ, mình có chia sẻ cho họ một ý tưởng, cái mà tự bị một số người chê trách phê phán thì được người phỏng vấn của mình nhận xét là có khả thi và sẽ áp dụng thử (đến giờ mình chưa hỏi lại có được không vì mình từ chối offer bên họ nên ngại liên lạc lại =))). Sau đó mình còn nói thêm là theo mình cái thứ này nó không được áp dụng để giải quyết vấn đề A được, họ cũng đồng ý. Có thể cả mình lẫn họ đều sai thì vẫn tốt hơn là những người cố chấp nói rằng "do mình không biết sử dụng chứ không phải nó sai" và rồi chẳng thấy cái cách sử dụng của người "biết" đâu cả. Thứ mà mình và bên kia có được là kinh nghiệm, cái mà mình từng nêu ra và bị phản đối bằng câu "về lý thuyết là không có trường hợp đó xảy ra, đừng có nói một điều phi thực tế như vậy" để rồi chính người nói câu đó lại rơi vào trường hợp mình đã cảnh báo. Nói thật, lần đó muốn nói cái câu "sao hồi đó tao nói mà mày không nghe" nhưng sợ bị nói là đào bới, bị nhắc nhở là "giờ việc xảy ra rồi thì giải quyết thôi, nói quá khứ có lợi ích gì"

Lời khuyên thứ tư: có những người, họ vấp ngã nhưng không có nghĩa là họ học được bài học gì, nếu mình thấy vui thì góp ý, không thì thôi.

Kinh nghiệm là một thứ mà gần như không một lý thuyết nào có thể nói hết được và đây lại chính là thứ mà mình phải áp dụng để cho sản phẩm mình tốt hơn, chứ không phải cái mớ lý thuyết suông. Make it better luôn phải làm với kinh nghiệm, với đau thương.

Có một vài trường hợp hài hước là sau khi áp dụng đao to búa lớn để giết con gà thì mỏi tay quá, mệt quá mà vẫn chưa kết liễu được thì người ta lại đi theo hướng đẽo bớt đao, búa đi. Mà trước đó thì lại làm nó cứng quá, đẽo cũng kiệt sức mà chưa đẽo xong và con gà thì vẫn nhỡn nhơ. Cho nên kết hợp với lời khuyên thứ nhất:

Lời khuyên thứ năm: mọi thứ sẽ dễ dàng trở nên tốt đẹp hơn nếu nó bắt đầu với sự đơn giản.

Để đến được giai đoạn này thì ban đầu mình nên làm sao cho mình dễ debug và fix bug, chứ không phải là thêm cái config mà mất 74 phút mới lên live được, hay là mất cả ngày mới debug ra được một vấn đề là do copy/paste. Code đơn giản thôi, đừng cồng kềnh quá, đừng bao bọc nhiều quá, đừng cứng nhắc quá, sau này mới dễ nâng cấp, dễ bảo trì. Cũng giống như một câu nói nổi tiếng:

Premature optimization ss the root of all evil - Donald Knuth

Kết luận

Có nhiều diễn giả, tác giả nêu ra khuyết điểm của thứ họ ca ngợi là thuyết phục được đồng đội đồng ý xài, họ sai khi họ chỉ nêu ra điều đó với ý nghĩ là nó mới nên nhiều người ngại, nhất là mấy lão già outdate. Ý đúng thì mình nghĩ là để thuyết phục được thì bạn phải cho đồng đội thấy thứ mang lại đáng để trả giá.

Mượn câu của một đồng nghiệp khác để chốt hết bài

Khi mọi người thấy mình giỏi hard skills là thấy lo rồi đấy - Mai Thị Thanh Hiền