Category Archives: Books/Reading

Recent reading

Posted on by
Reply

For Christmas, I got World War Z and The Gospel of the Flying Spaghetti Monster from Jim. Both of these were very quick reads.

WWZ took me just under a week to read, the writing is good, the story is good, much better than Brooks’ first try, The Zombie Survival Guide. Apparently there was a bidding war over the movie rights, expect it to come to a theater near you in 2008. The wife is now reading it, she was out of romance fluff. Definitely worth reading, assuming you can deal with stories of cannibalism and other not so nice topics. 8/10

The Gospel was also a quick read, but mostly because it was only 165 pages, with lots of pictures and diagrams. The premise of the book is essentially an expanded send up of the Intelligent Design goofballs, claiming that a Flying Spaghetti Monster has touched us all with His Noodly Appendages. And his Chosen People are the few remaining pirates, or just about anyone willing to wear “full pirate regalia” and drink grog. Funny, but not that funny. 5/10

Joel on Software

Posted on by
Reply

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:

  • Write specs for projects

    • 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.

  • Use source control

    • 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.

  • Tossing away the entire old codebase isn’t the solution

    • 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.

  • Neutralize the bozos

    • 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…

  • The customer never knows what they really want

    • 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.

  • The Zone

    • 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.

  • Examples, Examples, Examples

    • 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:

  • Student Computer Sites
    • Installed 110 new workstations
    • Installed 4 new color laser printers
    • Reinstalled the operating systems on all 380 workstations
    • Deployed Windows Server Update Services
    • Updated the virus scanner to McAfee VirusScan 8.0i
    • Replaced a proprietary conferencing server with open source solutions (yes, you old RSC people, FirstClass is no more)

Dude, How Short?

Posted on by

Either Dude, Where’s My Country: a) doesn’t have enought pages in it, or b) it’s a really quick read. I’m going with b.

And finishing this book just reinforces my previous beliefs: We are in a handbasket and Little Red Riding Dubya is skipping towards a place where the thermostat is always on high and the Micheal Bolton/Kenny G/John Tesh/David Hasselhoff musak never stops.

The following are stolen directly from the book:

  • Please, lets Rock the Vote in 2004.
  • No matter who you are voting for, try to take someone who wouldn’t normally vote with you.