Joel Spolsky

Quotes are word for word from the source.

• Eating your own dogfood

  “My company's product CityDesk is in beta, and I'm a strong believer in eating your own dogfood . So starting today this site will be produced using CityDesk, and thus the new look.”

  Our noteJoel explains why he is switching his blog's backend to his own company's new software.

• Small company constraints

  “As a tiny company, Fog Creek Software can't afford a sales team, or even a sales person, or in fact, a sales cat .”

  Our noteJoel explains why Fog Creek Software doesn't have a traditional sales department.

• Referral incentive program

  “If you know someone who can use the services of Fog Creek Software, and they hire us, I'll pay you 5% of the revenue we get from the project”

  Our noteJoel proposes a referral fee to replace a full-time sales staff.

• Talent versus certification

  “Would 18-year-old Shawn Fanning , who wrote Napster and changed the world, have been certified?”

  Our noteJoel questions whether formal certification would have recognized or allowed a young, world-changing innovator.

• Hidden dependencies

  “When you look closely at Enigma, you still need Internet Explorer, you're still using Internet Explorer, but you don't get any of the features.”

  Our noteJoel points out that the product lacks features despite using the same underlying engine.

• Understanding complex options

  “Bond C is a little more complicated so let me explain. On the tenth anniversary, the government gets to decide whether to pay you your $100K back and owe you nothing, or keep your $100K for another twenty years”

  Our noteJoel explains the mechanics of a callable bond where the issuer holds the decision power.

• Frustrating documentation

  “For the last 4 years I've been furious every time I try to find something in MSDN , and the bloody WinCE documentation kept getting in the way.”

  Our noteJoel expresses his frustration with irrelevant search results in technical documentation.

• First class database support

  “It's about time that a language designer admitted that RDBMS access is intrinsic to modern application implementation and supported it in a first-class way syntactically.”

  Our noteJoel argues that programming languages should have built-in support for database operations.

• UI and discovery

  “The UI is much better than anything Napster/KaZaa/Gnutella had, it's especially easy to find new things to listen to because everything is nicely cross-indexed and reviewed.”

  Our noteJoel explains why he prefers the Rhapsody music service over illegal file-sharing alternatives.

• Reasonable payment models

  “Finally, the recording industry (under extreme duress) has given us a reasonable way to pay for digital music.”

  Our noteJoel comments on the shift from piracy to legal subscription-based music services.

• Testing product features

  “CityDesk has pretty extensive multilingual support that was designed to make it easy to support a site in multiple languages, but I've never been able to try it out until today.”

  Our noteJoel discusses testing his own software's multilingual capabilities using his blog translations.

• Bug tracking importance

  “Keeping a database of bugs is one of the hallmarks of a good software team. I never cease to be amazed at how few teams are actually doing this.”

  Our noteJoel emphasizes that professional software development requires a formal system for tracking bugs.

• The scheduling paradox

  “Most people's intuition is to come up with conservative, padded estimates for each task, but they still find that their schedules always slip.”

  Our noteJoel explains why traditional project scheduling often fails despite adding extra time buffers to tasks.

• Efficient debugging mindset

  “Good programmers usually overcome this problem. It's a critical skill in debugging - we don't want to waste time investigating areas that could not possibly cause the bug.”

  Our noteJoel explains how great programmers handle uncertainty to solve problems faster.

• Solving nagging problems

  “This is a great implementation of a simple idea that brilliantly solves the nagging problem that it's just not easy enough to transfer large files down the hall, let alone halfway around the world”

  Our noteJoel explains why a simple file-sharing tool is effective for users.

• Fresh eyes find bugs

  “We've been banging on this dang thing for months. We fixed 329 bugs. Then Brad W. downloads it, plays for ten seconds, and finds another.”

  Our noteJoel describes how internal testing often misses bugs that new users find instantly.

• User Interface Design

  “Chapter Three of my UI series is now online, in which I beg, nay, plead with you to think hard before asking users to make a choice.”

  Our noteJoel introduces a new chapter in his series about user interface design principles.

• Prioritizing customer happiness

  “The current system, in which we expect FogBUGZ users to have enlightened development processes, makes us miss out on initial sales but it makes our existing customers happier.”

  Our noteHe explains why they sacrifice some sales to maintain a better product experience.

• Technical Leadership Importance

  “technical companies run by non-technical CEOs are a disaster waiting to happen; and he just GETS IT.”

  Our noteJoel discusses Charles Ferguson's view on why technical companies need technical leadership to succeed.

• Content and expertise

  “You're reading Joel on Software , stuffed with years and years of completely raving mad articles about software development, managing software teams, designing user interfaces, running successful software companies, and rubber duckies.”

  Our noteJoel describes the wide range of topics covered in his long-running software business blog.

• Value based pricing

  “The price of software has very little to do with cost, and everything to do with perceived value”

  Our noteJoel explains why software pricing should not be based on development costs.

• Evaluating software teams

  “So I've come up with my own, highly irresponsible, sloppy test to rate the quality of a software team. The great part about it is that it takes about 3 minutes.”

  Our noteJoel introduces his simplified method for assessing the quality of software development teams.

• Dangers of local optimization

  “Problem two: people may optimize locally to improve that one measurement, even at the cost of hurting the performance of the company as a whole.”

  Our noteHe explains why rewarding specific metrics can backfire on a company's overall goals.

• Top talent availability

  “The top 0.5% usually have jobs. They have jobs where they do very well, so their employers pay them lots of money and do whatever it takes to keep them happy.”

  Our noteJoel explains why the best developers are rarely looking for work on the open market.

• Value of talent

  “When software companies say that "their capital assets go home every night," they are serious. Dead serious.”

  Our noteJoel emphasizes that the real value of a software company lies in its people.

• Questioning tech hype

  “Clay has hit the nail right on the head; everybody's looking for the huge business opportunities around 802.11 and VoIP and they probably aren't really there.”

  Our noteJoel comments on the tendency of companies to chase hyped technologies that lack real business value.

• Limitations of web UI

  “The user suffers because the UI is abysmal and the programmer suffers because you can't MAKE a good UI no matter how hard you try.”

  Our noteJoel explains why the browser-based architecture of the time limited user experience.

• Commoditizing complements

  “Remember when I wrote that "smart companies try to commoditize their products' complements?" We decided to take some of our own advice, here”

  Our noteJoel discusses the strategic decision to support free database options for his software.

• Building Internal Tools

  “The product we're building is something we need internally anyway, so it's almost worth the expense even if nobody buys it, but we think it should be useful to a lot of other people, too”

  Our noteJoel discusses the low-risk strategy of building a product the company already needs.