Trong Agile Y, tôi có đề cập tới yearly master plan – phương pháp được tôi sử dụng để tạo lập kế hoạch. Tôi không phải là người theo đuổi trường phái thiết lập và bám theo những kế hoạch dài hạn, song tôi khuyến khích mọi người cần có mục tiêu và một kế hoạch phác hoạ cho một năm; và vì thế, cần có yearly master plan.

Mỗi năm, tôi thường dành từ 1/2 đến 1 ngày để tạo master plan vào ngày đầu năm (dương lịch) với các bước sau:

  1. Liệt kê những công việc muốn làm trong năm, theo độ ưu tiên. Ví dụ:
    1. Đọc 18 cuốn sách
    2. Đi du lịch 3 thành phố
    3. Viết 1 cuốn sách
    4. Viết 20 bài blog
    5. Học bơi
  2. Dự trù tài chính. Tính toán dòng tiền vào, ra hàng tháng, chi tiêu cố định, chi tiêu phát sinh, tiết kiệm… Ví dụ:
    1. Tháng 1: lương: 20 triệu, chi tiêu: 10 triệu, tiết kiệm: 10 triệu
    2. Tháng 2: lương: 20 triệu, chi tiêu: 20 triệu (hàng tháng: 10 triệu + Tết: 10 triệu), tiết kiệm: 10 triệu
    3. Tháng 3: lương: 20 triệu, chi tiêu: 15 triệu (hàng tháng: 10 triệu + mua điện thoại: 5 triệu), tiết kiệm: 15 triệu
  3. Dự trù thời gian. Tính toán thời gian cố định cho công việc, giao lưu, nghỉ ngơi… Ví dụ:
    1. Tháng 1: Bận chuẩn bị Tết, dư 15 giờ
    2. Tháng 2: Nghỉ Tết, dư 40 giờ
    3. Tháng 3: Muốn du lịch châu Âu
  4. Đánh giá 3 danh sách trên. Ba yếu tố trên chính là những yếu tố ràng buộc lẫn nhau, cho thấy được thời điểm và tính khả thi của từng mục tiêu. Ví dụ: Tháng 2 thích hợp cho việc đọc sách và viết blog, tháng 3 là không thích hợp cho mục tiêu du lịch châu Âu bởi tình hình tài chính chưa đảm bảo nhưng lại đủ cho mục tiêu học bơi hoặc du lịch trong nước;… Quay trở lại các bước 1-2-3, điều chỉnh lại mục tiêu, danh sách công việc và thời điểm cho phù hợp. Ví dụ: Điều chỉnh mục tiêu du lịch 3 thành phố xuống 1 hoặc điều chỉnh dự trù tài chính: cần tiết kiệm hơn, cần tìm kiếm nguồn thu khác…
  5. Liên tục lặp lại các bước này tới khi 3 yếu tố trên đạt sự cân bằng cần thiết và khả thi. Thông thường, một năm tôi sẽ chọn lấy 2 công việc cần thực hiện, trong đó có 1 công việc phải thực hiện: năm trước nữa là du lịch châu Âu, năm trước là Agile Y…

Tất nhiên, khi thực hiện, chúng ta khó có thể bám theo yearly master plan một cách hoàn hảo do hàng trăm sự kiện xảy đến trong năm khiến chúng ta phải điều chỉnh lại kế hoạch / mục tiêu theo từng tuần. Song yearly master plan rất quan trọng, nó cho thấy những gì chúng ta có thể làm và ưu tiên cao nhất trong một năm.

86 total views, no views today

Year ago, I had a post about iterating through collection. Today my colleague’s question gave me the idea about an example of using collection right. Let’s say we have a collection like NSArray that contains multiple NSString objects, we want to print them in lines includes the line number.

Easy problem, right? Let’s see we have some solutions:

What’s a best way? I can say #2 > #3 | #1.

About #3, you can refer to my post to know why we should use iterator instead of index while going through collection. Of course they perform same with NSArray but using iterator help us more easily use another collection type later. So #1 and #2 are usually better than #3. Why is #2 better than #1? The issue is:

#1 is O(n) while #2 is O(1). We can see #1 is more readable (a bit easier to understand than #2) but #2 has better performance.

You could see #1 is worser in some way. In case of duplicated strings in lines, you may also get wrong result (index is the first found): http://stackoverflow.com/questions/3167849/indexofobject-vs-indexofobjectidenticalto 

Hôm nay đồng nghiệp hỏi câu này: Tại sao nên viết như #a thay vì #b?

Tôi mở rộng câu hỏi thành: Sắp xếp các cách viết sau theo thứ tự “tốt dần”.

Khá khó để nói #3 và #4, cách nào tốt hơn; nhưng có thể dễ dàng khẳng định #1 và #2 không tốt bằng #3, #4. Tại sao?

Nguyên tắc chung của lập trình hướng đối tượng là trừu tượng hoá và cố gắng tối đa việc trừu tượng hoá. Trừu tượng (không phải là giải pháp toàn vẹn nhưng) là một phần trong cách tư duy về Open / Closed principle. #1 rất trực quan và dễ hiểu: tạo một danh sách lưu trữ sách dưới dạng ArrayList. Nhưng những thứ cụ thể rất khó để sửa đổi và thay thế. Ví dụ, sau khi implement, chúng ta phát hiện ra đoạn code phía sau sử dụng rất nhiều thao tác thêm phần tử vào list thay vì lấy phần tử ra; do đó lưu trữ dưới dạng Stack cho hiệu suất tốt hơn; chúng ta phải sửa đổi các đoạn code phía dưới với implement cụ thể của Stack (thay cho ArrayList). Một thời gian sau, nhu cầu lấy phần tử từ list đủ nhiều để sử dụng ArrayList cho hiệu suất tốt hơn, chúng ta phải sửa lại đoạn code phía dưới với implement cụ thể của ArrayList. (Tham khảo: hiệu suất các implement của List). Khổ chưa?

Một cách thông minh hơn là sử dụng #3, khi đó, đoạn code phía dưới chỉ sử dụng những method được định nghĩa cho interface List. Khi cần thay đổi implement cụ thể thành Stack, LinkedList…, chúng ta chỉ đơn giản thay new List<Book>() bởi new Stack<Book>() hay new LinkedList<Book>(). 

Và theo cách tư duy đó, #4 tốt hơn #3? Không hẳn, nếu chúng ta đã xác định list chỉ chứa Book, việc khai báo list chứa Object khiến chúng ta có thể mất công cast những object này trong trường hợp sử dụng những method cụ thể của Book (và thường là vậy). Nên dùng #4 thường là bất lợi hơn #3 (trừ trường hợp list chữa những object khác ngoài Book).

Do đó, sử dụng #3 (khai báo interface và khởi tạo bằng class (đương nhiên)) thường là cách viết nên được “quen tay”.

Thật ra #3 còn nên viết theo 1 cách khác tốt hơn như sau. Tại sao nhỉ?

442 total views, no views today

Following the topic in my short post eXtreme Programming is Dead, I had a talk at the monthly meetup of Agile Vietnam, Feb 2017, to explain more about my opinion.

Half of time, I focused on describing what exact eXtreme Programming (XP) is. Today most of development teams are applying some XP practices but they just do it with forgetting what are behind the scene: values and principles. It’s time to recall to how to do it right.

Then I explain more about my idea, why XP is dead. It’s dead in some ways: teams just follow the practices without knowledge of values and principles, the practices is more and more becoming standards of software development instead of extreme, original XP makes the confusion of applying it at enterprise.

You can find the slide here – it just is the outline, I will try to explain more in longer post later.

216 total views, no views today

Tại sao ở Việt Nam, những tư tưởng và thực hành XP không được coi trọng? Theo tôi quan sát, có ba lý do chính.

Một là, ngành CNTT của Việt Nam chủ yếu vẫn đang tiếp cận theo hướng top-down; những vấn đề về công nghệ, phương pháp luận, thực hành vẫn chủ yếu được định hình bởi các quản lý cấp cao, cấp trung. Và XP thường không bao giờ nằm trong danh sách lựa chọn của những nhà quản lý dự án hay quản lý tổ chức thuần tuý, bởi XP không phải là phương pháp luận về “quản lý”.

Hai là, tên. eXtreme Programming chết bởi cái tên. Kent Beck có lẽ nên chọn một cái tên khác, có thể là vô nghĩa thì tốt hơn. XP cho thấy sự coi trọng hoá programming một cách cực đoan. Và thực sự, điều đó là đúng. Gốc rễ của mọi sản phẩm phần mềm là lập trình. Song nếu như vậy, ngành công nghiệp phần mềm sẽ là quá chật hẹp; và những nhà tư vấn cần phải làm phức tạp nó lên, để mở ra nhiều vị trí khác, nhiều công việc khác. Tư tưởng này được đẩy tới những nhà quản lý, và họ thành ra không coi trọng vấn đề lập trình; họ hiểu rằng để làm ra sản phẩm phần mềm phức tạp, thì tổ chức phải cần những phương pháp phức tạp; và nhiều công việc, nhiều quản lý chính là cách hiện thực hoá điều đó. Có lẽ eXtreme Managing sẽ được lòng hơn là eXtreme Programming.

Và thế là, ba, thị trường XP ngày càng yếu. Những nhà tư vấn, đào tạo không hào hứng với việc đào tạo XP. XP là những gì hand-on rất cụ thể, tốn kém hơn, nhưng nhu cầu ít hơn, là mảnh đất khô cằn của thị trường tư vấn, đào tạo; trong khi những phương pháp quản lý tiếp tục lên ngôi trên một mảnh đất màu mỡ hơn. Và do ít được đào tạo, XP ít được biết đến và ít được thực hành; nên dữ liệu cũng ít, nên càng khó chứng minh được sức mạnh một cách rõ ràng.

Vậy là XP chết.

Đó là tình hình ở Việt Nam. Trên thế giới? XP cũng đã chết. Ít nhất là cái tên.

Ở Việt Nam, các tổ chức không coi trọng XP, họ coi trọng những phương pháp luận về quản lý dự án và quản lý tổ chức mới. Họ mải miết với việc xây dựng môi trường làm việc thân thiện, vui vẻ. Nhưng vui vẻ sao được khi chất lượng sản phẩm không cao? Vui vẻ sao được khi các lập trình viên phải fix bug trên production? Phải căng thẳng khi merge code và lo lắng rằng việc deploy không thành công? Phải để tester chờ tới đêm mới có một bản build?

Trên thế giới, trừ một số người “học hành tử tế”, bây giờ cũng ít ai nhắc tới XP. Nhưng thực tế lại trái ngược hoàn toàn. TDD, pair programming, code refactoring… là những khái niệm và thực hành rất căn bản, ai cũng có thể làm. Continuous Integration (với Jenkins, TeamCity…) xuất hiện ở mọi dự án, đến nỗi người ta không nhớ rằng đó là practices của XP, trừ những người nghiên cứu chi tiết. Và XP chết vì nó đã trở thành bình thường, trở thành “chuẩn” kỹ năng của mọi lập trình viên, không còn là eXtreme nữa. XP là extreme của những năm 2000. Sau gần 20 năm ra đời, XP giờ đây là chuẩn theo nghĩa phổ thông. Hãy thử tìm xem có IDE nào tử tế không hỗ trợ unit test và TDD? Hãy thử tìm xem có framework nào tử tế không có test?

Trong khi thị trường thế giới cạnh tranh gay gắt về những công cụ hỗ trợ tư tưởng, thực hành XP, thì ở Việt Nam, chúng ta vẫn chưa dùng nhiều. XP chết, ở hai nơi, theo hai cách khác nhau.

Tiêu đề rất kêu này của Hiệp Lê. Nhưng nội dung thì cả Hiệp và Hiển đều có chung ý tưởng và hoàn toàn đồng tình.

592 total views, no views today

Sáu năm trước, lần đầu tiên, một người thầy nói với tôi rằng “con cần cẩn thận, đừng sống theo quán tính như người ta”. Thời điểm đó, là quá sớm để tôi hiểu hết một câu nói bình dị, tôi chỉ đơn thuần bị ấn tượng bởi từ “quán tính” – không nhiều người sử dụng nó cho cuộc sống. Những năm sau đó, khi bắt đầu đọc và thực hành, hiểu hơn trong việc hình thành những thói quen tích cực, tôi dần hiểu ra rằng quán tính tích cực và cũng đáng sợ.

Khi chúng ta tiếp cận những điều mới mẻ, quán tính là mỏ neo giữ chúng ta lại. Một người chưa bao giờ hút thuốc, quán tính sẽ giữ anh ta lại, ngăn cản anh ta có những trải nghiệm mới trong làn khói; nhưng chính quán tính đó, sẽ giúp anh ta được an toàn và không làm điều tổn hại tới sức khoẻ.

Khi chúng ta, vì vượt qua quán tính để hình thành thói quen mới, ngay lập tức chúng ta đã vô tình hình thành một quán tính khác, quán tính giống như cánh buồm no gió đẩy chúng ta đi mãi. Một người khi đã quen với việc uống cafe mỗi tối, quán tính sẽ giúp anh ta tìm ra cách thưởng thức ly cafe tuyệt nhất sau bữa ăn; nhưng chính quán tính đó, sẽ đẩy anh ta tới những cơn mất ngủ, mãi không thôi.

Một con thuyền hoàn hảo phải có mỏ neo, cánh buồm và bánh lái. Một chiếc bè thì không cần như vậy, chỉ đơn giản là đứng yên khi nước lặng, và trôi tự do theo dòng khi nước đi. Và mỗi người, có sự lựa chọn của riêng mình, là chiếc bè hay con thuyền?

Có những người cảm thấy thoải mái khi là chiếc bè, cứ xuôi theo dòng chảy, mỗi ngày, làm những gì vẫn làm, và làm những gì người khác vẫn làm. Song chắc không nhiều người muốn sống cuộc sống của chiếc bè, có chăng, đa phần chỉ sống như vậy một cách thụ động, một cách bản năng; bởi họ vẫn thấy vui khi xuôi theo dòng nước, nhưng mấy ai lường được khi nước xoáy trong một cơn mưa lũ, chiếc bè có còn vui khi nó bị quán tính đẩy tới một tốc độ kinh hoàng? Tôi tin chỉ một số ít người thích thú với tốc độ.

Con thuyền thì khác, vốn tự thân nó đã chuẩn bị cho mình những thành phần và chức năng cần thiết. Thả mỏ neo khi muốn dừng lại, thu neo để xuôi theo dòng, giăng buồm để tăng tốc, và đánh lái sang một hướng khác khi muốn. Và khi cần, nó có thể đi ngược dòng nước. Nó cho phép mình có nhiều lựa chọn. Nó lựa chọn hướng đi của riêng mình trong quán tính của dòng nước. Tôi tin, hầu hết chúng ta muốn mình là một con thuyền. Chúng ta muốn được sống chủ động.

Để nâng cấp từ chiếc bè thành con thuyền không dễ, con người cần rèn giũa những kỹ năng để hình thành lên chiếc mỏ neo, cánh buồm và bánh lái. Song đó chưa phải là tất cả. Điều quan trọng hơn là cách lái con thuyền một cách thông minh. Khi nào thì quăng neo, khi nào thì nhổ neo, khi nào giăng buồm, và khi nào thì đánh lái? Điều đó cần hơn cả sự thông minh và tinh tế; cũng như phương pháp tốt. Con người cần nhìn lại vào chính mình, để hiểu thực sự mình cần gì, và muốn gì; để thu lại chiếc mỏ neo và rồi tận dụng quán tính để tiến về phía trước. Nhưng việc hiểu mình không cần gì, và không muốn gì cũng quan trọng không kém; để quăng ra chiếc mỏ neo và dừng lại khi cần. Và để nhìn vào chính mình, không gì tốt hơn những khoảng lặng. Nếu một người cứ mãi làm những việc một cách vô thức, chỉ vì ngày hôm qua anh ta làm vậy hay chỉ vì mọi người vẫn làm vậy, quán tính cuộc đời sẽ sớm đẩy anh ta tới một tốc độ kinh hoàng. Nếu anh ta nhìn có phút nhìn lại để nhận ra quán tính sẽ đẩy mình đi đâu, tới tốc độ nào, anh ta sẽ biết mình nên căng buồm, đánh lái hay thả neo.

Đó có thể là trong một trận bóng, tôi cố gắng kết thúc một tình huống, để có 10 giây suy nghĩ. Đó có thể là trong một bữa tiệc vui hay một cuộc buồn, tôi biến mất giữa đám đông 5 phút, để biết rằng mình nên tiếp tục hay trở về. Đó có thể là 1 giờ không làm gì để biết mình nên làm gì. Làm gì, và không làm gì, cũng đều quan trọng như nhau. Xác định được giá trị trong cuộc sống, chính là tìm ra cách sử dụng và điều khiển quán tính một cách hợp lý. Chúng ta sẽ luôn căng buồm theo những thói quen mà chúng ta tin rằng, đó là giá trị cuộc sống; chúng ta sẽ luôn xuôi dòng với những thói quen khác; và chúng ta sẽ thả neo để giữ mình lại trước khi hình thành nên một thói quen vi phạm những giá trị này. Vì sau cùng, chạy theo những thói quen của mình một cách vô thức đã là điều tồi tệ; để quán tính đẩy chúng ta theo những thói quen chỉ vì những người khác vẫn làm như vậy, còn tồi tệ hơn.

Quán tính có thể là sức ỳ, ngăn cản chúng ta chuyển động tới những điều mới mẻ, hình thành những thói quen.

Quán tính có thể là sức động, giữ chúng ta mãi trôi theo những thói quen.

Quán tính tích cực, và cũng tiêu cực như thói quen vậy.

Hiểu được bản thân cần sự tinh tế; sử dụng quán tính hợp lý để điều chỉnh cần sự sáng suốt. Và thật đáng buồn, con người lại là sinh vật phi lý trí nhất. Bởi vậy, sẽ tốt hơn nếu con người đi cùng nhau; người ta cần một đối tác sáng suốt; người sẽ căng buồm hoặc thả neo khi cần thiết. Đàn ông, với bản tính của mình, mấy khi sáng suốt?

771 total views, no views today

Đây là vấn đề cốt lõi cần được giải quyết của việc chuyển đổi sang môi trường Agile.

Push system (hệ thống đẩy) là mô thức quản lý phổ biến hiện nay, sử dụng một quy trình được đinh nghĩa trước cùng các vai trò và mô tả công việc tương ứng. Mọi công việc được chỉ định tới một thành viên cụ thể, quy định từng mức trách nhiệm và khả năng quyết định. Trong một hệ thống phân cấp, mọi công việc đều:

  • cần phối hợp và báo cáo cho người quản lý trực tiếp;
  • thực hiện bởi người ở mức thấp hơn trong phân cấp quản lý.

Thông qua việc định nghĩa rõ ràng sự phân cấp trong mô hình tổ chức, mọi công việc đều được định nghĩa cụ thể về mục tiêu, thời điểm hoàn thành, tiến độ… giúp người quản lý thực hiện việc push công việc xuống những nhân viên như commandcontrol được những gì đang xảy ra; chất lượng công việc phụ thuộc lớn vào tài năng của những nhà quản lý. Push system dựa trên giả định rằng những nhân sự không có động lực làm việc và luôn cần được giao việc và giám sát để hoàn thành.

Cuối thế kỷ 20, Peter Drucker lần đầu nói về thời đại của những lao động tri thức, những công việc trở nên phức tạp hơn, và cần nhiều kỹ năng để hoàn thành hơn. Hệ quả là sự bất hợp lý trong việc phân chia và giao từng công việc cụ thể tới một cá nhân; mô hình làm việc nhóm với những thành viên có đầy đủ kỹ năng trở nên thắng thế. Và bước phát triển tiếp theo là nhóm tự quản.

Pull system (hệ thống kéo) là mô thức quản lý được điều hướng bởi giá trị và kết quả; những công việc được xây dựng thành một danh sách cần hoàn thành theo một thứ tự nhất định và không được giao cho một thành viên cụ thể; những thành viên trong nhóm sẽ chủ động thực hiện pull công việc và thực hiện. Pull system được xây dựng trên giả định rằng những nhân sự luôn có động lực làm việc và không cần nhiều sự quản lý.

Hiểu được sự khác biệt giữa push systempull system là vấn đề lớn nhất với những tổ chức muốn chuyển đổi sang môi trường Agile. Điều cốt lõi nằm ở:

Cách thức định nghĩa quy trình. Trong push system, quy trình được định nghĩa trước, và thông thường được định nghĩa bởi những người không trực tiếp thực hiện công việc cụ thể, và đặt trọng tâm vào giá trị quản lý. Bộ phận quản lý quy trình định nghĩa ra cách thức thực hiện một chiến lược marketing, những bước thực hiện, tài liệu trao đổi giữa các phòng ban từ việc thiết lập chi phí đến thiết kế hình ảnh, nội dung… song chính họ lại có rất ít kiến thức về cách tạo ra một chiến lược marketing hiệu quả. Quy trình được định nghĩa chủ yếu hướng tới việc giúp những nhà quản lý có cái nhìn toàn cảnh và kiểm soát công việc thông qua chỉ định công việc tới từng cá nhân cụ thể; cho mọi dự án. Nhưng sự cứng ngắc của những quy trình được định nghĩa sẵn làm hạn chế sự sáng tạo, tạo ra rào cản làm chậm quá trình tạo ra giá trị thực sự. Push system và Agile hướng tới thực nghiệm. Thông qua việc thực hành và đo đạc hiệu quả, nhóm tự tổ chức biết cách thực hiện nào là phù hợp cho nhóm trong từng hoàn cảnh cụ thể, và hình thành quy trình riêng cho nhóm; từ đó loại bỏ rào cản và tối ưu giá trị tạo ra.

Trách nhiệm hoàn thành công việc. Điều khiến mọi người phân vân là trách nhiệm cá nhân trong pull system: nếu một công việc không được chỉ định cho một cá nhân cụ thể, điều gì khiến công việc đó được hoàn thành? Đây là một câu hỏi hợp lý; song suy nghĩ theo một cách khác, nếu mọi công việc được chỉ định theo cá nhân cùng KPI tương ứng, những cá nhân này có thể vì tập trung nỗi lực hoàn thành một phần việc cụ thể mà bỏ qua việc cộng tác trong bức tranh toàn cảnh và tạo ra giá trị lớn hơn. Một tester được giao nhiệm vụ cụ thể sẽ cố gắng tìm ra thật nhiều bug thay vì cộng tác với developer trong nhóm nhằm tìm cách hạn chế chúng. Pull system và Agile hướng trọng tâm vào xây dựng nhóm có động lực làm việc – tập trung vào con người. Nhưng đó là cách làm phù hợp với thị trường lao động tri thức ngày nay khi nhu cầu người lao động đi dần lên phía đỉnh của tháp Maslow.

Chất lượng công việc. Công việc được nâng cao khi người thực hiện hiểu được giá trị và có cái nhìn thổng thể. Push system thường chỉ tập trung vào từng công việc cụ thể và bỏ qua góc nhìn về toàn cảnh hệ thống và giá trị, mức độ quan trọng cụ thể của một thành phần công việc tạo ra giá trị chung. Pull system cung cấp góc nhìn toàn cảnh, những giá trị đóng góp của từng công việc cụ thể tạo thành giá trị chung, hỗ trợ việc ra quyết định chính xác hơn. Cách vận hành kiểu thực nghiệm của pull system cũng giúp nhóm tìm ra quy trình cho chính mình, giúp loại bỏ trở ngại, tăng năng suất và chất lượng công việc.

Về cơ bản, push systempull system khác nhau về hệ quy chiếu đo lường và đánh giá. Push system đo lường và đánh giá số lượng và khối lượng những công việc được hoàn thành; song cả số lượng và khối lượng công việc được hoàn thành không đại diện cho giá trị được tạo ra. Ngược lại, pull system đo lường và đánh gía dựa trên giá trị được tạo ra.

1,080 total views, no views today

Ngược dòng.

Ngành CNTT Việt Nam hình như đang đi theo một con đường kỳ lạ, rất nóng và ít bền vững.
 
Từ khi còn giảng dạy, đến giờ, tôi vẫn khuyên các bạn trẻ hơn rằng nên bắt đầu từ nền tảng căn bản: học ngôn ngữ trước khi học framework, học lập trình trước khi học công nghệ. Và tôi tin rằng đây là con đường phù hợp, bền vững; công nghệ thay đổi từng ngày và chúng ta không thể cứ chạy mãi từ nơi này sang nơi khác nếu thiếu nền tảng cơ bản.
 
Khi tìm đồng nghiệp, tôi cũng tư duy theo cách này. Song càng đi, tôi càng thấy mình ngược dòng với xu thế CNTT Việt Nam hiện nay.
 
Một câu hỏi được tôi đưa ra cho ứng viên là “Làm thế nào để sắp xếp 1 text file, gồm nhiều dòng, có dung lượng 2GB?”. Tôi nhận được câu từ chối trả lời nhã nhặn rằng: “Tôi không giỏi về thuật toán, và công ty cũng đang tìm iOS developer? Vậy hãy hỏi tôi những kiến thức về iOS.”.
 
Tôi đồng tình và đưa ra câu hỏi mới về iOS: “Bạn nhận được 1 text file từ vụ VN Airlines leak, gồm nhiều dòng, có dung lượng 2GB, và cần hiển thị thông tin đó trên 1 iOS app dưới dạng danh sách được sắp xếp theo alphabet để tiện tra cứu. Bạn sẽ làm thế nào?”
 
Đó chính xác là 1 câu hỏi về iOS? Và nếu một developer không giải quyết được bài toán đó, anh ta chỉ là junior.
 
Tôi không biết chúng ta có 1 chuẩn nào để phân biệt giữa “junior” và “senior” developer; ở Việt Nam tôi chỉ thấy “senior” mà thôi, mọi nơi, mọi CV; chỉ cần sau khi tốt nghiệp ĐH 1 năm. Trong buổi nói chuyện với ứng viên, đôi khi tôi phải nói rằng “ở công ty khác, bạn có thể được coi là senior developer, nhưng ở đây, title của bạn là developer”. Ngược đường. Không ai thu hút ứng viên tới công ty bằng cách đó hết :). Tôi biết, song chúng tôi không sử dụng những từ không mô tả đúng bản chất.
 
Khi Việt Nam “phổ cập” ĐH về mặt “bằng cấp” mà không phải “trình độ”, thì bằng ĐH được coi rẻ. ThS rồi cũng vậy. Khi chúng ta quá dễ dàng gọi nhau là “senior”, thì bạn biết kết quả rồi đấy :). Sẽ ra sao khi senior developer Việt Nam nói chuyện với junior developer của Mỹ?
 
Tôi nghĩ dù khó khăn, chúng ta vẫn nên tuân theo những chuẩn chung, của cả nền công nghiệp trên thế giới, đừng hạ chuẩn và “thủ dâm tinh thần” mình bằng sự lệch pha bởi một con đường riêng như GD Việt Nam đang làm.
 
Chúng tôi không thể thay đổi được cả ngành công nghiệp này, nên giờ, để hướng ra thế giới, chúng tôi vẫn phải đi ngược dòng.

Xuôi dòng.

Cảm ơn mọi người đã chia sẻ quan điểm trong bài viết trước, tôi không nghĩ có nhiều người quan tâm như vậy.
 
Bỏ qua những vấn đề tiểu tiết về ví dụ, câu chữ (vì tôi có thói quen chỉ viết 1 lần và gần như không sửa lại)… thì nội dung tôi muốn truyền tải trong bài viết trước là:
 
1. Tôi cho rằng mọi lập trình viên nên đi từ căn bản, từ ngôn ngữ tới framework, từ lập trình tới công nghệ. Và tôi nhận thấy quan điểm này không giống với cách thực hành của đa số developer Việt Nam hiện nay; nên tôi gọi là “ngược dòng”.
 
2. Tôi thấy ở Việt Nam có quá nhiều senior developer, chỉ với 1-2 năm kinh nghiệm. Đó là điều không phù hợp. Chúng tôi không không làm như vậy; nên tôi gọi là “ngược dòng”.
 
Về #1, tôi bảo lưu ý kiến dù đồng tình rằng có hàng trăm cách tiếp cận khác nhau.
 
Về #2, tôi cho rằng việc phân định giữa “junior” hay “senior” developer đó là sự trưởng thành về mặt giải quyết bài toán trong lĩnh vực công nghệ phần mềm.
 
Ngoài cách giải thích trong hình, bạn có thể tham khảo thêm tại bài viết gần với quan điểm của tôi: https://business.stackoverflow.com/blog/what-defines-a-senior-developer
 
Làm thế nào để developer có sự trưởng thành về mặt giải quyết bài toán trong lĩnh vực công nghệ phần mềm? Họ cần thời gian và trải nghiệm. Rất nhiều chuyên gia cho rằng, họ cần “X năm” trải nghiệm, và thường là X = 10. Nhiều chuyên gia bổ sung thêm rằng, họ cần có trải nghiệm trong ít nhất 1 project thất bại. Một số người đặc biệt xuất sắc “trưởng thành” nhanh hơn, X có thể là 2-5 năm, như Mark, Bill… (cỡ 5-10%).
 
Nhiều người lý luận rằng “tôi làm hàng trăm project trong 2 năm và trải nghiệm hơn hẳn 1 người làm 10 năm”, hay câu chuyện vui là “tôi 20 tuổi, có 10 năm kinh nghiệm do OT”, tôi cho rằng đó nên là câu chuyện phiếm mà thôi. Hãy nhớ rằng “trưởng thành” là một quá trình cần thời gian để suy ngẫm, để lớn lên, “làm nhiều” chỉ là việc trải nghiệm – là một phần, nguyên liệu tạo ra sự trưởng thành, nhưng không phải tất cả.
 
“A person with 10 years experience is quite different than someone who has experienced the same year 10 times.” (http://mattbriggs.net/blog/2015/06/01/the-role-of-a-senior-developer/)
 
Tôi thì theo nguyên tắc đơn giản hơn, “senior” developer cần 10.000 giờ trải nghiệm. Đó là 10.000 giờ thực hành có chủ đích chứ không phải chỉ ngồi trước màn hình máy tính. Thế thôi. Ai chăm chỉ thì cần 3-5 năm.
 
Bài toán “sắp xếp text file có dung lượng 2GB” có thể khiến nhiều người không thích nếu nhìn nhận dưới con mắt “thuật toán”. Tôi thì nghĩ thế này: Với sự “trưởng thành” trong cách giải quyết vấn đề của senior developer, anh ta sẽ hiểu đó là 1 bài toán có thể hiện hữu trong thực tế, không tách biệt ra rằng đó là về “thuật toán” hay “lập trình iOS”. Và với góc nhìn đó, anh ta sẽ biết đâu là vấn đề quan trọng cần giải quyết, còn giải quyết theo cách nào là “chấp nhận được”, theo cách nào là “tốt”… thì phụ thuộc vào kiến thức và kỹ năng hiện có. Song cách anh ta tiếp cận bài toán cho thấy sự “trưởng thành” và quyết định anh ta là “junior” hay “senior”.
 
Tôi đề cập tới vấn đề này cũng do trải nghiệm bản thân. Mấy năm trước, tôi có tiếp xúc với 1 vài doanh nghiệp. Có nơi, sau khi tôi từ chối lần 1, họ trở lại với mức lương gấp đôi kèm title “senior developer”. Có nơi họ đặt tôi là “principle engineer”, chỉ bởi vì Principle Engineer là title cao nhất về engineer được Google sử dụng, và tôi là người giỏi nhất ở đó (haha, có lý đấy chứ?). Một sinh viên thì biết gì mấy về thế giới? Nhưng cũng là sinh viên giỏi, thì tiếp cận những title đó thế nào? Tự hào vì mình là số 1, là ngọc quý; đương nhiên. Nhưng thực sự là tôi đã rất may mắn khi từ chối những lời mời đó; nhìn rộng ra thế giới để biết chỗ thực sự của mình. Nếu không, giờ tôi sẽ gửi bạn namecard là Principle Engineer đó, nghĩ tới thôi đã buồn cười :).
 
Bởi vậy, nhiều người chỉ trích tôi về sự “khó khăn” khi gọi những đồng nghiệp của mình là “senior developer” dù trước đó họ còn có những title “khủng” hơn thế. Tôi vẫn cho rằng việc mình làm là đúng, chúng tôi cần hướng tới quy chuẩn chung của thế giới, để “senior developer Việt Nam” có cùng đẳng cấp với “senior developer” ở Silicon Valley, và thảo luận tay bo với họ về cách giải quyết bài toán, chứng minh trên từng dòng code, chứ không phải rụt rè trước thậm chí cả “junior developer Tây”.
 
Và tôi gọi đó là ngược dòng.
 
Nhưng tôi không ngờ suy nghĩ của mình cũng được nhiều người ủng hộ. Và tôi đặc biệt thích cách nghĩ của anh Manh Lan Pham rằng “Nếu nhiều thằng cắm đầu đi ngược dòng thì nó lại thành xuôi ấy mà ^^” 🙂
 
Vậy nên nếu bạn đồng tình, tôi hy vọng chúng ta có thể “cắm đầu đi ngược dòng” để chúng ta “xuôi dòng” cùng thế giới.

384 total views, no views today