Hating (or at Least...Not Loving) Microsoft

I saw this on scobleizer.com. It really gets to the core of my feelings about Microsoft.

The money quote:

To me it comes down to expectations. Microsoft is like the genius child who has rich and smart parents. Society holds huge expectations for such people. If they don’t succeed the story is it’s a child who hasn’t lived up to his/her potential.

Microsoft is much the same way.

Whenever I try to get to explain to others the core reasons for why I have such a disdain for Microsoft, I always end up coming up short. Usually, I just come off as your run-of-the-mill Microsoft basher. I've always had a hard time figuring out exactly why I dislike the Redmond Giant. Now I finally get it.

It really comes down to disappointment.

I've never been able to understand how a company like Microsoft - given how for decades the company always had the best and brightest minds (of which Google now has the lion's share) - has been so incapable of making a truly awesome OS.

You can make all the arguments about the more complex nature of PCs and how that made making a rock solid OS more difficult, but I still think given the brainpower available to them throughout the years that they could have pulled together one kick-ass system...over and above anything out there currently.

But it just didn't happen.

The turmoil I see presently surrounding Vista - with both users and vendors resisting the push of Microsoft to upgrade to the new OS - is what I see as the culmination of years of disappointment finally building up against Redmond.

People have been dealing with the same shoddy work from Microsoft for years, and many people (like me) feel that they could've done...that they could do...better than this.

They are finally saying "enough already."

Now I realize that MS has done some good. I'm not blind in thinking that they are just a total screw up and didn't contribute anything worthwhile to the industry. If it weren't for Microsoft we probably wouldn't be where we are today.

But I think they could have done so much more. So do many other people out there.

So, I don't hate Microsoft.

I just wish they would do better.

Shut Up and Code

OK...what's the deal with all these "my programming language is better than yours" posts nowadays?

Sure, there have been plenty of these kinds of "language X is better than language Y" comparisons going all the way back to the days of assembly language - I remember quite a bit of these kinds of rants between Java and C++ folks in the 90s. The bulk of them now are (surprise) between Ruby and Java, and the pissing matches seem to have reached unseen new heights.

Seriously. What's the deal?

These types of rants are the geek equivalent of "my dad can beat up your dad", and equally just as stupid.

If you want to provide some constructive comparisons between languages, fine. I'm all for that. But the petty "Ruby is better than Java/Java is better than Ruby" posts don't contribute much to the discussion, other than pissing everyone off and drowning out the more relevant discussions that should be made when comparing pros and cons of various languages.

Yes...Java has a few warts...

...so does Ruby...

...and Python...

...and C++...

...and C#...

The fact is each language serves the needs of the people that use it - if they didn't the languages would never be used. If someone isn't using your favorite language get over it.

The more pragmatic developers out there don't give a damn about the supposed superiority of some feature in your favorite language (or your supposed superiority in using said language). Hell, some of us don't even have a choice in what language to use...that's managements call...and they aren't likely to just jump on the bandwagon without a damn good reason.

And this isn't because we don't like your favorite language, either, but just that we have a job to do and if Java will work for the task, we'll use it...or Python...or Ruby.

So, if you have something constructive to contribute to the language discussion, go for it.

Otherwise, just go write code in your favorite language.

Let the rest of us do the same.

Becoming a Computer Programmer: Rule #1- Understand How Computers Work (And Know How to Build 'Em, Too)

I see plenty of suggestions by bloggers for what you should know in order to become a computer programmer (or software developer, or whatever term you like to call it). They'll recommend books, websites, and so on, which are all very useful.

But rarely do I ever see anyone recommend the obvious one: Learn how computers actually work.

Now, it could be that it's just that knowledge blind spot we all run into - it's so obvious that you don't think to mention it. But, believe it or not, I've run into plenty of developers out there who lack the basic understanding of even how the CPU executes code, so somewhere someone forgot to tell them it might be a good idea to know this sort of thing.

Of course, some will argue that, with dynamic languages, virtual machines, and the various other high-level technologies nowadays, you don't need to know how a CPU and its various components actually work. Certainly true, but you are no less better off knowing how a computer, and it's various components, actually do their thing.

To me, not knowing how a computer works is like a mechanic not knowing the intricacies of how an internal combustion engine works: You might be able to work on the engine, but you'll be missing out on a whole lot of key information that can make you much more effective at doing your job.

Knowing how the CPU fetches, decodes, and executes instructions is one of many things about computer hardware that I believe are very important to becoming an effective developer. Without this knowledge you're just going through the motions, with no clear understanding of the effects that certain areas of your code can have on a system.

Spending some time learning how a computer actually does its job is time well spent. You don't have to be genius to learn about it, either. Books like Inside the Machine (written by Jon "Hannibal" Stokes of Ars Technica, whose articles I always pay attention to) make it pretty easy to learn how the computer's mechanical brain ticks.

Beyond learning just how a computer works, I would even go so far as to say you should be able to build one, too. For me, being able to build, fix, repair and otherwise tinker with a PC has been invaluable. The troubleshooting skills this has provided me with are by and far the most valuable skills I've acquired from working with and learning about PC hardware.

A recent series of blog posts on Coding Horror, covering how to build a computer, is a good start for learning how to do this sort of thing. But really it takes time and on-the-job experience to develop these skills, which might not be feasible for everyone. If your young and looking for a job while your in college, or otherwise honing your programming abilities, go find a job that will give you experience in this kind of work. A place like a local computer repair shop, or even a Best Buy or CompUSA, working for their upgrade center, can be valuable.

So, at minimum you should know how your computer's hardware ticks (particularly the CPU). This will give you much more insight into the code you write. But, if you can manage to expand your knowledge into building and repairing computers as well, it will help you that much more.

Either way, you're going to be way ahead of many of the software developers out there.

Automating a Development Environment Setup

I mentioned in a previous post that I took over the configuration management role to improve the developer environment setup and ensure that anyone can successfully get up and running with the project I was brought on to help with...

Well, I've taken it a step farther.

The project's original configuration setup used an older version of Eclipse, along with the Web Tools Platform - a separate plugin that needed to be manually installed and configured by the developer when setting up their system. With the lated versions of the Eclipse, the guys at the Eclipse Foundation combined these plugins (along with a host of other add-ons) into a single entity for J2EE development.

Naturally I decided to update our developer configuration to include this new version, thereby removing a few steps from the several required to set up a developer's system (and the fewer steps, the fewer times I have to help people resolve any pesky problems from their failing to properly read the documentation).

After thinking about it, I thought it would be an interesting exercise to see if I could figure out a way to completely automate the development environment setup. Since having the entire process automated would make the whole thing pretty-much idiot-proof (yes, I know, idiots are so ingenious...), it would potentially eliminate the need for me to take time to help developers debug their setups when things don't work right.

After a few days of creating batch files, Ant build scripts, and tinkering with config files, I managed to completely automate the entire setup routine.

This included:

1. Getting the latest version of the project code from source control (CVS in this case)
2. Installing Oracle's OC4J container and automatically creating a default admin password
3. Installing Eclipse with a workspace already configured with a project pointing to the code checked out.

The only real trouble I ran into was the last part. In order to get a workspace configured, I needed to first go through the trouble of setting one up by hand. I then had to copy that workspace to a place where it could be used in the setup script for copying into the user's installation. As a result of this, I had to spend time removing any absolute references to directories (since these needed to be altered during the install to point to wherever the user decided to install all the components). I even had to hack a binary file filter into a custom Ant task since, for some strange reason, Eclipse uses a few binary config files (which doesn't make much sense to me since 99% of the config files are XML, why mix and match?) and one of those files happened to contain an absolute reference to the source code directory.

But once I got over that hurdle, I was able to create a pre-configured development environment that is super-easy to set up, and requires on limited intervention from the user.

And now I get a bit more peace and quiet at work since I don't have to play tech support for developers :-)

How To Avoid Ruining Your Life

This blog post is a cautionary tale about how becoming a programmer can potentially ruin your life.

An excerpt:

A program is highly malleable. You can make a nearly unlimited number of changes. You can re-implement. You can optimize. You can run the compile-test-debug cycle ad infinitum. Make a change, see a result. Life is not like this. Every action you take is followed by a commit and the transaction cannot be rolled back. You can continue to make changes and optimizations as you move forward but the effects of these will not be immediately apparent. The instant feedback of development is sorely lacking in real life. Furthermore, your changes might simply be ignored. Data will be skipped. Blocks will not be executed. Optimizations will go unnoticed. The world is resistant to your tinkering.

My response: "Well...duh"

Anyone in this world that tries to take a strictly programmer-like, analyze-and-optimize approach to living their lives deserves whatever bad results ensue.

I've been a programmer for most of a decade now...hell if you count my non-professional work I've been programming most of my life. I've never been so stupid as to try to apply the mindset I had while programming to my "out of computer" life. I knew long ago that trying to treat the real world as a giant computer problem waiting to be solved would never work. Why? Because social interactions aren't totally predictable like a computer.

I thought most people figured this out in grade school.

The post does make a good point about letting work take over your every waking moment, which is typically never a good thing for most people. But I think this also speaks toward a disconnect between those that treat programming as work as opposed to a career, too. The people that really truly enjoy the software development world allow themselves to become so wrapped up in it because they enjoy it so much. To them, work and play are one in the same. People without this level of enjoyment have a hard time understanding this.

But that's not to say you shouldn't stop and smell the roses either. Like all things in life, try to take it in moderation.

The Pragmatic Approach to "If They Come, How Will They Build It?"

update: I've written a follow-up to this post that I strongly advise people reading this post to look at. I fell into a classic developer trap here: I created a solution to the wrong problem. Read my follow up for details.

Looking at the recent post on Hacknot (pointed out via dzone) reminded me of my experience with a similar situation not too long ago: I joined a project already in progress and had to spend time getting my development environment up and running. In my case there was some documentation to follow, but it wasn't 100% accurate (hadn't been updated in a while, from the looks of it). So naturally, I spent more time troubleshooting the environment setup than actually getting work done when I first started with the project.

The Hacknot post (rightly) places responsibility for such lapses in documentation on the existing developers that are working on a project. They should always try to make sure that all the stuff regarding IDE setup, libraries, class paths, etc. are easy to figure out for the new guys. But developers are a lazy bunch.

Sometimes we're our own worst enemies.

So, in the case of my new proejct, rather that sit there and fret over the lack of good documentation, I invoked good ol' Pragmatic Programmer rule #5: Be a catalyst for change.

So if nobody bothered to updated the documentation, I'd do it myself.

And that's exactly what I did, too.

Once I gathered all the information I needed to get up and running on the aforementioned project, worked out all the kinks, gotchas, pitfalls, and was able to correctly build and use everything necessary, I took all that information and completely rewrote the documentation.

As a result of doing this, I've become "the guy" with regards to environment setup. I'm consistently the first person asked about environment setup whenever there's an issue. And now, rather than an environment problem being the result of poor (or no) documentation, it's usually now due to someone failing to read the documentation fully.

It's amazing what a little bit of effort can get you.