Julio Santos

1) Make sure you’re all upgraded (10.5.x) before moving to snow leopard. If you aren’t, the installer will have you do it, so it’s all good.

2) Log out all but one user. If you don’t things will still work, but the installer won’t continue until you do, so do that too to save a few minutes.

3) It takes about an hour

iMac: everything worked fine after the upgrade: Time Machine, Adium, iTunes, Firefox. These being the main apps I tried.

MacbookPro #1: Time Machine worked, so did mounting net disks, iTunes and Safari. Spirited Away needed Rosetta. The OS was smart enough to let me know about Rosetta and install it on its own. Worked fine. Wireless and hard wired connections worked. World of Warcraft works, though my toons are still lame. Couldn’t get Exchange to work, and it’s back to Entourage. Oh well. VPN through Juniper Network Connect didn’t work and I had to do this for it to:

sudo chmod 755 /usr/local/juniper/nc/{version}/
sudo mkdir ‘/Applications/Network Connect.app/Contents/Frameworks’

iStat menus are gone, but the desktop widget still works.

Still have two macbook pros to upgrade, but it’s looking good so far.

Skorks says his 3 pillars are money, people and type of work.

Rod Hilton says it’s people, project and the company.

I say it’s the people, the technology and the appreciation you get.

People: If the people you work with are nice, or your friends, or rich & famous, or funny, or easy to work with. Basically if I don’t hate to be with them, I can check that box.

Technology: Challenging, relevant, interesting, in high demand, brain teaser. That does it.

Appreciation: $$$, your users, your coworkers, your boss, the industry. Any of these is good.

3 out of 3: you run red lights to get to work in the morning
2 out of 3: you run yellow lights
1 out of 3: you slow down at the green light
0 out of 3: been there, no fun, but it gets better.

A couple of weeks ago I asked on twitter/facebook for examples of awesome companies(*) built with TDD, and never got a satisfying answer.

As a TDD advocate and practitioner, I want those companies to exist. TDD (or at least “an insane amount of tests”) has been working for me for almost a whole decade, and it would be disappointing if the technique only works for average companies or products (I still haven’t built a product worthy of awe).

I was told that there’s no correlation between TDD and product awesomeness. In that case if, say, 1% of all teams in the world practice TDD (or lotsa tests), then for every 100 awesome companies, I should be able to find one that was built thanks to TDD.

I can’t think of any (perhaps Rails by 37 signals?). If you know of one, or even better, work or worked there, I would like to hear about it.

(*) I want to be very clear about the fact that I already know that TDD works great for building good enough products. I don’t need to see examples like how Division 37 of BigCorp has 82.3% code coverage which allowed them to ship in 3 months instead of 6. I do mean awesome companies or products. For example: gmail, google 1.0, netflix, amazon, firefox, mac os, blizzard, facebook.

I’m also less interested in TDD used to maintain products, great or not. So for example, if World of Warcraft 1.0 was built with TDD I want to know about it. If a team of developers added test coverage after wow 1.0 was out, so fixing bugs would be easier, it would be nice to hear, but it’s not what I’m looking for.

My hypothesis is that TDD is great for making average products better. But for building truly exceptional products, you need truly exceptional individuals, and those individuals tend to be slowed down by TDD. Therefore truly exceptional products are not built with TDD. QED (unless proven otherwise :p)

Of course bad or below average programmers also would never user TDD, and that’s where the similarity ends.

A few weeks ago a co-worker of mine came across this PG’s essay and sent it to the rest of the company.

It sparked a conversation which was great. I was surprised that “the other side” didn’t already know this stuff. Especially useful because everyone seems to “get it now”. Sometimes all it takes is to share information.

Anyway, another co-worker just asked:

- putting together a model airplane falls in the “maker” category, right?
- how do you makers eat since you can’t take breaks.

I responded, and here’s, for the most part, what I said:

> There are other examples/ analogies outside programming – any manufacturing
> process has the same issues – whether you are making high tensile steel or
> putting a model airplane there are the same issues.

You’re absolutely right. PG was careful enough to say maker instead of
programmer for that reason. However, and though it’s true this is not unique
to programmers, I don’t think Paul Graham meant “maker” to be as generic as
to include manual labor, or any other activity you can do while watching TV
and having a conversation with your neighbors. I imagine that’s how one puts
together airplane models :)

The mental concentration necessary to make a program, or to calculate pi in
your head, or to integrate a complex mathematical expression, is not
comparable to the mental concentration necessary to put together a model
airplane, or to make a table out of wood, or, and that’s his point, to be in
a meeting.

Especially in a meeting with more than 2 people in it, it’s common to see
people doing something else. Perhaps chatting with their friends, or
“catching up on email”, or whatever it is that people choose to do during
meetings.

To a naïve observer such as me, that indicates that the act of meeting
though important in so many ways, requires less mental concentration than
what a maker would need.

Programming, unlike other mental activities such as trying to memorize the
first 50 decimals of pi, are even more to PG’s point, because they not only
require periods of intense mental concentration, but these periods tend to
be longer than just 15 minutes.

It’s an accepted fact that it takes 15 to 20 minutes just to get back to a
decent concentration level. Which btw means that when you (you here is the
general you) interrupt a maker “with a quick question”, it will take the
maker 15 to 20 minutes to start being productive again.

> One question springs to mind – eating – always thinking about food – how
> does a maker eat if they can’t take a break?

Important question as well.

Of course makers *can* take breaks. PG’s point was not that makers can’t
take their eyes off the monitor.

Eating works (vs having meetings) because eating, or going to the bathroom,
doesn’t require mental context switch. I can be eating and still be thinking
about the problem I was trying to solve. Same for going to the bathroom. I
can go for a walk around the block, and though it might look like I’m just
goofing off, I’m actually working.

Another reason why these types of break work, is that they’re not time
bound. Unlike a meeting which happens to be scheduled for say 3:00,
eating/peeing is more flexible.

If my lunch alarm goes off (yes, I have one) and I’m in the middle of
something, I know I don’t have to drop everything and go eat right now! I
can start winding things down, take notes so I remember where I was when I
come back, or even skip lunch all together if I really need to.

Compare that to having a meeting at 3 o’clock, where you’re supposed to be
there and perhaps even participate (when you’re not also “catching up on
email”). In that case I cannot just show up 20 minutes late “because I was
in the middle of something”. Or god forbid, not show up at all, which is
actually better, than to show up and only pretend to be there, but that’s
for another day.

If you add all these notions together:

Meetings start at fixed time + takes 15 to 20 minutes to start being
productive + programming requires long periods of sustained concentration,
and you can see how having 2 hours of non-meeting time is as good as having
no time at all.