Làm an toàn thông tin thì học gì?

1 Giới thiệu

Tôi nhận được thư từ của nhiều bạn hỏi về việc nên học gì và như thế nào để có thể tìm được việc làm và làm được việc trong ngành an toàn thông tin (information security). Tôi nghĩ việc đầu tiên bạn cần phải làm là in toàn bộ bài viết "Làm thế nào để trở thành white hat hacker" ra giấy, nhưng đừng đọc, mà hãy để chúng trong toilet khi nào cần thì xài dần.

Quay trở lại câu hỏi. An toàn thông tin là một ngành rộng lớn với rất nhiều lĩnh vực. Những gì tôi biết và làm được chỉ gói gọn trong một hai lĩnh vực. Có rất nhiều mảng kiến thức cơ bản mà tôi không nắm vững và cũng có nhiều kỹ năng mà tôi không thạo. Hack tài khoản Yahoo! Mail là một trong số đó. Tôi cũng không biết cách tìm địa chỉ IP của bạn chat :-(.

Xét theo năm mức ngu dốt thì tôi nằm ở mức "1OI - thiếu kiến thức" ở hầu hết các lĩnh vực trong an toàn thông tin. Cũng có lĩnh vực tôi nằm ở mức "2OI - thiếu nhận thức". Nhiều lần đọc sách vở hoặc nói chuyện với đồng nghiệp, tôi hay nhận ra rằng có nhiều thứ tôi không biết là tôi không biết. Theo ý của anh Ngô Quang Hưng thì đây là chuyện bình thường:

Dân máy tính thường phải đọc/học rất nhiều để theo kịp sự phát triển với tốc độ ánh sáng của ngành mình. Trong quá trình này, với mỗi vấn đề X của ngành, ta sẽ chuyển dần dần từ 3OI xuống 1OI. Sau đó, nếu X là cái mà ta thật sự thích hoặc cần cho công việc thì sẽ chuyển nó lên 0OI. 

Rất nhiều sinh viên và nghiên cứu sinh KHMT ở mức 3OI khi mới bắt đầu đi học. Sau đó họ tìm hiểu về quá trình nghiên cứu, quá trình tìm các vấn đề và hướng nghiên cứu mới, quá trính cập nhật kiến thức về ngành của mình, và chuyển dần các thứ lên 2OI. Để có một quá trình hiệu quả từ 3OI lên 2OI không dễ chút nào. Ví dụ đơn giản: các journals, conference nào trong ngành mình là có giá trị, làm thế nào để tìm đọc các bài trong chúng, phương pháp lọc bài đọc thế nào, vân vân.

Tôi thấy anh Hưng nói có lý, nên mục tiêu chính của bài viết này là cung cấp một quá trình hiệu quả để bớt ngu về an toàn thông tin.

2 Làm an toàn thông tin là làm gì?

Tôi muốn viết phần này vì nhiều người tưởng tôi làm bảo vệ khi tôi nói tôi làm security. Ngoài ra có lẽ là do thị trường việc làm an toàn thông tin ở Việt Nam không phong phú nên hầu hết đều nghĩ rằng làm an toàn thông tin nghĩa là đảm bảo an toàn hệ thống mạng (network/system security), trong khi thực tế đây chỉ là một trong số rất nhiều công việc trong ngành.

Trong bốn phần nhỏ tiếp theo, tôi sẽ giới thiệu bốn nhóm công việc chính trong ngành. Đối với mỗi nhóm công việc, tôi sẽ bàn một chút về triển vọng nghề nghiệp ở Việt Nam và Mỹ, hai nơi mà tôi có dịp được quan sát. Nếu bạn không biết bạn thích làm gì thì cứ chọn một công việc rồi làm thử. Các công việc này đều có liên quan nhau, nên kiến thức mà bạn học được trong quá trình thử vẫn hữu ích cho những nghề khác.

2.1 An toàn sản phẩm (product security)

Công việc chính của nhóm này là làm việc với các đội phát triển sản phẩm để đảm bảo sản phẩm làm ra an toàn cho người dùng và an toàn cho hệ thống của công ty, cụ thể là:

• Kiểm định mã nguồn và thiết kế của sản phẩm

• Phát triển các giải pháp kỹ thuật và quy trình phát triển phần mềm an toàn để phát hiện và ngăn chặn những kỹ thuật tấn công đã biết

• Đào tạo nhân lực để nâng cao nhận thức về an toàn thông tin cũng như kỹ năng viết mã an toàn 

• Nghiên cứu các hướng tấn công mới có thể ảnh hưởng hệ thống sản phẩm và dịch vụ của công ty 

Tóm gọn lại thì nhóm này chuyên tìm lỗ hổng và kỹ thuật tấn công mới. Đây là công việc của tôi và tôi thấy đây là công việc thú vị nhất trong ngành :-).

Ở Mỹ thì thông thường thì chỉ có các hãng có phần mềm và dịch vụ lớn như Facebook, Google, Microsoft, Oracle, v.v. hay các tập đoàn tài chính ngân hàng lớn mới có đội ngũ tại chỗ để đảm nhiệm công việc này. Các công ty nhỏ thường chỉ thuê dịch vụ của các công ty tư vấn. IBM và Big Four đều có cung cấp dịch vụ tư vấn này. Dẫu vậy nếu được chọn lựa thì tôi sẽ chọn làm cho các công ty chuyên sâu như Matasano, iSec, Leviathan, Gotham, IOActive, Immunity, v.v.

Ở Việt Nam thì thị trường việc làm cho người làm an toàn sản phẩm có vẻ ảm đạm hơn. Cho đến nay tôi biết chỉ có một vài công ty ở Việt Nam là có nhân viên chuyên trách lĩnh vực này. Các công ty khác (nếu có quan tâm đến an toàn thông tin) thì hầu như chỉ tập trung vào an toàn vận hành. Các công ty tư vấn an toàn thông tin ở Việt Nam cũng không tư vấn an toàn sản phẩm, mà chỉ tập trung tư vấn chung chung về các quy trình và tiêu chuẩn an toàn thông tin.

2.2 An toàn vận hành (operations security)

Công việc chính của nhóm này là đảm bảo sự an toàn cho toàn bộ hệ thống thông tin của doanh nghiệp, với ba nhiệm vụ chính:

• Ngăn chặn: đưa ra các chính sách, quy định, hướng dẫn về an toàn vận hành; kiện toàn toàn bộ hệ thống thông tin, từ các vành đai cho đến máy tính của người dùng cuối; cấp và thu hồi quyền truy cập hệ thống; quét tìm lỗ hổng trong hệ thống, theo dõi thông tin lỗ hổng mới và làm việc với các bên liên quan để vá lỗi, v.v.

• Theo dõi và phát hiệ: giám sát an ninh mạng.

• Xử lý: phản hồi (incident response) và điều tra số (digital forensics) khi xảy ra sự cố an toàn thông tin, từ tài khoản của nhân viên bị đánh cắp, rò rỉ thông tin sản phẩm mới cho đến tấn công từ chối dịch vụ.

Đây là công việc khó nhất, nhưng lại ít phần thưởng nhất của ngành an toàn thông tin.

Tương tự như trên, chỉ có các hãng lớn của Mỹ mới có đội ngũ tại chỗ để phụ trách toàn bộ khối lượng công việc đồ sộ này, nhất là mảng xử lý và điều tra. Đa số các công ty chỉ tập trung vào ngăn chặn và sử dụng dịch vụ của bên thứ ba cho hai mảng còn lại. Các hãng như Mandiant, Netwitness hay HBGary cung cấp dịch vụ điều tra các vụ xâm nhập và có rất nhiều hãng khác cung cấp dịch vụ giám sát an ninh mạng.

Ở Việt Nam thì thị trường việc làm cho người làm an toàn vận hành tương đối phong phú hơn so với an toàn sản phẩm. Các công ty và tổ chức tài chính lớn đều có một vài vị trí chuyên trách về an toàn vận hành. Đa số người làm về an toàn thông tin ở Việt Nam mà tôi biết là làm trong lĩnh vực này. Dẫu vậy hầu như chưa có ai và công ty tư vấn nào làm về phản hồi và điều tra sự cố.

2.3 Phát triển công cụ (applied security)

Công việc chính của nhóm này là phát triển và cung cấp các công cụ, dịch vụ và thư viện phần mềm có liên quan đến an toàn thông tin cho các nhóm phát triển sản phẩm sử dụng lại.

Nhóm này bao gồm các kỹ sư nhiều năm kinh nghiệm và có kiến thức vững chắc về an toàn thông tin, viết mã an toàn và mật mã học. Họ phát triển các thư viện và dịch vụ dùng chung như phân tích mã tĩnh - phân tích mã động (static - dynamic code analysis), hộp cát (sandboxing), xác thực (authentication), kiểm soát truy cập (authorization), mã hóa (encryption) và quản lý khóa (key management), v.v.

Đây là dạng công việc dành cho những ai đang viết phần mềm chuyên nghiệp và muốn chuyển qua làm về an toàn thông tin. Đây cũng là công việc của những người thích làm an toàn sản phẩm nhưng muốn tập trung vào việc xây dựng sản phẩm hơn là tìm lỗ hổng.

Rõ ràng loại công việc này chỉ xuất hiện ở các công ty phần mềm lớn. Ở các công ty phần mềm nhỏ hơn thì các kỹ sư phần mềm thường phải tự cáng đáng công việc này mà ít có sự hỗ trợ từ nguồn nào khác. Ở Việt Nam thì tôi không biết có ai làm dạng công việc này không.

2.4 Tìm diệt mã độc và các nguy cơ khác (threat analysis)

Ngoài an toàn sản phẩm ra thì đây là một lĩnh vực mà tôi muốn làm. Công việc chính của nhóm này là phân tích, truy tìm nguồn gốc và tiêu diệt tận gốc mã độc và các tấn công có chủ đích (targeted attack). Mã độc ở đây có thể là virút, sâu máy tính, hay mã khai thác các lỗ hổng đã biết hoặc chưa được biết đến mà phần mềm diệt virút thông thường chưa phát hiện được. Các loại mã độc này thường được sử dụng trong các tấn công có chủ đích vào doanh nghiệp.

Tôi nghĩ rằng sau hàng loạt vụ tấn công vừa rồi thì chắc hẳn các công ty lớn với nhiều tài sản trí tuệ giá trị đều muốn có những chuyên gia trong lĩnh vực này trong đội ngũ của họ. Ngoài ra các công ty chuyên về điều tra và xử lý sự cố như Mandiant, HBGary hay Netwitness mà tôi đề cập ở trên đều đang ăn nên làm ra và lúc nào cũng cần người. Các công ty sản xuất phần mềm diệt virút dĩ nhiên cũng là một lựa chọn.

Ở Việt Nam thì tôi nghĩ hầu hết doanh nghiệp vẫn chưa thấy được nguy cơ đến từ các cuộc tấn công có chủ đích, thành ra họ sẽ không tuyển người chuyên trách vấn đề này. Tôi cũng không biết có công ty tư vấn nào ở Việt Nam chuyên về điều tra và xử lý sự cố hay không. Tôi nghĩ lựa chọn khả dĩ nhất cho những người thích mảng công việc này là các công ty phần mềm diệt virút.

Tuy nhiên cũng cần lưu ý rằng trong vài năm gần đây ở Việt Nam còn xuất hiện những loại mã độc nhắm vào đông đảo người dùng máy tính bình thường. Vấn nạn này có lẽ sẽ còn kéo dài trong nhiều năm tới và lẽ đương nhiên "phe ta" lúc nào cũng cần thêm những chiến sĩ lành nghề như anh TQN. Thành ra dẫu triển vọng nghề nghiệp không sáng sủa cho lắm, nhưng tôi rất hi vọng sẽ ngày càng nhiều người tham gia vào việc phân tích các mã độc nhắm vào người dùng máy tính ở Việt Nam. Đối với tôi họ là những người hùng thầm lặng, chiến đấu đêm ngày với các "thế lực thù địch" để bảo vệ tất cả chúng ta.

3 Học như thế nào?

Đa số những bạn viết thư cho tôi đều đang học đại học ngành CNTT và tất cả đều than rằng chương trình học quá chán, không có những thứ mà các bạn muốn học. Tôi nghĩ đây là một ngộ nhận.

Hối tiếc lớn thứ nhì trong sự nghiệp học tập mấy chục năm của tôi là đã không học nghiêm túc khi còn là sinh viên (hối tiếc lớn nhất là tôi đã không nghỉ hẳn, nhưng đó là một câu chuyện dài khác). Tôi cũng đã nghĩ rằng chương trình học ở đại học là lạc hậu và không cần thiết. Bây giờ nhìn lại thì tôi thấy nội dung và cách dạy của từng môn học thì đúng là lạc hậu (chỉ có mấy môn triết học Mác-Lênin là bắt kịp ánh sáng thời đại), nhưng toàn bộ giáo trình đại học vẫn cung cấp được một cái sườn kiến thức rất cần thiết cho một kỹ sư an toàn thông tin.

Ở đại học người ta có cách tiếp cận top-down, nghĩa là dạy từ đầu đến cuối những kiến thức nằm trong chương trình. Điều này dễ dẫn đến tình trạng là người học phải học những kiến thức mà họ không thấy cần thiết. Nếu chương trình học cũ kỹ và không có nhiều thực hành, hoặc người dạy không chỉ ra được bức tranh toàn cảnh, vị trí hiện tại của người học và bước tiếp theo họ nên làm là gì thì người học sẽ dễ cảm thấy rằng họ đang phí thời gian học những kiến thức vô bổ.

Trong khi khi đi làm thì cách tiếp cận là bottom-up, nghĩa là lao vào làm, thấy thiếu kiến thức chỗ nào thì học để bù vào chỗ đó. Lúc này tôi hoàn toàn chủ động trong việc học và tôi cũng hiểu rõ tôi cần học cái gì và tại sao. Điều thú vị là mỗi khi truy ngược lại nguồn gốc của những kiến thức tôi cần phải có, tôi thường thấy chúng nằm trong chương trình đại học.

Ví dụ như tôi muốn luyện kỹ năng dịch ngược mã phần mềm (reverse code engineering - RCE) thì tôi thấy rằng tôi cần phải có kiến thức về tổ chức và cấu trúc máy tính. Hoặc nếu tôi muốn học về mật mã học thì tôi phải học lý thuyết tính toán, mà khởi nguồn là lý thuyết automata. Nhưng tại sao trước đó tôi cũng đi làm nhưng không thấy được những lỗ hổng kiến thức này? Tôi nghĩ là do tôi làm không đủ sâu. Ví dụ như nếu bạn suốt ngày chỉ lập trình PHP thì bạn sẽ không thể hiểu được tại sao phải nắm vững tổ chức và kiến trúc máy tính. Hoặc giả như công việc của bạn là sysadmin thì cũng sẽ rất khó để bạn thấy được tại sao cần phải học lý thuyết automata.

Những gì tôi nói lan man ở trên có thể tóm gọn lại thế này:

• Học dựa theo chương trình đại học. Nếu bạn đang học đại học các ngành công nghệ thông tin, khoa học máy tính hay toán tin thì nên tập trung vào việc học các môn trong trường. Các học liệu trong phần 4 cũng được soạn theo các đại học lớn trên thế giới.

• Học kiến thức căn bản thật vững (cái gì là căn bản thì xem phần 4), những món còn lại khi nào cần (căn cứ vào nhu cầu công việc) thì hẵng học.

• Tìm dự án lề (side project) mà bạn thích để làm để có thể nhanh chóng nhận ra những mảng kiến thức còn thiếu.

• Thời điểm tốt nhất để học một cái gì đó là khi bạn đang là sinh viên. Thời điểm tốt thứ hai là ngay bây giờ!

Các lớp mà tôi liệt kê trong phần 4 đa số là của đại học Stanford. Bạn không cần phải đến tận nơi, ngồi trong lớp mới có thể học được. Tôi thấy trong nhiều trường hợp thì bạn chỉ cần đọc lecture notes, sách giáo khoa mà lớp sử dụng rồi làm bài tập đầy đủ thì vẫn sẽ tiếp thu đủ kiến thức. Một số lớp mà tôi liệt kê dưới đây được dạy miễn phí rộng rãi trên Coursera.

Bạn có thể tham khảo chương trình SCPD nếu muốn học chung với các sinh viên Stanford khác. Đây là chương trình học từ xa thông qua video. Buổi sáng lớp diễn ra thì buổi chiều bạn đã có video để xem. Thi cử như các sinh viên chính quy khác và điểm phải trên B mới được học tiếp. Đây là chương trình mà tôi theo học. Điểm thú vị là mỗi học kỳ bạn chỉ cần lấy một lớp, nhưng Stanford vẫn sẽ cho bạn xem video của tất cả các lớp khác.

Ngoài Stanford và Coursera ra, bạn cũng có thể tham khảo các lớp trên Udacity, OCW và MITx. Khi tôi đang viết những dòng này thì MIT và Harvard công bố dự án edX. Chúng ta đang sống trong một thời đại cực kỳ thú vị! Bây giờ chỉ cần bạn chịu học thì muốn học cái gì cũng có lớp và học liệu miễn phí. Nhưng mà học cái gì bây giờ?

4 Học cái gì?

Có ba món quan trọng cần phải học: lập trình, lập trình và lập trình! Để làm việc được trong ngành này, bạn phải yêu thích lập trình. Không có cách nào khác. Thề luôn!

Tôi dành khá nhiều thời gian tìm hiểu giáo trình khoa học máy tính của các trường đại học lớn trên thế giới và tôi thấy tất cả các môn học đều có phần bài tập là lập trình. Học cái gì viết phần mềm cho cái đó. Học về hệ điều hành thì phần bài tập là viết một hệ điều hành. Học về mạng thì viết phần mềm giả lập router, switch hay firewall. Cá nhân tôi cũng thấy rằng lập trình là cách tốt nhất để tiếp thu kiến thức một môn học nào đó, biến nó thành của mình. Nói cách khác, lập trình là một cách mã hóa tri thức khá hiệu quả.

Ngoài ra nhìn vào mô tả công việc ở phần 2, bạn cũng có thể thấy kỹ năng lập trình quan trọng đến dường nào, bởi hầu hết các vấn đề và giải pháp của an toàn thông tin là đến từ phần mềm. Rõ ràng muốn tìm lỗi của phần mềm thì bạn phải hiểu được phần mềm thông qua mã nguồn trực tiếp hay trung gian của nó. Rất có thể bạn sẽ không phải lập trình hàng ngày, nhưng bạn phải viết được những công cụ nhỏ hay những thư viện hỗ trợ cho công việc và các lập trình viên khác.

Vậy làm thế nào để lập trình giỏi? Câu hỏi này làm tôi nhớ đến câu chuyện cười về ông lập trình viên không thể ra khỏi phòng tắm vì trên chai dầu gội có ghi hướng dẫn sử dụng là "cho vào tay, xoa lên đầu, xả nước và lập lại". Từ khóa trong câu chuyện này là "lập lại": muốn giỏi lập trình thì cách tốt nhất là lập trình nhiều vô!

Nhưng mà lập trình bằng ngôn ngữ gì bây giờ? Đây là câu hỏi dễ làm cho các lập trình viên oánh nhau nhất ;-). Cá nhân tôi thấy rằng người làm an toàn thông tin bây giờ cần phải thông thạo C, x86 Assembly, Python (hoặc Ruby) và JavaScript. Tôi có nói lý do tại sao trong phần giới thiệu sách tiếp theo.

Lập trình

• Brian Kernighan, Dennis Ritchie, The C Programming Language (2nd Edition): kinh điển và phải-đọc cho tất cả những ai muốn học C! Linus Torvalds từng nói rằng "[...] all right-thinking people know that (a) K&R are _right_ and (b) K&R are right". Tôi đã từng rất sợ C (vì nghĩ nó phức tạp), và cuốn này giúp tôi không còn sợ nữa.

• Randal Bryant, David O'Hallaron, Computer Systems: A Programmer's Perspective: cuốn này được dùng cho lớp CS107. Đọc cuốn này và làm bài tập của lớp CS107 sẽ rèn cho bạn kỹ năng lập trình C và x86 Assembly. Sau khi đọc cuốn này, bạn sẽ biết tại sao có lỗi tràn bộ đệm và cách khai thác chúng. Tôi rất thích các chương nói về x86 và sự liên kết giữa các công cụ như preprocessor, compiler và linker.

• David Hanson, C Interfaces and Implementations: muốn mau "lên cơ" bida thì phải thường xuyên xem người khác chơi để mà học "đường" mới. Tương tự, muốn giỏi lập trình thì phải thường xuyên đọc mã của những cao thủ. David Hanson là một cao thủ C và cuốn sách này sẽ chỉ cho bạn nhiều "đường" mới trong việc sử dụng C. Tôi thích các bài tập của cuốn sách này. Tôi nghĩ chỉ cần luyện các bài này là đủ để trở thành một lập trình viên C hạng lông.

• Justin Seitz, Gray Hat Python: Python Programming for Hackers and Reverse Engineers: cuốn này sẽ giúp bạn sử dụng Python để viết những công cụ nho nhỏ mà bất kỳ ai làm an toàn thông tin cũng sẽ phải viết một vài lần trong đời. 

• Douglas Crockford, JavaScript: The Good Parts: JavaScript là ngôn ngữ thống trị WWW. Nếu bạn muốn làm an toàn (ứng dụng và trình duyệt) web thì bắt buộc phải thành thạo ngôn ngữ. Cuốn sách rất mỏng này của tác giả JSON giới thiệu đầy đủ những vấn đề mà người làm an toàn ứng dụng cần phải biết về JavaScript. Cuốn này có thể dùng làm sách giáo khoa thay cho cuốn "Javascript: The Definitive Guide" trong lớp CS142 (xem bên dưới). Đọc cuốn này tôi mới hiểu closure là gì và bản chất prototypal của JavaScript.

• Sẽ đọc: những cuốn được giới thiệu ở đây.

Hệ điều hành

• Abraham Silberschatz, Peter Galvin, and Greg Gagne, Operating System Concepts, 8th Edition Update: cuốn này là giáo trình của lớp CS140. Tôi nghĩ không cần đọc cuốn này, chỉ cần đọc notes và làm bài tập (viết các phần khác nhau của một hệ điều hành!) là đủ. Đây là một lớp nặng. Tôi theo đuổi lớp CS140 này giữa chừng thì phải dừng lại do không có đủ thời gian.

• Intel Software Developer Manuals: tôi thấy nên đọc tài liệu của 80386 trước, rồi sau đó hẵng đọc tài liệu của các CPU mới hơn.

• Red Hat, Introduction to System Administration: tôi rất thích chương nói về "philosophy of sysadmin" của cuốn này và tôi nghĩ kỹ năng quản trị hệ thống là cực kỳ cần thiết khi muốn nghiên cứu các kỹ thuật tấn công/phòng thủ mới. Không thể làm an toàn vận hành nếu không có kỹ năng quản trị hệ thống.

• Sẽ đọc: Mark Russinovich, David Solomon, Alex Ionescu, Windows Internals, Part 1: Covering Windows Server 2008 R2 and Windows 7.

Mạng máy tính

• Richard Stevens, TCP/IP Illustrated Vol I: cuốn sách này quá nổi tiếng rồi nên tôi nghĩ không cần phải giới thiệu. Tôi chưa đọc Vol II, III nhưng nhất định sẽ tìm đọc trong thời gian tới. Lớp CS144 dùng một cuốn sách khác. Tôi chưa học lớp này, nhưng tôi thấy bài tập của họ khá thú vị.

• Stephen Northcutt, Lenny Zeltser, Scott Winters, Karen Kent, Ronald W. Ritchey, Inside Network Perimeter Security, 2nd Edition: tôi thích cuốn này vì nó viết rất dễ hiểu về các vấn đề  và công cụ thường gặp trong an toàn mạng.

• Sẽ đọc: Fyodor, Nmap Network Scanning.

Sau khi đã có những kiến thức cơ bản ở trên, bạn có thể theo đuổi lớp CS155. Lớp này có trên Coursera với tên Computer Security. Song song với lớp CS155, bạn có thể tìm đọc các sách sau:

Tìm lỗi phầm mềm

• Mark Dowd, John McDonald, Justin Schuh, The Art of Software Security Assessment: Identifying and Preventing Software Vulnerabilities: Kinh điển và phải-đọc! Cuốn này là kinh thánh của lĩnh vực an ninh ứng dụng. Tôi thích nhất phần nói về tràn số nguyên và những vấn đề của ngôn ngữ C trong cuốn này.

• Dafydd Stuttard, Marcus Pinto, The Web Application Hacker's Handbook: Discovering and Exploiting Security Flaws: cuốn này tập trung vào ứng dụng web. Tôi không đọc cuốn này kỹ lắm, mà chỉ thường dùng nó để tham khảo. Dẫu vậy tôi nghĩ nó là một cuốn giới thiệu tốt cho những ai mới bắt đầu.

• Michal Zalewski, The Tangled Web: cuốn này mới xuất bản gần đây nhưng đã ngay lập tức trở thành kinh điển! Cuốn này đúc kết quá trình nghiên cứu về an ninh web trong vài năm trời của một trong những hacker xuất sắc nhất thế giới. Tôi nghĩ chỉ cần đọc cuốn này là bạn đã có thể bắt đầu tìm lỗ kiếm tiền được rồi. Cuốn này và cuốn ở trên được dùng làm sách giáo khoa của lớp CS142.

• Sẽ đọc: Tobias Klein, A Bug Hunter's Diary: A Guided Tour Through the Wilds of Software Security

Dịch ngược mã phần mềm

• Eldad Eilam, Reversing: Secrets of Reverse Engineering: mặc dù có rất nhiều người viết về RCE nhưng tôi thấy đây là cuốn duy nhất hệ thống hóa được các bước quan trọng cần phải làm khi cần dịch ngược mã của một tệp chương trình nào đó.

• Chris Eagle, The IDA Pro Book: The Unofficial Guide to the World's Most Popular Disassembler: IDA Pro là công cụ tốt nhất để làm RCE và đây là cuốn sách tốt nhất về IDA Pro. Nắm vững C và x86 Assembly thì chỉ cần đọc cuốn này là bạn có thể bắt đầu RCE các phần mềm phức tạp.

• Tham khảo các tài liệu về dịch ngược mã phần mềm của lớp PenTest của đại học NYU.

• Sẽ đọc: Christian Collberg, Surreptitious Software: Obfuscation, Watermarking, and Tamperproofing for Software Protection: Obfuscation, Watermarking, and Tamperproofing for Software Protection

• Sẽ đọc: Michael Sikorski, Andrew Honig, Practical Malware Analysis: The Hands-On Guide to Dissecting Malicious Software

Điều tra số (digital forensics)

• Brian Carrier, File System Forensic Analysis: Brian Carrier là tác giả của bộ công cụ forensic nổi tiếng The Sleuth Kit. Cuốn này đã giúp tôi "khai quật" được một đoạn video bị xóa lưu trong một máy camera quay lén các máy ATM.

• Sẽ đọc: Cory Altheide, Harlan Carvey, Digital Forensics with Open Source Tools

Mật mã hóa

• Niels Ferguson, Bruce Schneier, Practical Cryptography: tôi có nhiều kỷ niệm đẹp với cuốn này ;-). Hầu hết các kết quả làm việc của tôi trong vài năm vừa rồi là nhờ vào việc đọc cuốn này. Tôi chép lại đây giới thiệu rất hay của một người bạn: "The best security books, you can read "inside out", taking any recommendation on what to do and looking for people to do the opposite to find flaws. "Firewalls and Internet Security" was like that. So was "Practical Unix Security", and so is TOASSA. This is that book for crypto. It's also the one book on crypto you should allow yourself to read until you start actually finding crypto flaws."

• Jonathan Katz, Yehuda Lindell, Introduction to Modern Cryptography: Principles and Protocols: đây là sách giáo khoa của lớp CS255. Lớp này là lớp Cryptography trên Coursera.

• Sẽ đọc: Adam Young, Moti Yung, Malicious Cryptography: Exposing Cryptovirology

Chú ý đây là những cuốn sách tập trung vào công việc hàng ngày và sở thích của tôi -- nói cách khác, còn thiếu nhiều sách của các mảng công việc khác. Dẫu vậy tôi nghĩ những cuốn sách này sẽ giúp bạn có được một kiến thức nền tảng vững chắc để từ đó theo đuổi các nghề nghiệp khác nhau trong ngành an toàn thông tin. Trong thời gian tới tôi sẽ cập nhật thêm những cuốn sách mà tôi đang và sẽ đọc. Nếu bạn biết sách nào hay thì hãy giới thiệu cho tôi.

Ngoài ra trong các sách mà tôi vừa liệt kê không có cuốn sách toán (và lý thuyết khoa học máy tính) nào cả. Tôi nghĩ bạn sẽ tự có câu trả lời cho câu hỏi "Có nên học toán hay không?" khi bắt đầu học mật mã. Về hai mảng này thì tôi rất thích lớp "Great Ideas in Theoretical Computer Science" của Scott Aaronson và cuốn "A Computational Introduction to Number Theory and Algebra" của Victor Shoup. Thích đến nỗi tôi phải viết đoạn này chỉ để nhắc đến chúng ;-). Tôi cũng đã từng dành ra nhiều tháng để đánh vật với Introduction to the Theory of Computation của Michael Sipser. Nhưng thôi, tôi không muốn giới thiệu sách toán nữa vì tôi rất dốt món này!

5 Bắt đầu nói nhảm và hết

Phew! Không ngờ là tôi cũng viết được cho đến đây (hi vọng là bạn vẫn đang đọc!). Tôi định viết dông dài về thái độ học tập này nọ, nhưng thôi bài đã dài và nhiều thông tin rồi, nên tôi chỉ nói ngắn gọn thế này:

Cái mà tôi vừa "vẽ" ra là một con đường. Thú thật là tôi không biết đích đến của nó là gì -- tôi chỉ biết rằng hành trình mà tôi đã đi qua (và hi vọng là những chặng đường sắp tới) đã mang đến cho tôi rất nhiều niềm vui -- niềm vui của một con người đi khám phá thế giới, chinh phục những thử thách, để rồi chia sẻ những câu chuyện hay ho với tất cả mọi người.

Mỗi ngày tôi đều dành thời gian đọc sách, làm bài tập, viết mã hoặc chứng minh một cái gì đó. Không ai bắt tôi phải làm những chuyện đó. Có những thứ tôi học cũng không (hoặc chưa) có liên quan gì đến công việc. Tôi học chỉ vì tôi thích và tò mò. Tôi học vì tôi muốn hiểu thêm những thứ mà tôi cho là hay ho. Tôi học vì tôi muốn đi mãi, đi mãi, đi đến tận cùng những cái mà người ta viết trong sách, để xem ở đó có gì hay không.

Hôm rồi tôi đọc một mẩu chuyện về Richard Feynman, trong đó có đoạn kể về lúc Feynman bị bệnh gần đất xa trời, ông tâm sự rằng, "[I'm going to die but I'm not as sad as you think because] when you get as old as I am, you start to realize that you've told most of the good stuff you know to other people anyway". Đương nhiên những gì tôi biết làm sao mà "good" bằng những gì Feynman biết, nhưng dẫu sao thì tôi cũng sẽ học theo Feynman: có biết chuyện gì hay ho thì kể cho nhiều người khác cùng biết. Bài này là một chuyện như thế.

Happy hacking!

                                                                                              by: Thai Duong

Tự Hoc Là Cốt Lõi

Tự đốt đuốc mà đi

(Mượn lời tựa một bài viết của anh Giáp Văn Dương)

Trong một bài viết trên blog này tôi có nói hối tiếc lớn thứ nhì trong "sự nghiệp" học tập của tôi là đã không tốt nghiệp đại học và hối tiếc lớn nhất là tôi đã không nghỉ hẳn việc học đại học. Hôm nay tôi muốn nói một chút về suy nghĩ này, nhân dịp đọc bài đã dẫn của anh Dương cũng như bài của một bạn sinh viên về việc mất định hướng trên Tuổi Trẻ Cuối Tuần.

Tôi học đại học rất tệ. Thời gian đến trường đến lớp của tôi rất ít. Chủ yếu tôi chỉ học khi còn một vài ngày nữa là thi. Tôi thường hay nói là vì tôi bận đi làm, nhưng thật ra nếu cố gắng, tôi nghĩ tôi cũng sẽ có thể vừa học vừa làm. Chủ yếu vì tôi làm biếng. Kết quả là sau hơn 5 năm ngoài việc nợ một vài môn chuyên ngành, tôi còn nợ một môn cần thiết để làm luận văn. Tôi quyết định nghỉ, chứ không đi học lại những môn đó nữa.

Tôi chọn học ngành công nghệ thông tin vì tôi cảm thấy tôi thích ngành này. Đây cũng là một ngành thời thượng lúc bấy giờ. Ở thời điểm bắt đầu học đại học thì mục tiêu của tôi rất rõ ràng: tốt nghiệp đại học rồi đi làm kỹ sư an toàn thông tin. Điều buồn cười là lúc đó tôi không biết làm an toàn thông tin là làm gì. Tôi nghĩ đây cũng là tình trạng chung của nhiều bạn bè của tôi. Đa số chúng tôi chọn ngành học vì một sở thích mơ hồ, rồi cố theo đuổi mà dần dà trở thành một sở thích thật sự, hoặc là vỡ mộng rồi lụi tàn.

Trong suốt quá trình học đại học, những gì trường đại học cung cấp cho tôi cũ kỹ và có vẻ như rất thiếu thực tế so với những gì mà tôi thấy trong quá trình làm việc bên ngoài. Làm sao mà tôi thích đi học khi mà những hệ thống mà tôi xây dựng và quản trị ở công ty đang sử dụng những công nghệ tiên tiến nhất lúc bấy giờ, trong khi trường lại dạy những kiến thức tưởng chừng như chẳng ăn nhập vào đâu.

Bây giờ nhìn lại thì tôi thấy nội dung và cách dạy của từng môn học thì đúng là lạc hậu, nhưng toàn bộ giáo trình đại học mà tôi học vẫn cung cấp được một cái sườn kiến thức rất cần thiết cho một kỹ sư công nghệ thông tin. Dựa trên cái sườn này, nếu biết cách tự học thì cũng sẽ thu được một lượng kiến thức đáng kể. Nhưng lúc là sinh viên, thiếu cái nhìn toàn cảnh, thiếu kinh nghiệm, tôi không có cách nào hiểu được như vậy.

Tôi chẳng đổ thừa trường mà tôi học hay các thầy cô. Tôi có nguyên tắc: cái gì tôi làm không được là lỗi của tôi! Cũng có nhiều bạn học như tôi và vẫn học tốt. Dẫu vậy tôi nghĩ điều mà tôi không hài lòng, để rồi dẫn tới việc chán học, là đại học đã không như tôi kỳ vọng. Tôi nghĩ đây cũng không phải là suy nghĩ của cá nhân tôi. Nhiều bạn sinh viên mới vào đại học cũng thường đặt ra những kỳ vọng cao đẹp về đại học.

Bây giờ nhìn lại thì tôi thấy mình ngây thơ quá. Đó là lỗi của tôi. Thử hỏi xem thời nay có ai điên khùng đi kỳ vọng vào chất lượng của một đơn vị do nhà nước quản lý? Có bao giờ bạn đi làm giấy tờ, đi khám bệnh viên công, hay đơn giản như là chạy xe ngoài đường v.v. mà bạn cảm thấy mình được phục vụ một cách chu đáo, hay là đường xá chất lượng tốt, thông thoáng, an toàn đúng như bạn mong muốn?

Các trường đại học, kể cả trường được xem là tốt như trường mà tôi đã học, thật sự chẳng có bất kỳ động lực gì để đáp ứng kỳ vọng của sinh viên cả (nhìn rộng ra thì không chỉ trường đại học mà cả thể chế xã hội hiện tại ở Việt Nam chẳng có bất kỳ động lực gì để mà đáp ứng kỳ vọng của mỗi cá nhân cả, nhưng chuyện này nói sau). Thậm chí nói không ngoa, các trường cũng không có động lực để nâng cao chất lượng giảng dạy. Người muốn làm sinh viên thì nhiều, mà trường đại học thì ít, thành ra cầu bao giờ cũng nhiều hơn cung. Nếu trường có tiếng một chút, thì khỏi phải lo đầu vào. Sinh viên vào trường rồi thì ít khi chuyển đi chỗ khác. Bọn sinh viên cũng toàn lũ ngây dại, có dạy dở thì chúng cũng chỉ có hai cách: bỏ học hoặc cắn răng mà học cho xong, cấm có phàn nàn.

Trường được xem là tốt chủ yếu là do hai lý do: sinh viên đầu vào tốt và những nỗ lực cá nhân của một số thầy cô. Vai trò của người thầy cực kỳ quan trọng. Thầy tốt sẽ làm thay đổi khoa, khoa tốt làm thay đổi cả trường. Làm thế nào để có thầy giỏi? Lương bổng là một vấn đề lớn, một con voi trong phòng của giáo dục Việt Nam, thành ra chỉ còn có thể kỳ vọng vào những người thật sự yêu thích việc dạy học và có kiến thức ở mức chuyên gia về lĩnh vực mà họ muốn dạy. Nhưng tiếc thay tôi nghĩ những người như vậy chỉ là thiểu số.

Phần đông giảng viên đại học mà tôi được học rơi vào hai nhóm. Nhóm những thầy cô đã lớn tuổi và họ dạy đi dạy lại một hai môn trong suốt nhiều năm liền mà không có bất kỳ cải tiến gì về giáo trình. Rất ít người là chuyên gia nghiên cứu trong lĩnh vực mà họ giảng dạy và xem tiểu sử của họ thì không có ai đã hoặc đang làm việc gì khác ngoài việc giảng dạy. Nhóm thứ hai là sinh viên mới ra trường, được giữ lại trường rồi đi dạy. Những người này có thật sự thích việc dạy học hay không đã là một dấu hỏi lớn (vì đa số ở lại trường vì muốn đi du học), nhưng rõ ràng trình độ của họ không đủ để dạy đại học, mặc dù có thể họ năng động hơn nhóm thứ nhất.

Như vậy chỉ còn hi vọng vào sinh viên đầu vào, nghĩa là sinh viên phải dựa vào chính mình. Phải tự đốt đuốc mà đi.

Xã hội chỉ phát triển khi mà những người đi trước vẫn trồng cây mặc dù họ biết là họ sẽ không bao giờ được hưởng bóng mát của chúng. Hãy nhìn vào xã hội của chúng ta và hãy hiểu rằng chuyện đó là cổ tích, ít nhất là trong những năm hiện tại. Có phải đã có ông nghị sĩ từng tuyên bố: cứ mượn nợ, con cháu sẽ trả! Khi chúng ta hiểu được rằng chẳng thể kỳ vọng gì vào nhà trường và xã hội thì việc tự mình phải vươn lên, phải tự cứu lấy mình, phải tự bảo vệ mình sẽ trở thành chuyện hiển nhiên, không cần phải suy nghĩ.

Phải dậy, phải đốt đuốt, phải đi thôi. Ngay bây giờ! Người ta đã đi xa và đang đi nhanh lắm rồi.

Đuốt thì đốt rồi, nhưng... đi đường nào bây giờ

                                                                                                             by Thai Duong

Định Hướng Cho Lập Trình Viên

Ken và Sun hay câu chuyện đào tạo lập trình viên

Sáng Chủ nhật cuối xuân, anh cu Ken cùng chị Sun hẹn nhau ở quán Cây sấu cuối đường Yết Kiêu, uống cà phê và chém gió. Lần này họ bị sa vào câu chuyện xung quanh việc đào tạo lập trình viên. Mở ngoặc: Ken là một giảng viên lập trình thâm niên chuẩn bị “ra riêng”, còn chị Sun là một CEO của một công ty phát triển phần mềm đang phát triển nóng trong mấy năm trở lại đây; Ken và Sun là bạn cấp ba của nhau, họ còn rất trẻ và đầy khao khát.

Sun: Ông Ken ạ, dạo này mót người quá, đơn hàng nhiều, dự án thiếu người mà tuyển mãi chẳng được. Từ đầu năm tới giờ tôi mới tuyển được mấy chục đứa, trong khi nhu cầu gấp chục lần.

Ken: Biết rồi khổ lắm nói mãi. Xưa nay bọn tôi sống được là vì các bà khan “hàng”, nhưng sức cung ứng của bọn tôi yếu ớt, mà chất lượng thì dạo này cứ một đi xuống. Bọn tôi cũng cố nhiều, nhưng chả thay đổi được mấy. Tôi nghĩ là các cơ sở đào tạo hiện nay đang vướng phải những lỗi hệ thống nghiêm trọng, cứ vá víu mãi vừa mất công vừa chả được việc gì.

Sun: Thế hử? Lỗi ấy là gì?

Ken: Bọn tôi không xác định được định hướng xuyên suốt, làm việc không đường lối nên bị “vòng xoay cuộc đời” nó kéo đi, đôi lúc không biết đi về đâu, làm gì tiếp theo.

Sun: Cơm áo gạo tiền thì ai chả vướng?

Ken: Ừ, kinh doanh là vấn đề sống còn đối với các đơn vị tư nhân như bọn tôi. Đầu vào lúc nào cũng là quan trọng hàng đầu. Dạo này nó đi xuống cả lượng lẫn chất.  Không có người học thì cả lũ như một đoàn tàu há mồm, thế nên cứ phải xoay mọi cách để có sinh viên đã. Tình hình tuyển sinh ngày càng nản, y như việc tuyển nhân sự của bà ấy. Bọn tôi lúc đầu còn cành cao, không ham hố số lượng, nhưng rồi cũng cứ phải đảm bảo tốc độ tăng trưởng đều đều 1/3 mỗi năm. Rồi cũng đến lúc phải mở rộng, phải vơ bèo bạt tép. Mà như thế thì …

Sun: Bọn tôi kiên quyết không làm vậy được, làm thế là tự giết mình. Ông  biết đấy, đợt vừa rồi bọn tôi nhận 4000 hồ sơ, chỉ tuyển có bốn mươi thôi. Mà đấy mới chỉ bốn mươi ứng cử viên thử việc thôi, chứ còn phải đào tạo lại chán. Tôi nhắc lại để ông  khỏi tưởng là nghe nhầm: bốn mươi trên bốn nghìn, tức là 1% đấy nhé. Bọn tôi có muốn loại nhiều thế đâu, mệt mỏi chết đi được…

Ken: Bọn tôi thì loại nửa phần trăm là nhiều hehe.

Sun: Nhân sự là yếu tố then chốt nhất của nền kinh tế sáng tạo, nhân sự yếu kém là một dạng đầu tư lãng phí, nên bọn tôi có ưu tiên và tiêu chuẩn rất khắt khe.

Ken: Tôi hiểu, công ty của bà là một ví dụ về việc xác định rõ lối đi và các mối ưu tiên. Bọn tôi đang vướng chỗ ấy.

Sun: Nói rõ xem nào

Ken: Bọn tôi chưa bao giờ ngồi nghĩ xem mình đào tạo ra con người kiểu gì, cho những đơn vị sử dụng lạo động nào, đẳng cấp ra sao, ở đâu. Tức là để ngỏ cái đích đến của quá trình đào tạo. Thứ đến, do bọn tôi mua công nghệ đào tạo của nước ngoài nên cũng chẳng bao giờ quan tâm xem dạy học như thế nào thì tốt, tốt hơn thì như thế nào, mình cần tốt lên bao nhiêu nữa. Cuối cùng, bọn tôi cũng hầu như ít quan tâm đến việc phải dạy những cái gì. Mọi thứ cứ như hiển nhiên vậy. Tự nhiên như người Hà Nội hehe.

Sun: Như thế gọi là làm bừa à?

Ken: Bừa là thế nào? Thực ra bọn tôi xác định là mình chẳng biết gì nên đi mua quách công nghệ đào tạo về cho nó nhanh. Ban đầu thì cũng thuận lợi lắm, cũng không thể nói là toàn gặp may, bọn tôi cũng chịu khó làm ăn, chịu khó học hỏi. Nhưng dần dần khiếm khuyết cứ bộc lộ ngày càng nhiều, và bọn tôi thì… trưởng thành hơi chậm để kịp thời đương đầu với các khó khăn đó. Bây giờ là lúc bọn tôi phải nghĩ lại về tất cả mọi chuyện. Bản thân tôi sau khi nghĩ xong cứ thấy văng vẳng trong đầu là: đập đi làm lại.

Sun: Chết chết, đập thế nào được, cả đống người liên lụy ấy chứ. Nhưng mà nghĩ lại về những việc mình làm cũng là điều hữu ích. Thay đổi tư duy trước hết. 

Ken: Cho tôi tranh thủ hỏi bà một tí: theo bà thì nên đào tạo ra một con người như thế nào? Ý là lập trình viên ấy.

Sun: Nói về kỳ vọng thì dài lắm. Nhưng trước hết, ông cho tôi hỏi, ý ông là gì khi ông đề cập đến từ “lập trình viên”?

Ken: Là người lập trình… À, khoan… Câu này khó đấy! Quá khoai là đằng khác.

Sun: Đấy, đôi khi chúng ta quên mất định nghĩa cái mà mình muốn hướng đến. Thế thì thảo luận tiếp theo thế nào được. Tôi tin ông có nhiều tri thức về việc này hơn tôi.

Ken: Tôi tin cánh Employer như bà mới là người có định nghĩa rõ hơn. Cánh bọn tôi thường quan tâm tới khía cạnh nhà nghề là How-to mà ít khi thực sự để ý một cách có hệ thống về đầu ra. Cái này phải hỏi các bà mới đúng. Tôi đang mở tai lắng nghe đây…

Sun: Tôi thường xếp lập trình viên (LTV) vào ba cái giỏ.

Loại A: Những LTV cho các dự án Startup đi tìm sản phẩm mới, khách hàng mới, công nghệ mới.

Loại B: Những LTV làm cho các dự án gia công, cho nội bộ hoặc cho các khách hàng lớn với yêu cầu cao và khắt khe, đôi khi rất quái dị và khó tính về chất lượng sản phẩm cũng như thời hạn giao hàng.

Loại C: Những LTV cho các dự án không critical lắm, đôi khi là làm xong rồi bỏ, hoặc cho những khách hàng cực kì dễ tính, hoặc làm chỉ để báo cáo và giải ngân, chẳng để ý đến phần mềm đó có hữu ích gì không.

Ken: Loại A là hàng xịn, loại B gia công, loại C làm code dạo. Cũng dễ hiểu đấy. Xưa nay bọn tôi chỉ đào tạo hạng B thôi, từ ngày mua chương trình của các “thánh” outcourcing về bán lại cho dân mình, bọn tôi chủ trương không đào tạo engineer mà là worker, có phân khúc hẳn hoi. À mà nghe phân loại cứ như bà đang phân đẳng cấp ấy hehe.

Sun: Vừa đúng vừa không. Tôi nói rõ hơn nhé:

Nói rộng ra thì nghề nào cũng bình đẳng cả, công việc nào thì yêu cầu kĩ năng ấy, nên nói kĩ sư cao hơn nông dân là không đúng. Cứ cho ông kĩ sư canh nông đi cày xem có hơn ông nông dân không?

Lao động khi phân được phân công thì ắt là có những phân khúc như thế, dự án nào thì cần người tương ứng cho phù hợp. Loại A cho các dự án mở đường, ví dụ như RnD hoặc startup chẳng hạn, nó cần những người với năng lực phát triển sản phẩm (product development), phát triển khách hàng (customer development), đòi hỏi năng lực cách tân (innovation); nó đòi hỏi lập trình viên có khả năng linh hoạt (agility) cao độ để học tập nhanh nhất, tìm tòi nhanh nhất, hiệu quả nhất. Mà ông biết đấy, không chịu khó tìm kiếm cái mới mà cứ ăn mòn các thứ hiện tại thì sớm muộn gì cũng tèo, chẳng thể mút mãi một cục kẹo ngọt mà sống mãi được. Loại B cần cho các dự án gia công, đòi hỏi tính chắc chắn đôi khi là cứng nhắc, phụ thuộc khách hàng; một số trường hợp có sự phân hóa về kĩ năng cao độ, có anh chỉ cần thạo Excel, có anh chỉ cần thạo HTML, có anh chỉ cần thạo Data Base… là ra tiền rồi. Ở loại này, năng lực sáng tạo không phải là ưu tiên hàng đầu, sự thích nghi cũng thế, bởi vì ta có thể dùng các quy trình nhất định để giải quyết nhược điểm của nhân sự, tạo lập các Pool và điều phối là OK. Nhưng dĩ nhiên nếu nhân sự có được những phẩm chất đấy thì càng ngon.

Ken: Thế chẳng phải là loại A “đẳng cấp” hơn loại B rồi còn gì?

Sun: Chưa chắc, trong một số trường hợp, một anh cực giỏi Testing có thể hoạt động rất tốt trong các dự án gia công, lại không phát huy được nhiều trong dự án Startup vì ở đó đòi hỏi nhiều hơn ở Developer. Ngược lại, một số anh rất thạo Extreme Programming, làm code nhoay nhoáy, nhưng khi vứt sang một dự án outsourcing phân khúc test hoặc code theo thiết kế dựng trước; khi đó các thứ TDD, Pair-Programming chả để làm gì. Kiểu như dùng đại bác bắn chim thì vẫn có thể thua dùng súng cao su vậy. Cái cuối cùng là tính tới hiệu quả về kinh doanh thì kĩ năng cũng được coi là công cụ. Xưa nay người ta vẫn hay dùng từ resource (tài nguyên) để chỉ những thứ được huy động cho dự án, gồm cả con người đấy. Tài nguyên nào dùng vào dự án gì, hướng đến mục đích ra sao… nhiều khi bị điều khiển bởi mục đích kinh doanh như thế.

Cho tôi hỏi ông: ông có sẵn lòng trả 1000 đô cho một vị trí kiểm thử thủ công mức đơn giản không?

Ken: Không.

Sun: Đấy. Cho nên không phải là chuyện cao thấp, mà chuyện phù hợp. Loại C thì phù hợp với những công việc đơn giản, chỉ cần thợ mức trung bình là làm việc tốt.

Ken: Cái này tôi biết. Hiện nay sinh viên làng nhàng của chúng tôi vừa yếu tư duy vừa yếu kĩ thuật vừa yếu ngoại ngữ chỉ biết có đường code dạo thôi. Mà tôi hỏi thiệt, nước mình có hàng trăm trường đào tạo CNTT, sao lại thiếu nhân lực thế nhỉ?

Sun: Thừa thì vẫn thừa, thiếu thì vẫn thiếu. Nhưng thiếu nhất thì là nhân sự thuộc Loại A, Loại B cũng có nhưng số lượng không đủ, và đặc biệt yếu về ngôn ngữ (Tiếng Anh là chủ yếu) và tác phong làm việc, còn loại C thì chúng tôi lại không cần nhiều người mặc dù nơi này nơi khác có thể vẫn sử dụng nhiều. Như ông biết đấy, làm gia công cũng kiếm tiền tốt, nhưng sẽ tốt hơn nữa nếu có sản phẩm đột phá. Như thằng WhatsApp đấy, có mấy chục người mà làm ra công ty trị giá gần hai chục tỉ đô, bằng chục tập đoàn loại khủng ở Nhật, bằng một phần ba gì đó GDP một năm của Việt Nam, trong khi một ông cực giỏi có mấy nghìn Dev là FSOFT cũng chỉ kiếm ra có hai trăm triệu; hay như thằng FlappyBird đấy, nghe đâu mỗi ngày 1 tỉ đồng doanh thu. Làm kinh doanh thằng nào chả tham, không chỉ ham kiếm tiền mà lúc nào cũng ham kiếm rất nhiều tiền hehe. Mà muốn thế thì không thể trông chờ vào các anh Loại C kia được. Ngay cả đối với những trường như bọn ông, mỗi năm ông đào tạo cả nghìn người, nhưng toàn loại đi “code dạo” thì chẳng thể mang lại danh tiếng được, trong khi trường ông chỉ cần làm ra một Mark Zuckerberg thì nổi như cồn ngay, người ta kéo đến ùn ùn ngay, chắc ông nhớ cảnh phụ huynh đạp đổ trường Thực nghiệm để xin cho con học? Đất nước cũng cần những đầu tàu làm ra những cá nhân có khả năng tạo ra những sản phẩm ngon lành cho xã hội. Ông biết đấy chỉ có một FlappyBird mà bọn Mỹ ồn hết cả ào, rằng thì “hóa ra Việt Nam không chỉ có chiến tranh và ăn cắp vặt”, “Việt Nam đang dạy lại cách làm game cho thế giới”. Nếu có vài chục chú cỡ FlappyBird thì sao? Thương hiệu quốc gia chắc là sẽ thêm một góc lóng lánh, chưa kể là tiền sẽ đổ ào ào về Việt Nam. 

Ken: Ờ, nghe cũng bùi tai lắm. Hóa ra bà cũng là người lãng mạn. Còn loại B thì sao, chẳng phải là có nhiều người nói Việt Nam có cơ hội thành điểm gia công lớn của thế giới, thế thì chẳng phải đào tạo coder làm gia công là “đáp ứng nhu cầu của xã hội” tốt nhất hay sao?

Sun: Thì cũng có phần đúng, nhưng tôi đang nhấn mạnh về một cơ hội khác: sự liên hệ giữa làm sản phẩm mới và đẳng cấp của lập trình viên. Tôi nói cụ thể như thế này, ông là người trong ngành hẳn là biết rõ việc phân công lao động quá chi tiết dẫn đến việc nhân sự đôi khi chỉ biết dùng có mỗi một loại “võ công”, anh giỏi test thì lại không biết code, anh biết code lại không thèm để ý gì kiến trúc, anh QA lại chỉ biết có giấy tờ… Trong khi đổi mới lại cần những anh có các môn võ công tổng hợp, có khả năng thích ứng cao độ. Thêm nữa, quy trình của việc làm ra các sản phẩm cách tân cũng đòi hỏi nhân sự không chỉ có bộ kĩ năng đa dạng hơn mà còn phải làm chủ được quy trình phát triển sản phẩm linh hoạt. Không thể nói rằng ông có thể ngon lành mà không cần đến thứ na ná XP. Chắc ông biết rõ về quá trình khởi sự của Facebook, Atlassian hay Spotify …

Ken: Tôi có đọc những case study này. Chúng được đề cập kĩ trong sách về Lean Startup của Eric Ries, Steve Blank và nhiều tác giả khác.

Sun: Nói tóm lại, khởi sự sản phẩm hay một nhánh kinh doanh mới trong ngành công nghệ thì cần thạo ít nhất hai thứ: một là phát triển khách hàng (customer development), hai là Agile engineering. Chỗ customer developent thiên về kĩ năng liên quan đến thị trường, còn agile engineering thì có nỗ lực xóa mờ ranh giới cái gọi là chuyên viên (specialists, ví như chuyên viên testing, chuyên viên chỉ thiết kế DB)…

Ken: Tôi nghe đồng nghiệp phàn nàn nhiều về việc yêu cầu một lập trình viên phải vừa hiểu nghiệp vụ, vừa thạo việc code, lại vừa chịu trách nhiệm thiết kế, lại vừa phải đảm bảo chất lượng code… là hơi quá khắt khe. Là coder siêu hạng hết à?

Sun: Tôi nhắc lại, tôi đang nói về loại A. Không phải tất cả mọi người đều phải như thế.

Ken: Cái gọi là agile engineering mà họ nói đấy, bị nhiều đồng nghiệp của tôi phàn nàn nhiều lắm.

Sun: Tôi xin phép không gia nhập đội suốt ngày chỉ biết đến phàn nàn và kêu khó. Kể cả khi họ phàn nàn có lý thì tôi vẫn chú ý tới các khía cạnh tích cực và cơ hội của vấn đề. Không ai phủ nhận được thực tế là các công ty như chúng tôi bây giờ coi Agile là thứ không thể thiếu. Mà tôi không đơn độc đâu, nói có sách mách có chứng nhé, bọn Forrester Research nó làm thống kê rồi: trên 30% công ty đang dùng Agile, gần tưng đó sử dụng một số triết lý giống Agile. Lí do rất đơn giản: như tôi nói phần trên, nó là vấn đề sống còn của business của bọn tôi. Đấy là tiếng nói từ Industry, còn bọn SEI (Software Engineering Institute thuộc Carnegie Mellon University) sau khi khảo sát một hồi cũng đi đến kết luận là Agility là yêu cầu bắt buộc cho nhân lực thế kỉ XXI đầy biến động này. Mà tôi hỏi các ông đã dạy cái này trong trường chưa?

Ken: Có, nhưng hơi dè dặt bà ạ.

Sun: Sao lại không mạnh dạn lên? Tôi thấy nó có cao siêu gì đâu? Bây giờ những IDE tiêu chuẩn như VS, NetBeans, Eclipse… để làm việc đều hỗ trợ Agile tận răng, tức là nó trở nên mainstream, sao lại còn phải dè dặt? Phải để 100% sinh viên biết thế nào là XP, 100% biết thế nào là Scrum, 100%…

Ken: Đừng quá khích thế chứ. Các thầy sợ sinh viên phải học nhiều quá đấy!

Sun: Đấy, chết ở chỗ ấy! Các ông vẫn dạy toàn cái cũ, thế thì thời gian đâu cho những cái cần thiết cho thì hiện tại và tương lai. Tôi ngờ là giáo viên các ông chây lười bỏ mẹ, không chịu học hỏi nên cứ cái cũ mà làm cho đỡ tốn công?

Ken: Ấy ấy, sao lại nặng lời thế? Nhưng mà tôi đồng ý với bà hehe. Đấy là một tình trạng đáng ngại. Nói thật với bà, tôi đang tính ra ở riêng…

Sun: Hay quá. Mạnh dạn là tốt, ông định thế nào?

Ken: Có nhiều ý giống bà đấy hehe

Sun: Nói nghe xem nào, tôi ném đá cho

Ken: Nói ngắn gọn nhé. Tôi tập trung suy nghĩ về business với ba câu hỏi chủ chốt: Đầu ra trông như thế nào? Học gì để được cái đó? Và học như thế nào? Tạm thời tôi chưa nghĩ đến nhu cầu về thị trường vội. Thực ra là việc đó sẽ dễ dàng hình dung được sau khi khớp được đầu ra của mình với nhu cầu hiện có và tương lai của ngành.

Sun: Đấy là các câu hỏi đúng đắn để đặt vấn đề. Ông nói tôi nghe xem nào, có thể chúng ta còn nhiều điểm chung nữa đấy!

Ken: Câu hỏi một, “Đầu ra trông như thế nào?”, tôi xin trả lời luôn cho gọn: phần lớn sẽ là Loại A theo cách phân loại của bà, với yêu cầu khắt nghe nhất về kĩ thuật, có trang bị đầy đủ các phương pháp luận về sáng tạo, các quy trình phát triển đa dạng (cả Agile/Lean lẫn các quy trình tuyến tính hóa khác dạng waterfall), với khả năng giao tiếp ngon lành bằng ít nhất hai thứ tiếng (mẹ đẻ và tiếng Anh), trang bị cơ bản về business, quản lí và lãnh đạo nhóm, cũng như khả năng học tập suốt đời. Đầu ra này thỏa mãn cả cho khu vực sáng tạo/startup và cả khu vực gia công chất lượng cao.

Sun: Tham đấy..

Ken: Như bà gợi ý đấy, tôi sẽ không dạy những thứ ít dùng. Hơn nữa, nếu có cách làm đúng đắn thì học ít nhưng được nhiều và cao. Nhưng khoan bàn về chuyện đó vội, tôi nói về câu hỏi thứ hai đã: “Học cái gì?”. Kể ra thì dài lắm, nhưng túm lại là cũng chỉ có xoay quanh mấy cái năng lực cốt lõi này thôi:

1. Năng lực tự học và thích ứng
2. Năng lực giao tiếp (bằng hai thứ tiếng, Anh và Việt). Tôi nhắc lại nhé, cả tiếng Việt đấy!
3. Năng lực tự quản lí bản thân
4. Năng lực nhóm (cộng tác, quản lí và lãnh đạo)
5. Năng lực lập trình linh hoạt (với tiêu chuẩn cao của một software craftsman – một nghệ nhân phần mềm)
6. Năng lực sáng tạo và đổi mới
7. Năng lực thực hành đạo đức nghề nghiệp (professionalism)

Sun: Sao không thấy Java hay .NET, là thứ mà các ông cứ hay nhắc đi nhắc lại là thế mạnh?

Ken: Gói trong trong cái số 5 rồi. Nhưng, từ lâu tôi nhận ra cốt lõi không phải là Java hay .NET, hay Python mà vẫn nằm ở các kĩ nghệ lập trình. Đó là cái lõi, còn Java và .NET hay gì gì đó là những công cụ, là những vật mang. Chỉ cần thạo cái lõi thì cộng với năng lực tự học và thích ứng tốt, ta sẽ có được những thứ khác trong thời gian ngắn. Dĩ nhiên là ta phải học lập trình thông qua một vài ngôn ngữ và platform nào đấy, nhưng nó không phải là cái đích của việc đào tạo. Peter Norvig có lần mỉa mai các cuốn sách“Tự học  Lập trình ABC trong vòng 21 ngày” bằng một bài viết rất nổi tiếng là “Tự học lập trình trong 10 năm”, bọn tôi dịch và đăng trên Tạp chí Lập trình rồi đấy, view ầm ầm. Bác ta phê phán cái chuyện người ta cứ hay chạy theo cái vỏ, mà quên mất cái lõi thực sự. Theo nguyên lí dài hơi đó, chuyện “tự học suốt đời” không phải là khuyến khích nữa, nó là bắt buộc. Nhưng bấy lâu nay, chẳng nhà trường dạy người ta tự học thế nào. Có nhiều người cứ thích hô hào khẩu hiệu “học tập suốt đời” nhưng chả hiểu gì. Nhiều người quan niệm có bằng là “học xong”, thế là chết rồi. Quan niệm sai lầm đó thực ra là lỗi tại nhà trường. Chẳng trường nào thực sự dạy người ta trang bị một tinh thần và năng lực để học tập suốt đời cả.

Sun: Tôi thấy rất hấp dẫn ở chuyện tự học, rất “make sense”. Như thế thì doanh nghiệp sẽ bớt được khá nhiều khoản đào tạo lại và đào tạo liên tục. Thử tưởng tượng là chỉ cần giảm tỉ lệ đào tạo lại từ 80% như hiện nay xuống còn một nửa thì doanh nghiệp (nói rộng ra là xã hội) tiết kiệm được bao nhiêu tiền…

Ken: Điều quan trọng nhất là việc đó cần bắt đầu từ trong lúc ngồi trên ghế nhà trường. Thực ra điều tôi nói ở đây dựa trên một trong những kết quả quan trọng trong các nghiên cứu giáo dục học: việc phát triển các kĩ năng tự học (meta-cognition) sẽ giúp cho việc học của sinh viên trở nên dễ dàng và hiệu quả hơn rất nhiều. Thế thì bồi dưỡng năng lực tự học ở trong nhà trường vừa là đích đến, nhưng cũng vừa là phương tiện hữu hiệu để gia tăng đáng kể năng suất học tập.

Sun: Tôi mới nghe lần đầu đấy, tôi cứ nghĩ rằng năng lực tự học là trời phú.

Ken: Phần lớn giáo viên hiện nay cũng “ngỡ” giống bà. Đó là một ngộ nhận nghiêm trọng. Phần nhiều giáo viên đòi hỏi sinh viên phải tự học, phải có phương pháp học tốt, phải nọ phải kia. Nhưng kêu họ chỉ rõ những thứ đó là gì, làm thế nào để đạt được, sinh viên cần làm những gì thì phần lớn là ú a ú ớ, qua loa đại khái. Việc đơn giản nhất như đọc một cuốn sách, học trò ngày nay đánh vật cả tháng trời vẫn chưa xong một chương. Trong khi một chuyên gia phải xử lí cả tạ sách mới mong sâu sắc được. Ấy thế mà chẳng ai giúp họ cả. Bởi vì ít người quan tâm đến khía cạnh này. Không phải là giáo viên dốt, mà là ít khi để ý. Giống như đi trên đường vậy, bà mà không để ý thì đố bà biết là sáng nay bà đi qua mấy cái đèn đỏ đấy!

Sun: Nhưng liệu đó có phải là một năng lực có đạt được dễ dàng không?

Ken: Với biện pháp sư phạm đúng đắn thì hoàn toàn khả thi. Chắc bà có nghe qua nhóm Cánh Buồm đúng không? Họ chủ trương bậc tiểu học là bậc Phương pháp học, tức là họ tự tin trang bị cho trẻ con thành thục phương pháp học từ tấm bé, để đến lớp 6 là học sinh đã có thể tự mình tìm tòi tri thức mới (dĩ nhiên là có sự hướng dẫn và trợ giúp) cho mình. Tôi đồng ý với quan điểm đúng đắn của họ rằng giáo dục suy cho cùng là tự giáo dục, chẳng ai ép anh thạo cái gì nếu như anh không tự mình thạo cái đó. Học cũng thế thôi. Cái rất cần cho tất cả mọi người là: Thạo việc học.

Sun: Quả đúng như vậy.

Ken: Tôi lấy ví dụ thêm nhé, ông Jean Piaget đấy, ngay từ lúc 11 tuổi đã làm nghiên cứu khoa học rồi. Dĩ nhiên là nó chưa hoành tráng. Tôi tin là bằng phương pháp sư phạm đúng đắn, có thể tái hiện điều đó cho số đông.

Sun: Nhưng mà này… ông có đơn giản hóa vấn đề không khi đặt vấn đề về năng lực lõi có vẻ cũ kĩ? Thế ông định đặt các công nghệ mới ở đâu? Ngoài Java, .NET còn nào thì SMAC xì miếc? Không học thì sao thành thục được? Ai dám tuyển dụng những sinh viên của ông?

Ken: Cho tôi sửa một chữ của bà nhé: Cổ điển chứ không phải cũ. Cổ điển tức là cái mang tính chuẩn mực và cốt lõi. Như nhạc cổ điển ấy, hơn hai trăm năm trước ông Mozart bên tây soạn nhạc cổ điển, đầu thế kỉ XXI này ông Đặng Hữu Phúc ở ta vẫn soạn nhạc cổ điển cho người ta chơi và nghe đấy thôi! Người học nhạc kinh điển thì vẫn học những thứ kinh điển ấy, nó có giá trị xuyên thời gian. Một anh học lập trình về cơ bản sẽ vẫn phải đi qua một vài ngôn ngữ nào đó, làm chủ các cấu trúc dữ liệu và giải thuật, biết tận dụng các framework phù hợp cho các giải pháp đặc thù, các nền tảng và hệ sinh thái ứng dụng khác nhau. Nhưng, tôi nhắc lại nhé: công nghệ thì nhất thời, nội lực tư duy và giải quyết vấn đề thì còn mãi. Còn dĩ nhiên là phải học công nghệ mới rồi, cái đó nếu đứng riêng rẽ thì là thứ cộng thêm, nếu kết hợp với năng lực cốt lõi như tôi nói thì nó thành sức mạnh đột phá để sáng tạo. Nắm được công nghệ là nắm được lợi thế cạnh tranh lớn, nhưng điều quan trọng là biết dùng công nghệ ấy để làm ra cái gì chứ không phải là học xong để đấy. Tôi hỏi bà, người ta cứ tung hô Mây mù với lại Mobi mô biếc, thế tôi đố bà chỉ ra cho tôi một giải pháp hay sản phẩm tử tế của mấy ông hô hào đấy! Cho nên là cứ phải “back to classic” cho tử tế đã, người ta đang thiếu cái đó.

Sun: Nhân tiện, ông trả lời luôn cho câu hỏi “học thế nào?”, với trường hợp cụ thể này đi, tôi hỏi lại cho rõ nhé “làm thế nào để có năng lực tự học?”

Ken: Đây là nghề của người dạy học, chính là chỗ phân biệt rõ nhất về nghề nghiệp của một giảng viên so với một chuyên gia phần mềm đây.  Nếu như anh chuyên gia có việc chính là làm ra sản phẩm phần mềm xuất sắc thì anh giảng viên biết rõ cách giúp cho người khác trở thành người làm ra phần mềm một cách xuất sắc.

Sun: Tôi hiểu. Tôi chẳng bao giờ ngộ nhận chuyện đó cả, một chuyên gia giỏi có thể dạy học rất tồi, và ngược lại. Anh nói rõ thêm về chuyện tự học này đi, tôi hơi sốt ruột rồi đấy.

Ken: Cứ từ từ. Tôi hỏi bà điều này đã: bà quan niệm tự học là gì?

Sun: Là tự mình học, học ở nhà, là học mà không cần thầy giáo chứ sao?

Ken: Thế thì cần nhà trường làm gì? Cần quái gì thầy giáo? Nhất lại là trong bối cảnh bà có thể lên Internet có tất tần tật thông tin các loại.

Sun: Ông làm tôi giật mình rồi đấy!

Ken: Đấy, quan niệm về tự học mà chỉ đơn giản như bà nói thì làm giảm vai trò của nó đi nhiều lắm; chưa kể là không khéo lại dẫn đến tình trạng rất bi hài kịch là một số người chuyển từ thái cực nhồi nhét cho bằng được thật nhiều thông tin cho sinh viên sang thái cực là quẳng hết việc cho sinh viên bằng những bài tập lớn, chẳng giảng gì nữa. Có anh bảo: nhớn rồi, tự bơi đi. Phần lớn là chưa bơi đã chết đuối hết cả, thầy trò đều chết đuối keke. Như thế thực ra là một dạng rũ bỏ trách nhiệm chứ chẳng phải là áp dụng phương pháp gì.

Sun: Đúng đúng đúng đúng! Hỏi lại, thế làm thế nào để phát triển năng lực tự học? Sốt hết cả ruột!

Ken: Về những chi tiết bếp núc của việc đào tạo thì có thể rất rắm rối, nhưng về ý tưởng thì lại hết sức đơn giản. Đơn giản hơn chúng ta có thể tưởng: Là tổ chức cho sinh viên lặp lại những trải nghiệm quan trọng của những lập trình viên giỏi một cách có ý thức. Để sinh viên tự học được năng lực lập trình thì phải xem các coder siêu hạng đã trải qua việc đó như thế nào. Ông biết đấy, ông Gladwell có nói tới quy tắc 10 000 giờ, mà ông Peter Norvig nhắc lại trong “Tự học lập trình trong 10 năm” ấy. Ta cần tìm ra một cái mẫu mà một lập trình viên có thể lặp đi lặp lại một cách có hệ thống để thành thạo dần dần. Không một newbie nào thành master trong vòng một tháng được, mà cần tới khoảng 10 năm. Cho nên chẳng bao giờ có chuyện “học xong” ngay khi “học xong” một môn nào đó cả, mà nó mới chỉ là “bắt đầu”. Bí quyết nằm ở chỗ, nếu mình thấy được ông Master làm thế nào để trở thành master thì mình lọc nó ra, quy trình hóa nó và tổ chức cho người học đi lại nó. Khi đó, người học sẽ tự mình làm ra năng lực cho mình. Vai trò của giáo viên ở chỗ tổ chức cho người học làm điều đó, đôi khi là khích lệ, đôi khi là tư vấn, đôi khi là trợ giúp. Cái đó gọi là sự tự học có thiết kế và có sự trợ giúp, một dạng thực hành có chủ đích (deliberate practice) mà các nhà tâm lí học giáo dục có nhắc đến. Nếu quan niệm dạy học là truyền đạt, thì việc học sẽ “xong” ngay khi các thông tin cuối cùng được ông thầy thuyết giảng; còn nếu ta quan niệm việc học như là tổ chức hoạt động như thế thì việc tự học tự nhiên được sinh viên thực hành hằng ngày, mỗi ngày một tốt lên, và chính họ tự làm ra kiến thức cho mình. Dù có giáo viên hay không, cuối cùng thì mỗi người đều phải tạo dựng năng lực của chính mình.

Sun: Tức là vai trò của người thầy phải thay đổi từ chỗ giảng giải sang tổ chức hoạt động và làm công tác hỗ trợ (facilitator) đúng không?

Ken: Đúng rồi. Như thế bà có thể thấy là công việc của giảng viên dạy lập trình và một tay lập trình viên siêu hạng là khác nhau rất nhiều, chẳng thể lẫn được.

Sun: Lâu nay tôi hay nghe là “learning by doing”, tôi cũng thường nghĩ là đấy là cách tốt nhất để học cái mới, mà tôi vẫn thực hành hằng ngày đấy thôi. Không học điên cuồng, đố đứa nào làm CEO nổi 100 ngày. Nhưng chưa bao giờ tôi nghĩ nó là một phương pháp sư phạm cả.

Ken: Ừ. Điều quan trọng nữa là, nhiệm vụ của người thầy, cũng là cái hay dở của người thầy là ở chỗ làm sao để thúc đẩy cái tiến trình đó nhanh hơn. Bởi vì anh được trang bị những kiến thức về tâm lí giáo dục, về xã hội học giáo dục và khoa học về thần kinh, cũng như hàng tá các lí thuyết về việc học (learning theories), thì anh phải biết vận dụng những cái đó vào công việc hằng ngày. Anh gia tăng năng suất lao động của mình với những “súng ống” đặc thù đó. Một thầy giỏi là phải giúp được thật nhiều học trò gia tăng đáng kể năng suất học tập của mình.

Sun: Nhưng làm sao để ông biết là con đường một lập trình viên đã đi là con đường nào? Có cả hàng trăm nghìn con đường ấy chứ! Mà ông không phải là lập trình viên giỏi thì làm sao ông tỏ tường con đường ấy là con đường nào?

Ken: Câu hỏi hay quá! Tôi cũng không nghĩ rằng có một con đường nhất quán. Nhưng để tìm ra một con đường cơ bản thì không phải quá khó khăn. Bà đọc “Coders at work”chưa? Tôi tìm thấy rất nhiều mẫu số chung trong cách phát triển của các lập trình viên giỏi. Mình phải lấy cái mẫu từ những người giỏi, đem phân tách, so sánh và chắt lọc các thao tác có ý nghĩa, sắp xếp lại, thiết kế và tổ chức các hoạt động mang tính sư phạm để người học làm lại điều đó một cách dễ dàng nhất. Đấy cũng chính là cốt lõi của sư phạm. Còn dĩ nhiên là người thầy phải biết lập trình, giỏi là một lợi thế, nhưng không phải là yêu cầu bắt buộc đối với đại đa số.

Sun: Tôi tạm hiểu phần nào rồi. Giờ thì quay lại bộ các năng lực cốt lõi mà ông đã đề cập. Tôi đang thắc mắc tại sao quản lý bản thân lại được ông nhìn nhận như là năng lực cốt lõi?

Ken: Khi mang cái bộ năng lực này ra, một số người còn nhấn mạnh đây là năng lực số 1, có nó thì mọi việc khác tự nhiên sẽ đến. Tôi cũng thấy cái năng lực này là mẫu số chung của nhiều nghiên cứu về năng lực và kĩ năng cần thiết được đề xuất bởi một số tổ chức nghiên cứu thị trường lao động, điển hình như ETS với bản báo cáo “Standards for What?The Economic Roots of K-16 Reform”. Tôi hỏi nhé, bà thích bao nhiêu nhân viên của mình thật chủ động khi làm việc?

Sun: 100%, dĩ nhiên rồi!

Ken: Thế hiện nay bà có bao nhiêu nhân viên thực sự chủ động trong công việc?

Sun: Tôi sẽ về thống kê lại, nhưng chắc là không nhiều.

Ken: Nghề của bọn tôi là đảm bảo phần lớn đạt được điều đó…

Sun: Nhất trí, tôi sẽ không hỏi sâu thêm về điều này nữa. Nhưng có một điều chắc chắn là cánh Employer của bọn tôi sẽ hưởng lợi nhiều từ việc này. Tôi sẵn sàng đặt hàng các ông những nhân viên tương lai như thế. Miễn là “hàng xịn” như quảng cáo hehe. Tôi hỏi điều cuối: cái professionalism có phải là đạo đức nghề nghiệp không? Đạo đức nghề nghiệp của một lập trình viên là cái thứ chi chi?

Ken: Cái này tôi không phịa ra, tôi nhắc lại bác Bob (Robert C. Martin) thôi, tất cả được đề cập rất chi tiết trong tác phẩm “Clean Coder” của bác. Thực ra bác Bob không hề cô đơn. Ngay từ đầu thập kỷ trước, Kent Beck, tác giả của lập trình cực hạn (XP) đã mạnh dạn tuyên ngôn cho những người lập trình viên: đó là những người đang làm thay đổi thế giới thông qua sản phẩm họ làm ra, vì thế họ cần có đầy đủ trách nhiệm với xã hội thông qua công việc của mình, chính họ phải làm cuộc sống tốt đẹp hơn, và nghề nghiệp đó cũng cần được ghi nhận tương xứng. Nhưng để được ghi nhận, thì trước hết LTV phải tự xứng đáng, và tự biết mình cái đã. Tôi muốn nhấn mạnh điều này thực sự là hệ trọng ở Việt Nam bởi lẽ nghề coder vẫn bị chính coder và những người khác coi rẻ  trong hệ thống nghề nghiệp trong ngành IT. Người ta cứ đổ dồn để phấn đấu thành manager này leader nọ mà quên trau dồi nghề ngỗng cho đàng hoàng. Về mặt cá nhân, nó khiến coder rất tự ti và sống thiếu đàng hoàng với chính mình (mặc dù đâu đó cũng có vài chú ảo tưởng về nghề nghiệp, nhưng cũng chỉ là chút ảo giác ban đầu, xong rồi đâu lại vào đấy, tự ti như nhau cả); về mặt nghề nghiệp và xã hội, rõ là nó gây thiệt hại đáng kể trong việc gây dựng đội ngũ chuyên gia thứ thiệt, có trách nhiệm, và tích cực đóng góp đáng kể cho ngành nghề và đất nước. Ví dụ cho vui nhá: ở nước mình chưa có hiệp hội Lập trình viên, trong khi hội những người yêu hip-hop thì đông lắm. Tôi hỏi thật, chỗ bà có bao nhiêu lập trình viên với hơn 10 năm kinh nghiệm?

Sun: Tôi không đếm, nhưng hình như là trên đầu ngón tay. Mà lại không có tên người Việt.

Ken: Đó có thể coi là một khiếm khuyết mang trong mình yếu tố quán tính văn hóa của người Việt, nhưng cũng là khiếm khuyết của các tổ chức trong việc tạo ra một môi trường đủ tốt để thúc đẩy các lập trình viên tự tin bước đi trên một lộ trình dài hơi, liên quan đến chính sách về quy hoạch nghề nghiệp, cũng như văn hóa công ty. Tôi cho rằng, chúng ta phải thay đổi hiện trạng đó, nhưng không thể hô hào các doanh nghiệp được, mà cần bắt đầu từ cái lõi nhất: tính chuyên nghiệp theo nghĩa đầy đủ nhất của một cá nhân trưởng thành hành nghề lập trình. Tôi tin vào sức mạnh thay đổi thế giới của giáo dục.

Thực ra professionalism có giá trị vượt ra ngoài cụm từ dễ gây hiểu nhầm là “đạo đức nghề nghiệp”. Professionalism đặt ra các câu hỏi rất mật thiết liên quan đến cuộc sống của mỗi người, đến giá trị sống, đến những thứ sát sườn như giá trị là gì, giá trị của nghề nghiệp là gì, giá trị của bản thân, của tổ chức là gì, làm sao để đạt được hạnh phúc… Gần đây tôi đặc biệt đến chương trình “Search Inside Yourself” của Google, rất hay. Họ xây dựng các chương trình để giúp lãnh đạo và nhân viên cùng tập thiền với sự trợ giúp của các thiền sư tiếng tăm, như thầy Thích Nhất Hạnh chẳng hạn; từ đó để nhận ra các chân giá trị từ bên trong, vừa giúp gia tăng hiệu quả công việc, nhưng cũng để được hạnh phúc nhiều hơn. Điều đáng chú ý là Google không phải là trường hợp cá biệt có những chương trình kiểu đó. Nói thêm tí nữa, hồi năm ngoái tôi có đọc được cuốn “Five Minds for the Future” của Howard Gardner, ông ấy có điểm danh năm trí tuệ cơ bản cần cho tương lai: Bên cạnh trí tuệ Chuyên ngành (Disciplined Mind), Tổng hợp (Synthesizing Mind), Sáng tạo (Creating Mind) thì còn hai trí tuệ khác thuộc về khu vực nhân văn là Trí tuệ Tôn trọng (Respectful Mind) và Trí tuệ Đạo đức (Ethical Mind). Cho nên những gì được gói ghém trong Professionalism vừa mang một mục tiêu cụ thể về nghề nghiệp hết sức thực dụng, nhưng cũng vừa mở ra một cánh cửa thênh thang để học tập và thực hành suốt đời những điều hết đỗi quan trọng cho cuộc sống.

Sun: Nghe đau hết cả đầu! Tôi sẽ nghiên cứu kĩ điều này sau. Thôi, có lẽ ta dừng ở đây đã, mặc dù vẫn còn vài nghi vấn nữa trong số các thứ mà ông đề cập. Nhưng để lần sau ta trò chuyện tiếp. Cũng cần thời gian để nghĩ lại về những gì chúng ta vừa trao đổi. Tôi có thể thấy là với đường lối như thế này thì có vẻ là ông  đang đi đúng hướng, tôi sẽ đặt hàng những sản phẩm từ lò đào tạo của ông  và kiểm chứng những gì ông nói. Thời gian phía trước là của chúng ta mà hehe. 

Họ cùng nhau nhâm nhi những giọt cà phê đặc quánh cuối cùng trước khi tạm biệt nhau và hẹn sớm gặp lại.

Dương Trọng Tấn