Mort, Elvis, Einstein, và Bạn
Đầu tuần vừa rồi tôi có viết bài “Có hai kiểu lập trình viên”. Dựa vào số lượng lớn các bình luận mà độc giả để lại, tôi dường như muốn đứt một dây thần kinh. Hoặc hai dây cũng nên. Điều này làm tôi khá ngạc nhiên, bởi vì nội dung bài viết không bao giờ có ý nghĩa công kích và khiêu khích hoặc chỉ trích như nhiều người đã hiểu lầm. Nội dung nó đã là như vậy khi ra khỏi tay tác giả gốc của bài viết mà tôi đã trích dẫn lại là Ben Collins-Sussman, tôi chỉ hướng bài viết của mình với mục đích làm sáng tỏ thêm bài viết ban đầu của ông ta.
Bạn là kiểu lập trình viên Mort, Elvis hay Einstein?
Nhiều độc giả đã cảm thấy bị xúc phạm vì nghĩ rằng tôi bằng cách nào đó đã gộp họ vào nhóm 80% những tay lập trình viên xoàng xĩnh. Đây chính là điều thực sự mỉa mai: vì mọi hành động bình luận trên một bài viết về phát triển phần mềm thì đồng nghĩa với việc bạn không phải là một người nằm trong nhóm 80% lập trình viên đi làm cho xong chuyện chỉ để kiếm cơm đó rồi. Tin tôi đi. Tôi hoàn toàn không hề gọi bất kỳ vị độc giả nào của mình là xoàng xĩnh cả. Tôi không nói điều đó bởi vì tôi cũng chỉ như bạn; blog của tôi không phải là một dạng trường hợp đặc biệt hoặc thậm chí đặc biệt tốt gì cả. Tôi nói ra điều này bởi vì nếu bạn đang đọc bất kỳ blog lập trình nào, thì bạn đã chứng tỏ một mong muốn cải thiện các kỹ năng của bạn và tìm hiểu nhiều hơn về nghề nghiệp mà bạn đã chọn lựa.
Vì vậy, nếu bạn đọc bài viết này, thì hầu như chắc chắn là bạn đã ở trong nhóm 20% rồi.Nhóm 80% kia thì không tích cực nghĩ về nghề phát triển phần mềm. Họ sẽ chẳng bao giờ tìm thấy bài viết này, chứ đừng nói là đọc nó. Họ chỉ đơn giản là không đọc các blog về lập trình – mà họ chỉ ngồi tìm kiếm các kết quả trên Google để tìm ra các câu trả lời nhanh chóng cho một vấn đề cụ thể mà họ đang gặp phải. Và họ cũng chẳng đọc bất kỳ cuốn sách nào trong danh sách những cuốn đề xuất của tôi. Cái đặc trưng để định nghĩa về phần lớn của cái gọi là các “lập trình viên kiếm cơm” đó là họ là những người không thể với tới được. Cho dù những gì mà bạn, tôi hoặc bất kỳ ai viết ra ở đây – thì họ sẽ chẳng bao giờ nhìn thấy.
Vấn đề không phải nằm ở 80% kia. Mà vấn đề là chúng ta đang bị mắc kẹt bên trong ốc đảo nhỏ bé 20% trong thế giới của mình, và chúng ta quên mất rằng có một nhóm rất lớn các lập trình viên mà chúng ta hầu như không ảnh hưởng lên họ được chút nào. Rất ít việc mà chúng ta làm sẽ tạo ra bất kỳ một sự khác biệt bên ngoài nhóm nhỏ của mình. Vấn đề ở chỗ, rõ ràng là tôi đã thất bại trong việc làm sáng tỏ điều này trong bài viết trước, đó là tìm cách làm thế nào để vươn tới những lập trình viên không thể tiếp cận đó. Đó là làm thế nào để bạn tạo ra những thay đổi lâu dài và vĩnh viễn trong nghề phát triển phần mềm này. Không phải bằng cách suốt ngày đi phục vụ cho tầng lớp tinh anh – những người có thể tự chăm sóc cho bản thân họ – mà bằng cách tiếp cận đến đại đa số lập trình viên loại “tà tà kiếm cơm” qua ngày.
Đó mới là quan điểm của tôi. Tôi xin lỗi vì đã rất kém cỏi trong việc truyền đi thông điệp đó. Nhưng về mặt tích cực, ít ra thì nó cũng làm cho mọi người suy nghĩ và nói về vấn đề này.
Một số người phản đối mọi ý tưởng về việc phân loại các lập trình viên thành các nhóm dù bất kỳ dạng nào. Nhưng lịch sử đã cho thấy rất nhiều người đã làm chính xác điều đó, với những hậu quả thú vị và đôi khi nằm ngoài ý muốn. Vào đầu năm 2004, Nikhil Kothari đã viết về 3 loại tính cách (personas) mà Microsoft đã đưa ra trong khi làm việc trên sản phẩm Visual Studio 2005.
Chúng tôi có 3 loại tính cách (personas) chính trên khắp các bộ phận phát triển: Mort, Elvis và Einstein.
Mort, là kiểu lập trình viên cơ hội, thích tạo ra các giải pháp nhanh chóng cho các vấn đề ngay lập tức. Anh ta tập trung vào năng suất và học tập khi cần thiết.
Elvis, là kiểu lập trình viên thực dụng, thích tạo ra các giải pháp lâu dài để giải quyết các vấn đề chung, và học hỏi trong khi làm việc trên giải pháp đó.
Các mô tả ở trên chỉ là một tổng kết sơ bộ về một số đặc điểm thu thập được và ghi chép lại bởi những đồng nghiệp của chúng tôi. Trong một cuộc họp, một vị program manager của nhóm chúng tôi đã áp dụng những tính cách đó trong ngữ cảnh của các server control cũng khá hay:
- Mort sẽ là một lập trình viên cảm thấy thoải mái và hài lòng nhất nếu control đó có thể sử dụng được như thiết kế của nó và control đó hoạt động tốt.
- Elvis muốn có khả năng tùy biến control đó để nhận được các hành vi mong muốn thông qua các properties và code, hoặc sẵn sàng để kết nối nhiều control lại với nhau.
- Einstein rất thích việc có khả năng hiểu một cách sâu sắc về cách thực thi của control đó, và muốn có khả năng mở rộng nó để mang lại cho control đó một hành vi (behavior) khác, hoặc đi xa hơn đó là tái thực hiện lại nó.
Tôi không thể nhớ chính xác cái ngày khi mà những tính cách đó xuất hiện tại Microsoft. Wesner Moise thậm chí còn có một bình luận sớm hơn về những tính cách này, trong đó anh ta tự chọc quê bằng cách tự nhận mình “đã từng là một Einstein.” Wes, anh bạn thân mến, tôi sợ rằng anh là một Einstein nguyên mẫu, cho dù anh có nghĩ khác đi bao nhiêu chăng nữa.
Những tính cách (personas) này đã gây ra tranh cãi trong nhiều năm trời; chúng đã tạo ranhiều tranh luận nảy lửa. Rõ ràng là có một ranh giới giữa “persona (tính cách)” và “stereotype (khuôn mẫu)”:
Các tính cách (personas) của các lập trình viên tại Microsoft bao gồm Mort, Elvis, và Einstein cuối cùng là một sự suy đồi về đạo đức khi mà người ta đem “nhốt chuồng” các lập trình viên phần mềm vào các thể loại quá đơn giản mà chỉ mấy tay nhân viên marketing mới cảm thấy thoải mái. Trong khi mục đích ban đầu là để giúp phân khúc ký sinh đặc biệt này của thế giới doanh nghiệp, thì việc mô hình hóa các hành vi theo khuynh hướng tâm lý của các nhà phát triển phần mềm tại công việc của họ là một cách đơn giản không thực tế, thay vì đó nó đã biến thành một hệ thống của những hạn chế mà các lập trình viên phải bắt đầu áp đặt lên chính họ để gây tổn hại cho sự tiến bộ của thực tiễn phát triển ngành công nghiệp phần mềm. Nó dường như là một nỗ lực của các nhà phát triển để giải thoát chính họ khỏi năng lực tư duy hợp lý có lợi cho việc xác định các thương hiệu của các công ty và phần mềm nổi tiếng.
Personas (cá tính), tự bản thân nó thì không có gì là xấu cả. Trước đây tôi đã viết về tầm quan trọng của khả năng sử dụng API, và personas cho bạn một lợi thế về tính dễ sử dụng (usability) bằng cách xem xét những đối tượng người dùng khác nhau sẽ sử dụng code của bạn.
Nhưng tôi có thể thấu hiểu điều này. Trong một thời gian dài là một lập trình viên sử dụng Visual Basic và VB.NET, tôi thực sự cảm thấy khá bực bội khi bị gộp vào nhóm người kiểu như Mort. Tôi không phải là một tay lập trình viên kiểu “tà tà kiếm cơm” – tôi thực sự quan tâm về nghề nghiệp phát triển phần mềm. Vì vậy điều gì sẽ xảy ra nếu tôi viết code trong một ngôn ngữ mà không được hỗ trợ về phân biệt chữ hoa chữ thường và cả cặp dấu ngoặc xoắn? Việc lựa chọn ngôn ngữ của tôi cuối cùng chẳng có ý nghĩa nhiều hơngiữa việc lựa chọn nước giải khát CocaCola và Pepsi, vì vậy không có nhiều sự khác biệt ở đây.
Paul Vick làm việc tại nhóm tạo ra ngôn ngữ VB tại Microsoft và ông ta có phản hồi về một vài mối quan tâm của tôi:
Sai lầm cơ bản mà tôi nghĩ rằng hầu hết mọi người đều làm với các personas đó là họ nhìn thấy chúng loại trừ lẫn nhau chứ không phải là các điểm nằm trong cùng một dải kinh nghiệm. Khi tôi đang làm việc để tạo ra VB compiler, thì tôi chắc chắn là một Einstein, luôn suy nghĩ ở mức rất cao. Khi tôi đang làm việc trên các thứ kiểu như VBParser sample, thì tôi thường là một Elvis, tư duy ở một cấp độ thấp hơn một chút. Và khi tôi đang viết một batch scripts hoặc các công cụ phân tích dữ liệu ad-hoc, tôi chắc chắn là một Mort, vọc vậy tìm kiếm xung quanh để tìm ra cách làm những gì mà tôi đang cố gắng để làm.
Quan điểm thực sự đó là hầu hết mọi người thường là Mort, Elvis, và Einstein tất cả cùng một lúc, tùy thuộc vào những gì họ đang làm. Và bằng cách xây dựng các công cụ sẽ tập trung vào kiểu người này hay người kia, chúng ta đang cố tình phân chia công việc của mọi người vào trong những “cái xô” riêng lẻ mà không thực sự phản ánh đúng công việc hàng ngày của họ. (Tôi cũng đã tranh luận về việc một số phiên bản Visual Studio được phát hành trước đây đã quá nhấn mạnh những personas hơn những yếu tố khác). Hãy tìm một cách tốt hơn để phục vụ mọi người khi họ trôi theo dòng chảy công việc hàng ngày, và một cái gì đó cần sự chú ý nghiêm túc hơn.
Mort, giống như phần 80% mà Ben đã đề cập đến trong bài viết gốc, nó còn hơn cả một persona (tính cách) hoăc một stereotype (khuôn mẫu). Đó là một lời kêu gọi hành động.
Tôi nghĩ rằng giải pháp ở đây là bỏ thái độ gia trưởng và coi thường khi nghĩ về Mort, mà thay vào đó là yêu cầu Mort phải làm việc tốt hơn. Nếu khả năng của những lập trình viên trung bình thật sự chỉ làng nhàng như hiện có, chúng ta không nên chỉ chấp nhận điều đó, mà phải làm việc để nâng cao chất lượng của các lập trình viên loại trung bình. “Lập trình viên loại trung bình” nên phải ở một cấp độ năng lực có thể chấp nhận được.
Chúng ta phải nhận ra rằng Mort phải chịu trách nhiệm cho rất nhiều hệ thống quan trọng. Các hệ thống mà có ảnh hưởng đến phần đông dân số. Khi tôi nghe về các vụ trộm cắp tài khoản gần đây tại Choicepoint, đặc biệt nguyên nhân bởi sự lỏng lẻo trong việc bảo mật như là sử dụng các mật khẩu mặc định cho cơ sở dữ liêu, tôi nghĩ về Mort. Khi tôi đọc thấy rằng $250 triệu đô-la tiền thuế của dân đã được đầu tư vào việc đại tu hệ thống Case File của FBI, và hệ thống đó đã bị loại bỏ, tôi nghĩ về Mort.
Đưa ra nhiều trách nhiệm như vậy, chúng ta nên mong chờ nhiều hơn từ Mort. Vì vậy Mort ơi, tôi rất ghét phải nói ra với bạn điều này, nhưng phát triển phần mềm không giống như là đang làm việc tại quầy thu ngân của tiệm bánh McDonalds, nơi mà bạn chỉ việc đến có mặt từ 9 giờ sáng đến 5 giờ chiều là đủ. Mặc dù chúng ta cần cân bằng giữa công việc và cuộc sống, nhưng bạn phải hiểu một điều rằng, phát triển phần mềm là một lĩnh vực vô cùng thách thức, đòi hỏi phải tập trung cao độ và có một năng lực tinh thần mạnh mẽ. Đây là thời điểm bạn nên tham dự một vài buổi hội thảo để cải thiện những kỹ năng của mình. Đây là lúc để bạn nên đăng ký đọc một số blog lập trình và đọc một thêm một số cuốn sách. Nhưng hãy đọc những cuốn sách sâu sắc chứ đừng đọc mấy cuốn sách loại 3 xu rẻ tiền như “Làm thế nào để lập trình VCR trong 21 ngày”. Ví dụ, hãy đọc một cuốn sách về Design Patterns hoặc Refactoring. Mort ơi, tôi e rằng đây là lúc bạn nên rời bỏ lối mòn cũ. Đã đến lúc bạn nên bước lên một nấc thang mới trong nghề lập trình.
Tôi tin chắc rằng đó là công việc của chúng ta để giúp nghề phát triển phần mềm trở nên tốt hơn so với khi chúng ta mới bước chân vào nó. Nếu bạn có bất cứ điều gì giống như tôi, bạn đã viết code tồi khủng khiếp khi bạn mới bắt đầu như là một lập trình viên non trẻ. Nhưng thông qua sự phối hợp giữa nỗ lực và thực hành, tôi đã cố gắng để viết code bớt tệ hơn một chút sau mỗi năm. Tôi sẽ thừa nhận rằng điều này là khá đau khổ, bởi vì các lập trình viên chúng ta không biết chính xác về các kỹ năng trong bản thân mình.Nhưng chúng ta có bổn phận với nghề của mình – và cả với chính chúng ta nữa – để tiếp cận và giúp đỡ những lập trình viên đồng nghiệp khác, ít ra là theo một cách nhỏ nào đó.
Việc trở thành một lập trình viên chuyên nghiệp thì không chỉ đơn thuần là ngồi viết ra thật nhiều code tuyệt vời. Mà trở thành một lập trình viên chuyên nghiệp nghĩa là phải giúp đỡ những lập trình viên khác cũng trở nên chuyên nghiệp. Nào tất cả chúng ta hãy cùng góp sức. Dù chúng ta không thể tiếp cận tới tất cả mọi người. Nhưng ít ra là sẽ vươn tới được một số lập trình viên loại 80% đó.
ITZone via vinacode