Reading the classics


Over the past month, I’ve finally taken the plunge and decided to finally read those classic technical books that everyone seems to have read (though that many have only skimmed). I’ve also been reading oddball classics that are recommended by acquaintances and folks in the know. As for the big classics that I’ve read since May 1:

I’ve also been paging through my Knuth’s again. Why, oh why would I be doing this? First off, I love the act of designing systems, writing code, and just geeking out in my chosen profession. Second, I know that I needed to read these classics so I could stop being an architect with no grounding in classic computer literature. I mean, I knew what the books were all about, but that was only through someone else’s eyes, not my own. So, with this journey still in motion, what have I been learning?

First, I needed a refresher on my algorithms. I was able to get most of the exercises in Programming Pearls and Skiena with a little bit of thought and some time by a compiler. It felt good to go through Bentley’s text and figure out the really advanced, best performing solutions to many problems. It was a morale boost to see that I could still figure this kind of thing out with just a little bit of effort.

From Peopleware, I took many ideas I have for this programming shop I want to start up ‘someday’ and refined the heck out of a bunch of ideas. For example, did you know that most people find performance reviews to be demotivating? I didn’t. I thought I was the oddball that hates performance reviews and would prefer life much better if I never got another one. It turns out that no one likes these-they are stressful. Unfortunately, I also learned some things about businesses I’ve been introduced to in my area. There are a lot of poisonous businesses out there taking a great profession and turning it into something where you feel odd to be one of the following:

  1. A proud, 36 year old developer. In my opinion, that’s still young. Yet, many folks in the profession stop coding much before this age. I’m SOOOO glad I’m not one of those people.
  2. Unwilling to ship because the quality bar is not only low, it doesn’t exist. Apparently, the shipping feature matters even when things aren’t right.
  3. Unit testing is an OLD idea. JUnit, NUnit, and other unit testing tools are not new ideas. Shoot, Fred Brooks talks about unit testing going on for IBM back in the 1950s and 1960s. And yet, I still have a really hard time convincing folks that unit testing is important and it is an OLD idea. Unfortunately, fixing build breaks takes time when unit tests are present. They slow down development and make it take longer to get to the official test, file bug, fix, repeat cycle.

I find that my focus on my career is getting sharper. I’m seeing how I can make a difference, how to achieve it without stepping on toes and hurting feelings, and I’m seeing how fast people can be expected to change. People hate change and will only do so slowly when you are trying to move a group. People are more willing to change when they are being assimilated into a group-it feels better to be a part of the group than apart from the group. (yes, the use of ‘a part’ and ‘apart’ is intentional) At the moment, I’m trying to find a place where I can be a positive force for change and I need to make sure that I do this at a proper speed. If you know of a development shop that is top notch and just wants to get better, give me a call. I’d love to talk to you and find out what you are doing to make things happen.

%d bloggers like this: