Just at 10 open tickets, only a few IGuides are here now. Tomorrow is the first day of real move-ins, about 1000 Living and Learning Communities residents.
The computer labs open on Friday, Saturday is the big day for freshman move-in. Everybody else comes back on Sunday.
Since I think we’ve told just about everyone in person (sorry if I missed you and this is how you find out), the wife and I are expecting our first child in February. Many people at the wife’s work think she’s having a kitten and I can see that in the sonos. For some reason, she doesn’t find that funny…
You know, there’s nothing quite like campus at 6:30 am during the short break between Summer Session II and Fall. There’s hardly anybody here, it’s all quiet, few cars around and you can actually ride around on a bicycle without risking your life.
As I’ve mentioned before, I’ve been reading Joel on Software. The book itself really isn’t aimed at my profession per se, but it does give some useful advice and insight on how to wrangle developers and management. The phrase “pushing on a string” is used more than once, and I think it’s a perfect analogy for how some things happen around here.
There are also some excellent suggestions on ways to improve your process that apply to things outside of software development:
Not just for coding projects, for everything. This forces you to think about the steps required for doing the job, detailing every minute step along the way. Who knows how many “Damn, I never thought of THAT happening” late night/early morning panic sessions could be avoided just by writing down and running through paper writeups of the process.
We’ve been trying for years to get our developers to see the power of source control (even if it is just Visual SourceSafe). It’s a mish-mash of forcing “no making changes in production without scripts/code/etc being in sourcesafe” and general habit forming that is slowly dragging everyone over. Now if Visual Studio.NET would just integrate better with VSS, we’d all be happier.
Okay, I’ll admit it, this one is pretty much programmers only. But, there are some applications to real life here. Would you junk your 5 year old car just because it needs new tires or a new water pump? Depends on the car, I know, but in general, small maintenance is better than large, delayed outlays giving your competition time to run over you. Rewrite large chunks of code if you feel the need, but don’t toss all the code out just because you wrote a bad sort function 5 years ago. I’m just as guilty of this as everybody else.
If you’ve got dead weight on your team (and you can’t get rid of them), give them some small, easily accomplished sub-project to work on that might take them months. Best case? They actually finish it, it works and you can integrate it into the big picture. Worst case? They are hopelessly lost for several months and you end up handing that task off to someone more talented to do in a few days. Win/Win in my book…
Taking a page from Office Space, you should just accept the fact that the customer only knows how the interface should look, not how the code under the hood should actually work. We’ve got at least one ongoing project where this is painfully true. The interface is implemented in what I like to call “so, this button goes here” and the business logic was decided, and is constantly re-decided, by strings of emails between non-technical Important People, non-technical managers and technical programmers.
I know lots of people have told you this before, but Joel brings it out in a way that makes you able to show your manager that being “in the zone” is a good thing and supplying all the things needed to get you there is good.
This isn’t really something that’s in the book, but it’s how I translated the spec writing suggestion into my job: Anytime you suggest a change, give as detailed as an example as possible. If you can’t go back and read an email 2 days later and understand exactly what you meant because you were so far “in the zone” on that problem at the time, saving your old mail as a reference isn’t going to help much…
There are some things I’d like to start doing at work from this book, but who knows if I’ll actually have the time or the energy. The most visible one would be to put together a “What did Housing Network Engineering do this summer?” entry for the intranet.
Some back of an envelope items for that list:
MS KB 326965: IIS6 won’t serve .iso files until you add a MIME type for them.
Stumble over that 404 error for a while, why don’t you?
Saturday my parents, the wife and I went up to the Museum of Science and Industry to see Bodyworlds. It was definitely worth the drive and the small amount of standing in line for Bodyworlds. The Museum, on the other hand, has gotten a little stagnant it seems. Many of the exhibits haven’t really changed in 10+ years (the oversize heart, the train layout, etc) and the ones that have didn’t seem to interest us much. I’m sure the U-505 is nicer now that it’s inside, but how much could have changed?
And, if you go, I’d recommend buying your tickets in advance online. Just like the website says, no standing in line (to get into the museum), no waiting, just park, ride up the escalator, get your ticket scanned and off you go. Well worth the small convience charge.
Hard to believe it’s been almost 20 years since Hurricane Gloria, but this Earth Science Picture of the Day proves it.
I can remember spending at least one night in the base alert facility, listening to the wind howl and playing an old Red Baron video game. Dad had flown one of the planes off to some other base, Homestead AFB I think, to avoid the storm and family of the unit were allowed to take shelter in the alert facility.
Famous last words: “It should only take 15 minutes.”
And going on hour 4, but at least it’s consulting work….
Oh my, this is a mess. Trying to keep amavisd-new up to date, using the fine RPMs provided by Dag Wieers. First, apt-get tells me that amavisd-new is being held back because perl-Time-HiRes is less than 1.55. RHEL4 has an updated RPM, so download the SRPM from RedHat Network and rpmbuild --rebuild it, all is better, right? Nope, amavisd-new still needs perl(Digest::MD5) > 2.22. No handy rpm from RHEL4, it’s part of the main perl package. So, maybe I can just update it with CPAN (perl -MCPAN -e shell). After configuring CPAN, and remembering the odd commands to try an install, I get this error when doing install Digest::MD5:
Makefile:84: *** missing separator. Stop
Luckily, google seems to have indexed some new mailing list pages since the last time I searched for this, and I found this mailing list post. So, drop out of CPAN, export LANG=en_US, climb back into CPAN and now the build works. Silly broken multilang support.
Yay, up to date on amavisd-new. Now to get the other packages up to date and update the primary mail host.