Tag Archives: joel-spolsky

Summarising Joel on Software

Now that Joel Spolsky has ‘retired’ from blogging at Joel on Software (in the format the site has been known for, at least), Jan Willem Boer is reading the entire back-catalogue of entries and condensing the knowledge within each essay into a single sentence (or two).

The result is a stunning list of tips on running a small business, programming best practices, productivity tips, technical hiring practices and entrepreneurship.

The series:

When (and When Not) to Consider Venture Capital

On discussing why he and his co-founders are seeking venture capital funding for their programming question and answer site (StackOverflow), Joel Spolsky provides a number of scenarios for when a company should give consideration to VC funding:

  1. There’s a land grab going on.
  2. There is a provable concept that’s repeatable.
  3. The business could benefit from the publicity of getting an investment from someone who is thought of as being a savvy investor.
  4. The investor will add substantial value to the business in advice, connections, and introductions.
  5. The business can potentially have a big exit or become a large, publically traded company.
  6. The founders are happy to give up some control to make the business more successful.

And when a company should not consider it:

  1. The founders are risk-averse and are willing to trade a much smaller payout for lower risk.
  2. The founders are technical without substantial business experience and wish to maintain absolute control forever.
  3. If the investor is mostly “dumb money.”
  4. If you’re going into an established field with a lot of competition.
  5. If the product is immature and unproven.
  6. If the founders don’t have enough of the right kinds of industry connections, or the idea is not compelling enough, so that raising VC would take months or years
  7. If there is any other way to raise the kind of money you need.

A number of pieces have been written disagreeing with Spolsky’s article, suggesting that either StackOverflow does not fit these criteria or that the reasoning is just plain wrong. 37signals’ post covers both.

The Five Whys

Five Whys is “a question-asking method used to explore the cause/effect relationships underlying a particular problem. Ultimately, the goal of applying the 5 Whys method is to determine a root cause of a defect or problem”. Developed by Taiichi Ohno–one of the inventors of the Toyota Production System–the oft-cited example is as follows:

  • My car will not start. (the problem)
  1. Why? – The battery is dead. (first why)
  2. Why? – The alternator is not functioning. (second why)
  3. Why? – The alternator belt has broken. (third why)
  4. Why? – The alternator belt was well beyond its useful service life and has never been replaced. (fourth why)
  5. Why? – I have not been maintaining my car according to the recommended service schedule. (fifth why, root cause)

I was introduced to Five Whys in a post by Joel Spolsky back in early 2008 detailing their post-mortem examination following a system outage (which also looks at the problems with SLAs).

Entrepreneur Eric Ries recently wrote a comprehensive post detailing how to conduct a Five Whys root cause analysis which I suppose acts as an update to this previous post of his where he introduces his readers to the Five Whys concept and adds this important caveat:

The next step is this: you have to commit to make a proportional investment in corrective action at every level of the analysis.

Five Whys is a concept I’ve attempted to–somewhat successfully–apply to myself and my development. When I make mistakes or when I don’t understand something I ask why until I find the root cause of my error, the misunderstanding, or the negative reaction. Similarly, GigaOM’s Mike Speiser recommends Five Ways as one of the four techniques you should embrace in order to become at ease with ideas that make you uncomfortable.

You may find that your reaction is more about protecting existing orthodoxy or the source of the idea than it is about the merits of the particular approach at hand.

And of course, to end in a joke, you don’t want to ask why too many times (via Kottke).

Microsoft, Google and Startups Compared

After visiting both the Microsoft and Google campuses to discuss Stack Overflow (Google Tech Talk: Learning from StackOverflow.com), Joel Spolsky discusses the similarities and differences between the two corporations and his own small company.

What I’ll probably remember most about the trip is what I learned about company culture and how it’s affected by scale. Giant corporations such as Google and Microsoft are like cities full of relatively anonymous people: You don’t actually expect to see anyone you know as you walk around. Going to lunch on either campus is like going to the cafeteria at a huge university. The other 2,000 students seem nice, but you don’t know most of them well enough to sit with them. Meanwhile, a typical lunchtime at my company is like Thanksgiving dinner: There’s a big meal you get to share with a bunch of people you know and like.

I particularly liked Spolsky’s reaction to his discovery that while Microsoft’s campus-wide Wi-Fi network is closed-access and requires registration, Google’s was free and open: “I had to wonder: What might we be doing at our company that is similarly a waste of time?”.

It made me think: What might I be doing that is similarly a waste of time?

Procrastination as Newton’s First Law

There’s a lot I identify with in this article of Joel Spolsky’s where he talks of using the Fire and Motion strategy to cope with workplace procrastination.

There have been times in my career as a developer when I went for weeks at a time without being able to get anything done. As they say, I’m not in flow. I’m not in the zone. I’m not anywhere. […]

Once you get into flow it’s not too hard to keep going. Many of my days go like this: (1) get into work (2) check email, read the web, etc. (3) decide that I might as well have lunch before getting to work (4) get back from lunch (5) check email, read the web, etc. (6) finally decide that I’ve got to get started (7) check email, read the web, etc. (8) decide again that I really have to get started (9) launch the damn editor and (10) write code nonstop until I don’t realize that it’s already 7:30 pm.

Somewhere between step 8 and step 9 there seems to be a bug, because I can’t always make it across that chasm. For me, just getting started is the only hard thing. An object at rest tends to remain at rest. There’s something incredible heavy in my brain that is extremely hard to get up to speed, but once it’s rolling at full speed, it takes no effort to keep it going. […]

Maybe this is the key to productivity: just getting started. Maybe when pair programming works it works because when you schedule a pair programming session with your buddy, you force each other to get started.

I feel that the text in bold is key.

via Less Wrong