Category: Java
Enterprisey Developers, Acronyms, and Discrimination
Over the past few years my clientele shifted from a mix of mostly mid-market companies and a few startups to almost entirely startups, and that shift has resulted in a wider palette of languages requested by clients. Where my business was about 95% Java for the first 10+ years of my career, today it is closer to 25%. As I’ve written before, my business veered naturally from a pure Java focus when a considerable amount of the Java talent I have represented in years past started to migrate and show interest in diverse languages and ecosystems.
Unlike the boom periods for startups in the past, it appears that today’s startup is much less likely to choose Java as the primary development platform. Many developers who did Java work for startups in the mid 2000’s sought higher ground in the late part of the decade when small shops took a hit, and found themselves working for large companies and more corporate environments.
Flash forward to the past few years and the resurgence of startups. Many of those engineers who took shelter in the larger firms are now interested in establishing themselves once again as a major contributor on a small team in a startup, and when I have represented some of these highly qualified developers to startups now, I’ve been met with the feedback ‘The candidate’s résumé appears too enterprisey‘. As an aside, I don’t get that response nearly as often for Java engineers that stayed with small companies.
The enterprisey label, in my experience, seems to be used in two situations that can often (but not always) go hand-in-hand. First, enterprisey is often used to describe candidates that come from large development shops regardless of the languages used (although Java and .Net platforms are the norm), where the bias is that the development culture and the broader company culture make that candidate less likely to succeed in the startup. This is the result of preconceptions surrounding development methodology, possible unnecessary complexity in applications, a slower release schedule, or the impression that developers in these larger environments are sheltered from tasks related to data, devops, sysadmin, and QA that are frequently handled by developers at startups. The label may be applied liberally to virtually any candidate coming from a company larger than the hiring firm.
The second common enterprisey tag is used on any developer using Java or .Net regardless of the employer size, due to the predominant viewpoint that other language communities have developed regarding Java/.Net being wrought with and plagued by dozens of frameworks and bloated stacks. As someone who sees thousands of résumés a year, it is clear that résumés of Java and .Net developers are often significantly longer than those of developers in other languages, but there could be several factors at play there beyond just the number of potential bloat items (insert Java = verbose joke here). At a distance, the résumés of Java developers can resemble an eye chart, with acronyms outnumbering actual words. One hiring manager of a Scala shop provided this gem:
“The laundry list of legacy enterprise technologies (JMS, JMX, etc.) doesn’t do anything for me.”
The word ‘legacy’ seems particularly cruel there.
Sadly, many of those making hiring decisions in these startups are quick to dismiss a highly-skilled talent simply because of their experience working for a larger company or their primary language being in the Java or .Net worlds. Whereas an interest in, say, functional languages is now often used by startups as an indicator of ability, the prolonged use of Java or .Net at a large firm can be a detriment when applying for work in any other language or polyglot environments.
So how can engineers labeled ‘enterprisey’ escape that bias and be accepted by smaller shops with different languages?
Résumé and bio de-enterprisification – That’s not a word (yet), but the concept would be to go back and make sure your résumé/bio/LinkedIn profile/etc. doesn’t read like a corporate Buzzword Bingo card. Eliminate or modify anything that may appear steeped in bureaucratic process and procedure, and be wary of any items that can be perceived as indicative of a glacial development pace. References to project length and time between releases should typically be avoided. Emphasize new development over maintenance tasks, and accomplishments over process. Listing too many tools, frameworks, and specifications will often work against you and may be considered an indicator of your dependence upon them. Shortening the résumé is almost always the way to go here, and three + page résumés generally smell of enterpriseyness.
Develop other language credibility – Any code that you can point to that does not run the risk of being labeled enterprisey is better than nothing. As stated before, some startups perceive functional programming interest as a marker for ability, so even an implementation of a typical interview exercise in a functional language (or one different from your primary) has value. Provide links to this code on your résumé and reference any personal projects that are applicable.
Stop calling yourself ‘LANGUAGE Developer’ – I do it too (all the time), but you should not. Use whatever you feel is appropriate – Software Engineer, Programmer, Developer, Geek – but stop inserting a language when describing yourself on paper or verbally. And perhaps more importantly, stop thinking of yourself as a LANGUAGE Developer. Sometimes you may need to dumb it down so the clueless recruiter will find you, but try to minimize those instances the best you can (and do you really want that recruiter to find you anyway?).
Express your outside interests – Just because you get paid by some insurance company to write Java/.Net apps all day doesn’t mean that is who you are. If you are exploring other languages through books, conferences, and self-study, make that known in whatever way may be discovered during your job search (résumé, blog, social media, etc.). Hobbies like robotics, Raspberry Pi, and Arduino are probably unrelated to your job but not necessarily unrelated to your career. Any technical interests beyond the primary function of your job demonstrate at least some level of versatility and the ability to adapt outside of your enterprisey 9 to 5.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
How Hackers Choose Tools (thoughts on Paul Graham’s Java’s Cover)
Recently, a 2001 blog post with the title Java’s Cover written by Paul Graham (of Y Combinator fame) spread across Twitter and was linked by all the other usual tech site suspects. The piece was about what Graham called ‘hacker’s radar‘, which he describes as the ability of hackers to ‘develop a nose for good (and bad) technology‘. For his description of hacker’s radar, he decided to cite Java as an example of a technology that smelled bad at the time. Java’s popularity in 2001 made it a pretty big target for critique. The title Java’s Cover is a reference to judging a book by the cover, and Graham argued that Java’s cover was a stinker.
Graham admits in the article that he had never written Java and his main exposure was when he ‘glanced over reference books‘, though Graham does have substantial tech credibility as a hacker. He lists 12 reasons why he didn’t like the look of Java, and mentions that he had a hunch that Java would not be a very ‘successful language‘ (but he ‘may turn out to be mistaken‘).
The commentary on the aforementioned usual suspect sites seems, predictably and unfortunately, to be centered on the accuracy (‘is Java truly successful?’) or inaccuracy (Java is everywhere) of the prediction itself. I feel it is a much more interesting exercise to take the opportunity to go into the author’s opinions as representative of an advanced technologist, and to see what factors would lead a like-minded and influential technologist to potentially have the same negative reaction to a new tool/language based on relatively non-technical factors. Every day we read articles that are highly critical of languages, frameworks, design patterns, and anything else you can imagine, and it can be difficult to tell how much experience the author may actually have (or even need) to make such assertions. When an industry voice writes an opinion on a topic based on the factors listed by Graham, what weight is given to the conclusions by the community? Graham’s article is somewhat unique in that he was willing to list the ‘smell’ reasons for his suspicion.
Looking at each reason Graham gave individually may give us some insight into how technologists yesterday and today may form opinions about a variety of topics, and whether or not we can use these tests to determine future success.
1. It has been so energetically hyped.
While it is certainly true that excessive hype can be a sign of any potential product’s weakness, that certainly isn’t always the case. Graham mentions notes that ‘A real standard tends to be already established by the time most people hear about it’. You will find that almost every technology that is highly criticized has been blessed/cursed with a fair amount of hype, either generated by marketing people with profit motive or evangelists that may have much smaller (or even zero) financial interests. I’m not sure that hype alone should make technologists wary about a new offering, but people who are naturally skeptical will surely be wary of over-the-top hype efforts.
2. It’s aimed low.
This one seems to have some merit. In this case Graham is saying that Java is intentionally dumbed down, and that ‘Java’s designers were consciously designing a product for people not as smart as them. Historically, languages designed for other people to use have been bad: Cobol, PL/I, Pascal, Ada, C++. The good languages have been those that were designed for their own creators: C, Perl, Smalltalk, Lisp.‘
When people create a product/tool for other people to use, they obviously want their audience to be able to learn it, and Graham seems to argue that by ‘aiming low’ and focusing on ease of use you are probably placing unnecessary limitations on the product you are building. If you were creating based solely on the need to solve specific problems, ease of use would not be as great a factor.
3. It has ulterior motives.
In this case Graham is speaking of Sun’s plan to ‘undermine‘ Microsoft. We could certainly apply some tests of ulterior motives to several new developments in tech over the past several years, but I’d imagine it would be a difficult task to find similar motives in the overwhelming majority of new products. This one is probably, in most cases, not applicable.
4. No one loves it.
Ouch! Every language, every tool, is loved by someone. Remember all those people in #1 above that make up the hype machine? Perhaps by saying ‘I’ve never heard anyone say that they loved Java‘, Graham meant that that no one of any influence or importance loves it. If a product is eschewed by the most widely respected folks in industry, that is a warning sign. When some thought leaders begin to endorse tools they become viable for others to adopt (see alternative JVM programming language adoption by big firms today). Some former Java evangelists professing a love for Scala comes to mind.
5. People are forced to use it.
Being told that you have to use a tool does not make it questionable, but in Graham’s brief description he infers that the anecdotal evidence includes smart people that would have used the tool voluntarily if it were good. This is probably better said as ‘Outside forces with potentially differing objectives force technologists to use it against the techie’s own better judgement.’ It’s hard to argue with that.
6. It has too many cooks.
This one is quite interesting, especially with the changes that have occurred in the industry since 2001 and the emergence of open source as a dominant player in the market. Graham went on to write that ‘the best programming languages have been developed by small groups. Java seems to be run by a committee. If it turns out to be a good language, it will be the first time in history that a committee has designed a good language.‘
Issues with the JCP over the years have been written about ad nauseam. But what would Graham make of other open source developments over the years? I imagine the rebuttal would be that only the highest level members of an open source project are truly the ‘cooks’ he refers to, with the rest of the members merely relegated to chopping and slicing. Maybe not. Being suspicious of multiple decision-makers pandering to multiple masters would be natural, and warranted.
7. It’s bureaucratic.
In this case Graham is referring to the language structure itself and not the leadership. This can be perhaps lumped into #2 It’s aimed low although not in every instance. If a language is ‘aimed low’, you might expect that the designers would try and limit the types of mistakes users could make (see #9 as well).
8. It’s pseudo-hip.
Interesting perspective. I’d argue it was hip. Graham continued, ‘Sun now pretends that Java is a grassroots, open-source language effort like Perl or Python. This one just happens to be controlled by a giant company. So the language is likely to have the same drab clunkiness as anything else that comes out of a big company.‘
I couldn’t help but notice the words Graham uses to critique Java in 2001 are very similar to how Democrats paint the modern day Tea Party (an observation on the language, not a political statement). The real meat of this criticism seems to be that the product is controlled by a large organization, which per Graham would by default make it ‘clunky’, but posing as a much more community-friendly and open option. I’m guessing this element of Graham’s opinion would have been amplified dramatically after the Oracle acquisition. Would hackers feel differently if a big company tool wore the corporate badge proudly?
9. It’s designed for large organizations.
Graham specifies that Java was designed to limit large teams of mediocre programmers from causing damage. This seems very much like reasons #2 It’s aimed low and #7 It’s bureaucratic above. This is probably more accurately categorized as ‘designed for mediocre programmers‘. I would assume that any advanced technologist would probably be less interested in a tool that seems to be created for a lesser engineer. Graham wants only languages for big boys and girls, and most advanced and even intermediate hackers would probably agree.
10. The wrong people like it.
Graham lists the wrong people as ‘suits’ tuned into the hype from #1, big company programmers from #9, and college kids looking to get a job. He feels that all three of these groups change their minds regularly. I’d say the college kids of 2012 appear to be interested in newer technologies (Ruby, Python, functional programming, mobile) that are probably not the core of their curriculum (Java), and in 2001 they were also interested in newer technologies (Java) that were also not the focus of their education (C/C++). Does the interest of college grads in Ruby and Python make those tools the wrong tools, or do today’s college grads have a bit more of a sophisticated hacker palate? What do the suits and big company programmers love today? Tools with ample talent supply, maybe?
11. Its daddy is in a pinch.
Java’s OLD daddy was, but Java’s new daddy buys islands! But this isn’t about Java. The financial standing of the steward of a language or product is certainly a valid consideration to make when evaluating the future viability regarding use in developing a product. But who would be deemed the daddy of open source tools? Individual project owners perhaps? The vendor ecosystem that supports them? The landscape has changed enough since 2001 that this criticism might be less of a factor now.
12. The DoD likes it.
Guilt by association, and Graham calls DoD culture the ‘opposite‘ of hacker culture. In some recent discussions about Java and alternative JVM languages, I’ve seen this discrimination used in reverse, where Java supporters claim that the use of the alternative JVM languages by start-ups is a strike against using the alternative options. The argument is that start-ups are all run by kids and cowboys, so any choices they make can’t be grounded in solid technical judgment. Interesting how two groups, who both probably feel they are above-average technologists, can come up with opposite interpretations.
CONCLUSION
If you made it to the very bottom of Graham’s post, there is a link to an article called Trevor Re: Java’s Cover, which refers to comments by Trevor Blackwell (also a YC partner) about the post. Blackwell classifies programmers as either ‘brilliant hackers‘ or ‘corporate drones‘ with most tools being written for the drones, so hackers need to know the smell tests to decipher quickly which tools are meant for the hacker and which were designed for the drones. Of course, very few of the people Blackwell calls drones probably feel they are in that camp, which just complicates the issues even more.
I feel that Graham’s article is interesting as a time capsule to compare how hackers thought about new tools in 2001 and how they may come to conclusions about languages today. As an investor, I’m sure some of the same smell tests Graham listed would apply to how he evaluates start-ups for potential funding. Whether Graham was right or wrong about Java doesn’t matter at all, but getting a glimpse into his thought process then is quite valuable.
How would the current batch of popular and emerging technologies fair today, using Graham’s microscope?
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Advice From A JUG Leader II – Debate Breakdown
It’s been a week since I posted “Advice From A JUG Leader – Learn a Different Language” and it seems to have ruffled at least a few feathers in the Java community. As the article has been re-posted and bounced around on Twitter, I have had some opportunity to interact with some members of the Java community who have strong feelings about the content. None have called for my death, and the debate has been almost entirely polite thus far.
I think and sincerely hope that the Java community understands that the impetus for writing this article was an observation that many in the Java community are simply not aware of the trends in the industry, and by the time those trends become standards it is too late. These are the people that, if the train does come, never heard it approaching. My purpose is not to predict or encourage the demise of Java, as that should not and will not happen. The Java community is deeply loyal to Java, perhaps even to a fault, and I hope these articles serve as a wake-up call that the most important loyalty should be to your career as a software professional and to neither an employer or language.
I have noticed from these mini-debates is that defenders of Java, at least in my interactions so far, seem to primarily be highly experienced developers that perhaps have the most invested in Java. As I mentioned in my original article, I don’t expect known Java experts to feel any changes. At least a few of the comments seem to come off as rants against youth (“go play your Xbox“?) and startup culture and not a defense of the language’s health itself. I haven’t seen the younger generation of Java pros, but I know they are out there. I don’t seem to see Java enthusiasts attacking faults in the alternative languages or praising Java for a superior feature set.
Some comments seem to admit that Java has some shortcomings just like other languages, but it’s what we have for now. That is good enough for some people – particularly those that have been in Java for a long time – but not good enough for many developers who want to work with the best available. The arguments so far have been, in no particular order:
Argument #1 – Don’t Use Alternative Languages Because The Languages are Unproven, and/or Only Startups Use Alternative Languages
“And, don’t forget, 70% of startups will fail within the first ten years. So, I’m not inclined to base my decisions on the faulty and unproven ability of start-ups to make sound business decisions for themselves.” – Comment from TSS reader, click for full context
Some of the languages are more proven than others obviously, but we can’t ignore the fairly regular news regarding established firms transitioning to alternative languages and platforms or taking a polyglot approach. I would hardly call companies like Twitter, YouTube, foursquare, LinkedIn and Google immature startups at this point. If you are going to argue that there are plenty of other shops that use Java, we all know that. The point is some startups (those most apt to use these alternative languages) have made bad decisions (as have large firms), but to call the languages themselves ‘unproven’ at this point would not be accurate. No guilt by association here.
Businesses don’t make decisions, people do. I don’t think we should fall into the trap of lumping together the decisions made inside of some startups as any proof of language relevance at this point. When a host of startups fail due to their language choice alone, that conversation can be had.
If you were around back in the late nineties there were a lot of technology startups with funny sounding dot-com names. Many of these companies were using a three or four year-old programming language called Java. They could not have predicted that Java would grow to be as popular as it is today.
Note: Python is older and Ruby is about the same age as Java, Scala has been around for 9 years, Clojure for 5 years.
Argument #2 – If You’re Bored With Java, That Is No Reason To Branch Out
“Becoming “bored or frustrated with Java” is a pretty poor excuse for branching out. As a professional, I’m not paid to feel entertained and broadened in my horizons. I’m paid to get things done as efficiently and as well as I possibly can… Go home and play your Xbox to relieve boredom. Don’t make your employer pay for yet another language learning curve so that you feel less bored and frustrated.” – Comment from TSS reader, click for full context
Simply being bored with Java could be enough for someone to look for other alternatives. I think the bigger issue is that technologists who pay attention to developments in other languages are envious of the features that other languages provide. Today, I feel that a smaller percentage of the Java community explore alternative languages based either on less curiosity or less opportunity. As the Java community at large is exposed to these other languages more and more, I would expect you will see many more defectors. The early adopters of Java were the most curious C++ or C developers who were looking for something different and stumbled on Java, and the most curious of Java pros stumbled on these other languages over the past few years.
Argument #3 – The Assumption That Most or All Of These Alternative Languages Will Be Dead In 5-10 Years
“If I’m off learning optional languages, I’m falling short of what I get paid to do. What’s more, I may have decided to do some development in one of the latest and greatest languages that, in a few years, will fall by the wayside, and now I’ve left my employer with a bunch of projects that will have to be re-written into a language that is currently active and supported.” – Comment from TSS reader, click for full context
Many of the early adopters of Java, as I mentioned in my article, have already been exploring some of these alternative languages for some time now. Often they were not initially paid to do so. Could some of these languages be dead in 5-10 years? Sure. Most of the languages I’m thinking of when I talk about alternative languages are already 5 years old, and some much older. Even the young Ruby/Rails combo has been around for over 5 years.
Did people make the same assumption about Java back in the late nineties?
Argument #4 – Look At The Evidence That These Alternative Languages Are Not Being Adopted/Used/Sought After
Some defenders of Java have been pointing me to various statistics as proof that these alternative languages are not being used, not being sought after by employers, or not being adopted. I would cede that none of the current crop are even close to Java in terms of popularity today. I was sent to this link from Networkworld.com that says Java developers are the “most difficult tech pros to land, followed by mobile developers“. I wonder where the demand for mobile developers was three years ago? Would mobile development be a valuable skill to learn at this point?
As a recruiter, I’m also having a bit of a harder time finding Java developers now. One of the main reasons for that is pretty simple – a lot of the people that I know that used to do Java work aren’t interested in doing Java work any more. Over the years I’ve met a fair amount of experienced Java developers that were dying to get a job doing mobile work, Ruby work, Scala work, etc., but I’m not finding too many Ruby or Scala programmers with five years out of school looking for their first Java job. Maybe it’s just me, but I don’t see that…ever.
Another link was given to the Tiobe Index, which is pretty widely used to highlight trends of language popularity. It is based on search engine hits. All indexes like this have some obvious flaws. If you read Tiobe’s Definition, the phrase “Java programming is dead” will actually improve Java’s position in the rankings. So absorb these ratings with that in mind. They measure chatter, which could be positive or negative.
Tiobe Programming Community Index for July 2012
Well, the takeaway from this graphic, for me anyway, would be that Java dropped significantly and Objective-C seems to be gaining popularity dramatically. But this could be some anomaly in a given month.
Tiobe PCI 10 Year Trend
“Java has slid only recently and barely while the much touted JVM languages aren’t even on the radar” – Comment from Dzone.com reader, click for full context
The green line that is Java seems to be trending downward on a fairly regular basis since ’02. I’m not sure I’d refer to a 10 year decline as ‘recent’ in the technology industry. Again, I don’t think the Tiobe index is the ultimate indicator, but I wouldn’t point someone to this statistic to support an argument that Java is healthy.
Objective-C wasn’t listed in 1997, was ranked #46 in 2007, and now stands at #3 on the index. If you had picked up Objective-C a few years ago, say in ’07 when it was not entirely popular, you would probably be doing well today as the demand for iOS work is quite high and the supply of developers is quite low. In ’97, Java was #5 – one spot behind VB and two spots behind COBOL.
Conclusion
The arguments against learning a new language or using a new language in production were probably the same back in the late nineties when Java was still new. People surely came to the defense of C and C++ saying that we didn’t need a new language then. It’s progress and subsequent resistance to change, and in the technology industry change can sneak up on you pretty quickly if you aren’t paying attention.
I feel that many in the Java community may not be paying close attention.
If you were a C++ programmer messing around with applets back in ’96, you’ve already been through this transition once. What I’m hearing now from experienced folks is that these alternative languages are for start-ups, “Trix are for kids!“. I know quite a few gray haired former Java developers that are getting paid to write code in other languages now, and I think they would tell you that the alternative language market isn’t just for kids. Were you using Java in a start-up back in the day – were you one of the kids?
My purpose in writing these posts is to make a certain element of the Java community aware of what is out there, and that in my opinion now is an opportune time based on external market forces to explore other languages. This is not an attack on Java as a language or on the people that choose to write in Java. I’ve dedicated much of the past 12 years to the Java community and I don’t intend to change that now. I expect that I will be involved with Java professionals for several years, helping them to find jobs and scheduling great events for my JUG. I chose to change the focus of my business beyond Java, and my suggestion to Java professionals would be to at least consider and research doing the same.
Advice From A JUG Leader – Learn A Different Language
The cry of “Java is Dead” has been heard for many years now, yet Java still continues to be among the most used languages/ecosystems. I am not here to declare that Java is dead (it isn’t and won’t be anytime soon). My opinion, if you haven’t already heard:
Java developers, it’s time to learn something else
First, a little background as basis for my opinions:
I founded the Philadelphia Area Java Users’ Group in March 2000, and for the past 12 years I have served as ‘JUGmaster’. Professionally, I have been a technology recruiter focused on (you guessed it) helping Philadelphia area software companies to hire Java talent since early 1999. I started a new recruiting firm in January that is not focused on Java, and I’m taking searches for mostly Java, Python, Ruby, Scala, Clojure, and mobile talent. This was a natural progression for me, as a portion of my candidate network had already transitioned to other technologies.
I launched Philly JUG based on a recommendation from a candidate, who learned that the old group was dormant. Philly JUG grew from 30 to over 1300 members and we have been recognized twice by Sun as a Top JUG worldwide. This JUG is non-commercial (no product demos, no sales or recruiting activity directed to the group), entirely sponsor-funded, and I have had great success in attracting top Java minds to present for us.
The early signs
After several years of 100% Java-specific presentations at our meetings, I started to notice that an element of the membership requested topics that were not specifically Java EE or SE. I served as the sole judge of what content was appropriate (with requested input from some members), and I allowed the group to stray a bit from our standard fare. First was Practical JRuby back in ’06, but since that was ‘still Java’ there was no controversy. Groovy and Grails in ’08 wasn’t going to raise any eyebrows either. Then in ’09, we had consecutive non-Java meetings – Scala for Jarheads followed by Clojure and the Robot Apocalypse (exact dates for said apocalypse have been redacted). Obviously there is commonality with the JVM, but it was becoming readily apparent that some members of the group were less interested in simply hearing about JSP, EJB, Java ME or whatever the Java vendor universe might be promoting at the time.
I noticed that the members that sought these other topics and attended these alternative meetings were my unofficial advisory committee over the years – the members I called first to ask opinions about topics. These people were the thought leadership of the group. Many of them were early adopters of Java as well.
It was apparent that many of the better Java engineers I knew were choosing to broaden their horizons with new languages, which prompted me to write “Become a Better Java Programmer – Learn Something Else“. That ’09 article served to demonstrate that by learning another language, you should become a better overall engineer and your Java skills should improve just based on some new approaches. Today I go a step farther in my advice for the Java community, and simply say ‘Learn Something Else‘.
To be clear, the reason I make this suggestion is not because I feel Java as a language is going to die off, or that all companies will stop using Java in the near future. Java will obviously be around for many years to come, and the JVM itself will certainly continue to be a valued resource for developers. The reason I advise you to learn something else is that I strongly believe that the marketability of developers that only code in Java will diminish noticeably in the next few years, and the relevance and adoption of Java in new projects will decline. Known Java experts who are at the top few percent probably won’t see decreased demand, but the vast majority of the Java talent pool undoubtedly will.
The writing on the wall
I think at this point the writing on the wall is getting a bit too obvious to ignore, and you have two forces acting concurrently. First, there is a tangible groundswell of support for other languages. A month doesn’t seem to go by that we don’t hear about a new language being released, or read that a company transitioned from Java to another option. Much of this innovation is by former Java enthusiasts, who are often taking the best elements of Java and adding features that were often desired by the Java community but couldn’t get through the process for inclusion. Java has been lauded for its stability, and the price Java pays for that stability is slowed innovation.
The second contributing factor is that Java has simply lost much of its luster and magic over the past few years. The Sun acquisition was a major factor, as Oracle is viewed as entirely profit-driven, ‘big corporate’, and less focused on community-building than Sun was with Java. The Java community, in turn, is naturally less interested in helping to improve Java under Oracle. Giving away code or time to Oracle is like ‘working for the man‘ to the Java community. Oracle deciding to run JavaOne alongside Oracle OpenWorld may have been an omen. Failures such as JavaFX and the inability to keep up with feature demand have not helped either.
My suggestion to learn something else is also rooted in simple economic principles. I have seen the demand for engineers with certain skills (Ruby, and dare I say JavaScript are good examples) increasing quickly and dramatically, and the low supply of talent in these markets makes it an opportune time to make a move. It reminds me of the late 90’s when you could earn six-figures if you could spell J-A-V-A. Some companies are now even willing to teach good Java pros a new language on the job – what is better than getting paid to learn? The gap in supply and demand for Java was severe years ago, but it seems the supply has caught up recently. Java development also seems to be a skill that, in my experience, is shipped offshore a bit more than some other languages.
Still don’t see it? Remember those early Java adopters, the thought leaders I mentioned? Many of them are still around Java, but they aren’t writing Java code anymore. They have come to appreciate the features of some of these other offerings, and are either bored or frustrated with Java. As this set of converts continue to use and evangelize alternative languages in production, they will influence more junior developers who I expect will follow their lead. The flow of Java developers to other languages will continue to grow, and there is still time to take advantage of the supply shortage in alternative language markets.
Java will never die. However, the relevance and influence of Java tomorrow is certainly questionable, the marketability of ‘pure’ Java developers will decline, and the market for talent in alternative languages is too strong for proactive career-minded talent to ignore.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search even more helpful. You can follow Job Tips For Geeks on Facebook, Twitter, or Google+.
Lessons From a JUG Talk With Eric ‘ESR’ Raymond
(full video of ESR’s presentation from YouTube below this post)
I have been President of the Philadelphia Area Java Users’ Group for 12 years, and as one might expect a typical meeting is geared around a presenter with a slide deck that gives a deep dive into some Java topic. We could hear a case study, an explanation of a tool, tips for programming effectiveness, etc. The JUG has followed this model since I founded the group in 2000, and we manage to get between 75-150 attendees at most meetings.
Last month we held a meeting that was entirely different. I had reached out to Eric Raymond (aka ‘ESR’), who is best known as a leader in the open source software movement and author of The Cathedral and the Bazaar, about potentially speaking to the group. Although ESR is not commonly associated with Java, I thought it would be an opportunity for the group to hear a well-known and respected engineer speak about a topic. ESR suggested that he would do a free-form type presentation, without notes and slides, and simply take questions from the audience to use as improv material. With about 150 engineers in attendance, ESR fielded a fairly wide array of questions on everything from functional languages to open source licensing to coding standards.
So why am I posting this article on JobTipsForGeeks? As a recruiter I am often asked for career advice by my network of engineers, and my answers are always based much more on market trends (supply and demand) and ‘buzz’ around various technologies than on the viability of the technologies themselves. For example, I am well qualified to discuss the adoption of specific languages by software companies in my region, but I am much less qualified to discuss the long-term viability of those adoption choices from a technical viewpoint.
As ESR was asked some of the same questions I am often asked, I thought his answers and insights were an opportunity for the audience to hear a ‘technically-grounded’ counterpoint (or supporting evidence) to the market-based advice I provide to individuals. His specific commentary on functional programming languages and the value of learning them regardless of adoption rate was something I thought was insightful advice for engineers of all levels, and his musings on coding standards and how to obtain management ‘buy-in’ on open source are great tips for navigating at companies that may not be as tech-friendly as others. These are not all specifically ‘job tips’, but I believe there is certainly some value in reading these opinions as you decide on which directions you may take your software career.
The quotes below are ESR’s responses to questions, organized by topic.
ON PYTHON
“Yes, I really like Python. I like it for a very specific reason. I like Python because of all the languages I have ever used, it is the one that maximizes ease of long term maintainability. That is, the ease with which you can read your code six months later. The longer I program, the more convinced I am that that is THE most important metric of a language, bar none… Most of the programming I do these days is in either Python or C.”
ON JAVA
“I still haven’t actually learned Java well enough to do more than a couple hundred lines of programming in it. I don’t dislike Java but I think it is a little over-verbose, it’s become kind of top heavy. So it’s not my first choice, but if I had to write something in Java I wouldn’t go ‘ICK’.
ON C++
“C++ has the exact opposite problem to the virtue I had called out in Python. Long-term maintainability of C++ code, TERRIBLE.”
ON PERL (answer continues from his answer on C++ above)
“OK, the best thing I can say about that is, it’s not as bad as Perl, but I’m afraid that constitutes damning with faint praise. I still like Perl fine and occasionally use it, as long as the program isn’t more than 25 lines long.”
ON GOOGLE GO
“I am sort of gingerly dipping my toes into the waters of Go, Google’s new language… I’ll tell you one concurrency thing I am really pleased by. I have been wondering since about 1971 why nobody took the ball and ran with Hoare’s communicating sequential processes model. So elegant, so pretty, so nice to reason about and 40 years later the Go people picked it up and ran with it. That’s one reason I’m looking at Go. CSP is the basis of their concurrency model in that language which is enough to motivate me to want to look at it some more.”
THOUGHTS ON THE JVM BECOMING MORE GENERAL PURPOSE
“I’m mostly ok with that. I think the JVM has some deficiencies near word length and there are some serious problems with the numerical tower…It needs some work to be a really robust platform, it’s good but not as good as it needs to be.”
ON RUBY
“I’ve dipped into Ruby a little bit, there was a point where I had to modify some Ruby code for a project I was working on, so I think I understand the language a little, maybe not master level. My impression of Ruby is that it has pretty much the same virtues and the same problems as Python, and I might be tempted to switch except that it’s not different enough. Functionally speaking of course, I mean aesthetically there is all kinds of odd little differences. But it’s not different enough from Python to make me move, that’s my impression.”
ON SCALA
“It’s on my list of languages to learn. I have a friend whose judgment I trust who says it is a very good design, and that’s enough reason for me to go look at it.”
ON OPEN SOURCE LICENSING/GPL
“…this is one of my more incendiary opinions, I don’t think we need the GPL anymore…My attitude in general is just use permissive licenses, stop with the viral stuff…”
ON OPEN SOURCE
“If you’re thinking in terms of bringing open source inside the corporation, you’ve already failed. That is already thinking in the wrong direction because you’re trying to figure out how to control and make safe a process that thrives on lack of control and no safety, other than good code review. Instead of thinking about how to bring open source inside the corporation, the right kind of question to ask is ‘how do I start up an open source project that benefits my corporation, build a community, and THEN sell it to my bosses?’. Because one of the iron laws of dealing with bureaucracy is ‘it is easier to get forgiveness than permission’…How do I start an open source project that will interest my bosses, get it viable, and then sell it to them once they have a benefit that they can see?…Show them a benefit. Don’t say ‘we can do this wonderful thing if you authorize me to spend n hours with no obvious physical return’. That is something a manager is always going to say ‘no’ to. What you have to do is show them a benefit. It works much better, for example, to find an existing piece of open source software that is fairly close to solving the business problem and going to your boss and saying ‘you know, this thing already works and already has a user community and I can show you where it’s deployed, give me 50 hours and I can turn it into something that will solve our problem too’. At that point you have a much better pitch, because that’s the kind of trade-off your manager is used to thinking about.”
ON OPEN SOURCING PRODUCTS DEVELOPED IN-HOUSE
“The universal argument that works for that is to say ‘hey boss, how would you like to reduce your maintenance costs?’. Lay off the work on other people so it’s not coming out of your budget. That’s the reason for open sourcing stuff that was developed in-house. The argument for that is cost-spreading and risk-spreading. And you want to put it exactly that way, ‘hey look, I’m going to reduce your bottom-line expenses’.”
PROS AND CONS OF CODING STANDARDS
“My first overarching observation is that the smartest thing you can do is choose a language in which coding standards are not necessary because there’s a uniform style that the language semi-enforces. Yes I have Python in mind. Go also has this property, it’s very difficult to have indent style variations in Go…The smartest thing you can do if all other things are equal is pick a language where you will never have coding standards wars. The reason that that is a high-utility thing to do is, of course, the purpose of coding standards is to maximize readability of the code and long-term maintainability. And yes, I do think that is extremely important… in particular if you are writing in C, the thing to do is pick a coding standard but don’t try and be too anal about it. There comes a point at which the effort to enforce every conformance to every minutiae of a coding standard is causing you more pain and overhead than it is actually worth in reduced maintenance costs.”
THOUGHTS ON LISP/FUNCTIONAL PROGRAMMING
“There’s a can of worms. The first thing you need to know about me in this connection is I’m an old Lisphead…I actually cut my teeth on APL…The result of the first two languages that I learned is I have this mental measure of a programming language’s adhesiveness. A programming language is adhesive to the degree that it sticks to your brain and cannot be displaced from your brain except by a language that is more adhesive. I learned APL first, and then I got exposed to Lisp…My first question was ‘which one is more powerful in a practical sense?’, and yes, yes I know they are all Turing equivalent…So I decided to test the question by writing two toy implementations. One of an APL interpreter in Lisp, and one of a Lisp interpreter in APL…That is why I switched to Lisp, and discovered that Lisp is more adhesive than APL, and it displaced APL from my brain. Nothing has displaced Lisp from my brain. I have not encountered any language that is more adhesive than Lisp. Which is not to say I use Lisp a whole lot, but that it still dominates the way I think about programming.”
ON HASKELL
“I dipped my toes into Haskell, and someday I’ll have to do a significant project in Haskell. But that time is not yet though. I haven’t found anything for which it is better than the tools I’m already using. The problem with languages like Haskell…and I have digested dozens and dozens of computer languages in my time and I used to be a mathematician with a specialty in formal and foundational logic. With all these credentials, Haskell makes my brain hurt. So if Haskell and other pure functional programming languages make your brain hurt, that’s ok. And the thing that worries me about them, is that if they make MY brain hurt, how the hell are they going to make any traction with people who didn’t used to be foundational logicians with a specialization in logic.”
ON FUNCTIONAL LANGUAGES
“My worry is that these are beautiful tools that will never actually achieve mass acceptance because they are simply too hard for most programmers to use. The question is, what is the attraction then? For the class of problems that is easily addressed using a functional language, using functional languages produces solutions that are breathtakingly, devastatingly elegant, beautiful and terse. When the tool matches the problem, there are very few things in the universe more lovely than a properly designed functional program. The issue though, is ‘A’ – that the tools are difficult to comprehend, and ‘B’ – I said ‘when the problem matches the tool’, there are lots of problems that don’t match functional programming language tools because functional programming language tools really want to live in a universe where everything is stateless and all transactions are reversible. Uh oh. You run into problems with those assumptions the moment you deal with messy things like input/output operations…intrinsically not reversible. A lot of the complexity in functional programming languages arises from this unavoidable interface, this energy barrier between the programming language’s internal world of pure logic, statelessness and reversibility and infinite backtracking, and the messy exterior world where we actually have to deal with stateful objects…They are fascinating tools, they are good for some classes of problems, I love them aesthetically. I don’t know if they will ever be more than a small minority preference.”
ON LEARNING FUNCTIONAL LANGUAGES
“Nevertheless, even though these tools may never get huge traction, learn one anyway. When you get deep enough into any functional language, for me it happened with Lisp…there will come a point at which you will achieve Satori, you will achieve enlightenment about how functional programming actually works and your entire universe will lurch sideways and never be quite the same again. And even if you never use a functional programming language for a line of code after that, it will change the way you think, it will change the way you form abstractions, it will clean things up.”
ON JAVA AND PYTHON SEEMING MORE FUNCTIONAL
“Ironically in the case of Python, Guido actually doesn’t like Lisp and his personal preference would be to take the functional constructs out of the language (Python), but every time he does that a bunch of his friends and senior developers, including me, look at him and say ‘you will take away my lambdas when you pry them from my cold dead fingers’.”
PYTHON VS JAVA
“The advantage of Python over Java is that it’s less heavyweight, there isn’t a huge syntactic thicket of declarations and codicils and stuff that from a point of view of a Python programmer is extraneous junk that gets in the way of comprehension. There are languages that are much worse that way, see my rant about C++. Java is a bit too syntax-heavy and cluttered for optimum long-term maintainability. That is my opinion anyway.”
OPEN SOURCE
“We now live in a situation where lots of people can use and enjoy open source tools and an increasing number of people can make a living writing and maintaining them, and that’s a good thing. Do I want to see all software become non-proprietary? It wouldn’t particularly bother me if that happened but it’s not a major objective for me. It doesn’t harm me that other people write proprietary software as long as they don’t try to infringe on my freedom to write software the way I want to. That’s the freedom I’m concerned with protecting. I want people who voluntarily choose to be part of the open source community to be able to continue to be a part of it, and as long that objective is achieved, what other people do is not really of much concern to me.”
Your comments are welcomed below, thanks for reading.
The Future: Polyglot Programmers
I wrote an article three years ago, “Become a Better Java Programmer – Learn Something Else“, that was subsequently picked up by JavaWorld and DZone and received moderate positive and a bit of negative feedback. The negative was primarily aimed at my assessment that “perhaps 80%” of the best local Java talent were familiar with at least one of a set of other languages I listed. Some readers felt the 80% was pulled from thin air (or pulled perhaps from somewhere else), and I concede the number was simply an estimate. And of course the “best local Java talent” line was also subjective, but time has shown I am a good judge of that.
The gist of the article was that the best Java pros that I knew at the time were either fortunate, curious or ambitious enough to learn other languages and platforms. Perhaps they wanted to improve their Java skills, to simply climb a mountain because it was there, to have a Plan B in case Java went downhill (article published June ’09, Oracle/Sun deal announced April ’09), or maybe they knew something I admittedly didn’t know regarding where things were headed.
When I wrote the article, I was offering career advice targeted to Java developers who wanted to continue to be Java developers – learn another language and you should become more effective using Java. I don’t think I had any real instincts that things were going to change dramatically over the next several years. I think the dramatic change is now happening, and it’s time to pay attention if you haven’t been.
The concept of polyglot programmers and polyglot programming isn’t new by any means, and I realize that I’m certainly not the first person or the most qualified person (I may be the tallest) to think or write about the subject. Neal Ford mentioned it over five years ago in a blog post that was quite prophetic.
Think of it this way: Years ago if you were living in Germany, chances are you only spoke German. As travel became easier and business spread to different countries, the world got smaller, and it was advantageous or even necessary to learn new languages because the chances of encountering a non-German speaker were greater. Now many Europeans speak at least a couple languages fluently out of necessity. If you are a bartender in Rome, chances are you know how to say ‘beer’ and ‘thank you’ a few ways. The software development world and the options within it have grown vastly, but the need to be productive or conversant in more than one programming language has not historically been a requirement to get ahead. I feel that has changed, and will continue to change in the years to come.
Since writing my last newsletter I had a couple interesting and vastly different conversations with two technologists that made quite an impression. One was with a very experienced (>10 years) Java programmer who admittedly had no real programming experience beyond the more common Java tools and API’s (some MVC, JSP) and invested little time trying to keep up with industry trends. She had many years with the same company and saw very little change in the tech environment. The second conversation was with a grad student finalizing a Master’s in Comp Sci who had academic, internship, and professional experience (< 2 years) with Python, Java, C++, and Ruby. He was involved in various tech communities and technology was a hobby in addition to being a chosen profession.
Right now, both of these candidates are quite employable, and as you would expect the experienced Java programmer will earn more at present. If I had to buy stock based on future earnings and career advancement in these two candidates today, I’d put all my money and mortgage my house on the grad student. This Java pro is, at this point, not even aware that the world has passed her by.
Historically, most software shops were hung up with hiring requirements that listed minimum amounts of acceptable experience with a technology. I can recall having to explain to a client a few years ago that the only person that might have had the amount of Spring experience they were seeking was Rod Johnson (true story). When I speak to my clients now, it is clear that most are more interested in aptitude over experience with specific languages or tools, as well as an understanding of certain core engineering concepts and principles (perhaps multi-threading or functional programming) in addition to a set of character traits that tend to result in productive engineers.
The metaphor I often use is to liken engineers to athletes. A great athlete can throw a football or a baseball skillfully and is able to use both a hockey stick and golf club to make solid contact with a puck or ball, once the athlete makes some simple adjustments to the chosen object. Likewise, a truly great engineer should be able to succeed using any of several languages, once they understand the syntax and basics.
With the wide variety of robust languages and platforms currently available and ready for prime time, it is hard to imagine that any one or two will become as dominant a force as Java and .Net have been over the past 10+ years. I believe the days of hearing ‘We are a Java shop’ or ‘We are a Python shop’ are behind us. The most innovative shops are mixing technologies based on using the language/platform that is the best fit for the task while also factoring in the experience level of the team members. To remain valuable and relevant, it is becoming necessary to write software in more than one language. Having the ability to produce in more than one language may be a luxury today, but it is becoming very clear that this will be a necessary skill for tomorrow’s engineer.
If you found this post useful, you may find my ebook Job Tips For GEEKS: The Job Search very helpful. You can also follow Job Tips For Geeks on Facebook, Twitter, and Google +.
Job Tips For Geeks 