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:
- Năng lực tự học và thích ứng
- 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!
- Năng lực tự quản lí bản thân
- Năng lực nhóm (cộng tác, quản lí và lãnh đạo)
- 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)
- Năng lực sáng tạo và đổi mới
- 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 – dadien.net
Loại A chắc phải có được : sự đam mê + cảm hứng + ý thức tự nghiên cứu + chí hướng và + với một bộ não thực sự hoạt động đúng vai trò của nó.
Tôi thích lập trình vì tôi học được tính logic của nó và áp dụng được nó cuộc đời.Bất cứ một sự việc gì trong cuộc sống tôi cũng coi nó như một bài toán của lập trình để có thể đưa ra mọi case có thể xảy ra và từ đó kiểm tra tính khả thi của nó. Và điều tôi ao ước, giá như cuộc đời có thể debug được.
mong là Ken và Sun sẽ gặp lại nhau và bàn tiếp 🙂
Mình có ý kiến 1 chút về đoạn loại A và đoạn này “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ờ”
Lý do của những chuyện này:
– Thứ 1: Đa số mọi người coi code hay test chỉ là 1 nghề để kiếm tiền và khi thu nhập họ thấy đủ rồi thì họ chẳng cần nâng cao trình độ làm gì.
– Thứ 2: Đúng là đa số tester thường có xu hướng không chịu học hỏi kiến thức mới, test web làm bao nhiêu năm và vẫn chẳng biết html là gì, cơ bản về database cũng không biết, mặc dù những cái đó học để làm thì cần nhiều thời gian chứ học để hiểu thì quá dễ.
– Thứ 3: Tại sao lại có chuyện developer không biết làm architect, bỏ qua những người không chịu học, nói đến những người muốn học để biết làm đi. 1 là chẳng có nơi nào dạy cái đó, thứ 2 là software architect phải từ những dự án thực tế, thứ 3 là vào dự án rồi cũng chẳng ai nói cho bạn kiến trúc phần mềm của dự án đó vì cái đó vừa là bí mật kinh tế, vừa có lý do cạnh tranh trong công việc. Kiến trúc phần mềm cũng như kiến trúc tòa nhà trong xây dựng, những tòa nhà kiểu như tháp Effein , Keangnam chẳng mấy người biết, thiết kế xong họ phải bảo mật và mỗi người chỉ biết đủ để làm
Về đoạn này:
“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ì.”
Làm cái gì cũng cần nhiều kinh nghiệm hết, khi 1 nhân sự của công ty bạn làm không tốt mà bạn là quản lý chỉ nghĩ là họ chỉ có thể làm 1 thứ chỉ là do bạn không có kinh nghiệm làm thực tế nên nghĩ rằng 2 cái nó giống nhau nên chuyển sang làm cũng thế. Nói ví dụ như kỹ sư sản xuất xe máy thì giỏi sản xuất xe máy, chuyển sang làm sản xuất ô tô thì phải có thời gian tích lũy kinh nghiệm. Nếu muốn nhanh thì phải những người đi trước truyền lại là nhanh nhất, nhưng người đi trước họ vì cạnh tranh họ sẽ không truyền lại và họ nói với quản lý rằng anh này kém không tiếp thu được. Bạn có thể nghĩ đến tìm tổ chức bên ngoài dậy, nhưng thực tế thì chả có tổ chức nào dậy những cái đó.
Bài của bạn viết cũng có những thứ đúng, nhưng cũng có những điểm do kinh nghiệm thức tế không chính xác và không đi sâu đi sát vào tổ chức.