Big Dave’s Blog

Joel Spolsky recently wrote a guest editorial on Inc.om. It was a good read, and I happen to agree with him on most points. One of the main points is a top developer is often 10 times more valuable than an average developer. Given me a small team of stars any day! Sometimes, even one or two stars on a larger team is all you need. The stars will be the ones that solve all the tough problems, but most of all, it is the stars that think up great solutions or save the team (and the company) valuable time. In the software biz, time is everything. Your costs are almost always related to time, and time to market is absolutely critical.

One thing I would add is that the star also needs to fit with the rest of the team. Team chemistry is often mentioned in sports, but it is also very important in software development. It’s a beautiful thing to watch when a great team gets together and cranks out great stuff. As a manager, often the best thing I can do is make sure no one interrupts them.

Anyway, it’s a good read. I recommend it.

I’ve been around software and technology for a long time now. My early days were filled with coding in Assembler. From there, I graduated to C/C++, then Java, .NET, and lately Ruby. There are a few others in there as well, but not enough to get excited about. I don’t code much these days, but still I jump in on occassion. Each language has its strong points, but the progression is always about removing control from the programmer and moving it to the language or framework. In the vast majority of cases, I welcome not having to deal with memory management or pointer arithmetic. However, there are times when I long for knowing exactly what is going on when I look at code.

After many years away, I recently did some consulting for an old company of mine. They were having some issues with a C++ service I wrote a while back. This service handles distributed caching and session management. It’s complex code to get all the threads and distributed machines synchronized. The system has grown considerably since I wrote it, but it was years before the service started to have issues with scale. Sure enough, I had a comment in the code that mentioned the potential for a future problem, but it wasn’t worth solving it then (premature tuning is a subject for another post). After 4-5 years, it’s now an issue. I bring this up only because I was amazed at how quickly I knew what the code was doing. Other than C++ constructor/destructors, there was no magic happening behind the scenes — no AOP, no thousands of lines of framework, no garbage collection, nothing. I know I wrote the code, but I haven’t looked at it for many years so I barely remember what I was doing. If this had been Java with frameworks and AOP, it would have taken me a lot longer to figure out what was going on.

The ironic thing about my point above is that as programming languages have simplified the coding process, they have also made things more complex. No longer can you read ten lines of code and know what is going on. You now have to understand the underlying framework and know about all the AOP hooks that may be in place.

Now, where is that Ruby book again?

This is a great tool to keep around. A picture is almost always better when you are trying to get your point across, and this one page gives you lots of examples.

Google Developer Day is coming May 31. It’s a global event held in 10 cities at the same time, but note there is only one location in the US, and it’s nowhere near Boston. There is a decent cluster in Europe, but only Mountain View, CA in the states. We here on the right coast know a thing or two about development.

Where’s the love?

According to the lead developer at Twitter, Ruby doesn’t scale easily. While I agree there are issues with scaling in Ruby, it can be done. The issues are just different. Where I think people get in trouble is to depend too much on the things that make Ruby so productive. As you scale, you need to be aware that simple line of Ruby code can result in single threaded execution or several database calls. To scale, code may need to be more complex. It’s the same with any platform that hides complexity.

My son, Declan, was born March 31, 2007. Declan is my wife and I’s third child. The twins, Cameron and Zoe, are very excited. We are all a little sleep deprived, but that is to be expected. The great thing about is that this time nothing will bother me. I remember leaving the hospital with the twins thinking these people can’t possibly send us home with two infants. We have absolutely no clue what we are doing! Somehow, we got by. I don’t remember a whole lot of the first several months because there was very little sleep involved. Thankfully, the crew of the ferry I took to work every day would wake me up when I got into Boston. After a week at home with Declan, it’s a breeze so far. The “little dude”, as Cameron and Zoe refer to him, is great. Even at only a week old he still finds a way to make us laugh. I don’t want to jinx us, but two infants are far more than twice the work of one. I guess it helps that until now I only knew what is like to have two.

This is my first post of many. Why Big Dave? First of all, when you are 6’5″ tall, people tend to classify you as big. Pretty soon I was always being referred to as “Big Dave”. It’s interesting that even before “Big Dave” stuck, I always stuck by the phrase “Go big, or stay home!” Between the two, it works for me.

Generally, I will be posting random thoughts about life and technology.