The goal of your software company is not to solve some specific problem, but to be able to convert money to code through programmers. -- Converting Capital Into Software That Works.
Interviewing. It is much, much better to reject a good candidate than to accept a bad candidate. You’re looking for people who are smart, and get things done. -- Guerilla guide to interviewing.
Every decision should made by the person with the most information, which is probably the team working on the software, not the manager. -- Command and Conquer and the Herd of Coconuts.
Companies need to keep their employees loyal by treating them well, not by enforcing blind loyalty though a contract. -- NDAs and Contracts That You Should Never Sign.
Realistic schedules are possible and are the key to creating good software. -- Evidence Based Scheduling.
Performance reviews and incentives simply can't work in the workplace. It's insulting and demeaning and lowers morale. -- Incentive Pay Considered Harmful
Don't rewrite an application from scratch. There is absolutely no reason to believe that you are going to do a better job than you did the first time. -- Things You Should Never Do, Part I.
UI design for programmers
A user interface is well-designed when the program behaves exactly how the user thought it would. Pick the simplest possible model. -- Controlling Your Environment Makes You Happy and Figuring Out What They Expected.
Design is the art of making choices. Don't give the user options that are not relevant to the task he wants to perform.-- Choices.
Well-designed objects make it clear how they work just by looking at them. -- Affordances and Metaphors.
Consistency is a fundamental principle of good UI design. Emulate popular programs as closely as possible. It may not show off much creativity, but in the long run it makes users happier. -- Consistency and Other Hobgoblins
Design your software so that it does not need a manual. Minimize text in the UI. -- Designing for People Who Have Better Things To Do With Their Lives.
Design your program so that it does not require a tremendous amount of mouse-agility to use it right. Prevent the need for pixeltinkering -- Designing for People Who Have Better Things To Do With Their Lives, Part Two
You shouldn't ask people to remember things that the computer could remember. And: show respect towards your users. -- Designing for People Who Have Better Things To Do With Their Lives, Part Three
Find out which features support the most important user activities. The Process of Designing a Product.
Give knowledge workers space, quiet, and privacy to maximize productivity. -- Where do These People Get Their (Unoriginal) Ideas? See also: Bionic Office.
You need 1 tester for every 2 programmers. -- Top Five (Wrong) Reasons You Don't Have Testers
If you start a company, pick one of: 1) Amazon model (invest a lot and get big fast) or 2) Ben and Jerry's model (grow slow but steady and durable). -- Strategy Letter I: Ben and Jerry's vs. Amazon
Any business plan that calls for making a computer that doesn't run Excel is just not going anywhere. -- Strategy Letter II: Chicken and Egg Problems
Google obviously did not read this article before introducing Google Wave.
Joel provides other example of the chicken and egg problem in Wasting Money on Cats
Eliminating barriers to switching (both ways) is the most important thing you have to do if you want to take over an existing market. -- Strategy Letter III: Let Me Go Back!
To get programmers to work for you: make the workplace attractive, eliminate obstacles, and provide benefits which are more valuable than the money they cost. --Whaddaya Mean, You Can't Find Programmers?
"The Joel test" is introduced as a rogue alternative for testing your company's coding quality with twelve simple yes/no questions. In practice the Joel test seems to do quite well. -- The Joel Test: 12 Steps to Better Code
Writing specs
When you design your product in a programming language instead of human language, it takes weeks to do iterative designs instead of minutes. A spec saves time communicating. With a spec, it is possible to make a schedule. Writing a spec is a great way to nail down all those irritating design decisions, large and small, that get covered up if you don't have a spec. -- Painless Functional Specifications - Part 1: Why Bother?
Specs have a disclaimer, one author, scenarios, nongoals, an overview and a lot of details. It's ok to have open issues. Text for particular audiences go into side notes. Specs need to stay alive. -- Painless Functional Specifications - Part 2: What's a Spec?
You need a dedicated "program manager" to write the specs. The Program Manager is both technically and socially gifted: he has to get along with all people involved, like customers, sales and the developers. -- Painless Functional Specifications - Part 3: But... How?
If you want readers for the specs you wrote, follow these rules. 1. Be funny. 2. Write understandable. 3. Write as simple as possible (be "unprofessional"). 4. Review. 5. Don't use a template. -- Painless Functional Specifications - Part 4: Tips
The only time a company would want to change its name, from something people recognize to something completely new, would be if it had such low brand equity that the old name was a liability. -- Blog post on 2000/11/12
Use a bug tracking system. Every good bug report needs exactly three things. 1. Steps to reproduce, 2. What you expected to see, and 3. What you saw instead. -- Painless Bug Tracking
A good architect only uses tools that can either be trusted, or that can be fixed. -- Up the tata without a tutu.
11 comments:
Nice summary!
thanks very much, this is really good
Not sure how literal you meant by "one sentance", but some are 2
Great goal! Joel usually has some awesome insights.
@Anonymous:
you're right. It sometimes gets seriously out of hand.
Very Cool. Thanks.
Great work compiling these. Perhaps you could collaborate with Joel to publish them as a book of software aphorisms.
This doesn't sound very smart when compiled to the bare essence :)
for those who care (= probably no one): anonymous flame posts are deleted.
@Anonymous (2):
remember these posts were written TEN years ago.
Post a Comment