Home > Musings, Open Source, Personal, Programming Languages > Working On the Dark Side of the Technology Stack: A .NET Developer Working in the Java Community

Working On the Dark Side of the Technology Stack: A .NET Developer Working in the Java Community

February 26th, 2009

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

  1. Ruz Safai
    March 3rd, 2009 at 05:11 | #1

    One thing these text editor environments did was provide an old-school exercise in time and patience in learning an archaic interface. The shortcuts were obscure, there was usually no gui, documentation was sparse, and sometimes changing an option meant changing a config file. But when you mastered something like <a href=”http://thomer.com/vi/vi.html”>vi</a>, the rewards were being able to move mountains with a few keystrokes, and you got the feeling of conquering something that took an effort to learn. To go through this exercise meant you were either insane or highly persistent and patient, a quality that comes with having passion for what you do. Although we live in a gui world and work with gui objects, work with languages that use various frameworks, the virtues of patience and persistance applies to all these development platforms.

  2. Adam Kahtava
    March 8th, 2009 at 05:12 | #2

    I completely agree with you, I prefer the knowledge centric approach. Editors like vi / emacs / textmate place more emphasis on knowledge and less on tools.

    Robert Glass makes this interesting point:Software developers talk a lot about tools. They evaluate quite a few, buy a fair number, and use practically none.Facts of Software Engineering Management

  1. No trackbacks yet.