Fostering good code vs enforcing it

April 8, 2008

During my time with a previous employer I learned many lessons that one is confronted with when on team with a non-trivial percentage of permanently-junior-coders (my code word for those people Joel Spolsky would put in a rubber room away from production code.) One particular lesson I learned was the folly of trying to enforce good code by not only taking steps to foster ‘good’ code, but to also prevent bad code. The senior members of the team (including myself) agreed that a particular coding ‘act’ was a pretty strong code smell. And we decided to use a somwhat more complex classpathing arrangement to prevent any code from being able to give off that particular code smell. After awhile this started to rub me the wrong way when I realized certain sacrifices were being made in order to keep the safety net. But before much came of it I moved onto greener pastures with my current employer.

Well, some time later I learned that the safety net was abandoned. And not only was it abandoned, but the way it came to be abandoned was that one of the permanently-junior-coders had simply (and likely unknowingly) broken the safety net. Just brushed it away with a simple mouse click. And not only that, but no klaxons sounded or anything when it happened, so significant time had elapsed between the net being bypassed before anyone even knew it. Upon learning this I started to think a little about that experience. Trying to learn what there was to learn.

I had read Joel Spolsky’s book “Smart and Gets Things Done” at the suggestion of my fellow blogger Barry. And what Joel says about the “rubber room” has begun to hit home with me. There are folks who will claim the permanently-junior-code can be put to good use in many cases. And I’m not going to make a claim they are ALWAYS wrong. However, having senior coders spend time and effort making those permanently-junior-coders effective is a cost. And that cost should be weighed against the benefits to be gained by having the senior coders work on real code. To be sure I’m not saying senior coders shouldn’t have to make good readable maintainable code (I’m not trying to justify coding myself some job security.) But they shouldn’t have to make sacrifices that are only necessary to benefit the permanently-junior-coder.


Linux is Cool

April 8, 2008

I’ve been a Linux enthusiast for about a decade. Enough so to be able to get it running at home for various things, and be the one guy on a java/web development team to be able to have a somewhat in-depth convo with the server admins. Recently I’ve put together another server’s worth of hardware to host several services, mainly a JEE app server and DB. It’s certainly not new hardware (Athlon 2500++) but it’s easily the strongest hardware I’ve ever had in a Linux server. I chose to use Ubuntu Server but, admittedly, without a real strong reason. Ubuntu Desktop had just treated me well, and I’d heard a few good recommendations about it.

So you might be asking, why is this guy saying Linux is so cool? Well, it’s not gonna be anything new to those already familiar with Linux or who’ve heard those Linux-heads spouting their love for it. That is, that with some 4 year old hardware (and older in the case of a few pieces,) a few hours of work, and a bunch of FREE (as in I haven’t paid a freaking dime) software I now have a web server (apache), a code repository (SVN/webSVN), a relational database (mysql), a JEE appserver (glassfish v2), an SSH server (openSSH), as well as a bunch of other tools I don’t have a use for yet. And, imagine that, it’s secure to boot. I don’t think that is something someone is likely to setup as quickly and cheaply with M$ based stuff. And it would be even more unlikely if Linux hadn’t come along to challenge them.

While that alone makes Linux pretty cool, Barry and I have also learned a cool new use for the ssh server. That is as a SOCKS proxy for web browsing, IRC, and more secure administration of the DB server. This comes in handy when wanting at least the smallest semblence of security when wifi-ing at conferences, restaurants, etc. And again, very little work and absolutely no cash involved. SWEET!