Nhiều lập trình viên không chịu đọc sách — nhưng bạn đừng giống họ

Bài viết được dịch từ blog Coding Horror

Một trong những đề tài trung tâm của stackoverflow.com đó là nhiều nhà phát triển phần mềm không còn học lập trình từ những cuốn sách nữa, như Joel đã đề cập:

Các lập trình viên ngày nay dường như không còn đọc sách nữa. Thị trường sách về các chủ đề lập trình thì quá nhỏ khi đem so sánh với số lượng các lập trình viên đang làm việc.

Joel cũng đã nói rõ ý kiến tương tự vào năm 2004 trong một bài viết có tên là The Shlemiel Way of Software:

Phần lớn mọi người vẫn không chịu đọc. Hoặc viết. Phần lớn các lập trình viên không chịu đọc các cuốn sách về phát triển phần mềm, họ cũng không chịu đọc các trang web về phát triển phần mềm, họ thậm chí còn không đọc cả các trang như Slashdot.

Là một lập trình viên thì tôi có nên thường xuyên đọc sách?

Nếu ngày nay các lập trình viên không học từ các cuốn sách, thì làm thế nào để họ học lập trình được? Họ làm việc này theo cách đã lỗi thời: là cứ việc xắn tay áo của họ lên và hùng hục viết code – trong khi tìm kiếm giải pháp cho vấn đề họ đang gặp phải trên internet trong một cửa sổ thứ hai. Internet đã làm cho những cuốn sách lập trình trở nên lỗi thời. Nó thì nhanh hơn, hiệu quả hơn, hay chỉ đơn giản là thông minh hơn để tìm được thông tin về lập trình bạn muốn trên môi trường trực tuyến. Tôi tin vào kinh nghiệm của Doug McCune, khi anh ta nêu ra một số lý do khá điển hình trong bài viết Lý Do Tại Sao Tôi Không Đọc Sách.

Tôi liệt kê ra đây một phần của những chỉ trích gay gắt đối với những vấn đề trong ngành xuất bản sách kỹ thuật của chúng ta:

• Hầu hết các cuốn sách về lập trình đều rất cùi bắp. Điều kiện để trở thành một tác giả viết sách, thì tôi có thể nói là gần như không tồn tại. Với sự hỗn loạn của ngành xuất bản sách thì người ta có thể xem rằng nó cũng chả tốt đẹp gì hơn cái mà bạn tìm thấy trên môi trường hoang dã của internet. Có hàng trăm cuốn sách về lập trình được xuất bản mỗi năm, và có lẽ chỉ có từ 2 đến 3 cuốn trong số đó là có giá trị thực sự để bạn đầu tư thời gian vào đọc.
• Các cuốn sách lập trình giờ đây được bán theo cân nặng (kiểu bán ve chai), chứ không bởi giá trị của nó. Dường như có một mối quan hệ nghịch lý giữa độ dày của một cuốn sách và chất lượng của nó. Cuốn sách càng dày, thì càng có ít thông tin hữu ích được chứa trong đó. Liệu đó có phải là đặc điểm của những cuốn sách khổng lồ dạng tham khảo toàn tập? Bạn có tìm được bất cứ thứ gì ở trong đó không, hay là toàn những thứ vớ vẩn?
• Những cuốn sách lập trình đa số là kiểu “mì ăn liền” nhắm đến đối tượng lập trình viên mới vào nghề. Tôi không có ý chống lại những người mới tham gia vào lĩnh vực lập trình. Nhưng tôi tiếp tục tin rằng vô số cuốn sách dạng “Học [bổ sung ngôn ngữ lập trình vào đây] trong 24 giờ!” đang làm hại nghề nghiệp của chúng ta. Việc cứ chăm chăm vào các giải phápăn liền và nhanh nhất, dễ dàng nhất có thể thì sẽ dẫn những người mới bắt đầu vào một con đường sai lầm – hoặc tôi thích gọi nó là, “PHP”. Tôi đùa đấy! Tôi nói giỡn chút thôi!
• Sách lập trình mà cứ như là sách báo khiêu dâm vậy. Nhiều người cứ sưu tập một đống sách dày cộp, gồm rất nhiều các cuốn sách về lập trình trông có vẻ quan trọng trên giá sách, phần lớn là chưa đọc, và hy vọng bằng cách nào đó nó sẽ khiến bạn trở thành một lập trình viên giỏi hơn. Như David Poole một lần trước đây đã viết cho tôi trong email rằng, “Tôi sẽ chẳng bao giờ làm điều đó trong thế giới thực”, nó giống như là một đống sách lập trình với chủ đề khiêu dâm vậy. Đấy là lý do tại sao tôi đã cân nhắc, và từ chối mua cuốn sách “Art of Computer Programming” của tác giả Knuth. Hãy mua những cuốn sách về thực hành để bạn sẽ thực sự đọc, và điều quan trọng hơn là chuyển nó vào hành động.

Là một tác giả viết sách, tôi cũng cảm thấy tội lỗi. Tôi là đồng tác giả của một cuốn sách lập trình, và tôi vẫn không nghĩ rằng bạn nên mua nó. Tôi không nói điều này với mục đích nói ngược để dụ bạn mua sách của tôi. Ý tôi là cuốn sách đó thì tương đối bình thường. Nó không phải là một cuốn sách tồi theo bất kỳ hình thức nào. Tôi luôn có sự tôn trọng rất lớn dành cho những người đồng tác giả kính mến của mình. Nhưng những thông tin tương tự trong cuốn sách thì bạn có thể truy cập ở nhiều nơi trên web. Việc gom tất cả vào trong một cuốn sách như vậy thì cuối cùng chỉ là một việc tốn công mất sức.

Internet chắc chắn đã đẩy nhanh sự thoái trào của những cuốn sách lập trình, nhưng có một vài bằng chứng rằng, thậm chí trước thời có internet thì các lập trình viên cũng không đọc nhiều sách về lập trình. Tôi đã khá ngạc nhiên khi đọc được đoạn sau đây trong cuốn sách nổi tiếng Code Complete:

Nếu bạn đang đọc cuốn sách này thì bạn đang học nhiều hơn hầu hết mọi người trong ngành công nghiệp phần mềm, bởi vì hầu hết các lập trình viên đọc ít hơn một cuốn sách mỗi năm(tác giả DeMarco và Lister 1999). Việc đọc một chút sẽ giúp bạn tiến một bước dài về phía trước trong sự nghiệp của mình. Nếu bạn đọc thậm chí chỉ một cuốn sách lập trình chất lượng mỗi hai tháng, hay xấp xỉ 35 trang sách một tuần, thì bạn sẽ sớm có một chỗ đứng vững chắc trong ngành công nghiệp này và khiến bạn nổi trội hơn so với đám đồng nghiệp xung quanh.

Tôi tin rằng đoạn trích đó cũng có trong phiên bản đầu tiên của cuốn sách Code Complete vào năm 1993, nhưng tôi không còn giữ một bản copy của nó để xác nhận lại điều đó. Qua một chút tìm kiếm thì tôi đã khám phá ra một đoạn của Steve McConnell được trích trong cuốn sách Peoplewarecủa hai tác giả DeMarco và Lister như sau:

Thống kê về việc đọc sách làm cho chúng ta vô cùng nản lòng: Các nhà phát triển phần mềm trung bình, thường không sở hữu một cuốn sách nào về chủ đề mà anh ta hoặc cô ta đang làm việc, và chưa bao giờ đọc một cuốn nào cả. Thực tế đó làm kinh hãi bất kỳ ai quan tâm đến chất lượng công việc trong lĩnh vực này; và cho những ai đang viết sách như chúng tôi, đó thực sự là một tấn bi kịch.

Tôi đã khổ tâm lẫn dằn vặt rất nhiều khi đọc được những lời bình luận trên mạng xã hội Reddit và biết được rằng mọi người đang hiểu tuyên bố sứ mệnh về “đứa con” của tôi là stackoverflow.comnhư là một sự phủ nhận những cuốn sách lập trình. Có nhiều cảm xúc trái ngược trong tôi về thị trường sách lập trình hiện nay, tôi yêu các cuốn sách lập trình! Mỗi blog mà tôi tạo ra đều dựa trên khái niệm từ danh sách những cuốn sách nên đọc mà tôi đã giới thiệu đến các lập trình viên. Nhiều bài viết trên blog này là tôi đang cố gắng giải thích theo cách của mình về các khái niệm quan trọng được đề cập từ lâu ở trong các cuốn sách lập trình kinh điển đó.

Làm thế nào để tôi có thể dung hòa những điều tưởng chừng như mâu thuẫn đó, tôi nên yêu hay nên ghét sự biến động này? Bạn biết đấy, có những cuốn sách lập trình, và cũng có những cuốn sách lập trình. Những cuốn sách lập trình tốt nhất là những cuốn sách bất tử. Chúng vượt quá việc lựa chọn ngôn ngữ, IDE, hoặc nền tảng nào đó. Chúng không giải thích cho câu hỏi như thế nào, mà giải đáp cho câu hỏi tại sao. Nếu bạn cảm thấy bị thôi thúc để dọn bớt giá sách của mình cứ mỗi 5 năm, thì tin tôi đi, bạn đang mua nhầm phải những cuốn sách lập trình tồi rồi đó.

Tôi sẽ không bán kệ sách lập trình của mình với bất cứ giá nào. Tôi tham khảo chúng hầu như mọi lúc mọi nơi. Thực ra, tôi đã tham khảo nó hai lần trong khi viết mỗi bài trên blog này.

Tôi sẽ không giải thích thêm về sự quan trọng của danh sách những cuốn sách mà tôi đã đề nghị bạn nên đọc, cũng như tôi luôn giữ gìn nó như một niềm kiêu hãnh trong nhiều năm qua.

(Cập nhật: Một người bạn tên là Tim Spalding tốt bụng đã tạo một tài khoản thay mặt cho tôi trên trang LibraryThing – và các thành viên ở đó đã liệt kê tất cả các cuốn sách có trong bức hình về kệ sách của tôi. Thật là ấn tượng, và khá tuyệt!)

Nhưng tôi cũng xin nói rõ là: top 5 cuốn sách lập trình của mình mà tôi nghĩ mọi lập trình viên đang làm việc nên sở hữu – và đọc. Những cuốn sách này là hạt giống để làm phong phú thêm cả lý thuyết lẫn thực tiễn, từ năm này sang năm khác, bất kể là tôi đang làm về dạng lập trình nào. Mỗi lần đọc thì chúng càng mang lại nhiều giá trị sâu sắc hơn và nhiều sự tinh tế của kỹ nghệ phần mềm đến với tôi, mặc dù đã lăn lộn nhiều năm kinh nghiệm trong nghề này. Nếu bạn vẫn chưa đọc những cuốn sách này, thì bạn đang đang còn chờ đợi điều chi?

Code Complete 2	Don’t Make Me Think
Peopleware	Pragmatic Programmer
Facts and Fallacies

Mục đích lớn nhất của tôi là biến stackoverflow.com như là một phần bổ sung cho những cuốn sách lập trình kinh điển và bất tử nói trên. Không có cách thức, hình dạng hay khuôn mẫu nào có thể thay thế cho chúng được cả.

Một mặt khác, nếu bạn không may lại là tác giả của cuốn sách “Perl for Dummies”, thì hãy ngoảnh lại nhìn phía sau lưng mình, bởi vì chúng tôi rõ ràng đang chĩa súng về phía bạn đấy anh bạn ạ!

Các bài viết liên quan:

• Tầm quan trọng của việc đọc sách đối với lập trình viên
• 10 Lợi ích của việc đọc: Tại sao bạn nên đọc sách mỗi ngày
• Làm IT nên đọc ebook của nhà xuất bản nào?
• Điểm yếu của các bạn trẻ khởi nghiệp tại Việt Nam là tiếng Anh
• Thiết kế website đúng cách với 5 cuốn sách

Về tác giả bài viết:

Jeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack Exchange và Discourse.

16 Cuốn sách “kinh điển” mà tất cả lập trình viên đều nên đọc

Bài viết được dịch từ Coding Horror

Lời bàn của Vinacode:

Trong bài viết gần đây, một lập trình viên Mỹ đã than rằng:

“Tôi đã sai lầm khi dành quá nhiều thời gian để đọc những cuốn sách về một công nghệ nhất định nào đó như là ASP.NET hoặc Hibernate, thay vì nên đọc những cuốn sách kiểu như ‘Code Complete’, ‘Clean Code’, và ‘Agile Principles, Patterns And Practices in C#’. (Tất cả những cuốn sách này, nếu bạn chưa đọc chúng thì tôi khuyên bạn nên dành thời gian để đọc.)”

Chúng ta đều biết là số lượng không bằng chất lượng. Bằng chứng là vào năm 1958, một học giả người Mỹ là ông Sturgeon đã công bố nghiên cứu nổi tiếng về quy luật 90/10, rằng “90% tất cả mọi thứ trong đời đều là vớ vẩn“, bạn thử kiểm tra lại các mối quan hệ bạn bè đồng nghiệp, các sách báo mình đã đọc… xem có đúng không?

Và trước khi xem qua danh sách này thì chúng ta hãy cùng đọc lại một đoạn trong bài viết của một lập trình viên khá nổi tiếng tại Ấn Độ nhé:

“Cũng giống như ngoài đại dương bao la kia, phía trên bề mặt thì sóng rất dữ dội nhưng ở mực nước sâu thì mọi thứ tương đối yên tĩnh, phẳng lặng và hầu hết các sinh vật sống và phát triển tại đây. Vì thế, hãy tự cảm nhận rằng mình đang ở mực nước sâu và tiến gần với những công nghệ cốt lõi. Bạn hãy dành nhiều thời gian để học về những khái niệm cốt lõi hơn là cứ ngồi đó mà lo lắng về những framework và công cụ luôn thay đổi xoành xoạch xung quanh nó. Cùng với nền tảng vững chắc của những kiến thức cốt lõi, bạn sẽ luôn dễ dàng học được những framework, công cụ và các API mới.”

Lập trình viên nên chọn cuốn sách nào để “gối đầu giường”?

1. Code Complete 2

Cuốn sách Code Complete 2 của tác giả Steve McConnell đối với các nhà phát triển phần mềm thì cũng nổi tiếng như cuốn Joy of Cooking dành cho các chuyên gia đầu bếp vậy. Đọc nó nghĩa là bạn yêu thích công việc của mình, bạn có thái độ nghiêm túc về cái bạn làm, và bạn muốn làm cho nó trở nên tốt hơn. Trong Code Complete, tác giả Steve ghi chú rằng lập trình viên trung bình đọc ít hơn một cuốn sách kỹ thuật mỗi năm. Và với việc đọc cuốn sách này thì đã giúp kéo bạn ra xa khỏi 90% các đồng nghiệp của còn lại. Theo hướng tốt hơn.

Tôi thích cuốn sách này nhiều đến nỗi tên miền blog của tôi (Coding Horror) là xuất phát từ nó. Bạn nên đọc cuốn sách này đầu tiên, và là cuốn sách đầu tiên mà bạn giới thiệu đến các lập trình viên đồng nghiệp của mình.

2. The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition (2nd Edition)

Có nhiều ý kiến cho rằng đây là cuốn sách “kinh điển” duy nhất trong lĩnh vực phát triển phần mềm của chúng ta. Nếu bạn vẫn chưa đọc nó, thì thật đáng hổ thẹn.

Tôi thách thức bất kỳ lập trình viên nào đọc cuốn The Mythical Man Month mà lại không tìm thấy câu chuyện về một hệ điều hành không tồn tại nữa, và nhóm người đã phát triển ra nó, rất đáng ngạc nhiên là chúng lại rất liên quan đến vấn đề của bạn ngày nay. Cuốn sách 25 năm tuổi đã minh họa sâu sắc một quan điểm rằng: máy tính có thể thay đổi, nhưng con người thì không.

Đọc cuốn sách kinh điển này chắc chắn sẽ tốt hơn rất nhiều việc bạn sử dụng thời gian để nghiền ngẫm trên hàng ngàn trang tài liệu kỹ thuật mới nhất hiện nay.

3. Don’t Make Me Think: A Common Sense Approach to Web Usability

Một cuốn sách tốt nhất về usability (tính dễ sử dụng của phần mềm) mà tôi đã từng đọc. Tác giả Steve Krug đã bao quát mọi khái niệm quan trọng về usability trong cuốn sách này, và ông làm công việc đó rất tốt. Đọc cuốn sách này thì rất vui. Nếu bạn chọn đọc chỉ một cuốn sách về usability, thì hãy lựa chọn cuốn này. Nó chứa rất nhiều thông tin tuyệt vời, và hình thức trình bày thì ngắn gọn súc tích, dễ áp dụng theo. Nó phù hợp với bất kỳ độc giả nào: dân kỹ thuật, không phải dân kỹ thuật, người dùng bình thường, lập trình viên, nhà quản lý v.v…

4. Rapid Development

Tiêu đề đầy đủ của cuốn sách này là Rapid Development: Taming Wild Software Development Schedules, nó không chỉ dài dòng và hơi buồn cười, mà nó còn dùng sai từ một cách đáng tiếc nữa.

Rapid Development thì không nói về việc phát triển nhanh ứng dụng như cái tên của nó. Nội dung cuốn sách nói về *thực tế của thất bại*. Phần lớn các dự án phát triển phần mềm đều thất bại: chúng thường vượt quá thời hạn kế hoạch đã đặt ra, tạo ra các kết quả không đạt yêu cầu, hoặc đôi khi thậm chí nó còn không thể kết thúc được. Điều này không còn phải tranh cãi; vì đó là một thực tế đã được thống kê. Có một sự thực không mấy dễ chịu đó là team của bạn phải trở nên giỏi hơn trong việc tránh những thất bại đơn giản để có thể thành công. Trong khi nghe điều này có thể làm bạn nản lòng — vâng, nó thì rất nản lòng — nhưng bạn sẽ vẫn muốn đọc cuốn sách này.

Tại sao ư? Bởi vì một nửa thành công là không được lặp lại những sai lầm mà bạn hoặc người khác đã mắc phải. Quan điểm của cuốn sách này đó là việc phạm sai lầm là tốt. Nhưng nếu bạn đang phạm phải chính những sai lầm kinh điển trước đây, thì bạn đã thất bại ngay trước khi thậm chí bắt đầu. Và nếu bạn không biết điều đó là như thế nào thì bạn đang phạm phải một trong những sai lầm đó ngay lúc này.

Lĩnh vực của chúng ta là một trong số ít lĩnh vực thường xuyên thay đổi, vì vậy cách duy nhất là ôm lấy sự thay đổi đó và thử áp dụng những kỹ thuật phát triển “Rapid” khác biệt. Nhưng điều ngược lại thì không đúng. Chúng ta không thể cho rằng có quá nhiều thay đổi từ năm 1970, dẫn đến tất cả các bài học về phát triển phần mềm trước đây đều trở nên lỗi thời và không thích hợp khi so sánh với những công nghệ mới đang “hot” hiện nay. Điều này thì cũng đề cập đến cùng một câu chuyện:máy tính đã thay đổi; con người thì không.

Ít nhất thì cũng có một vài ý tưởng về cái gì làm việc và cái gì không trước khi bạn bắt đầu — như McConnell đã nói, “hãy đọc hướng dẫn sử dụng trên thùng sơn trước khi sơn“. Chắc chắn là vấn đề này nghe có vẻ hiển nhiên cho tới khi bạn đọc cuốn sách này và nhận ra điều đó rất hiếm khi và thực sự xảy ra trong lĩnh vực của chúng ta.

5. Peopleware : Productive Projects and Teams, 2nd Ed.

Nếu bạn đã từng nhìn thấy màn trình diễn của một đội bóng toàn ngôi sao nhưng được dẫn dắt bởi một vị huấn luyện viên tồi, thì bạn sẽ đánh giá cao cuốn sách này. Không quan trọng là có bao nhiêu “siêu sao” trong nhóm của bạn, khi không ai trong số họ có thể trao đổi cùng nhau, hoặc đồng ý về bất cứ việc gì. Và không có lập trình viên nào, dù có tài năng đến mấy, có thể làm việc hiệu quả khi luôn luôn bị rào cản bởi những ngắt quãng nhỏ nhặt. Các lập trình viên không đánh giá đúng các kỹ năng về con người của họ, nhưng một điều trớ trêu thay: thành công của dự án của bạn có thể phụ thuộc rất nhiều vào điều đó. Nếu bạn có bất kỳ một khát khao chính đáng để trở thành một “Team Leader” thực thụ thay vì chỉ là cái chức danh hão, thì bạn cần phải đọc cuốn sách này.

Trong khi Peopleware chứa đầy những quan điểm hoàn toàn vững chắc và tuyệt vời, nó cũng ngụ ý về một mức độ kiểm soát nhân viên dựa trên không gian làm việc là hoàn toàn kỳ quặc tại hầu hết các công ty. Nhưng ít nhất bạn cũng sẽ biết khi nào thì môi trường làm việc của mình, hoặc team của mình đang gặp một vấn đề thực sự — và quan trọng hơn là cần phải làm gì để giải quyết nó.

6. The Design of Everyday Things

Công việc phát triển phần mềm có thể làm bạn nản lòng đến mức khó tin, bởi vì có quá nhiều thứ có thể trở nên sai sót. Có rất nhiều thứ chúng ta làm là để phòng thủ: cố gắng đoán trước điều gì sẽ trở nên sai trước khi nó xảy ra. Nó là nguyên nhân làm bạn kiệt sức về tinh thần, và thậm chí có thể biểu lộ bản thân theo một số cách khá tiêu cực. Đôi khi tôi mô tả công việc này với những người không chuyên về kỹ thuật như thể tôi đang tạo ra một cái đồng hồ với hàng ngàn chi tiết nhỏ, tất cả chúng có thể hỏng một cách ngẫu nhiên vì những kích thích nhỏ nhất.

7. About Face 3.0: The Essentials of Interaction Design

Alan Cooper, cha đẻ của ngôn ngữ Visual Basic, và là cha đỡ đầu của usability. Tôi xin nói thành thật rằng: tôi đã đọc cuốn sách này cách đây lâu lắm rồi. Tôi mua cuốn sách này khi nó được xuất bản vào khoảng năm 1995, vì vậy tôi có phiên bản “cũ” 1.0 của cuốn sách. (Nó có bị xem là usability tồi không? khi bạn không dùng những cuốn sách của mình lúc có những phiên bản mới?)

Cuốn sách này, cùng với cuốn GUI Bloopers, có khuynh hướng trở thành những cuốn sách về quy tắc sư phạm trong việc trình bày một GUI nhất quán. Nhưng đây là một trong những chỉ dẫn đầy đủ nhất mà bạn có thể ứng dụng được.

Không giống như cuốn GUI Bloopers, vì nó xuất bản thời trước khi có web, vì vậy không có sự bàn luận về cách trình bày trên web và nó có tác động đến thiết kế GUI như thế nào. Nhưng nó thì vẫn là một cuốn sách hữu ích tuyệt vời; tôi đã sử dụng chương sách nói về mô hình quản lý thông điệp lỗi (error messages) cho một dự án .NET gần đây.

8. The Inmates Are Running the Asylum : Why High Tech Products Drive Us Crazy and How To Restore The Sanity

Đây là cuốn sách đã giới thiệu với thế giới về khái niệm personas (con người): thay vì trước đây chúng ta cứ nghĩ người dùng là trừu tượng, khó mô tả, là một nhóm người không xác định, thì giờ đây với khái niệm personas sẽ hướng dẫn chúng ta nói chuyện về những người dùng xác định, người mà có tên, có cá tính, có nhu cầu và mục tiêu. Liệu người dùng (users) của chúng ta có muốn chức năng print preview không? Bố ai mà biết được? Nhưng nếu Gerry Manheim là kế toán trưởng, và anh ta phải in ra bảng báo cáo chi tiêu hàng tuần như là một phần công việc của mình, thì tốt hơn là bạn nên tin rằng chức năng print preview cần phải có trong phần mềm. Không có gì thần kỳ ở đây cả; luôn phải biết người dùng của bạn là ai và họ thực sự muốn làm gì — và kỹ thuật sử dụng khái niệm personas đúng là một cách rất tuyệt vời.

Cũng có một phân tích khá thú vị ở đây về việc các lập trình viên có khuynh hướng nghĩ rằng bản thân họ có khả năng tạo ra các quyết định về usability nhân danh những người dùng “bình thường”, nhưng trong thực tế thì hoàn toàn ngược lại. Các lập trình viên chính là những người dùng kỳ cục và cực đoan nhất.

Một bài học ẩn chứa phía sau cuốn sách này đó là đôi khi thiết kế của bạn có tốt như thế nào chăng nữa cũng không quan trọng: phần mềm cho máy scanner và phần mềm phát triển web được sử dụng làm ví dụ trong cuốn sách này, cả hai đều thất bại trên thị trường vì những lý do rằng không có gì phải làm với tính usability của chúng cả.

Dù sao thì đây là một cuốn sách tuyệt vời khác của tác giả Cooper, và một sự tiến bộ hợp lý kể từ cuốn About Face đã đề cập phía trên. Trong cuốn About Face, tác giả Cooper coi đối tượng “Perpetual Intermediates” như là độc giả chính, còn ở đây, có một sự xác định rõ ràng hơn và vì vậy dễ phát triển hơn, đó là đối tượng personas.

9. GUI Bloopers: Don’ts and Do’s for Software Developers and Web Designers

Quay trở lại những ngày tươi đẹp của Windows 95 và Apple’s System 7, đã có những quy tắc thực tế về giao diện người dùng GUI. Và đây là một cuốn sách đặc sắc trong việc thiết kế GUI, về tính nhất quán trong các menu, việc căn lề các button và các text trên các cửa sổ dialog. Bạn có thể tranh luận rằng liệu có bao nhiêu người dùng có thể thực sự hiểu về những quy tắc này, nhưng it ra thì họ cũng có thể mong chờ giao diện người dùng của ứng dụng A có cách bố trí rất giống với ứng dụng B.

Một thực tế đó là thế giới GUI cổ điển và thế giới của trình duyệt (browser) đang dần nhập lại với nhau — kết hợp lấy tất cả những ưu điểm tốt nhất của cả hai. Có những loại ứng dụng mà có giao diện giống hệt của browser.

10. Programming Pearls (2nd Edition)

Tôi đã hơi lưỡng lự khi liệt kê cuốn Programming Pearls vào danh sách này, bởi vì nó chứa khá nhiều kỹ thuật lập trình ở mức thấp, nhưng có đủ “pearls” (tác giả chơi chữ vì pearl có nghĩa là ngọc trai) của nghề phần mềm trong cuốn sách này để làm cho nó có giá trị đối với thời gian của bất kỳ một lập trình viên nào. Programming Pearls là cuốn sách hay tiếp theo để bạn làm việc bên cạnh như thể đang làm cùng với một lập trình viên tài năng vậy. Nó là một tập hợp của những khôn ngoan của nhiều lập trình viên “cao thủ” đã được chưng cất và cô đọng lại, nhưng khá dễ hiểu.

Tôi sẽ không nói dối bạn: phần lớn các chương trong cuốn sách này bạn có thể lờ đi. Ví dụ, tôi không thể tưởng tượng việc thực thi các thuật toán sorting, heap hoặc hash lại được viết lại trong các chương 11, 13 và 14 tương ứng, vì ngày nay đã có những thư viện tuyệt vời cho những thứ nguyên thủy cơ bản này. Chỉ cần đọc lướt qua cuốn sách, lờ đi các phần code. Chương 8, “Back of the Envelope” thì quan trọng, có thể là phương pháp ước lượng tốt nhất mà tôi đã từng được nhìn thấy. Nó cũng tiến một bước dài về phía trước để giảng giải về những câu hỏi phỏng vấn điên khùng mà các công ty thường sử dụng để làm phiền chúng ta.

11. The Pragmatic Programmer: From Journeyman to Master

Cuốn sách này khiến tôi nhớ về rất nhiều điểm trong cuốn Programming Pearls, nhưng nó thì thực sự tốt hơn, bởi vì nó ít tập trung vào code. Thay vì việc lo lắng về code, các tác giả đã đưa vào tất cả những hướng tiếp cận mà họ đã nhận thấy nó làm việc trong thế giới thực vào trong một cuốn sách này. Không phải tất cả những thứ này đều là về kỹ thuật lập trình. Ví dụ, việc hỏi bản thân rằng “Tại sao tôi lại làm điều này? Liệu làm việc này thậm chí có chút giá trị nào chăng?” thì không phải đang nghĩ ra ngoài cái hộp (thinking outside the box); nó là một điều gì đó bạn nên tổ chức vào trong các hoạt động hàng ngày để giữ cho bản thân mình — và đồng nghiệp của bạn — luôn được sảng khoái. Và chính điều đó đã làm cho Pragmatic Programmer trở thành một cuốn sách tuyệt vời.

Nếu bạn muốn biết thêm một chút về cuốn sách này, thì tôi đã tạo ra một phiên bản HTML một phần mục lục tóm tắt để tham chiếu đến các phần bên trong, nó sẽ cung cấp cho bạn một cái nhìn tổng quan về nội dung cuốn sách.

12. Designing Web Usability : The Practice of Simplicity

Tác giả Jakob Neilsen nổi tiếng vì trang web usability của ông, và nghề nghiệp là một chuyên gia về usability từ những năm 1989 khi mà cuốn sách đầu tiên của ông được xuất bản. Cuốn sáchDesigning Web Usability là một khóa học đầy đủ kiến thức căn bản về web usability, nhưng nó có một chút khác biệt hơn các cuốn sách hướng GUI của tác giả Cooper ở trên.

13. The Visual Display of Quantitative Information

14. Visual Explanations: Images and Quantities, Evidence and Narrative

15. Envisioning Information

Thông tin thì rất “đẹp”. Và một giao diện người dùng GUI được thiết kế tốt cũng vậy. Bạn không cần phải sở hữu tất cả 3 cuốn sách trong sê-ri này trừ khi bạn là một người hoàn hảo, nhưng 2 cuốn đầu thì rất cần thiết.

16. Mastering Regular Expressions, Second Edition

Hệ điều hành UNIX thường nổi tiếng một cách xứng đáng vì độ phức tạp và không thể xâm nhập. Và Regular Expressions cũng nổi tiếng như vậy.

Tôi có thể trở thành một thành viên của câu lạc bộ “Keep It Simple Stupid – giữ cho nó đơn giản nhất đồ ngốc ạ”, nhưng tôi đang làm một ngoại lệ đối với regular expressions. Nếu viết tốt, thì chúng sẽ tiết kiệm cho bạn vô số thời gian trong việc thao tác bằng tay để bắt các trường hợp khác nhau, và tôi cũng hiếm gặp một dự án nào mà chúng lại không có ích ở một nơi nào đó.

Một khi bạn đã nhảy vào thế giới của regular expressions, thì bạn có thể sẽ trở nên mê mẩn với sức mạnh tuyệt vời và tiềm năng mà chúng có.

Các bài viết liên quan:

• Hãy tích cực viết blog để chia sẻ kinh nghiệm lập trình – Phỏng vấn anh Trịnh Minh Cường
• 10 Lợi ích của việc đọc: Tại sao bạn nên đọc sách mỗi ngày
• Thiết kế website đúng cách với 5 cuốn sách
• Làm IT nên đọc ebook của nhà xuất bản nào?
• 10 Bí quyết để tăng tốc độ đọc và khả năng hiểu của bạn

Về tác giả bài viết:

Jeff Atwood là một chuyên gia công nghệ tại Mỹ, hiện đang sinh sống và làm việc tại Berkeley, CA. Anh là một kỹ sư phần mềm chuyên về công nghệ Microsoft .NET, và là một blogger nổi tiếng trong cộng đồng công nghệ với blog Coding Horror, anh là người sáng lập và kiêm Giám đốc điều hành (CEO) của trang web hỏi đáp uy tín Stack Overflow và cũng là đồng sáng lập của Stack Exchange và Discourse.