Adam.Kahtava.com / AdamDotCom

Over the past couple months I had the pleasure of working in a Java shop. Up to this point I've spent most of my time in the .NET realm. Working with Java was a great chance to experience the similarities and contrasts between environments, cultures, and web application implementations. Here are a couple of my observations.

Java developers are more knowledgeable than the typical .NET developer. Java developers tend to gravitate towards complexity, Linux, UNIX, open source, and continuous learning. They are less familiar with the wizards and drag-n-drop style development that often characterize .NET development. The Java developers I worked with didn't depend on a single unified IDE (like Visual Studio), instead each developer chose their text editor / environment (Emacs, Eclipse, TextMate, E-TextEditor, and jEdit were all being used on a single project). Each developer was responsible for being productive with their editor; and took responsibility for learning shortcuts, and other performance enhancing techniques. This broad use of editors placed an emphasis on the core command line tools which ensured that developers knew how the application was put together, and cultivated broad application troubleshooting skills within the team.

Unified IDEs (like Visual Studio or Eclipse) do not result in faster development, better developers do. Developers empowered with the ability to choose their development environment / text editors / operating system resulted in more passion and responsibility. Informal friendly rivalry between editor users drove development faster while providing diversity within the work place.  

Programming languages and technology stacks don't matter to experienced software developers. As a developer it's easy to become a fanboy of languages or technologies stacks, but… they don't matter – writing good software within the bounds of our project do. There's no reason to be tied to a specific language or technology stack. Sure, languages fall into a specific category (dynamic, static, classical inherited, prototypical inherited) but programming languages are very similar.

Steve McConnell has been saying this all along:

mastering more than one language is often a watershed in the career of a professional programmer. Once a programmer realizes that programming principles transcend the syntax of any specific language, the doors swing open to knowledge that truly makes a difference in quality and productivity. – Steve McConnell, Code Complete 2nd Edition

Eric Evans offers this piece of advice:

Don’t write frameworks for dummies. [Frameworks designed by organizations] that assume some developers are not smart enough … are likely to fail because they underestimate the difficulty of … development. … This attitude also poisons the relationship between [the developers and framework designer]. – Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

Evans goes on to make the point that there’s a fine line between designing for dummies, and providing useful encapsulation / abstraction. I found this advice interesting because I had been wrestling with whether the ASP.NET AJAX Framework is for Dummies.

Happiness is when what you think, what you say, and what you do are in harmony. – Mohandas Gandhi

Ruby is consistently placed as one of the ten most popular programming languages – see the TIOBE Programming Community Index for more language comparisons. Matz (the creator of Ruby) described his guiding philosophy for the language as one that’s “designed to make programmers happy”. While the Ruby language gets a lot of praise for its zen like qualities, its clarity, and terseness. The tools surrounding Ruby like the RubyGem Package Manager along with its active community and growing collection of Gems (view the list here) are often overlooked.

I like the RubyGem system just as much as Ruby, it makes a developer’s life easy.

For example, let’s say I want to design a new class:

• Install Ruby
• Install the Test-Unit Gem (along with a couple automatically installed prerequisites):

C:\>gem install test-unit
 Successfully installed test-unit-2.0.2
 Successfully installed hoe-1.8.3
 Successfully installed rubyforge-1.0.2
 Successfully installed rake-0.8.3

• Create a new test.rb file along with a new class.rb file (alternately we could have used the Interactive Ruby Shell directly from the command line)
• Run the test (test.rb):

C:\>ruby test.rb
 Loaded suite test
 Started
 .
 Finished in 0.001 seconds.
 1 tests, 1 assertions, 1 failures, 0 errors

• ???
• Profit! :)

Contrasting this to the Java / C# world: I’d be installing a compiler (or slower yet an IDE), then installing / configuring a testing framework. I’d also probably be installing a build process tool (like ant / nAnt), then I’d need to create a build file.

Similarly if I wanted to install Rails at the command line I specify gem install rails or if I want to use  RSpec gem install rspec.

The Ruby tools, ecosystem, and community is fantastic.