What do you think?
Rate this book
Joel On Software #1
Joel on Software
Someone once said that the task of a writer is to "make the familiar new and the new familiar". For years, Joel Spolsky has done exactly this at www.joelonsoftware.com. Now, for the first time, you can own a collection of the most important essays from his site in one book, with exclusive commentary and new insights from joel.
362 pages, Paperback
First published January 1, 2004
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 148 reviews
August 27, 2016
Most tech books get old and out-of-date with time. However I learned plenty of stuff from Joel on Software and enjoyed the author's humour and approach on many topics.
Here's a non-exhaustive list of things I learned (more) about:
- Always have a bug tracking system.
- Fix bugs first before you move on to working on new features. Saves lots of time.
- The Joel Test. I need to score better at that.
- Character encodings. I always got away with not knowing much about that, now I do. Thanks Joel :D.
- Do paper prototyping.
- Incentive pay. Don't do that.
- Avoid multi-tasking. Humans aren't really good at it.
- Not-Invented-Here Syndrome. It's not necessarily bad.
- Chicken-And-Egg problems in the software world.
There's a sequel: More Joel on Software, I might read it sometime.
Quotes:
I always wanted to start a blog, this is somewhat of a motivation.
About the Not-Invented-Here Syndrome:
Here's a non-exhaustive list of things I learned (more) about:
- Always have a bug tracking system.
- Fix bugs first before you move on to working on new features. Saves lots of time.
- The Joel Test. I need to score better at that.
- Character encodings. I always got away with not knowing much about that, now I do. Thanks Joel :D.
- Do paper prototyping.
- Incentive pay. Don't do that.
- Avoid multi-tasking. Humans aren't really good at it.
- Not-Invented-Here Syndrome. It's not necessarily bad.
- Chicken-And-Egg problems in the software world.
There's a sequel: More Joel on Software, I might read it sometime.
Quotes:
I always wanted to start a blog, this is somewhat of a motivation.
[...] Philip Greenspun, who taught me that if you know something, you need to publish it on the web for others to learn from.
Rewarding good coders by promoting them to a different position, one that involves writing English, not C++, is a classic case of the Peter Principle: people tend to be promoted to their level of incompetence.
About the Not-Invented-Here Syndrome:
If it's a core business function, do it yourself, no matter what.
July 1, 2015
In one sense, I haven't read the book, as the book.
In another sense, I've read it, as the essays on line.
Now, I'll buy it.
Very few people in IT can think so clearly or so deeply,
and very few can write so clearly.
Beautiful.
In another sense, I've read it, as the essays on line.
Now, I'll buy it.
Very few people in IT can think so clearly or so deeply,
and very few can write so clearly.
Beautiful.
December 15, 2007
If Jerry Seinfeld had decided to become a software professional, he might have written something like this. He observes the things that software developers and their colleagues do, skewers those practices with humor, and then says how it really ought to be done. Sometimes I agree with him, sometimes I didn't, but I like his writing well enough that it seemed worth buying a copy of the book. Most of the articles in the book are also available online on Spolsky's blog, but as I seem to recall from his introductory observations, at least a book won't electrocute you if you have a mishap while reading in the bathroom.
September 19, 2020
Equal parts nostalgia, historical artifacts, and timeless wisdom. Fun read overall.
April 11, 2017
It is surprisingly refreshing to find out that Joel's thoughts about how software should be developed nearly fifteen years ago have all been accomplished and further advanced. It is also funny to read about how Microsoft will lose the API wars (they lost it to the Web and Mobile) but still stay strong (which is still true).
August 18, 2009
Treat it like the Bible. Take only the good stuff out of it.
May 24, 2017
I really wanted to like this book more than I did because I'm a big fan of Spolsky. A lot of the content I'd read before from his blog, which I'm OK with and was fully expecting. However it really jumps all over the place. (I suppose the expanded title does allude to that.) The second half is decidedly random, doesn't follow on neatly from the first, and seems to have been added as an afterthought. The book stops so abruptly with no conclusion but a Q&A chapter where both the questions and answers I feel haven't really stood the test of time. I'm glad I bought it, his writing is very entertaining, and I'm still a big fan - but I give it only 3 stars.
November 17, 2013
I really enjoyed reading this book, even if Joel was kind of obsessed with Microsoft and Netscape. I like the little stories about problems he faces building his own company and learning about mistakes that compromise a business - not software bugs, but strategy bugs. My things to remember from this book are: know who your customers are and pay attention to what they need/want.
July 30, 2015
One of the best contemporary books on software engineering. Though a bit outdated (articles from early 2000s), the concepts and ideas are extremely valid. Got a lot of new perspectives from this book. Must read.
January 25, 2007
Joel's a windows coder - but a smart one. Its actually interesting to hear about that side of things, as usually I'm just turning my nose up at it :) A good read for any programmer.
January 2, 2023
This book probably was relevant pre-2005 when Microsoft was the biggest tech company and their technologies and methodologies were the standards in the tech industry.
This book is essentially a compilation of a selection of Joel's blog entries on his website between 2000 and 2004. This was just before the emergence of the next generation of tech companies and technologies that we are familiar with today (FAANG etc) and hence Joel sometimes says things that don't apply any more ("web-based document editors will never work").
Having said that, there are also a few chapters in this book pertaining to software management -- project and people management which probably are more relevant than the rest of the book. Project estimation, project launch strategies, bug tracking, bug fixing strategies etc are explained well and I learned a bunch from that. There's a chapter at the end that explains "compliments" in tech that was really interesting to me (If tech1 is a compliment of tech2, The cheaper that tech2 is, the higher the demand for tech1) and explains the reasons behind why certain tech companies invest in open source software (Oracle, Google etc) even though it has no seemingly direct benefit to them.
Joel worked for 3 years at Microsoft and then set up his own company (Fogcreek software) but devotes almost 60% of the time talking about Microsoft tech and its culture. This part seems incredibly outdated since M is not as sought-after workplace as it was in the early 2000s and its interviewing and hiring strategies are not as relevant anymore.
Joel has since gone on and founded StackOverflow which is used by developers throughout the world and I'd be interested in learning about his experiences in setting that up and the tech used in that process.
In all honesty, this book should not be sold as a software management book (at least at full price) anymore since it's outdated and does not help in learning too many new things.
This book is essentially a compilation of a selection of Joel's blog entries on his website between 2000 and 2004. This was just before the emergence of the next generation of tech companies and technologies that we are familiar with today (FAANG etc) and hence Joel sometimes says things that don't apply any more ("web-based document editors will never work").
Having said that, there are also a few chapters in this book pertaining to software management -- project and people management which probably are more relevant than the rest of the book. Project estimation, project launch strategies, bug tracking, bug fixing strategies etc are explained well and I learned a bunch from that. There's a chapter at the end that explains "compliments" in tech that was really interesting to me (If tech1 is a compliment of tech2, The cheaper that tech2 is, the higher the demand for tech1) and explains the reasons behind why certain tech companies invest in open source software (Oracle, Google etc) even though it has no seemingly direct benefit to them.
Joel worked for 3 years at Microsoft and then set up his own company (Fogcreek software) but devotes almost 60% of the time talking about Microsoft tech and its culture. This part seems incredibly outdated since M is not as sought-after workplace as it was in the early 2000s and its interviewing and hiring strategies are not as relevant anymore.
Joel has since gone on and founded StackOverflow which is used by developers throughout the world and I'd be interested in learning about his experiences in setting that up and the tech used in that process.
In all honesty, this book should not be sold as a software management book (at least at full price) anymore since it's outdated and does not help in learning too many new things.
November 25, 2022
more cohesive than the website, where by cohesive I mean "can read in the bathtub without fear of electrocution."
the lowest level Von Neumann fundamental stuff. Wipe J2EE out of your mind for a moment. Think bytes.
This code uses the Shlemiel the Painter's Algorithm. Try opening an overstuffed Windows recycle bin to see this in action—it takes hours to show up, which is clearly not linear in the number of files it contains. There must be a Shlemiel the Painter's Algorithm in there somewhere. Whenever something seems like it should have linear performance but it seems to have n-squared performance, look for hidden Shlemiels.
I used to call these fucked strings because it's easier than calling them null-terminated Pascal strings, but this is a G-rated channel, so you will have use the longer name.
garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)
the original HTML spec for TABLES was so badly designed that large tables on web pages can't be shown quickly to people with modems.
A minimal useful bug database must include the following data for every bug:
- complete steps to reproduce the bug
- expected behaviour
- observed (buggy) behaviour
- who it's assigned to
- whether it has been fixed or not
just make a simple five-column table with these crucial fields and start using it.
the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind. And if you find a bug in code that has already shipped, you're going to incur incredible expense getting it fixed.
Writing specs is like flossing: Everybody agrees that it's a good thing, but nobody does it.
you should enforce the simple rule "no code without spec."
There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively.
The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity.
Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I'm simply blown away that more people don't recognize it.
if you're still programming that way, you're not much better than a medical doctor who doesn't believe in germs.
Her baby brother (half brother) is vegged-out in front of the only TV set
(e.g., there is no @ sign or it contains characters that are not permitted in email addresses by RFC-822), the server returns another page that looks just like Log In Form
If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a " nongoals" section of the spec. Things we are just not going to do. A nongoal might be ("We don't care about performance in this release.
When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. 1(If you haven't read it, I highly recommend it.) The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n−1)/2, which grows at O(n2).
Since then, program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about five programmers for every program manager; these programmers are responsible for implementing in code what the program manager has implemented in the form of a spec. A program manager also needs to coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn't spend time on.
Program managers study UI, meet customers, and write specs.
Don't have coders report to the program manager. This is a subtle mistake. As a program manager at Microsoft, I designed the Visual Basic (VBA) strategy for Excel and completely speced out, to the smallest detail, how VBA should be implemented in Excel. My spec ran to about 500 pages.
As a spec-writer, you have to trick people into reading your stuff.
Rule 1: Be Funny
If you read a lot of Dave Barry, you'll discover that one of the easiest ways to be funny is to be specific when it's not called for. 1"Scrappy pugs" are funnier than "dogs." "Miss Piggy" is funnier than "the user." Instead of saying "special interests," say "left-handed avocado farmers."
If you show a chessboard, in the middle of a real game of chess, to an experienced chess player for even a second or two, they will instantly be able to memorize the position of every piece. But if you move around a couple of pieces in nonsensical ways that couldn't happen in normal play (for example, put some pawns on the first row, or put both black bishops on black squares), it becomes much, much harder for them to memorize the board. This is different from the way computers think. A computer program that could memorize a chess board could memorize both possible and impossible layouts with equal ease. The way the human brain works is not random access; pathways tend to be strengthened in our brains and some things are just easier to understand than other things because they are more common.
Netscape's 5.0 web browser is almost two years late. Partially, this is because they made the suicidal mistake of throwing out all their code and starting over
A dependency is when you have two tasks, one of which must be completed before the next one can begin.
The standard format I use for schedules is so simple you can memorize it. You start with just seven columns:
Only the programmer who is going to write the code can schedule it. Any system where management writes a schedule and hands it off to programmers is doomed to fail.
A programmer should never, ever work on new code if they could instead be fixing bugs.
Never, ever let managers tell programmers to reduce an estimate.
Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive.
But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it.
a professional programmer told me, "we used to keep a sit-up board in the office and do sit-ups while we were doing compiles. After a few months of programming I had killer abs."
Set your compilers to maximum warning level (-W4 in Microsoft's world; -Wall in gcc land) and set them to stop if they encounter even the smallest warning.
Your daily build script should report failures, via email, to the whole development team. It's not too hard to grep the logs for "error" or "warning" and include that in the email, too.
Fixing bugs is only important when the value of having the bug fixed exceeds the cost of fixing it.
Let me give you an example. Suppose you operate a peanut-butter-and-jelly sandwich factory. Your factory produces 100,000 sandwiches a day. Recently, because of the introduction of some new flavors (garlic peanut butter with spicy habanero jam), demand for your product has gone through the roof. The factory is operating full-out at 100,000 sandwiches, but the demand is probably closer to 200,000. You just can't make any more. And each sandwich earns you a profit of 15 cents. So you're losing $15,000 a day in potential earnings because you don't have enough capacity.
If you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn't even use large files. Well, don't fix it. Similarly, I've generally given up caring about people running off-the-shelf Windows 95 with no upgrades in 7 years.
here are some ideas for finding and fixing the right bugs: the ones economically worth fixing.
So the product units started insisting that PSS (Microsoft's tech support) provide lists of Top Ten Bugs regularly. When the development team concentrated on those, product support costs plummeted.
At Fog Creek Software, well, we're a tiny company (except in our own minds)
net present value of the savings would be about $150,000. That justifies 62 days of work; if you can do it in less than 62 person-days, it's worth doing.
we calculated that it would take 20 person-days (two people two weeks) to fix everything —that's $48,000 "spent" for a return of $150,000, which is a great return on investment just on the basis of the tech support savings.
we have a rock-solid product
The bug appears only with Polish keyboards, because of the way they use this alleged AltGr key (I had never heard of it) to enter special characters.
the noisiest users for some odd reason all seem to use Precambrian browsers
Fast code is more important than elegant code.
For more about paper prototyping, read Carolyn Snyder's book
the heroic, utopian grandiloquence
An object at rest tends to remain at rest.
the more questions you ask people, the less likely they are to answer.
We've found that knowing the exact line of code where the code crashed is enough information to fix almost any crash. For those rare cases where this isn't enough information, you can contact one of the users who experienced the crash via email and ask for any additional information that might help.
good triage skills—deciding which bugs are most important to fix, and ignoring the others
the only way to catch crashes that occur anywhere in the code is to add error handling to every function. Adding this code can be a pain; luckily there's a utility you can get called ErrorAssist ( http://www.errorassist.com), which will add error-trapping code to all your functions automatically. In every case, we just call a global function called HandleError, which displays our custom crash dialog.
Another way to accomplish the same thing from C++ code is to surround the main entry point with a __try/__catch clause.
I look for evidence that the person has gone through some particularly difficult selection process in the past and passed. For example, highly selective universities are a good sign. You may know of certain companies with a reputation of being very picky about who they hire; when you see these companies on a résumé, it might be worth investigating this candidate some more. Elite military units that only accept a small percentage of their volunteers are a good sign.
Call them up and chat about a particular programming problem for about half an hour. For example, "How might you go about writing an XML parser?" You can save time and money on the in-person interviews by rejecting these apparent morons now.
Finally, the on-site, in-person interview. You should always try to have at least six people interview each candidate who gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers). If even two of the six interviewers thinks that a person is not worth hiring, don't hire that candidate.
In software, things change so often and so rapidly that you need people who can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant who is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire.
Why am I so hardnosed about this? It's because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it.
You're looking for people who are
1. Smart
2. Get things done
People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.
they think that the candidate must be smart because "he thinks so much like me!"
thinks that smart means "knows a lot of facts."
don't ask around about the person before you interview them, and never, ever talk to the other interviewers about the candidate until you've both made your decisions independently. That's the scientific method.
The introduction phase of the interview is intended to put the candidates at ease. I ask them if they had a nice flight. I spend about 30 seconds telling them who I am and how the interview will work. I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
Next I ask a question about some recent project the candidate worked on. When interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed.
Often, engineering majors will just assume that everyone knows what Bates Theorem is or what Peano's Axioms are. If they start doing this, stop them for a minute and say, "could you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand." At this point many people will still continue to use jargon and will completely fail to make themselves understood. Gong! You don't want to hire them, basically, because they are not smart enough to comprehend what it takes to make other people understand their ideas.
Don't give them any problems that take more than about ten lines of code; you won't have time for that.
In first-year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were four years old.
Brilliant candidates might even suggest a caching scheme where bits are counted the first time they are used, and then stored in a lookup table so they don't have to be counted if they are used again. Really, really brilliant candidates will try to devise a way to compute the table using some kind of a shortcut taking advantage of the patterns that occur.
Good programmers tend to use really short variable names for loop indices. If they name their loop index CurrentPagePositionLoopCounter, it is a sure sign that they have not written a lot of code in their life. In C, look for good habits like putting the constant on the left-hand side of the "==" (e.g., if (0==x) instead of if (x==0)), which prevents accidentally using a "=" resulting in an assignment instead of a test.
avoid the illegal questions. Anything related to race, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, or physical handicap is illegal here in the United States. If their résumé says they were in the Army in 1990, don't ask them, even to make pleasant conversation, if they were in Kuwait.
Next, avoid any questions that might make it seem like you care about, or are discriminating based on, things which you don't actually care about or discriminate based on. The best example of this I can think of is asking someone if they have kids or if they are married. This might give the impression that you think that people with kids aren't going to devote enough time to their work or that they are going to run off and take maternity leave.
...at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all. - Alfie Kohn, "Why Incentive Plans Cannot Work." Harvard Business Review
When I watched her repro the bug I had one of those whack-your-forehead moments. Alt! You're holding down the Alt key! Why didn't I test that?
When you're managing a team of programmers, one of the first things you have to learn to get right is task allocation. That's just a five-dollar word for giving people things to do. you can get incredible productivity benefits if you do it right.
The longer a task switch takes, the worse the multitasking penalty.
some poor dweeb from Accounts Payable who got sent to work with the programmers because he was the slowest worker over there and they would barely notice his absence.
You know how an iceberg is 90 percent underwater? Well, most software is like that too—there's a pretty user interface that takes about 10 percent of the work, and then 90 percent of the programming work is under the covers.
Don't think that they're looking at the functionality. They're not. They want to see pretty pixels. Steve Jobs understands this. Oh boy does he understand this.
Every week, send out a self-congratulatory email talking about how you've moved from 32 percent complete to 35 percent complete and are on track to ship on December 25th.
We use TCP for many things like fetching web pages and sending email. The reliability of TCP is why every exciting email from embezzling East Africans arrives in letter-perfect condition. O joy. By comparison, there is another method of transmitting data, called IP, that is unreliable.. Nobody promises that your data will arrive, and it might get messed up before it arrives.
That is, approximately, the magic of TCP. It is what computer scientists like to call an abstraction: a simplification of something much more complicated that is going on under the covers.
There was a time when if you read one book by Peter Norton, 1you literally knew everything there was to know about programming the IBMPC.
big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time
Like the space alien in Star Trek watching Earth through a telescope; he knew exactly what human food was supposed to look like, but he didn't realize it was supposed to taste like something.
It seems like any time you try to measure the performance of knowledge workers, things rapidly disintegrate, and you get what Robert D. Austin calls measurement dysfunction. His book Measuring and Managing Performance in Organizations 3is an excellent and thorough survey of the subject. Managers like to implement measurement systems, and they like to tie compensation to performance based on these measurement systems. But in the absence of 100 percent supervision, workers have an incentive to "work to the measurement," concerning themselves solely with the measurement and not with the actual value or quality of their work.
tempted fate
Even though everybody's walking around with their chins glued to their chests
the lowest level Von Neumann fundamental stuff. Wipe J2EE out of your mind for a moment. Think bytes.
This code uses the Shlemiel the Painter's Algorithm. Try opening an overstuffed Windows recycle bin to see this in action—it takes hours to show up, which is clearly not linear in the number of files it contains. There must be a Shlemiel the Painter's Algorithm in there somewhere. Whenever something seems like it should have linear performance but it seems to have n-squared performance, look for hidden Shlemiels.
I used to call these fucked strings because it's easier than calling them null-terminated Pascal strings, but this is a G-rated channel, so you will have use the longer name.
garbage collection imposes a performance penalty are not entirely true, since typical malloc implementations had the same kind of performance penalty, albeit milder.)
the original HTML spec for TABLES was so badly designed that large tables on web pages can't be shown quickly to people with modems.
A minimal useful bug database must include the following data for every bug:
- complete steps to reproduce the bug
- expected behaviour
- observed (buggy) behaviour
- who it's assigned to
- whether it has been fixed or not
just make a simple five-column table with these crucial fields and start using it.
the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.
When you have a bug in your code that you see the first time you try to run it, you will be able to fix it in no time at all, because all the code is still fresh in your mind. And if you find a bug in code that has already shipped, you're going to incur incredible expense getting it fixed.
Writing specs is like flossing: Everybody agrees that it's a good thing, but nobody does it.
you should enforce the simple rule "no code without spec."
There are extensively documented productivity gains provided by giving knowledge workers space, quiet, and privacy. The classic software management book Peopleware documents these productivity benefits extensively.
The trouble is, getting into "the zone" is not easy. When you try to measure it, it looks like it takes an average of 15 minutes to start working at maximum productivity. Let's say (as the evidence seems to suggest) that if we interrupt a programmer, even for a minute, we're really blowing away 15 minutes of productivity.
Mutt can't remember the name of the Unicode version of the strcpy function. He could look it up, which takes 30 seconds, or he could ask Jeff, which takes 15 seconds. Since he's sitting right next to Jeff, he asks Jeff. Jeff gets distracted and loses 15 minutes of productivity (to save Mutt 15 seconds).
If your team doesn't have dedicated testers, at least one for every two or three programmers, you are either shipping buggy products, or you're wasting money by having $100/hour programmers do work that can be done by $30/hour testers. Skimping on testers is such an outrageous false economy that I'm simply blown away that more people don't recognize it.
if you're still programming that way, you're not much better than a medical doctor who doesn't believe in germs.
Her baby brother (half brother) is vegged-out in front of the only TV set
(e.g., there is no @ sign or it contains characters that are not permitted in email addresses by RFC-822), the server returns another page that looks just like Log In Form
If you do them all, it will take infinite time and cost too much money. You have to start culling features right away, and the best way to do this is with a " nongoals" section of the spec. Things we are just not going to do. A nongoal might be ("We don't care about performance in this release.
When Microsoft started growing seriously in the 1980s, everybody there had read The Mythical Man-Month, one of the classics of software management. 1(If you haven't read it, I highly recommend it.) The main point of that book was that when you add more programmers to a late project, it gets even later. That's because when you have n programmers on a team, the number of communication paths is n(n−1)/2, which grows at O(n2).
Since then, program managers at Microsoft gather requirements, figure out what the code is supposed to do, and write the specs. There are usually about five programmers for every program manager; these programmers are responsible for implementing in code what the program manager has implemented in the form of a spec. A program manager also needs to coordinate marketing, documentation, testing, localization, and all the other annoying details that programmers shouldn't spend time on.
Program managers study UI, meet customers, and write specs.
Don't have coders report to the program manager. This is a subtle mistake. As a program manager at Microsoft, I designed the Visual Basic (VBA) strategy for Excel and completely speced out, to the smallest detail, how VBA should be implemented in Excel. My spec ran to about 500 pages.
As a spec-writer, you have to trick people into reading your stuff.
Rule 1: Be Funny
If you read a lot of Dave Barry, you'll discover that one of the easiest ways to be funny is to be specific when it's not called for. 1"Scrappy pugs" are funnier than "dogs." "Miss Piggy" is funnier than "the user." Instead of saying "special interests," say "left-handed avocado farmers."
If you show a chessboard, in the middle of a real game of chess, to an experienced chess player for even a second or two, they will instantly be able to memorize the position of every piece. But if you move around a couple of pieces in nonsensical ways that couldn't happen in normal play (for example, put some pawns on the first row, or put both black bishops on black squares), it becomes much, much harder for them to memorize the board. This is different from the way computers think. A computer program that could memorize a chess board could memorize both possible and impossible layouts with equal ease. The way the human brain works is not random access; pathways tend to be strengthened in our brains and some things are just easier to understand than other things because they are more common.
Netscape's 5.0 web browser is almost two years late. Partially, this is because they made the suicidal mistake of throwing out all their code and starting over
A dependency is when you have two tasks, one of which must be completed before the next one can begin.
The standard format I use for schedules is so simple you can memorize it. You start with just seven columns:
Only the programmer who is going to write the code can schedule it. Any system where management writes a schedule and hands it off to programmers is doomed to fail.
A programmer should never, ever work on new code if they could instead be fixing bugs.
Never, ever let managers tell programmers to reduce an estimate.
Many rookie software managers think that they can "motivate" their programmers to work faster by giving them nice, "tight" (unrealistically short) schedules. I think this kind of motivation is brain-dead. When I'm behind schedule, I feel doomed and depressed and unmotivated. When I'm working ahead of schedule, I'm cheerful and productive.
But you can never get 3n from n, ever, and if you think you can, please email me the stock ticker of your company so I can short it.
a professional programmer told me, "we used to keep a sit-up board in the office and do sit-ups while we were doing compiles. After a few months of programming I had killer abs."
Set your compilers to maximum warning level (-W4 in Microsoft's world; -Wall in gcc land) and set them to stop if they encounter even the smallest warning.
Your daily build script should report failures, via email, to the whole development team. It's not too hard to grep the logs for "error" or "warning" and include that in the email, too.
Fixing bugs is only important when the value of having the bug fixed exceeds the cost of fixing it.
Let me give you an example. Suppose you operate a peanut-butter-and-jelly sandwich factory. Your factory produces 100,000 sandwiches a day. Recently, because of the introduction of some new flavors (garlic peanut butter with spicy habanero jam), demand for your product has gone through the roof. The factory is operating full-out at 100,000 sandwiches, but the demand is probably closer to 200,000. You just can't make any more. And each sandwich earns you a profit of 15 cents. So you're losing $15,000 a day in potential earnings because you don't have enough capacity.
If you have a bug that totally crashes your program when you open gigantic files, but it only happens to your single user who has OS/2 and who, for all you know, doesn't even use large files. Well, don't fix it. Similarly, I've generally given up caring about people running off-the-shelf Windows 95 with no upgrades in 7 years.
here are some ideas for finding and fixing the right bugs: the ones economically worth fixing.
So the product units started insisting that PSS (Microsoft's tech support) provide lists of Top Ten Bugs regularly. When the development team concentrated on those, product support costs plummeted.
At Fog Creek Software, well, we're a tiny company (except in our own minds)
net present value of the savings would be about $150,000. That justifies 62 days of work; if you can do it in less than 62 person-days, it's worth doing.
we calculated that it would take 20 person-days (two people two weeks) to fix everything —that's $48,000 "spent" for a return of $150,000, which is a great return on investment just on the basis of the tech support savings.
we have a rock-solid product
The bug appears only with Polish keyboards, because of the way they use this alleged AltGr key (I had never heard of it) to enter special characters.
the noisiest users for some odd reason all seem to use Precambrian browsers
Fast code is more important than elegant code.
For more about paper prototyping, read Carolyn Snyder's book
the heroic, utopian grandiloquence
An object at rest tends to remain at rest.
the more questions you ask people, the less likely they are to answer.
We've found that knowing the exact line of code where the code crashed is enough information to fix almost any crash. For those rare cases where this isn't enough information, you can contact one of the users who experienced the crash via email and ask for any additional information that might help.
good triage skills—deciding which bugs are most important to fix, and ignoring the others
the only way to catch crashes that occur anywhere in the code is to add error handling to every function. Adding this code can be a pain; luckily there's a utility you can get called ErrorAssist ( http://www.errorassist.com), which will add error-trapping code to all your functions automatically. In every case, we just call a global function called HandleError, which displays our custom crash dialog.
Another way to accomplish the same thing from C++ code is to surround the main entry point with a __try/__catch clause.
I look for evidence that the person has gone through some particularly difficult selection process in the past and passed. For example, highly selective universities are a good sign. You may know of certain companies with a reputation of being very picky about who they hire; when you see these companies on a résumé, it might be worth investigating this candidate some more. Elite military units that only accept a small percentage of their volunteers are a good sign.
Call them up and chat about a particular programming problem for about half an hour. For example, "How might you go about writing an XML parser?" You can save time and money on the in-person interviews by rejecting these apparent morons now.
Finally, the on-site, in-person interview. You should always try to have at least six people interview each candidate who gets hired, including at least five who would be peers of that candidate (that is, other programmers, not managers). If even two of the six interviewers thinks that a person is not worth hiring, don't hire that candidate.
In software, things change so often and so rapidly that you need people who can succeed at just about any programming task that you throw at them. If for some reason you find an idiot savant who is really, really, really good at SQL but completely incapable of ever learning any other topic, No Hire.
Why am I so hardnosed about this? It's because it is much, much better to reject a good candidate than to accept a bad candidate. A bad candidate will cost a lot of money and effort and waste other people's time fixing all their bugs. Firing someone you hired by mistake can take months and be nightmarishly difficult, especially if they decide to be litigious about it.
You're looking for people who are
1. Smart
2. Get things done
People who are Smart but don't Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. whitepaper about the theoretical computational linguistic attributes of a spreadsheet as a programming language. Smart, but not useful.
they think that the candidate must be smart because "he thinks so much like me!"
thinks that smart means "knows a lot of facts."
don't ask around about the person before you interview them, and never, ever talk to the other interviewers about the candidate until you've both made your decisions independently. That's the scientific method.
The introduction phase of the interview is intended to put the candidates at ease. I ask them if they had a nice flight. I spend about 30 seconds telling them who I am and how the interview will work. I always reassure candidates that we are interested in how they go about solving problems, not the actual answer.
Next I ask a question about some recent project the candidate worked on. When interviewing college kids, ask them about their senior thesis, if they had one, or about a course they took that involved a long project that they really enjoyed.
Often, engineering majors will just assume that everyone knows what Bates Theorem is or what Peano's Axioms are. If they start doing this, stop them for a minute and say, "could you do me a favor, just for the sake of the exercise, could you please explain this in terms my grandmother could understand." At this point many people will still continue to use jargon and will completely fail to make themselves understood. Gong! You don't want to hire them, basically, because they are not smart enough to comprehend what it takes to make other people understand their ideas.
Don't give them any problems that take more than about ten lines of code; you won't have time for that.
In first-year computer science classes, there are always about 200 kids at the beginning of the semester, all of whom wrote complex adventure games in BASIC for their PCs when they were four years old.
Brilliant candidates might even suggest a caching scheme where bits are counted the first time they are used, and then stored in a lookup table so they don't have to be counted if they are used again. Really, really brilliant candidates will try to devise a way to compute the table using some kind of a shortcut taking advantage of the patterns that occur.
Good programmers tend to use really short variable names for loop indices. If they name their loop index CurrentPagePositionLoopCounter, it is a sure sign that they have not written a lot of code in their life. In C, look for good habits like putting the constant on the left-hand side of the "==" (e.g., if (0==x) instead of if (x==0)), which prevents accidentally using a "=" resulting in an assignment instead of a test.
avoid the illegal questions. Anything related to race, religion, gender, national origin, age, military service eligibility, veteran status, sexual orientation, or physical handicap is illegal here in the United States. If their résumé says they were in the Army in 1990, don't ask them, even to make pleasant conversation, if they were in Kuwait.
Next, avoid any questions that might make it seem like you care about, or are discriminating based on, things which you don't actually care about or discriminate based on. The best example of this I can think of is asking someone if they have kids or if they are married. This might give the impression that you think that people with kids aren't going to devote enough time to their work or that they are going to run off and take maternity leave.
...at least two dozen studies over the last three decades have conclusively shown that people who expect to receive a reward for completing a task or for doing that task successfully simply do not perform as well as those who expect no reward at all. - Alfie Kohn, "Why Incentive Plans Cannot Work." Harvard Business Review
When I watched her repro the bug I had one of those whack-your-forehead moments. Alt! You're holding down the Alt key! Why didn't I test that?
When you're managing a team of programmers, one of the first things you have to learn to get right is task allocation. That's just a five-dollar word for giving people things to do. you can get incredible productivity benefits if you do it right.
The longer a task switch takes, the worse the multitasking penalty.
some poor dweeb from Accounts Payable who got sent to work with the programmers because he was the slowest worker over there and they would barely notice his absence.
You know how an iceberg is 90 percent underwater? Well, most software is like that too—there's a pretty user interface that takes about 10 percent of the work, and then 90 percent of the programming work is under the covers.
Don't think that they're looking at the functionality. They're not. They want to see pretty pixels. Steve Jobs understands this. Oh boy does he understand this.
Every week, send out a self-congratulatory email talking about how you've moved from 32 percent complete to 35 percent complete and are on track to ship on December 25th.
We use TCP for many things like fetching web pages and sending email. The reliability of TCP is why every exciting email from embezzling East Africans arrives in letter-perfect condition. O joy. By comparison, there is another method of transmitting data, called IP, that is unreliable.. Nobody promises that your data will arrive, and it might get messed up before it arrives.
That is, approximately, the magic of TCP. It is what computer scientists like to call an abstraction: a simplification of something much more complicated that is going on under the covers.
There was a time when if you read one book by Peter Norton, 1you literally knew everything there was to know about programming the IBMPC.
big handwavy generalizations made from a position of deep ignorance is one of the biggest wastes of time
Like the space alien in Star Trek watching Earth through a telescope; he knew exactly what human food was supposed to look like, but he didn't realize it was supposed to taste like something.
It seems like any time you try to measure the performance of knowledge workers, things rapidly disintegrate, and you get what Robert D. Austin calls measurement dysfunction. His book Measuring and Managing Performance in Organizations 3is an excellent and thorough survey of the subject. Managers like to implement measurement systems, and they like to tie compensation to performance based on these measurement systems. But in the absence of 100 percent supervision, workers have an incentive to "work to the measurement," concerning themselves solely with the measurement and not with the actual value or quality of their work.
tempted fate
Even though everybody's walking around with their chins glued to their chests
August 4, 2020
Je suis tombé sur un commentaire (en anglais) qui disait à peu près ceci “C’est le livre qu’aurait écrit Jerry Seinfeld s’il avait été ingénieur en informatique”. Je n’aurais pas trouvé mieux pour caractériser ce livre. On retrouve chez les deux hommes le même humour fait d’intelligence. C’est toujours très plaisant, mais très rare de tomber sur des érudits qui ne se prennent pas au sérieux. C’est bien le cas de Joel Spolsky. Cet ancien chef d’équipe d’Excel chez Microsoft a créé sa société, Fog Creek Software, et a lancé en 2008 le célèbre site de questions / réponses pour les développeurs Stack Overflow. Avant d’être un livre il y avait – et il y a toujours – un blog. Ce livre n’est que le recueil d’articles parus, et encore accessibles, sur le blog de l’auteur.
Il y parle informatique dans toutes ses dimensions: technique, organisationnelle, stratégique et économique. Il est bourré de bonnes idées, de situations vécues, de bons conseils, de points de vues toujours très pertinents. Le mot d’ordre chez lui est le pragmatisme opposé au dogmatisme qui prévaut trop souvent dans les ouvrages consacrés à l’informatique. Il privilégie les choses simples et surtout, il n’oublie pas que derrière les écrans il y a des hommes et des femmes. A ce propos, l’un des concepts fondateur de sa société est de mettre les développeurs au coeur du dispositif et de leur fournir tout ce qu’il faut pour leur confort et leur bien-être. Ca paraît logique, mais ce n’est quasiment jamais le cas.
On pardonnera volontiers quelques répétitions et petites erreurs de jugement à côté de la montagne de bon sens qui surplombe ce livre – c’est facile 10 ans après de regarder et de voir que finalement si, Apple peut vendre des ordinateurs, mais qu’il avait raison, Sun n’en a pas été capable. Pour résumer: de l’expérience, de l’intelligence, une vision, le tout sans se prendre au sérieux et écrit dans un style humoristique qui agrémente la lecture. Que du bonheur !
P.-S.: Si vous n’êtes toujours pas convaincus et que vous vous demandez toujours pourquoi il figure dans les listes des meilleurs livres sur l’informatique, allez donc jeter un oeil sur son blog, c’est gratuit.
Également publié sur mon blog.
Il y parle informatique dans toutes ses dimensions: technique, organisationnelle, stratégique et économique. Il est bourré de bonnes idées, de situations vécues, de bons conseils, de points de vues toujours très pertinents. Le mot d’ordre chez lui est le pragmatisme opposé au dogmatisme qui prévaut trop souvent dans les ouvrages consacrés à l’informatique. Il privilégie les choses simples et surtout, il n’oublie pas que derrière les écrans il y a des hommes et des femmes. A ce propos, l’un des concepts fondateur de sa société est de mettre les développeurs au coeur du dispositif et de leur fournir tout ce qu’il faut pour leur confort et leur bien-être. Ca paraît logique, mais ce n’est quasiment jamais le cas.
On pardonnera volontiers quelques répétitions et petites erreurs de jugement à côté de la montagne de bon sens qui surplombe ce livre – c’est facile 10 ans après de regarder et de voir que finalement si, Apple peut vendre des ordinateurs, mais qu’il avait raison, Sun n’en a pas été capable. Pour résumer: de l’expérience, de l’intelligence, une vision, le tout sans se prendre au sérieux et écrit dans un style humoristique qui agrémente la lecture. Que du bonheur !
P.-S.: Si vous n’êtes toujours pas convaincus et que vous vous demandez toujours pourquoi il figure dans les listes des meilleurs livres sur l’informatique, allez donc jeter un oeil sur son blog, c’est gratuit.
Également publié sur mon blog.
June 22, 2022
Recommended to: EVERYONE who makes software. yes even game designers.
I wish Joel was my boss. If his company started making videogames, I'd apply there tomorrow.
Spolsky's an insightful and relentlessly reasonable guy. Either that or he has a way of describing ideas that make them seem like the most natural thing in the world.
There are small sections that will seem too technical for non-programmers, but the details of the specific technology or programming languages aren't really the important thing. Those sections can be interpreted through context or taken in a general sense and they're still as useful.
These very detailed sections were also useful to me in that they helped me to realize anyone can learn to make a programming language achieve a goal, the hard thing is to learn to do that thing in ten different ways and know which way is the best under a given set of circumstances. just like design, context is everything.
Everyone with even a passing interest in project management, running a company, or making software of any type should read this book.
I wish Joel was my boss. If his company started making videogames, I'd apply there tomorrow.
Spolsky's an insightful and relentlessly reasonable guy. Either that or he has a way of describing ideas that make them seem like the most natural thing in the world.
There are small sections that will seem too technical for non-programmers, but the details of the specific technology or programming languages aren't really the important thing. Those sections can be interpreted through context or taken in a general sense and they're still as useful.
These very detailed sections were also useful to me in that they helped me to realize anyone can learn to make a programming language achieve a goal, the hard thing is to learn to do that thing in ten different ways and know which way is the best under a given set of circumstances. just like design, context is everything.
Everyone with even a passing interest in project management, running a company, or making software of any type should read this book.
April 26, 2021
A series of somewhat unrelated software topics by one of the giants of software development and defacto father of Stack Overflow, Joel Spolsky.
Since most of the chapters here have a timestamp from the early 2000s, it is interesting how many of the ideas and advice stay relevant up until today. The „Joel Test“ is very applicable even 15 years later. Allocating time for debugging and testing is a problem that still plagues the software world. Peace, quiet and best tools are something that a lot of companies promote but fail to deliver to their employees.
On the downside, there is stuff in this book that has been refuted over time. There are topics where Joel strikes me as heavily biased (Microsoft's past, present, and future come to mind). And there is his crude and in-your-face style of writing that I personally didn't mind, but is often noticeable and might spoil this interesting handbook on good practices in software dev.
Since most of the chapters here have a timestamp from the early 2000s, it is interesting how many of the ideas and advice stay relevant up until today. The „Joel Test“ is very applicable even 15 years later. Allocating time for debugging and testing is a problem that still plagues the software world. Peace, quiet and best tools are something that a lot of companies promote but fail to deliver to their employees.
On the downside, there is stuff in this book that has been refuted over time. There are topics where Joel strikes me as heavily biased (Microsoft's past, present, and future come to mind). And there is his crude and in-your-face style of writing that I personally didn't mind, but is often noticeable and might spoil this interesting handbook on good practices in software dev.
November 23, 2022
Brilliant read, Joel’s thoughts have somehow withstood the test of time in one of the fastest-changing fields.
May 24, 2015
A fair bit out of date at this point, but that's one thing that makes it interesting - he made predictions about technology that are coming true (or not) right around now ("We'll never use [cloud-based] document storage!"; ("When we all have 100mbps internet...").
In any case, a lot of it is not really out of date or style - the software project management aspects in particular. He also drinks the Microsoft kool-aid, so prepare to hear a lot about .NET and Excel.
I'm gonna go catch up on his blog.
In any case, a lot of it is not really out of date or style - the software project management aspects in particular. He also drinks the Microsoft kool-aid, so prepare to hear a lot about .NET and Excel.
I'm gonna go catch up on his blog.
January 16, 2022
A nice book with pills of knowledge on everything having to do with software development, with some humor sprinkled in to make the book more interesting and easy to read.
The book shows its age, but not in a way that makes it incomprehensible, and in fact its seeming outdatedness becomes another source of interest, just like the author's frequent stories about his experiences in Microsoft, which show a privileged insight into the development process of many of its most famous products.
The book shows its age, but not in a way that makes it incomprehensible, and in fact its seeming outdatedness becomes another source of interest, just like the author's frequent stories about his experiences in Microsoft, which show a privileged insight into the development process of many of its most famous products.
January 12, 2017
Its a great book. It reminds you how the software industry is cyclical. Joel is a great writer and makes you want to keep reading - even the chapters with blatant Microsoft worship.
A few chapters could take updating to 2016. Most of the advice is valid some of it is not. A few noteworthy chapters → the one on unicode, the one where he talks about specs and the one about deadlines.
A few chapters could take updating to 2016. Most of the advice is valid some of it is not. A few noteworthy chapters → the one on unicode, the one where he talks about specs and the one about deadlines.
May 21, 2016
Joel does not play well with mumbo-jumbo. Illustrative software development real stories told with a fine sense of humor. Joel seems to be a great developer and software manager, which is hard to find. Every developer and manager should read it.
June 28, 2021
Wish more people were like this in my IT dept!
February 26, 2018
More than a collection of software engineering thoughts, this book describes a collection of experiences from several years of working in software engineering companies, starting as intern at Microsoft Excel's team, to his own company Fog Creek.
Reading it in 2018, 14 years after it was first published, it's still valuable as it was back then, as most of the lessons still apply (some of them I can relate with my own experience as software engineering). There's a lot to learn from these lessons and Joel provides lots of interesting links and book references, making it a must read for young software engineers and a great read for others.
Some of the lessons I personally relate to are:
* his thoughts about using .net as new shiny technology around (in my case wasn't .net but other), how upgrade was being planned, and particularly, how he felt he was not able to write good code even though he had many years of software development under his belt.
* painless functional specs (the importance of having clear specs that other developers can use to implement their code and how that can save countless of hours - specially in endless code reviews, which are too late to make changes anyways)
* fixing bugs vs. delivering features/value.
Notes to self: it's noticeable that Joel has read many many books about software engineering (technical and non-technical). Evidence was his statement that he read all self-published books from MS employees. It would be interesting to learn his thoughts now about some of the topics he wrote (e.g. Microsoft strategy and how it stands, web applications and where are we heading now, how to cope with even bigger set o technologies/libraries/tools that are appearing everyday).
Reading it in 2018, 14 years after it was first published, it's still valuable as it was back then, as most of the lessons still apply (some of them I can relate with my own experience as software engineering). There's a lot to learn from these lessons and Joel provides lots of interesting links and book references, making it a must read for young software engineers and a great read for others.
Some of the lessons I personally relate to are:
* his thoughts about using .net as new shiny technology around (in my case wasn't .net but other), how upgrade was being planned, and particularly, how he felt he was not able to write good code even though he had many years of software development under his belt.
* painless functional specs (the importance of having clear specs that other developers can use to implement their code and how that can save countless of hours - specially in endless code reviews, which are too late to make changes anyways)
* fixing bugs vs. delivering features/value.
Notes to self: it's noticeable that Joel has read many many books about software engineering (technical and non-technical). Evidence was his statement that he read all self-published books from MS employees. It would be interesting to learn his thoughts now about some of the topics he wrote (e.g. Microsoft strategy and how it stands, web applications and where are we heading now, how to cope with even bigger set o technologies/libraries/tools that are appearing everyday).
August 25, 2017
Great book, a bit dated now but interesting to see how some of his ideas went with regards to Microsoft's business directions.
Totally love his style and he's obviously a smart cookie who knows his stuff both as a programmer and a project manager. His wit is very engaging and turns even the driest discussions about API's into something of a comedy.
Spolsky talks from first hand experience, he's no theoretician which ironically allows him room to theorize quite accurately given the retrospective view this book now gives on the whole software industry.
One of the best parts about this book is that it makes one, as a developer, feel that what project managers are constantly telling you (It's late, you're slow, your estimates are unrealistically large) is somewhat of a universal pain felt by even the best of us. i.e. Joel.
Despite his plethora of knowledge, wisdom on the subjects he speaks about and intellect, he always comes across as humble and one who perhaps learnt the hard way, like us.
It's no longer 2003, but Joel on Software is still as relevant as it was back then.
Encouraging and realistic at the same time. A friend to read.
Totally love his style and he's obviously a smart cookie who knows his stuff both as a programmer and a project manager. His wit is very engaging and turns even the driest discussions about API's into something of a comedy.
Spolsky talks from first hand experience, he's no theoretician which ironically allows him room to theorize quite accurately given the retrospective view this book now gives on the whole software industry.
One of the best parts about this book is that it makes one, as a developer, feel that what project managers are constantly telling you (It's late, you're slow, your estimates are unrealistically large) is somewhat of a universal pain felt by even the best of us. i.e. Joel.
Despite his plethora of knowledge, wisdom on the subjects he speaks about and intellect, he always comes across as humble and one who perhaps learnt the hard way, like us.
It's no longer 2003, but Joel on Software is still as relevant as it was back then.
Encouraging and realistic at the same time. A friend to read.
March 17, 2023
I read “Joel on Software” because I’ve heard it’s a “classic” and I was hoping to get more great stuff like “The Absolute Minimum Every Software Developer … Must Know About Unicode and Character Sets.” Some of Joel’s old blog posts included in this book delivered on my hopes. Others came across as rants from a good friend.
In some ways this book has aged well, but I’d be nervous having a new software developer reading this and thinking it’s some sort of software development bible. It’s not.
There were some ironically funny rants about Internet Explorer following standards while Netscape/Mozilla on the other hand were a mess. It’s interesting to look back on these blog posts now that the browser wars have pit Internet Explorer in the grave.
If you want a reminder of how things were 20+ years ago, this book is an interesting piece of history.
In some ways this book has aged well, but I’d be nervous having a new software developer reading this and thinking it’s some sort of software development bible. It’s not.
There were some ironically funny rants about Internet Explorer following standards while Netscape/Mozilla on the other hand were a mess. It’s interesting to look back on these blog posts now that the browser wars have pit Internet Explorer in the grave.
If you want a reminder of how things were 20+ years ago, this book is an interesting piece of history.
April 13, 2020
Rewind to the turn of the millennium, when Windows programming ruled the world, the dotcoms were doomed, and managing large software projects still suffered from the same problems as they did back at IBM during the Mythical Man-Month era (as they still do now). Hyperbolic and hilarious, Joel tears apart the tropes and renders his own creed for programming, managing, and successfully making things with other people on computers. The hint of web programming at the end of the book is a prescient glimmer of today’s software landscape, and yet mobile is never discussed - fascinating to consider what might already be in our hands but not yet in our focus.
May 9, 2019
Читать книги 10-15 летней давности, которые считаются классикой, вроде бы любопытно, но в то же время несколько предвзятость накатывает, о том, что стоит ли.
Книга очень бодро повествует о мире разработки, составлении планов, ведении бэклогов, выявлении фич, которые брать в работу.
Все достаточно не техничным языком написано, не зря статьи из личного блога в книге сведены и переработаны.
Не смотря на несколько унылые вставки про восхваление си-шечки можно прочитать за выходные, когда уже не хочется читать что-то серьезное.
Можно считать полезным, для перетряхивания своего собственного опыта.
Книга очень бодро повествует о мире разработки, составлении планов, ведении бэклогов, выявлении фич, которые брать в работу.
Все достаточно не техничным языком написано, не зря статьи из личного блога в книге сведены и переработаны.
Не смотря на несколько унылые вставки про восхваление си-шечки можно прочитать за выходные, когда уже не хочется читать что-то серьезное.
Можно считать полезным, для перетряхивания своего собственного опыта.
January 7, 2021
This was probably a very good book when it was first released but, with the benefit of being almost a decade in the future, you can see that the predictions made in the book were basically a toss-up: every other one turned out to be plain wrong. It's a good example of why we should take predictions with a grain of salt.
It's interesting to read about some of the issues at the time and some of the arguments joel made back then still make a lot of sense today, but overall it's become a historical artifact.
It's interesting to read about some of the issues at the time and some of the arguments joel made back then still make a lot of sense today, but overall it's become a historical artifact.
March 2, 2022
Practical wisdom on managing talented people.
Skip straight to the Joel Test near the start. Read that first. 90% of the value.
The second third operationalizes part 1.
The last third of the book discussed strategy and opinion pieces which wasn't interesting other than his injunction to study microeconomics.
The 12 guidelines are pretty helpful and translate to any practical area where conscientiousness is vital.
It's only a book on software devs, but with little effort translates to other professional and creative areas.
Skip straight to the Joel Test near the start. Read that first. 90% of the value.
The second third operationalizes part 1.
The last third of the book discussed strategy and opinion pieces which wasn't interesting other than his injunction to study microeconomics.
The 12 guidelines are pretty helpful and translate to any practical area where conscientiousness is vital.
It's only a book on software devs, but with little effort translates to other professional and creative areas.
March 11, 2023
I've always loved Joel's writing and wanted to revisit this book to see how things have held up over the years. It turns out it's still pretty good! It's hard to recommend to younger developers because they won't understand the context for a lot of his arguments, but maybe 2/3 makes excellent points that are still relevant today. Even the chapters that aged less well (e.g., chapters about web vs desktop applications, the parts about .NET) are interesting because it's worth thinking about why the chapters aged poorly.
April 9, 2021
Отличная книга для разработчиков софта! Интересно и полезно было познакомиться с мыслями опытного программиста и предпринимателя. Впечатление только немного подпортили некоторые примечания так называемого «научного редактора», больше напоминающие довольно субъективную критику на форумах, совершенно неуместную в книге.
Displaying 1 - 30 of 148 reviews