Book Review: “Please Don’t Just Do What I Tell You!”

February 14, 2007

When my father gave me this book and mentioned that he was tempted to send out the letter found on page 9 to all his folks, I wondered what could be in a letter that would cause him to want to share it with so many folks. Usually, you pick up management tidbits here and there – a piece for this person, a little for that one or maybe a nice catch phrase to motivate the “laggers”. To find something that fit everyone wholesale sounded a bit to good to be true. Well – it wasn’t. As a highly motivated and driven person myself, I didn’t find the book to be revealing as much as it was a reinforcement of my current habits and feelings as well as a good explanation of what factors push me along. While it’s not a cure-all for slackers by any means, it puts in plain terms and examples what makes the difference between a good employee and a great one. It’s formatted for speed reading and an average reader could easily get thru it in a night or two.

Advertisements

Guilty As Charged…

January 5, 2006

Jason dropped a post on SVN today about the importance of the “middle” of the development cycle that worth a read – actually, I think that it should be a MANDATORY read for anyone in a position of power in the development world but I digress…

I’ve fallen victim to this myself more times than I can count – you’re all pumped about a new idea/project and get right to it. You plan and diagram so as not to miss anything. You start to throw down the code, pumping out beautiful, clean code complete with unit tests and XML comments. Initial revisions are flying thru the automated build system. Then somewhere in the middle, things start to cool down. The comments come in a trickle, if at all; unit tests are a pain so each class gets a little less built. Often times there are small surges when a class will get built here or there, maybe a little more documentation gets done, but usually there’s a big stall out in the middle that’s followed by the disappointing realization that the knowledge gained thru the coding process means that the original design needs to be reworked/tweaked. So where do you go?? Back to square one thus negating efforts to-date?? Or simply push on to the initial version and figure that you’ll return for a redesign/refactor for the “next version”??