The Problem with Java and C# ...

I'm going to stick with saying "Java" in this article, but the same argument applies to C# as well. Replace accordingly.

There seems to be a lot of bad sentiment aimed at Java these days. Either complaining about the verbosity of the language, the bloat of the surrounding tools or the mentality of the developers that use it. Other articles seems to talk about how rapidly that community is shrinking or the futility of the innovation in the community.

The problem with Java is not the language, it's the hiring mentality that goes behind it.

When companies decide to play in the "enterprise" space, they feel they need to use programming languages that best fit with those environments. This usually means Java. This is nonsense. Facebook, Twitter, Google and other hot new companies have incredibly scalable architectures, many without SQL, LDAP and Application Servers. We know there are other/better ways to solve the scalability problem. Also, you have compatibility with legacy systems without requiring an Oracle Application Server. If you need to have an army of Operations people to tune your app server, you might want to reconsider your architecture.

Another factor in this rationalization is the ability to hire from a wider gene-pool of developers. There are certainly more Java developers out there than nearly any other programming language. When hiring a Java developer many of these companies hire tactical skills, not general skills. Do you know Struts, JSF, Hibernate, Websphere, etc.? And I can understand why. If you build a product that is going to have a long life-cycle, you have to assume the software is going to have to live beyond the developers that assembled it. If the application is written on niche or trendy languages or tools it will be harder to replace these developers later.

This is broken thinking.

People will do what you reward. If you reward blindly learning software packages without understanding what their benefits and limitations are you will end up with a development team full of automatons. If you reward understanding computer science fundamentals, the best tool for the job, code simplicity and readability you will end up with a better software product and it will take less developers to build / maintain it.

And don't read this the wrong way. I'm not implying that all Java developers are sheep. There are many, many awe-inspiring Java developers out there. Sadly, there are far more sheep.

Can you blame the developer? No. The common sentiment is "If I stick with Java, I'll have a job." ... and it's mostly true. This is usually followed by "Do I like my job? Meh."

Yes, it is harder to hire these sorts of developers. Your interview process will be lengthy. You will eliminate more candidates. But do you want to work in a brain shop or a body shop? Which is harder: reading clean understandable code in a new language or reading verbose bloat code in an understood language? Which is easier: reading a new DSL or pages of XML?

What is the impact of developer farms that are hired for tactical skill sets instead of core understanding and passion? An uninspired workspace. A breeding ground for "[Flavor-of-the-Day] Coaches" who feed off the malaise of the corporation. "Certified [SilverBullet] Masters". Higher turnover. More developers pounding in Feature X, Y & Z without a care for the big picture. 

Let's not throw out the baby with the bathwater. Don't diss the language. Diss the companies that foster this lousy work environment on us developers. Developers, work on your core skills. Don't let yourself fall into the "must master the Java stack" trap. Learn other languages and see how they tackle the problems. Look under the hood at how the libraries you use today work and what the alternatives are. Learn new API's, but then learn their implementations. Review your algorithm books and decide if there are better ways to solve the problem.

Don't go wide, go deep and don't work for body shops.

Should You Always Explain Why?

When mentoring apprentice software craftsman there are times when rationale gets lost. You are trying to teach them caution. Caution means slowing down and being attentive to your surroundings so you don't do something dangerous. But if they never get hurt can they really understand why they should be cautious?

It's different with children. You don't want them to use the stove or run with scissors because the cost of not being cautious is too high. But you let them spin around like a top until they fall down, potentially getting a bop in the head. You let them have a pillow fight, knowing that someone is going to come screaming in a few minutes. Why? Because when they get hurt they learn a valuable lesson.

In software, how do you gauge what is an acceptable risk? I remember several years ago working with a group of junior developers and getting them to write unit tests. I was a broken record: "You have to write your tests." "Did you write your tests?" "You can't refactor without tests." "Did you run the tests before checking in?" "Did you run the tests as soon as you checked out?" ... but they had never really felt the pain of not having tests or dealing with poorly written tests. It was nearly three years later when one of the developers came to me and said "You know I finally get this unit testing thing now. I just did it before because we were told to, but I never really understood why. Now I do." Almost instantly, all the light bulbs went on for him. Short iterations, the importance of enforcing a coding style, the use of Fakes & Mocks ... it was easy to see he was no longer a junior developer. Testing was a part of his craft now.

Is there anything more I could have said to make this more evident? Probably. But I think the words would have been lost or come across as more preachy than it always was. He needed to feel the pain for himself to learn.

But ... as a manager, could we afford to have developers not doing tests for three years? not complying to the coding standard for three years? No. We had felt the pain. We know what the costs of not doing that stuff is. I'm sure many of the tests written during his journeyman-ship weren't very good ... but they were building muscle memory. I'm sure many master carpenters, glassblowers and potters do things by rote for a long time before really understanding the subtlety of their actions.

Being a mentor, just as being a parent, you have to make the hard decisions of when your charges are really going to hurt themselves and when it's ok for them to take a smack in the head. And, often times, explaining why beforehand gives no benefit.

How long can you work on a programming team before things get stale?

Assuming it involves lots of new learning initially, my gut tells me it's about 1-2 years. Once a developer understands the problem well enough they can start to get antsy.

I have a theory that 3yrs is the maximum amount of time a programmer can work in a given problem space before things get routine. It doesn't have much to do with your team or the company ... it's the challenge. The rest is an "exercise left for the reader."

Certainly there are exceptions. People can last longer but, to me, it seems generally they become ghosts in the machine. All the good programmers will tell you the same thing: "program on the side", "learn a new language", "experiment with an API", "moonlight".

But are your extra-curricular activities aligned with those who write you a check? A recent trend is for programmers to be let go for "not being engaged" ... that's scary.

Or, are you one of the really lucky ones? Is your work so in-depth and challenging that you constantly have to research new techniques to solve them ... and you are given the time to do so?

I think the quote on "Beards and Keyboards" regarding Change says it best:

So when you hear people say that change is hard because people are lazy or resistant, that’s just flat wrong. In fact, the opposite is true: Change is hard because people wear themselves out. And that’s the second surprise about change: What looks like laziness is often exhaustion.

— The first few pages of the book “Switch, how to change things when change is hard” are priceless. Get it! By Chip Heath & Dan Heath