What do you think?
Rate this book
Joel On Software #2
Джоэл. И снова о программировании
Продолжение вышедшего в 2006 году бестселлера "Джоэл о программировании" представляет собой подборку самых популярных статей. Исключительный писательский талант, техническая эрудиция и язвительный ум Джоэла создали ему высочайшую профессиональную репутацию и принесли его сайту скандальную известность. В книге затронуты разнообразные вопросы, касающиеся разработки и проектирования программного обеспечения, управления софтверным бизнесом, эффективного поиска и привлечения высококлассных сотрудников, организации рабочего места и общения с заказчиками. Автор предлагает практические советы как программистам, так и тем, кто руководит их работой.
320 pages, Paperback
First published January 1, 2008
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 36 reviews
May 2, 2015
I didn't expect a lot from this book. It was published when the world was still young and great reptiles ruled the world - eight years ago. I picked it up because I've read quite a bit of Joel Spolsky's blog and I expected quite a lot from the dead-tree version.
My expectations weren't betrayed. The book features a lot of great information on how software should be developed by tackling all the non-software problems: hiring developers, building a great work environment, handling delicate topics, and much more. It gave me a glimpse at the wider state of software development and get a sense of the direction we're heading in or what kind of problems the field is having.
The book also invoked a feeling of sadness, because, even though it was compiled a good eight years ago out of Joel's even older blog posts, most of the great actionable items described in it only live on in a few hundred software shops out there. We're still expected to be ok with working in noisy open-plan offices, being told to ditch quality control measures like testing in order to "get to market faster" (then told to work overtime to "fix them darn bugs of yours"), effective forms of Agile have died out (XP) and other forms of Agile have been mutated into tools of coercion (Scrum), and much more. There doesn't seem to be a light in the tunnel.
My expectations weren't betrayed. The book features a lot of great information on how software should be developed by tackling all the non-software problems: hiring developers, building a great work environment, handling delicate topics, and much more. It gave me a glimpse at the wider state of software development and get a sense of the direction we're heading in or what kind of problems the field is having.
The book also invoked a feeling of sadness, because, even though it was compiled a good eight years ago out of Joel's even older blog posts, most of the great actionable items described in it only live on in a few hundred software shops out there. We're still expected to be ok with working in noisy open-plan offices, being told to ditch quality control measures like testing in order to "get to market faster" (then told to work overtime to "fix them darn bugs of yours"), effective forms of Agile have died out (XP) and other forms of Agile have been mutated into tools of coercion (Scrum), and much more. There doesn't seem to be a light in the tunnel.
February 20, 2021
Il s’agit tout simplement d’un recueil d’articles du blog Joel on Software venant compléter ceux qui avaient été sélectionnés pour constituer le premier recueil au titre éponyme Joel on Software. On pourrait donc légitiment se dire que l’on y trouvera pas le meilleur, que ce sera du réchauffé – un peu comme la suite, souvent peu inspirée d’un film à succès – et d’un côté c’est vrai, il y a indéniablement de ça. Mais en même temps lorsque l’on a beaucoup apprécié le premier – et c’est mon cas – on est bien content d’avoir du rab qu’il soit réchauffé ou pas. On pourrait aussi se dire tout aussi légitimement qu’il s’agit de vielles histoires – de dinosaures – du temps des grands débuts tonitruants d’Internet, c’est vrai aussi, mais certaines n’en restent pas moins édifiantes, le recul ne les rendant que plus vraies.
L’une de celles qui m’a le plus intéressée et racontée dans l’article Martian Headsets est le renversement du principe de robustesse dans le design[1] qui se résume habituellement de cette façon.
Il explique comment ce principe, qui parait évident tellement il est frappé de bon sens, a mené à la catastrophe de la non standardisation des navigateurs web et finalement à un gâchis colossal de temps et d’argent – sans parler de l’énervement engendré auprès des utilisateurs qu’ils soient informaticien ou pas d’ailleurs. A la lumière de cette expérience cette tolérance pourrait être prise pour du laxisme.
Et puis il y a l’intelligence de Joel Spolsky et son écriture enthousiasmante pleine d’humour qui rendrait agréable la lecture d’un article consacré à l’encodage des caractères – et c’est vrai, il existe.
Encore un bon moment passé à lire des réflexions intéressantes avec un petit sourire aux coins des lèvres.
Également publié sur mon blog.
L’une de celles qui m’a le plus intéressée et racontée dans l’article Martian Headsets est le renversement du principe de robustesse dans le design[1] qui se résume habituellement de cette façon.
Be conservative in what you do, be liberal in what you accept from others.
Il explique comment ce principe, qui parait évident tellement il est frappé de bon sens, a mené à la catastrophe de la non standardisation des navigateurs web et finalement à un gâchis colossal de temps et d’argent – sans parler de l’énervement engendré auprès des utilisateurs qu’ils soient informaticien ou pas d’ailleurs. A la lumière de cette expérience cette tolérance pourrait être prise pour du laxisme.
Et puis il y a l’intelligence de Joel Spolsky et son écriture enthousiasmante pleine d’humour qui rendrait agréable la lecture d’un article consacré à l’encodage des caractères – et c’est vrai, il existe.
Watching nonprogrammer trying to run software companies is like watching someone who doesn’t know how to surf trying to surf.
Encore un bon moment passé à lire des réflexions intéressantes avec un petit sourire aux coins des lèvres.
Également publié sur mon blog.
June 2, 2023
The book is just “old” for current moment. It has some great stories but they not so useful in current days, especially for a developers that 2-3 years in the IT.
March 1, 2013
Another book bundling Joel Spolky's thoughts on software development, software education, companies and stuff. Actually, it's a collection of blog posts published somewhere between 2000 - 2008.
I like Joel. I like the way he writes. He must have been in 37Signals minds when they wrote in 'Getting Real': hire good writers. Joel is a good writer having the ability to explain difficult concepts in a language my father understands. On top of that he is funny at times.
My favourite story from this book is where he tells about refactoring the code for fogbugz ('Rub a Dub Dub'). It's really comforting to see that even guys like him are "removing all formatting from HTML on putting it in CSS" or "removing all SQL statements from presentation code". Software grows, emerges, evolves. You don't write genius code in one go. Only geniuses do. Not you. Not me. Not Joel.
Read this one and his other blog collection book as well.
I like Joel. I like the way he writes. He must have been in 37Signals minds when they wrote in 'Getting Real': hire good writers. Joel is a good writer having the ability to explain difficult concepts in a language my father understands. On top of that he is funny at times.
My favourite story from this book is where he tells about refactoring the code for fogbugz ('Rub a Dub Dub'). It's really comforting to see that even guys like him are "removing all formatting from HTML on putting it in CSS" or "removing all SQL statements from presentation code". Software grows, emerges, evolves. You don't write genius code in one go. Only geniuses do. Not you. Not me. Not Joel.
Read this one and his other blog collection book as well.
Read
October 21, 20261. Quản lý con người và tuyển dụng
- Tuyển dụng lập trình viên xuất sắc: Các lập trình viên giỏi hiếm khi xuất hiện trên thị trường việc làm tự do vì họ luôn được săn đón. Doanh nghiệp nên tìm kiếm họ thông qua chương trình thực tập sinh từ trường đại học, tham gia các hội thảo công nghệ chuyên sâu hoặc tự xây dựng cộng đồng
- Môi trường làm việc: Cung cấp phòng làm việc riêng yên tĩnh, bàn ghế chuẩn công thái học và màn hình lớn giúp gia tăng đáng kể năng suất làm việc cũng như tạo lợi thế cạnh tranh khi thu hút nhân tài
- 3 phương pháp quản lý:
+ Command and Control (Mệnh lệnh và kiểm soát): Thiếu hiệu quả trong ngành công nghệ vì quản lý không đủ thời gian vi quản lý và lập trình viên là người nắm rõ chi tiết kỹ thuật hơn cấp trên.
+ Econ 101 (Kinh tế học nhập môn): Dùng tiền thưởng, phạt trực tiếp dễ làm suy giảm động lực nội tại (intrinsic motivation) và khiến nhân viên tìm cách qua mặt hệ thống
+ Identity Management (Quản lý danh tính, sự đồng điệu): Phương pháp hiệu quả nhất, giúp nhân viên tự nguyện gắn kết và cống hiến bằng cách làm cho họ đồng điệu với mục tiêu và giá trị của tổ chức
2. Lời khuyên cho lập trình viên
- Ba kỹ năng nền tảng: Sinh viên máy tính cần rèn luyện kỹ năng viết và giao tiếp tiếng Anh rõ ràng để truyền đạt ý tưởng, học ngôn ngữ C để hiểu sâu về bộ nhớ, con trỏ và đệ quy và nắm vững kinh tế vi mô để hiểu giá trị kinh doanh của phần mềm.
- Phê bình mô hình JavaSchool: Việc các trường đại học chuyển sang dạy hoàn toàn bằng Java khiến sinh viên thiếu khả năng tư duy ở nhiều mức độ trừu tượng khác nhau (như quản lý con trỏ hay lập trình hàm)
3. Ảnh hưởng của thiết kế
- Giao diện xã hội Đối với phần mềm kết nối con người với con người (diễn đàn, mạng xã hội), thiết kế chỉ tiết kỹ thuật sẽ trực tiếp định hình hành vi và văn hóa của cộng đồng
- Tránh quá nhiều lựa chọn (Choices = Headaches): Việc cung cấp quá nhiều tùy chọn cấu hình khiến người dùng mệt mỏi, thiết kế tốt cần đưa ra các lựa chọn mặc định thông minh
- Chi tiết nhỏ tạo nên sản phẩm vĩ đại (A Game of Inches): Phần mềm xuất sắc được tích tụ từ việc kiên trì cải tiến hàng ngàn chi tiết nhỏ mỗi ngày
4. Quản lý dự án lớn
- Tiêu chuẩn web và tính tương thích ngược: Luôn có sự giằng co giữa nhà lý tưởng (muốn tuân thủ tuyệt đối tiêu chuẩn kỹ thuật) và nhà thực tế (cần duy trì tương thích ngược để ứng dụng cũ không bị lỗi)
- Sự phức tạp của định dạng tệp Office: Các định dạng nhị phân như Excel hay Word phức tạp không phải do lập trình kém, mà vì chúng phải biểu diễn toàn bộ tính năng phong phú của ứng dụng và duy trì tương thích qua hàng thập kỷ.
5. Lời khuyên lập trình
- Lập kế hoạch dựa trên bằng chứng (Evidence-Based Scheduling - EBS): Phương pháp dự đoán ngày hoàn thành dự án chính xác bằng cách chia nhỏ tác vụ (dưới 16 giờ), ghi nhận thời gian thực tế và chạy mô phỏng Monte Carlo dựa trên vận tốc làm việc lịch sử của từng lập trình viên
- Ưu thế của Lập trình hàm (Functional Programming): Việc dùng hàm ẩn danh, map và reduce giúp mã nguồn ngắn gọn, dễ tái sử dụng và có khả năng xử lý song song cao
- Biến code sai trở nên rõ ràng: Thiết lập các quy ước đặt tên để các lỗi hay lỗ hổng bảo mật tự nổi bật và dễ phát hiện ngay khi đọc code
6. Khởi nghiệp và kinh doanh phần mềm
- Nguyên tắc khởi nghiệp: Sản phẩm bắt buộc phải giải quyết một nỗi đau cụ thể của khách hàng, không nên khởi nghiệp một mình, và cần kiên nhẫn với sự tăng trưởng doanh thu tích lũy dần theo thời gian
- Dịch vụ khách hàng xuất sắc: Sửa mọi sự cố theo hai cách (giải quyết vấn đề trước mắt cho khách hàng + sửa tận gốc trong source code, quy trình để không bao giờ tái diễn), luôn sẵn sàng nhận lỗi và áp dụng chính sách hoàn tiền linh hoạt để tạo dựng niềm tin
- Định giá phần mềm: Tận dụng đường cong nhu cầu (demand curve) và phân đoạn thị trường (market segmentation). Phần mềm đóng gói giá rẻ hoặc giá vừa phải giúp thu hút lượng lớn người dùng tự lan truyền
- Xác định thứ tự ưu tiên tính năng: Tránh bẫy làm tính năng riêng cho một khách hàng cá biệt (consultingware), hãy dùng phương pháp bỏ phiếu và đánh giá chi phí tương đối để chọn ra danh mục tính năng đáng giá nhất
7. Bảo trì và phát triển phần mềm
- Cải tạo source code: Thay vì đập đi xây lại từ đầu - một việc rất rủi ro và tốn thời gian thì ta nên tiến hành dọn dẹp, tái cấu trúc (refactoring) source code từng bước nhỏ nhưng liên tục mà vẫn giữ hệ thống hoạt động bình thường
- Phương pháp Five Whys: Khi gặp sự cố kỹ thuật hoặc vận hành, hãy liên tục hỏi "Tại sao?" 5 lần để tìm ra nguyên nhân gốc rễ và đưa ra giải pháp ngăn ngừa vĩnh viễn.
- Tuyển dụng lập trình viên xuất sắc: Các lập trình viên giỏi hiếm khi xuất hiện trên thị trường việc làm tự do vì họ luôn được săn đón. Doanh nghiệp nên tìm kiếm họ thông qua chương trình thực tập sinh từ trường đại học, tham gia các hội thảo công nghệ chuyên sâu hoặc tự xây dựng cộng đồng
- Môi trường làm việc: Cung cấp phòng làm việc riêng yên tĩnh, bàn ghế chuẩn công thái học và màn hình lớn giúp gia tăng đáng kể năng suất làm việc cũng như tạo lợi thế cạnh tranh khi thu hút nhân tài
- 3 phương pháp quản lý:
+ Command and Control (Mệnh lệnh và kiểm soát): Thiếu hiệu quả trong ngành công nghệ vì quản lý không đủ thời gian vi quản lý và lập trình viên là người nắm rõ chi tiết kỹ thuật hơn cấp trên.
+ Econ 101 (Kinh tế học nhập môn): Dùng tiền thưởng, phạt trực tiếp dễ làm suy giảm động lực nội tại (intrinsic motivation) và khiến nhân viên tìm cách qua mặt hệ thống
+ Identity Management (Quản lý danh tính, sự đồng điệu): Phương pháp hiệu quả nhất, giúp nhân viên tự nguyện gắn kết và cống hiến bằng cách làm cho họ đồng điệu với mục tiêu và giá trị của tổ chức
2. Lời khuyên cho lập trình viên
- Ba kỹ năng nền tảng: Sinh viên máy tính cần rèn luyện kỹ năng viết và giao tiếp tiếng Anh rõ ràng để truyền đạt ý tưởng, học ngôn ngữ C để hiểu sâu về bộ nhớ, con trỏ và đệ quy và nắm vững kinh tế vi mô để hiểu giá trị kinh doanh của phần mềm.
- Phê bình mô hình JavaSchool: Việc các trường đại học chuyển sang dạy hoàn toàn bằng Java khiến sinh viên thiếu khả năng tư duy ở nhiều mức độ trừu tượng khác nhau (như quản lý con trỏ hay lập trình hàm)
3. Ảnh hưởng của thiết kế
- Giao diện xã hội Đối với phần mềm kết nối con người với con người (diễn đàn, mạng xã hội), thiết kế chỉ tiết kỹ thuật sẽ trực tiếp định hình hành vi và văn hóa của cộng đồng
- Tránh quá nhiều lựa chọn (Choices = Headaches): Việc cung cấp quá nhiều tùy chọn cấu hình khiến người dùng mệt mỏi, thiết kế tốt cần đưa ra các lựa chọn mặc định thông minh
- Chi tiết nhỏ tạo nên sản phẩm vĩ đại (A Game of Inches): Phần mềm xuất sắc được tích tụ từ việc kiên trì cải tiến hàng ngàn chi tiết nhỏ mỗi ngày
4. Quản lý dự án lớn
- Tiêu chuẩn web và tính tương thích ngược: Luôn có sự giằng co giữa nhà lý tưởng (muốn tuân thủ tuyệt đối tiêu chuẩn kỹ thuật) và nhà thực tế (cần duy trì tương thích ngược để ứng dụng cũ không bị lỗi)
- Sự phức tạp của định dạng tệp Office: Các định dạng nhị phân như Excel hay Word phức tạp không phải do lập trình kém, mà vì chúng phải biểu diễn toàn bộ tính năng phong phú của ứng dụng và duy trì tương thích qua hàng thập kỷ.
5. Lời khuyên lập trình
- Lập kế hoạch dựa trên bằng chứng (Evidence-Based Scheduling - EBS): Phương pháp dự đoán ngày hoàn thành dự án chính xác bằng cách chia nhỏ tác vụ (dưới 16 giờ), ghi nhận thời gian thực tế và chạy mô phỏng Monte Carlo dựa trên vận tốc làm việc lịch sử của từng lập trình viên
- Ưu thế của Lập trình hàm (Functional Programming): Việc dùng hàm ẩn danh, map và reduce giúp mã nguồn ngắn gọn, dễ tái sử dụng và có khả năng xử lý song song cao
- Biến code sai trở nên rõ ràng: Thiết lập các quy ước đặt tên để các lỗi hay lỗ hổng bảo mật tự nổi bật và dễ phát hiện ngay khi đọc code
6. Khởi nghiệp và kinh doanh phần mềm
- Nguyên tắc khởi nghiệp: Sản phẩm bắt buộc phải giải quyết một nỗi đau cụ thể của khách hàng, không nên khởi nghiệp một mình, và cần kiên nhẫn với sự tăng trưởng doanh thu tích lũy dần theo thời gian
- Dịch vụ khách hàng xuất sắc: Sửa mọi sự cố theo hai cách (giải quyết vấn đề trước mắt cho khách hàng + sửa tận gốc trong source code, quy trình để không bao giờ tái diễn), luôn sẵn sàng nhận lỗi và áp dụng chính sách hoàn tiền linh hoạt để tạo dựng niềm tin
- Định giá phần mềm: Tận dụng đường cong nhu cầu (demand curve) và phân đoạn thị trường (market segmentation). Phần mềm đóng gói giá rẻ hoặc giá vừa phải giúp thu hút lượng lớn người dùng tự lan truyền
- Xác định thứ tự ưu tiên tính năng: Tránh bẫy làm tính năng riêng cho một khách hàng cá biệt (consultingware), hãy dùng phương pháp bỏ phiếu và đánh giá chi phí tương đối để chọn ra danh mục tính năng đáng giá nhất
7. Bảo trì và phát triển phần mềm
- Cải tạo source code: Thay vì đập đi xây lại từ đầu - một việc rất rủi ro và tốn thời gian thì ta nên tiến hành dọn dẹp, tái cấu trúc (refactoring) source code từng bước nhỏ nhưng liên tục mà vẫn giữ hệ thống hoạt động bình thường
- Phương pháp Five Whys: Khi gặp sự cố kỹ thuật hoặc vận hành, hãy liên tục hỏi "Tại sao?" 5 lần để tìm ra nguyên nhân gốc rễ và đưa ra giải pháp ngăn ngừa vĩnh viễn.
This entire review has been hidden because of spoilers.
June 19, 2026
5/5 stars
Funny, opinionated, and surprisingly timeless.
Joel Spolsky writes the way a sharp senior engineer talks: direct, full of anecdotes, zero filler. This is a collection of essays on nearly everything that matters in software: hiring, managing people, scheduling, code quality, product design, customer support, and running a software business. It reads fast and sticks.
A few ideas that stayed with me long after I closed the book. Great developers are never on the job market; you have to go find them before they know they are in demand. Financial incentives corrupt intrinsic motivation, and any manager who thinks bonuses fix quality problems has not thought it through. Evidence-Based Scheduling is a genuinely practical system: break work into hours, track your actuals, compute velocity, simulate your ship date with Monte Carlo. A schedule is a probability distribution, not a promise. And the idea of making wrong code look wrong, architecting your conventions so that errors are visually obvious before you run anything, is the kind of insight that changes how you read code forever.
Joel's stance on programming standards is where the book shows its age most visibly. He argues that abstracting away the hard parts (pointers, recursion, memory management) produces weaker engineers. The world has since moved firmly in the opposite direction. AI is democratising programming, abstraction keeps going up, and I think that is the natural course of things. To build bigger systems, you need to think at higher levels. The bar did not get lower. It just moved.
But that tension is actually what makes the book worth reading in 2025. Most of his thinking on people, products, and process holds up completely. The fundamentals have not aged out.
Recommended for developers, and genuinely accessible to anyone who works with them.
Funny, opinionated, and surprisingly timeless.
Joel Spolsky writes the way a sharp senior engineer talks: direct, full of anecdotes, zero filler. This is a collection of essays on nearly everything that matters in software: hiring, managing people, scheduling, code quality, product design, customer support, and running a software business. It reads fast and sticks.
A few ideas that stayed with me long after I closed the book. Great developers are never on the job market; you have to go find them before they know they are in demand. Financial incentives corrupt intrinsic motivation, and any manager who thinks bonuses fix quality problems has not thought it through. Evidence-Based Scheduling is a genuinely practical system: break work into hours, track your actuals, compute velocity, simulate your ship date with Monte Carlo. A schedule is a probability distribution, not a promise. And the idea of making wrong code look wrong, architecting your conventions so that errors are visually obvious before you run anything, is the kind of insight that changes how you read code forever.
Joel's stance on programming standards is where the book shows its age most visibly. He argues that abstracting away the hard parts (pointers, recursion, memory management) produces weaker engineers. The world has since moved firmly in the opposite direction. AI is democratising programming, abstraction keeps going up, and I think that is the natural course of things. To build bigger systems, you need to think at higher levels. The bar did not get lower. It just moved.
But that tension is actually what makes the book worth reading in 2025. Most of his thinking on people, products, and process holds up completely. The fundamentals have not aged out.
Recommended for developers, and genuinely accessible to anyone who works with them.
July 28, 2020
Joel writings on software are witty and full of insights. His ideas come from applying various domains, such as economy, mathematics, psychology to the software development. This shows how important it is to be well rounded, knowledge hungry to be successful.
May 5, 2021
Вторая книга Джоэла оказалась такой же полезной пищей для размышлений, как и первая. Здесь он пишет, в основном, об управлении проектами разработки ПО и ведении софтверного бизнеса. Советую всем, кто собирается заниматься этим. Не понравился только неуместный анекдот про Россию.
Read
July 14, 2021這本比較偏向於如何經營一間軟體公司的本質。
October 20, 2023
Many ideas in this book go beyond software development and are thus applicable to other issues of your professional life.
February 23, 2010
Like the original Joel on Software, this book is a collection of articles that Joel Spolsky has posted on his website in the past 10 years. And like the original, it's loosely organized into parts, but there's no overarching narrative. Unlike the original, the articles are fascinating up to the last word, and I was genuinely surprised when I reached the last page. It left me wanting more.
Joel is an amazing writing about software development: programming itself, management, and the entire product lifecycle. His books are the new Mythical Man Month, but way more fun to read, way more comprehensive, and without any of the boring stuff that only pertains to writing operating systems in the 1960s. He covers programming, design, managing, hiring, pricing, customer service--everything a software company needs to succeed and thrive. And his writing is so good, even though you can find every word of this book on his website for free, you'll still want to buy this book and carry it with you and read it again and again as a moderm software development bible.
Joel is an amazing writing about software development: programming itself, management, and the entire product lifecycle. His books are the new Mythical Man Month, but way more fun to read, way more comprehensive, and without any of the boring stuff that only pertains to writing operating systems in the 1960s. He covers programming, design, managing, hiring, pricing, customer service--everything a software company needs to succeed and thrive. And his writing is so good, even though you can find every word of this book on his website for free, you'll still want to buy this book and carry it with you and read it again and again as a moderm software development bible.
May 17, 2014
This book certainly deserves a 5 star rating not because it talks about the intricacies of software industry from Joel's point of view but because it makes you aware of every single aspect of the software industry warning you of all the pitfalls. This is one of the best books I have ever read on software and is a bible every software guy should read and assimilate.It teaches you the tips and tricks of software development and the business in close proximity from someone who has been there and done that.As a startup guy I found it extremely invaluable and I am sure I'd read it over and over again going ahead.
February 10, 2012
I'm pretty sure I had read at least half of this book before on Joel's blog (big surprise, it's a book of blog posts) but it was still interesting to read through this. As I'm in the beginning stages of a programming career I found myself mostly nodding and saying "Yes, that seems correct" a lot. This is definitely the kind of book I want to pick up again in 5 years and dive a little deeper into the thoughts behind it all. Great writer, great book. He sets a high bar for me, another Joel in the software world. I've got a lot of blogs to write.
January 22, 2017
Well, Joel clearly thought I made so much money with the first book. May be I can make some more with the second one.
This is a poor follow up to the first book. It would have been 10 times better if Joel released an updated version of the first book - but I get it, he is not a full time book author.
Suggest skipping this book. Though: there are 2-3 quite good articles in it.
This is a poor follow up to the first book. It would have been 10 times better if Joel released an updated version of the first book - but I get it, he is not a full time book author.
Suggest skipping this book. Though: there are 2-3 quite good articles in it.
November 30, 2017
The continuation of the first book, Joel on Software, is also a set of articles from Joel's blog. Most of them are still relevant (business-related), some are relevant because software development stumbles upon the same problems again and again (history repeating), and a small part is old.
February 15, 2010
This book is basically selected blog posts from http://www.joelonsoftware.com in book form for offline portability. There is definitely some good relevant content here covering a wide range of topics around effective software engineering, management, and the state and nature of the industry.
March 28, 2013
Highly enjoyable and really interesting. It's not so often that you get a technical book that is actually a pleasure to read. Joel Spolsky has some really interesting opinions and I learned a lot of stuff about software development that I wasn't aware of.
August 3, 2015
Explains the things that should and do happen at software companies and in code. Pretty great, though I don't share his view on liberal arts or non prestigious schools for the most part. (It isn't Joel on Liberal Arts, and those classes weren't his favorites, which is fine.)
August 21, 2016
Like how "ignore everyone" was better than "the devil plan", More Joel on software is a bit less than the original Joel on software. If you have read Smart and Get Thing Done, the content of part 1, 2 (and 3? I don't remember clearly) is sort of repeated.
July 9, 2008
Here's what I think of this book: http://blogs.citytechinc.com/sanderso...
October 14, 2008
Joel, if you tell the "I once worked at this bakery..." story one more time, I swear I'm going to scream.
August 2, 2009
witty and intelligent. this is a great read. even if you are not planning to go into the software business, it's a great look into the mind of a sharp entrepreneur.
February 11, 2010
'Nother good Spolsky book. Almost enough said right there if you're a software developer.
Essays adapted from joelonsoftware.com, but with additional content. Hooray for that.
Essays adapted from joelonsoftware.com, but with additional content. Hooray for that.
March 30, 2010
Software development tips from the trenches! As good as the first one.
Read
August 3, 2011Another good selection of Joel writing from his web site. As always his style makes reading fun.
November 4, 2012
There is a lot to learn from him, I don't find him that much of a good writer compare to his popularity.
November 23, 2012
Better than the first.
my favorite quote: "Managers exist to get furniture out of the way so the real talent can do brilliant work."
my favorite quote: "Managers exist to get furniture out of the way so the real talent can do brilliant work."
February 23, 2013
Well written and filled with good, commonsense information. The first book was better, which is to be expected, as the books are culled from blogs on his website. Recommended for programmers.
October 12, 2013
Just as the cover advertises: all the best material from the blog, now in a convenient dead-tree format. Sometimes it's just good to freshen up on what you already read before.
November 13, 2013
Loved the sequel as much as the first book - thought provoking and humorous.
Displaying 1 - 30 of 36 reviews