Skip Ribbon Commands
Skip to main content
SharePoint
  • Apex |
    • Blog-JavaTipsandTrends

Visit the main blog page.

Java Tips and Trends from Skill Experts

August 2017- By Venkat Subramaniam and Ken Kousen

Java has been and remains to be a top technology skill set amongst our contractors and for our clients. We asked two of our frequent speakers and Java experts, Venkat Subramaniam and Ken Kousen, a few questions on what’s changing and what’s staying consistent and career tips for succeeding in the space.

Venkat Subramaniam is an award-winning author, founder of Agile Developer, Inc., creator of agilelearner.com, and an instructional professor at the University of Houston. He has trained and mentored thousands of software developers in the US, Canada, Europe, and Asia, and is a regularly-invited speaker at several international conferences. Venkat helps his clients effectively apply and succeed with sustainable agile practices on their software projects. Venkat is a (co)author of multiple technical books, including the 2007 Jolt Productivity award winning book Practices of an Agile Developer. You can find a list of his books at Looking for your next career opportunity? agiledeveloper.com.

Ken Kousen is a technical trainer, software developer, and conference speaker specializing in Java and open source topics, including Android, Spring, Hibernate/JPA, Groovy, Grails, and Gradle. He is the author of the O’Reilly books “Modern Java Recipes” and “Gradle Recipes for Android,” as well as the Manning book “Making Java Groovy.” In both 2013 and 2016, he was awarded JavaOne Rockstar status. He is currently the President of Kousen IT, Inc., based in Connecticut.

1. What are the top two to three technologies within the Java space you think developers should be starting to learn?
Venkat: Functional and reactive programing. Java had predominantly focused on imperative style of programming in the past. Most mainstream languages, including Java, have now adopted the functional style of programming. Embracing functional style is not a mere syntax change, it's a paradigm shift. Programmers need practice to think declaratively and to use function composition.

Reactive programming has slowly gained traction and a number of Java based libraries and frameworks are beginning to provide reactive APIs. Learning about stream based programming, how reactive programming nicely extends from functional style of programming, and how it differs from the Java 8 stream API can help us better make use of reactive libraries and tools in our applications.

Ken:Java 8 changed how Java code is designed and written. The addition of functional concepts like lambda expressions, method references, and streams makes it possible to write simpler, more declarative code that can often be easily changed to run in parallel. The Java industry is rapidly adopting the new idioms, and it's important for all Java coders to at least learn how to read and interpret them.

The big change coming in Java 9 (scheduled to be released September 21, 2017) is the addition of the Java Platform Module System, implemented in the Jigsaw project. Modularization will have significant ramifications in the future. It remains to be seen, however, how quickly the new approach will be adopted by the industry. It's a good idea to become familiar with the concepts so you'll be ready when the switch to the new version happens. My new book, _Modern Java Recipes_, covers these topics and will be published by O'Reilly Media in August.

On a more general note, the switch from traditional monolithic web applications to smaller, cloud-based microservices is also well underway. Newer tools like Spring Boot make it easier to create and deploy small, self-contained services, and that architecture is taking over the industry for good or ill. These services are often designed to simply produce and consume JSON data, so that they can support both mobile apps and web front ends based on JavaScript MVC frameworks like Angular, React, and so on. It's a good idea to become familiar with the principles of REST-based and reactive approaches, even if your company hasn't yet adopted them. It's a good bet they will at least consider them in the near future.

2. Do you think organizations value certifications for programmers? If so, what would be a couple of the main ones to consider?
Venkat: I am not a fan of certifications and place very little value in them. Intentionally, I have zero certifications. Far too many certified developers lack practical problem solving skills and programming ability. There are better ways to evaluate the capabilities of candidates than looking for a list of certifications they hold.

Ken: The value of certifications used to be much larger than it is now. In the late 90's and early 2000's, studying for a certification gave you a way to demonstrate both a serious level of commitment to a particular technology and insight into what the creators of that technology consider significant. Unfortunately, too many people took the factory approach of just cramming for the exams without actually learning anything (which is actually the hard way to pass those tests, but so be it), thus devaluing them for everybody.

Certifications can still have value, but the days of getting a raise (or even a job offer) just for taking a test are over. They're not bad if your purpose is to learn a technology beyond just the parts you encounter in your job, but don't focus only on getting certified. Certifications are not bad resume fodder, but you may need to overcome a bit of skepticism in the community when you get to the actual job.

The other problem with certifications is that they tend to have difficulty keeping up with new trends in the industry. It's fine to look at some of the Oracle Java certifications, but there's nothing widely accepted in the mobile space, or for reactive streams, or for any of the alternative languages (Groovy, Kotlin, Scala, Clojure), etc.

If you're considering studying for a particular certification, the easiest way to assess its value is to ask your co-workers, or local user group members, or contacts you've made in the industry.

3. What would be your top piece of advice to a junior programmer trying to advance their knowledge base and programming competencies to the next level?
Venkat: Find a mentor and be frequently critiqued. There are multiple better ways to design and write software and there is rarely one best way. Finding a good mentor who is willing to review code and provide constructive criticism to improve is very critical for the transition of that junior programmer into a good developer.

Ken: There are two ways senior (i.e., "old") programmers tend to answer this sort of question. One is to recommend that you study the deep, foundational programming languages, like Lisp or Haskell, to really learn how the underlying concepts of computer science are handled. That's certainly valuable, and if you want to do so, that's a great idea, but there's a time problem with that. There are two facts of life in our industry: there's never enough time to learn everything you need, and the subjects you've already learned keep changing. That means we spend our careers prioritizing, deciding what's worth our time (and, as you get older, what's worth our energy). It's sometimes hard to justify learning a language that you know your company does not employ or support, even though the long-term benefits to you may be significant.

The other recommendation senior developers often make is that you study the basic principles of computer science, like fundamental algorithms and data structures. This is definitely helpful if you, like so many people in software, were a career changer and not in a technology field from the beginning. I'm going to assume, however, that as a working developer you are already learning the basics as part of what you need to be productive.

Instead I'm going to take a different tack on this question. I'm going to suggest that one of the most productive activities you can do for yourself is to work on your written and oral communication skills. The more senior you become, the more you realize that solving bigger problems largely involves persuading co-workers that you know what you're talking about and can explain your reasons effectively. This also helps with the non-developers in your organization, who can have an enormous impact on your career.

One way to improve those skills is to get involved in your local Java (or other) user groups. User groups are always looking for speakers, and while you may not think you have anything to contribute, even talking about experiences during a particular project is valuable. Describe the problem, the technologies assessed, how you went about dealing with the issues that came up, and so on. Just learning how to talk to an audience is a very valuable skill.

Another side effect of speaking to groups is that it will help you acquire something else you really need -- allies. The job of a developer tends to be a solitary one, and many developers are introverts, but nobody succeeds alone.

One of the most necessary things you can do for yourself is to build a network of reliable contacts in the industry that you can use for questions, recommendations, or even just general discussions about what's hot these days. Running a simple "lunch and learn" at your company is another way to proceed. There's an old saying that you are the average of the five people you interact with the most. Make sure that the professionals in that network make your life better.

4. If you're looking to advance into a team lead or architect role, what should you start doing now?
Venkat: Diversify and get very hands on. Avoid becoming a Powerpoint Architect. The job of a team lead or an architect is not to figure out all the solutions. It is one of guiding the team to develop better software. By being hands on, they are able to provide practical guidance to their teams, not only about technologies used but also specific problems that may arise. By diversifying, they are able to evaluate and pick the right set of technologies and tools for the application at hand. Your strength is not in how good you once were, but how capable you continue to be.

Ken: Understand the business you're in. Evaluating a technology on its merits is only a small part of managing a major project. We all fall in love with a particular technology and then want to use it everywhere. The users, of course, don't care about any of that -- they just want their problems solved. The needs of the business are more important than any particular technology you want to use.

You also need to learn why things are done a particular way in your organization, especially if the reasons appear to be foolish. Every major system evolved as a set of compromises that seemed like a good idea at the time. Knowing the business reasons for why your company does what it does will help a lot when it comes time for you to make those decisions.

Looking for a partner in securing your talent? Contact your local Apex branch here.
Seeking your next technical opportunity? Give our openings a look.