Today I met with lots of interesting people again. Personalities from the
Chandler project, O'Reilly, Linux Journal, Ximian, the Perl community, the
Parrot project and various other industries and companies. I hope to spend
some more time with them tomorrow.
I attended two sessions today: the Python lightning talks, and Dan
Sugalski's "parrot in the real world" talk. He's really doing some
interesting legacy-system support with it: something that open source folks
frequently don't address very well.
I find myself in the enviable position of people I respect knowing of my
personal achievements, my company, and my father. While less useful
technically than PyCon, this conference has been a lot of fun so far.
I'm looking forward to the last day. I have some pictures, which I hope to
post tomorrow.
I saw Tim O'Reilly's keynote speech. He mentioned a bunch of things that were similar to Divmod's goals: smart address book, data portability, etc.
I saw r0ml's keynote speech. It was brilliant.
That was the last of the sessions I attended though, the rest of the day was all talking to people.
I met with Jeff Waugh of No Name Yet, and discussed some opportunities for collaboration between his company and mine. No concrete plans yet, but we're clearly companies with aligned philosophies, and not really any product overlap, so I think it's likely we'll do something. He also introduced me to Havoc Pennington of Red Hat.
I embarrassed myself by introducing myself to Yosh and a few other Gimp folks, thinking he was someone else, and casually mentioning that I'd been banned from #gimp a few times (by Yosh). All was well, though, and I got to pitch Divmod a little bit.
IronPython was released today. I missed the announcement but did get to thank Jim Hugunin, which appeared to frighten him.
Finally I met with as planned, and I had a hamburger. Then we added ezmlm mailing list filtering to Quotient (I believe). That's service for you: if Divmod doesn't do what you need, a developer will come to your home town and sit down with you and write it right there. :-)
Now I am getting ready to go to sleep. See you tomorrow.
I saw r0ml's keynote speech. It was brilliant.
That was the last of the sessions I attended though, the rest of the day was all talking to people.
I met with Jeff Waugh of No Name Yet, and discussed some opportunities for collaboration between his company and mine. No concrete plans yet, but we're clearly companies with aligned philosophies, and not really any product overlap, so I think it's likely we'll do something. He also introduced me to Havoc Pennington of Red Hat.
I embarrassed myself by introducing myself to Yosh and a few other Gimp folks, thinking he was someone else, and casually mentioning that I'd been banned from #gimp a few times (by Yosh). All was well, though, and I got to pitch Divmod a little bit.
IronPython was released today. I missed the announcement but did get to thank Jim Hugunin, which appeared to frighten him.
Finally I met with
Now I am getting ready to go to sleep. See you tomorrow.
As soon as I got to New York, my sister's laptop immediately died. Why is it
that wherever I go, problems follow me?
Has anyone ever had /etc spontaneously disappear, on a mac? /private/etc stayed in-tact, but /etc disappeared. It seems something else has gone wrong too, since at the phase of boot where you're supposed to see a big grey apple, instead we see a big grey universal "No" sign. (Circle with a slash through it.)
reflect, repent, reinstall
Has anyone ever had /etc spontaneously disappear, on a mac? /private/etc stayed in-tact, but /etc disappeared. It seems something else has gone wrong too, since at the phase of boot where you're supposed to see a big grey apple, instead we see a big grey universal "No" sign. (Circle with a slash through it.)
reflect, repent, reinstall
By the way, I'm going to be at the O'Reilly Open Source Convention 2004 in Portland next week. I'm arriving Tuesday evening.
If anyone in the area (and you know who you are, for example you are) would like to meet while I'm at the con, please add comments to this entry. I believe that the exhibit hall registration is free, so you can come down and have a look at some potentially amusing advertising while you're at it.
I would also appreciate it if you would post comments about groups that I should seek out and attempt to talk to for some reason for integration with the Twisted, Atop, Nevow, Quotient, etc, etc, etc. Double points if you're actually from that project, and triple points if you're the one who will meet me at the conference yourself. If you know someone interesting I should talk to, please refer them to this entry and encourage them to comment.
Advice about what to look for at the conference is also appreciated. I have no idea what I want to do when I get there other than watch the madman who built me rant and rave and look for interesting people to talk to.
Seriously though, I would offer that last as advice for you, the reader: I highly recommend going to the aforementioned madman's keynote. He's an impressive speaker with a stellar list of references and a lot of interesting things to say. He has an uncanny knack for looking at an issue in a completely alien and enlightening way. If you enjoyed seeing me speak at PyCon or the paper I co-wrote for USENIX, imagine somebody similar who's had 20 years more practice.
So with that, comment away! I hope to see you all soon.
If anyone in the area (and you know who you are, for example you are
I would also appreciate it if you would post comments about groups that I should seek out and attempt to talk to for some reason for integration with the Twisted, Atop, Nevow, Quotient, etc, etc, etc. Double points if you're actually from that project, and triple points if you're the one who will meet me at the conference yourself. If you know someone interesting I should talk to, please refer them to this entry and encourage them to comment.
Advice about what to look for at the conference is also appreciated. I have no idea what I want to do when I get there other than watch the madman who built me rant and rave and look for interesting people to talk to.
Seriously though, I would offer that last as advice for you, the reader: I highly recommend going to the aforementioned madman's keynote. He's an impressive speaker with a stellar list of references and a lot of interesting things to say. He has an uncanny knack for looking at an issue in a completely alien and enlightening way. If you enjoyed seeing me speak at PyCon or the paper I co-wrote for USENIX, imagine somebody similar who's had 20 years more practice.
So with that, comment away! I hope to see you all soon.
Overtime makes programmers less productive.
You have to be in the right mood, called "flow" by many, to be a good programmer. Different hackers can get into and out of this state more or less easily, and it is a large part of what determines their quality. When this blog was just a simple paper journal and not a multi-billion dollar media empire *, I spilled huge bottles of ink on wondering what the magic formula for instantly dropping into flow was. I've talked about it a lot with my friends in the years since then.
As the Tao and most physics teaches us, though, any powerful force has an equally powerful opposite. So it is with Flow, and I have experienced it: the Anti-Flow.
There's a lot of hacker mythology about working late into the night, eyes glazed over, blissfully hacking away on some deep problem, unaware of the outside world. It is generally acknowledged that this is a state of Being At One With The Machine. I believe that this is a false enlightenment. After this last round of crunch time, I have realized its true nature. After a certain number of hours of working, you think you're in flow. It seems as though everything is going well. What's really happening is that your mind is playing tricks on you: you're tired, you're making mistakes, but you're just not seeing them.
I think this is why the first programming methodology to get really bothered about programmer-written tests was also the first one to start complaining loudly that we should stick to a forty hour week. When you're just writing and writing and writing code, it doesn't occur to you that you're producing garbage, or if not garbage, at least substantially lower-quality code than usual. You hit your testing phase later, and you fix your bugs, and you shrug and think "that's software for you". It seems like you're productive on both ends, since you're producing lots of code when you're tired and you're fixing lots of bugs when you're awake.
But when you're sitting there bleary-eyed and trying to get your tenth test to pass and it just won't pass no matter what you do, you know it's time to quit. You have a real-time feedback loop that's telling you "go home". After a while, you put two and two together and realize that you're not really understanding the machine as much as you thought you were.
Of course, if you're not as rigorous as you should be, you just stop writing tests.
This week I watched a programmer who is normally incredibly fastidious about testing give up on his tests, work tons of overtime, jang it, and endure the consequent failure. I have done this myself many times when working overtime. I am much less likely to test code when I'm burning myself out than when I'm relaxed. It seems like the tests are just so much less likely to pass anyway, so why bother?
The moral of the story is that crunch time really doesn't work in the small any better than it does in the large. If a deadline looms in the near future and it looks like we're going to need overtime to make it, I am going to have to admit to myself and to my team earlier on that the deadline has already been blown.
I wonder how many more times I'll need to learn this lesson before it sticks.
*:
International guests: a gratuity of 15-20% is appreciated if you enjoyed the service, and may be included with the check for parties larger than 10.
You have to be in the right mood, called "flow" by many, to be a good programmer. Different hackers can get into and out of this state more or less easily, and it is a large part of what determines their quality. When this blog was just a simple paper journal and not a multi-billion dollar media empire *, I spilled huge bottles of ink on wondering what the magic formula for instantly dropping into flow was. I've talked about it a lot with my friends in the years since then.
As the Tao and most physics teaches us, though, any powerful force has an equally powerful opposite. So it is with Flow, and I have experienced it: the Anti-Flow.
There's a lot of hacker mythology about working late into the night, eyes glazed over, blissfully hacking away on some deep problem, unaware of the outside world. It is generally acknowledged that this is a state of Being At One With The Machine. I believe that this is a false enlightenment. After this last round of crunch time, I have realized its true nature. After a certain number of hours of working, you think you're in flow. It seems as though everything is going well. What's really happening is that your mind is playing tricks on you: you're tired, you're making mistakes, but you're just not seeing them.
I think this is why the first programming methodology to get really bothered about programmer-written tests was also the first one to start complaining loudly that we should stick to a forty hour week. When you're just writing and writing and writing code, it doesn't occur to you that you're producing garbage, or if not garbage, at least substantially lower-quality code than usual. You hit your testing phase later, and you fix your bugs, and you shrug and think "that's software for you". It seems like you're productive on both ends, since you're producing lots of code when you're tired and you're fixing lots of bugs when you're awake.
But when you're sitting there bleary-eyed and trying to get your tenth test to pass and it just won't pass no matter what you do, you know it's time to quit. You have a real-time feedback loop that's telling you "go home". After a while, you put two and two together and realize that you're not really understanding the machine as much as you thought you were.
Of course, if you're not as rigorous as you should be, you just stop writing tests.
This week I watched a programmer who is normally incredibly fastidious about testing give up on his tests, work tons of overtime, jang it, and endure the consequent failure. I have done this myself many times when working overtime. I am much less likely to test code when I'm burning myself out than when I'm relaxed. It seems like the tests are just so much less likely to pass anyway, so why bother?
The moral of the story is that crunch time really doesn't work in the small any better than it does in the large. If a deadline looms in the near future and it looks like we're going to need overtime to make it, I am going to have to admit to myself and to my team earlier on that the deadline has already been blown.
I wonder how many more times I'll need to learn this lesson before it sticks.
*:
International guests: a gratuity of 15-20% is appreciated if you enjoyed the service, and may be included with the check for parties larger than 10.