Discussions

News: Advice from a JUG leader - Learn a different language

  1. 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.

    Edited by: Cameron McKenzie (@potemcam) on Jul 17, 2012 9:53 AM

    Threaded Messages (21)

  2. i definitely feel the device and cloud developers are looking at me now like I looked at the C++ and COBOL developers when Java was first emerging.  I don't know if it's "learn something new" as much as "follow the buffalo." Or in the case of software developers, follow the margin.

    I have seen another trend in some technical people who learned Java in college and don't really progress beyond what their day job requires.  There is no sense of profession or "practice" where one keeps up with the industry and learns new skills.  The early Java adopters did this and in cases still have the passion.  The coders who jumped into the mature Java space don't seem to have this drive.

    Nice to see and article like this.

    Jenga!

  3. I have seen another trend in some technical people who learned Java in college and don't really progress beyond what their day job requires.  There is no sense of profession or "practice" where one keeps up with the industry and learns new skills.  The early Java adopters did this and in cases still have the passion.  The coders who jumped into the mature Java space don't seem to have this drive.

    I think this hits it on the head.  It seems the Java world has two camps (this surely goes beyond Java and even beyond engineering).  One camp that I'd call the 'Java programmers' who probably look at a problem and try to solve it using Java.  The second camp of 'Software engineers' look at a problem and see what tools would be best to solve it, and then solve with those appropriate tools.  People in this second camp have been at least investigating if not already using these other languages for a few years now.  I find it shocking how many people in this first camp haven't even heard of some of the more popular alternative options today, which would be found through a minimal amount of research or even browsing some technology sites.  Some of the 'Java programmers' camp don't even have knowledge about things within the Java ecosystem that would make them more marketable.  If you've been around Java for 5+ years and you haven't played with, say, Spring by now, it's a bit surprising.

    The time is now, based on market conditions.

  4. After you play with Spring be sure to put it back and don't leave it in your code.

     

  5. Aww such ignorance[ Go to top ]

    That proves thw point! Problem is not the language but the lack of skills solving the problems we face. Sometimes there might be other solutions that are better fit than Java BUT this will only marginally improve the overall solution to the customer. If you plan for the customer to support a system i 10 years you better stay with a stable environment and that is probably NOT one of the mentioned languages. Ask a betting firm for the odds of finding a Ruby developer and a Java developer 2022 .. Rememeber, someone has to support the crap you write no for the coming 10+ years probably and if its hard to find odd JVM-language developers now imagine how hard it will be with a dead language in 5 years from now.

    Dragging Spring into the discussion only proves that what we need is better developers, not other languages.

  6. Aww such ignorance[ Go to top ]

    If you plan for the customer to support a system i 10 years you better stay with a stable environment and that is probably NOT one of the mentioned languages.Ask a betting firm for the odds of finding a Ruby developer and a Java developer 2022 .. Rememeber, someone has to support the crap you write no for the coming 10+ years probably and if its hard to find odd JVM-language developers now imagine how hard it will be with a dead language in 5 years from now.

    Curt - Don't you think people were saying this exact same thing about Java in say 1998? 
    Before the Java ecosystem was mature, companies were reluctant to use Java based on the cost of Java talent.  I remember working with some companies back around 99 that had to pay ridiculous sums of money to hire Java talent because they were so scarce.  In a relatively short time, Java became a very mature and stable platform, and now it is everywhere with developers being much less scarce (very good developers, as you say, are always harder to find).  There is obviously a trend now of new languages being developed, functional programming being a larger player, and DSL's that weren't a big thing when Java was taking off. 

    Ask a betting man for the odds of finding a Java developer or a Ruby developer in 2022, you say?  Time machine back to '98, and you may have heard "Ask a betting man the odds of finding a Cobol developer or a Java developer in 2012?"  It's impossible to predict the future other than to know that things are going to change.  Java developers will be around in 2022 just as Cobol and VB developers are still around today. 

    Unfortunately, the developers in other 'dead' languages that didn't see the change coming quickly enough were stuck with low demand skills and had to retool and get in line behind those that saw the change coming (or just go lucky as often happens).  Odd JVM-language developers is a difficult skill to find, just like Java was back in '98, which is why I think now is an opportune time to take advantage of the short supply by learning a different language and make yourself marketable. 

  7. I do agree and I don't[ Go to top ]

    Dave,

    I appreciate your approach and sure, some things are better solved using other languages if you count lines of code but honestly, what customer cares about the lines of code? You might argue that you solve some problems in less lines of code using, say, Scala, but I argue that this is just a (small) part of the problem from the customer point of view. What's more important is the maintenance of these lines of code in 10 years time and, like it or not, Java is the Cobol of the nineties and yes, some of the other JVM languages MAY still be around in 10 years but Java knowledge certainly will.

    I see this discussion more as a (recurring) sign of frustration of lack of new "things" coming up. I have in my profession since early eighties met more "developers" eager to find some problem to adapt to a new technology than a serious, unbiased, will to solve a customer need that will last for the lifetime of the problem. I claim, there is no customer processing need that is not fulfilled by ANY major language today. If you can't express your design effectively in an object oriented language like Java then you should consider to improve your development skills.

    Having said that, there are "nice" things missing in Java and I, as you, mistrust the intent of Oracle but I belive that the community is large and active, and the customers will not accept Java to change in even the far future so I'll bet on Java for the coming years any  day.

    Dave, you know that new languages and technologies will pop up from time to time and we developers will find new ways to solve our customer problems and I really agree on your urge to teach new skills but what I don't agree is that those that haven't learned basic development skills split their concentration on yet another language. Those that can and should expand their toolbox already have - as you said!

    Curt, Java and Ruby where it fits!

  8. I do agree and I don't[ Go to top ]

    Dave,

    What's more important is the maintenance of these lines of code in 10 years time and, like it or not, Java is the Cobol of the nineties and yes, some of the other JVM languages MAY still be around in 10 years but Java knowledge certainly will.

    Agreed, Java certainly will still be around in 10 years, just as Cobol is still around now. 

    I see this discussion more as a (recurring) sign of frustration of lack of new "things" coming up. I have in my profession since early eighties met more "developers" eager to find some problem to adapt to a new technology than a serious, unbiased, will to solve a customer need that will last for the lifetime of the problem.

    I agree that there is certainly an element of engineers who rush to use a technology not based on fit but on their desire to do something different.  I often tell more junior developers that there was a time around when EJB first came out that a noticeable number of my candidates were only looking for jobs with companies that used EJB, and some companies used EJB just to say they used them or to attract talent.  That didn't turn out so well.  So I agree, you will find certain camps of people who are willing to sacrifice need for some other 'cool' factor.

    I claim, there is no customer processing need that is not fulfilled by ANY major language today. If you can't express your design effectively in an object oriented language like Java then you should consider to improve your development skills.

    Using this logic, we would never need any new development tools or languages.  We want better developers, but there can only be so many people at the top percentiles of ability in any profession.  New tools and languages serve to make the product better (faster, more useful, etc.) or make the developers more effective and efficient.

    Having said that, there are "nice" things missing in Java and I, as you, mistrust the intent of Oracle but I belive that the community is large and active, and the customers will not accept Java to change in even the far future so I'll bet on Java for the coming years any  day.

    If there are things that developers want that are missing in Java, Java can either include those in future releases (assuming they can get past the process).  But what is the harm in people taking the best of Java and other languages, improving upon the deficiencies, and making it a 'new' language?  Any new version of Java that includes significant changes will be different than the last version of Java, so at that point you are only protecting the Java 'brand' (which many developers would argue is damaged anyway, partly due to the Oracle association that you mention and that I mentioned in my post).

    Dave, you know that new languages and technologies will pop up from time to time and we developers will find new ways to solve our customer problems and I really agree on your urge to teach new skills but what I don't agree is that those that haven't learned basic development skills split their concentration on yet another language. Those that can and should expand their toolbox already have - as you said!

    Agreed (on most).  I would suggest that one way to get better development skills, regardless of what language you are using, is to learn a new language.  I firmly believe someone who only knows Java will become a much better engineer by learning another language - they will become a better Java engineer (long run) as they will learn new paradigms, and they will become a better overall engineer.  To use a geek metaphor, playing a certain video game for hours on end makes you better at that game, and also at gaming in general. We do need better and more engineers, but why limit them to the current (or past) set of tools.

    The demand for other skills is increasing, Java will always exist but it seems to be fading (years ago this article would have 50 comments by now, but what I'm saying isn't that controversial anymore).  As I said in the article, from a markeatability perspective I think learning a new language is critical for most Java talent at this point.  We can agree to disagree, and only time will tell.

  9. Relax[ Go to top ]

    With programming languages popping up like mushrooms and equally fast melting like snow under the sun, an element of practical use in everyday projects would spark more interest I think.
    In my company we've for instance tried GWT on a small project, but as time progressed it became clear that for large products the effort required to keep it up to date with the latest external dependencies wasn't worth it. Play with your toys all you like, but just don't let the customer become the victim of it all.

    And I also don't see why you would want to duplicate part of your codebase across multiple languages, because that's what you inevitably would have to do. I then prefer the reusability in one stable language, because over engineering interoperability between them sounds like providing a solution to a problem that doesn't exist.

    I myself learned a variety of programming languages (from Haskell to Pike) but after you've learned the concepts behind them, their relevance just diminishes if you're not able to use them regularly. And I highly doubt any of those make me more marketable. So I think the line between helpful and a waste of time is a thin one to walk. As for myself, I just learn a language when I need to, and I for instance haven't had a need for learning Spring yet.

    Don't worry, the languages of today will become legacy. But the languages of tomorrow will stick around long enough for you to learn them and not miss the boat. Once you see many job advertisements appearing for certain technologies that you would like to apply for, your interest will shift naturally and organically towards them. No point in learning stuff you'll never use for real.

     

  10. Relax[ Go to top ]

    And I also don't see why you would want to duplicate part of your codebase across multiple languages, because that's what you inevitably would have to do. I then prefer the reusability in one stable language, because over engineering interoperability between them sounds like providing a solution to a problem that doesn't exist.

    Not sure I follow this line of thinking about having to duplicate your codebase?  My suggestion was just for Java developers to learn a new language, I never intended that they would rewrite all the apps they've already written in something else.  That isn't very likely.  I believe that Java experience is going to be less valued in the future relative to talent in other languages, as alternative languages become more popular for new projects.  We already see this in several languages as I'm sure you know.  I like to think that they are all engineers at the end of the day, but the skill set matters to hiring companies (at least to some degree) and all skills are not valued equally due to supply and demand.



    I myself learned a variety of programming languages (from Haskell to Pike) but after you've learned the concepts behind them, their relevance just diminishes if you're not able to use them regularly. And I highly doubt any of those make me more marketable. So I think the line between helpful and a waste of time is a thin one to walk. As for myself, I just learn a language when I need to, and I for instance haven't had a need for learning Spring yet.



    You really don't feel that learning Haskell made you a better programmer overall, even if you don't use it everyday?  If the answer is yes, I certainly accept that, but I find that most of the people I've dealt with seem to have an epiphany after coding in a new language (whether for money or just on their own).  As an aside, the other thing I've noticed that seems to really get developers to feel like they learned something significant is when they prep and study for a certification.  I find that the certification itself has little value, but the studying to get it seems to really benefit the developer.

     

    Don't worry, the languages of today will become legacy. But the languages of tomorrow will stick around long enough for you to learn them and not miss the boat. Once you see many job advertisements appearing for certain technologies that you would like to apply for, your interest will shift naturally and organically towards them. No point in learning stuff you'll never use for real.

    I think once you see tons of job listings for a language, you're too late to take advantage of the supply and demand gap (which, as I'm saying, is what makes this an ideal time to learn something else - it's not too late nor is it too early IMO).  I'm sure lots of developers in other languages wished they had jumped to Java a bit earlier to take advantage of the early demand.  I've got clients now that are training Java developers in other languages (Ruby, Scala and Clojure recently), so they are getting paid to learn a language that interests them and that they will get to use every day.  This may be the exception to the rule right now, but you'll see more of this in the years to come as the alternative languages gain more ground.

     

  11. Re[ Go to top ]

    Not sure I follow this line of thinking about having to duplicate your codebase?  ...  I believe that Java experience is going to be less valued in the future relative to talent in other languages, as alternative languages become more popular for new projects. 

    When I start new projects, I normally draw on the common components already present in the ecosystem of the company. So for new projects to start using new technologies, some of the existing logic will need to be ported. Adapting new technologies for this reason will always be slow. And I consider that wise rather than being inflexible.

    And of course the landscape will slowly change, but I believe it to be gradual in order to not destroy capital and invalidate current investments.



    You really don't feel that learning Haskell made you a better programmer overall

    Absolutely, you learn insight in the design of programming languages and in the field of software engineering overall.

     

    the other thing I've noticed that seems to really get developers to feel like they learned something significant is when they prep and study for a certification.  I find that the certification itself has little value, but the studying to get it seems to really benefit the developer.

    That's an interesting one. I think you are right. That does work well as an incentive, putting some pressure to get it up to a certain level. Good way to make it relevant.

     

    I think once you see tons of job listings for a language, you're too late to take advantage of the supply and demand gap 

    If you're good, you'll always be scarce. The first time I had to work with J2EE it was already well established, and I was hired while they perfectly knew I had no experience in that field. I quickly read the books, tried a few things out and was able to never disappointed anyone.

     

    an ideal time to learn something else - it's not too late nor is it too early

    Any time is a good time to learn something new, I agree. Just be selective as to what you learn, because not every 'the next big thing' will be worth learning.

     

  12. Dilettantism[ Go to top ]

    Toward the end, I feel that the author finally stumbles across the real reason that so many Java developers gravitate toward other languages, when he states, "and are either bored or frustrated with Java." If this is the reason, then it speaks poorly of the developer because it indicates s/he is simply another ADHD dilettant, who prefers breadth over depth of knowledge.

    Yes, it's hard to truly master a single language, plumbing its depths so that any problem can be solved with it. In an age where Googling for an answer is so easy, one can often come upon a great solution to a dilemma, but it's in another language. Is the solution to extol its virtues and complain that it can't be done exactly the same way in Java? Or, is the reality that the "code by Google results" developer was just too lazy to master Java properly?

    Now, are there times when other languages may have a legitimate role in one's architectural stack? Sure! This can be found in client side development, where Java has long fallen short. For many years, I used DHTML, AJAX, Adobe Flash, and later Flex, to build the client UI. But, after being burned by companies, who either couldn't conform to W3C standards or who kicked their product out the door to go live with the neighbors, I have returned to Java on the client side because I know it (Java) will be there long after the Johnny-come-latelies have packed it up and gone home. Thankfully, new frameworks, such as ZKoss, are coming along with a robust component set, which doesn't require the client to have Java installed. And, that makes Java much more viable on the client.

    The bottom line, for me, is that, breadth is inversely proportional to depth. And, the less depth a person has in any one language, the more likely it is that the developed code will be inefficient. Why? Because there will simply be things that the developer didn't understand about his base language because s/he was spread too thin by trying to load up the resume with all the languages s/he "knows."

    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. 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.

    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.

  13. Dilettantism[ Go to top ]

    Toward the end, I feel that the author finally stumbles across the real reason that so many Java developers gravitate toward other languages, when he states, "and are either bored or frustrated with Java." If this is the reason, then it speaks poorly of the developer because it indicates s/he is simply another ADHD dilettant, who prefers breadth over depth of knowledge.

    I would hardly say that the Java pros that became bored or frustrated with Java and decided to create other languages are dilettantes, at least not with a negative connotation.  Bored is one thing, but frustration with the language is something that most in the Java community will not deny.  Significant updates and changes to Java come much slower than most developers would like to see, which again is the blessing of stability and the curse of slow progress.  This frustration is why we have other languages that are popping up, and if I were a betting man I'd say these new offerings are going to gain some traction very soon (with newer companies especially) and cut into Java's share.  All the start-ups were doing Java work back in 99-00, and lots of start-ups are not only steering away from Java, they are actually bragging about it.  I've had at least a few clients tell me specifically that they are virtually 'Java-free' as some badge of honor.

    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. 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.

    I would say that you are paid to be a software engineer, and if you are unhappy with the language that you are using you should find work somewhere that uses the language that you'd like to use (or convince management to consider your language of choice).  I'd argue (as I did in the linked post "Become A Better Java Programmer") that you spending time learning a new language would make you more effective with Java.  You may disagree, but in my many years of experience with my network I've never heard otherwise. 

    Being loyal to an employer that is not using technologies that will help your future marketability is admirable, and also incredibly foolish from a career perspective (unless you are certain that is where you will retire, which is often also unrealistic).  In many cases that i've seen the price you pay for that same loyalty is decreased marketability for your skills.

     

  14. Some Interesting Facts About That[ Go to top ]

    Bored is one thing, but frustration with the language is something that most in the Java community will not deny. Significant updates and changes to Java come much slower than most developers would like to see, which again is the blessing of stability and the curse of slow progress. This frustration is why we have other languages that are popping up, and if I were a betting man I'd say these new offerings are going to gain some traction very soon (with newer companies especially) and cut into Java's share. All the start-ups were doing Java work back in 99-00, and lots of start-ups are not only steering away from Java, they are actually bragging about it. I've had at least a few clients tell me specifically that they are virtually 'Java-free' as some badge of honor.

    I would suggest that all these new languages you see cropping up have more to do with people wanting to create a legacy for themselves, and not because it does something Java can't. 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.

    Being loyal to an employer that is not using technologies that will help your future marketability is admirable, and also incredibly foolish from a career perspective (unless you are certain that is where you will retire, which is often also unrealistic). In many cases that i've seen the price you pay for that same loyalty is decreased marketability for your skills.

    Interestingly, if I go to indeed.com, and punch in "Java developer" and my own home of Salt Lake City, I get 250 listings (25 of which are over $100K). Last year, you would have pulled up over 500 listings. Do the same for "Scala developer", and you get 1 listing. Replace that with "Ruby developer" and you get 23 listings with 5 over $90K.

    I'm thinking I like my marketability as a Java EE developer. And, it's also worth noting that a lot of these left field language shops will accept Java experienced professionals as applicants, and will not count it as a negative if that's what they used the majority of the time. But, the reverse is not true. In other words, if I'm interviewing an applicant that lists several languages, I'm going to ask, "What percentage of your time was spent doing Java?" The more you spend on other languages, the less you can respond was spent on Java, which makes you less attractive to me as a candidate.

  15. Some Interesting Facts About That[ Go to top ]

    I would suggest that all these new languages you see cropping up have more to do with people wanting to create a legacy for themselves, and not because it does something Java can't. And, don't forget, 70% of startups will fail within the first ten years.

    All the new languages are just ego driven?  There certainly are egos in the industry, but to suggest that new innovation is only to get famous or be remembered seems far-fetched.  Regarding start-up failure, 10 years is a lifetime in this industry.  I'm not sure of the source of those numbers, but I would have thought the fail rate would have been higher.  Regardless, companies have failed using any host of languages. 

    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.

     

    Start-ups don't make business decisions.  Companies don't make business decisions.  People do.  If the founders of Google leave today and start a start-up, are you going to have some preconceived notion that those decisions will be 'faulty and unproven'?  Stereotyping start-ups as places that people make unsound business decisions is pretty common these days, but let's focus on the people who make decisions.

    Interestingly, if I go to indeed.com, and punch in "Java developer" and my own home of Salt Lake City, I get 250 listings (25 of which are over $100K). Last year, you would have pulled up over 500 listings. Do the same for "Scala developer", and you get 1 listing. Replace that with "Ruby developer" and you get 23 listings with 5 over $90K.

    So Java jobs are done 50% in the past year - does that somehow support the argument?  Of course these languages haven't caught up to Java yet, I hope I wasn't seen as suggesting that these jobs are plentiful now.  If you don't see the growth in the popularity and adoption (adoption tends to lag behind popularity) of alternative languages and functional programming, I'm not sure what to tell you. 

    I'm thinking I like my marketability as a Java EE developer. And, it's also worth noting that a lot of these left field language shops will accept Java experienced professionals as applicants, and will not count it as a negative if that's what they used the majority of the time. But, the reverse is not true. In other words, if I'm interviewing an applicant that lists several languages, I'm going to ask, "What percentage of your time was spent doing Java?" The more you spend on other languages, the less you can respond was spent on Java, which makes you less attractive to me as a candidate.

    Yes, the alternative language shops will often train Java talent - I know I've mentioned that in a few places, not sure if TSS was one of them.  I certainly understand that you may ask people how much time they have spent with Java if they are working in multiple languages.  I'd encourage you, as a responsible manager, to 'tech them out' and see how their engineering mind works.  In my experience, and this is perhaps just anecdotal (though I sincerely doubt it), the best Java engineers are playing with other languages to some degree already.  Find one top engineer who has a main focus on Java that isn't playing with another JVM language at this point.  Run the list of the best Java thinkers you can and see if any are talking about languages other than Java.  I think the results of that research will cause any Java engineer to think twice.

  16. Re[ Go to top ]

    frustration with the language is something that most in the Java community will not deny

    I personally really don't care if it's Java 5, 6 or 7 (but I can't live without generics). The rest is mostly syntactic sugar, and any limitations in API normally is countered by having common components in the codebase or using one of the many open source projects available.

    An to be honest, I'm afraid what for instance lambda expressions would bring. Yes very convenient and powerful when used correctly, but devastating when abused by less capable programmers. I think some limitations are actually protecting us from bad practise.

  17. I too am a "JUG" leader (http://wjpg.ca), however my JUG is a "JVM Programming Group".  I purposely chose JVM over Java because the JVM offers so much more these days than just Java.

    I started my group not as a recruiting vehicle (in fact we have strict policies against using the group for recruiting purposes), but rather to

    a) introduce developers to technologies they aren't exposed to during their 9-5 job, and
    b) form a sense of community in our city, something which was drastically lacking.

    Since starting the JVM group last year, we've had everyone from Ruby, C++, Python and of course Java developers attending.  Employers love the group because we provide free training, and get their developers excited about new technologies.

    Java is not dead, and you can't even say Java is stagnant anymore (http://tataryn.net/2011/11/java-is-not-the-new-cobol/).  Take today's Project Coin features in Java7 coupled that with Java8's lambdas and defender methods and the result is: Oracle is doing a great job of keeping the language relevant while isolating their enterprise users from binary compatibility issues. The lambda syntax you write for your Java 8 source code, will compile down to byte-code which can run on Java7, Java6, Java5, etc...  Anyone can write a new language, with every bell and whistle in the book, but can they maintain binary compatibility between versions?  That's an accomplishment we should be praising.

    So I so realize your problem (although I don't sympathize), you are a recruiter and Java-only presentations aren't putting bums in the seats anymore so your talent pool is drying up and perhaps LinkedIn charges too much for your tastes.  So here is my advice nonetheless: You've pivoted your business, why not pivot your JUG too?  Java developers would love to learn new languages, especially those compatible with the very code they've written at work. It's easier to convince their pointy haired boss to use Scala/Clojure/Groovy for a few components since they'll be able to leverage the leagues of code already written in both the OSS and enterprise ecosystems.  And if they learn that new technology on their own time via a JUG, all the better for all parties.

     

  18. I too am a "JUG" leader (http://wjpg.ca), however my JUG is a "JVM Programming Group".  I purposely chose JVM over Java because the JVM offers so much more these days than just Java.

    Craig - Very cool, I expect more JVM groups, and I think the fact that you chose to be a JVM group and not just a Java group proves some of the points I'm trying to make, no?  I think learning a different language, particularly some of the other JVM languages, is a good thing to do right now.

    I started my group not as a recruiting vehicle (in fact we have strict policies against using the group for recruiting purposes), but rather to

    a) introduce developers to technologies they aren't exposed to during their 9-5 job, and
    b) form a sense of community in our city, something which was drastically lacking.

    Just to be clear, my JUG is not a recruiting vehicle.  Most of the membership met me first as a recruiter and joined after working with me.  We, too, have strict policies against recruiting and sales presentations.  I think none of my members would suggest that my group is at all a recruiting vehicle.

    So I so realize your problem (although I don't sympathize), you are a recruiter and Java-only presentations aren't putting bums in the seats anymore so your talent pool is drying up and perhaps LinkedIn charges too much for your tastes.  

    To be frank, Craig, you couldn't be more wrong about these statements here.  You don't know me and made some assumptions based on my post, but I'll clarify for you.  I think part of the problem is the broken relationship between recruiters and technologists.  I'm working hard to change that. 

    I didn't write this article because I have a 'problem' - far from it.  My business is doing quite well actually and I reached my annual goal in June.  My JUG is equally successful, where we've had between 90 and 150 attendees at each meeting this year, and for the past several years I regularly get over 100 attendees at each meeting.  There are not many JUGs in the world that can claim that kind of attendance (from what I've been told), and I don't see in the article where I ever mentioned declining attendance at meetings?  I'd argue I have one of the healthier JUGs around, at least based on what my past speakers have told me. 

    I've run the group for 12 years.  Twelve years.  How many JUG leaders have come and gone since then?  If all I wanted to do was get my name out there, I could have quit running it 7 years ago (meeting attendance is great, but we aren't exactly getting as many new members as we were back in the day).  My talent pool is also just fine, thanks for asking.  :)

    Again, my reason for writing this article is not based on any problem that I, my JUG, or my business have.  I feel there is a segment of the Java community that is not seeing the signs that they may want to proactively invest some time into learning a new language, based on the high demand for these alternative languages (that you have even chosen to include in your JVM group) and on the signs that are out there.  I am sincerely trying to make the Java community aware of what I feel is coming, and to be prepared for it.  If you question my motives, that is your choice as someone who knows nothing about me.  I think my network of technology professionals would stand behind my ethics and reputation.

    So here is my advice advice nonetheless: You've pivoted your business, why not pivot your JUG too?  Java developers would love to learn new languages, especially those compatible with the very code they've written at work. It's easier to convince their pointy haired boss to use Scala/Clojure/Groovy for a few components since they'll be able to leverage the leagues of code already written in both the OSS and enterprise ecosystems.  And if they learn that new technology on their own time via a JUG, all the better for all parties.

    Craig, I really need to ask now - did you read the article or just the title?  I sincerely don't mean that as an insult, but based on this question I have to ask.  If you read the article, the JUG has been pivoting for several years now.  6 years ago we did our first venture outside of pure Java (this is mentioned in my article). 

    I appreciate your comments and I sincerely hope I've cleared up a few serious misconceptions.  If people don't choose to listen, that is their choice - these are just my opinions as someone who has spent 12 years with the Java community.

     

  19.  

    Craig, I really need to ask now - did you read the article or just the title?  I sincerely don't mean that as an insult, but based on this question I have to ask.  If you read the article, the JUG has been pivoting for several years now.  6 years ago we did our first venture outside of pure Java (this is mentioned in my article). 

     

    I did read the article, I didn't really see where you pivoted your JUG other than allowing a few non-java meetings.  The website seems to indicate its still Java user group.

    Sorry if I came off as rude, it's been my experience that when recruiting companies start up JUGs it's for ulterior motives. I guess I shouldn't paint with such a broad stroke.

  20. Craig - No worries, I get that quite a bit from technologists.  It's more a function of the recruiting industry being seen in a negative light, and often that reputation is deserved.  I knew that starting the JUG wouldn't hurt my business obviously, but I started the group at the suggestion of other Java professionals who thought it made sense since I knew more Java pros than most other people would.  We haven't officially made any announcements that the JUG is open more to JVM topics, but our future content will surely have some non-traditional elements.  There are active local groups for many other languages and a functional group as well, so we also try not to step on too many toes.  Good luck with your group!

  21. Mother, Jugs, and Speed[ Go to top ]

    As one who has attended Dave's JUG meetings in the past, I'd say he has done a great job for Java developers.  This article in TSS is inline with his style of being helpful to the Java community - for a long time. He has street cred.  I go to the JUG meetings to help my day job and so does he but he never talks about his.  

    Back to the article.  He's being uncomfortably objective in his advice maybe. And a reader for this site my have the initial reaction that a recruiter doesn't really care - but Dave really does.  I was able to read the article and not be jaded.  In the end, he wants rates to stay up as much as I do and that's the reason for the article.

  22. Dave has posted a second installment of the new JVM language debate on his blog. Check it out here and let us know where you stand.