News Stay informed about the latest enterprise technology news and product updates.

Seven tips to becoming a Java developer Zen master

At JavaOne 2015, Martijn Verburg presented a Zen-focused lesson on mastering the Java developer role.

CONFERENCE COVERAGE:

News from JavaOne 2015

+ Show More

Putting aside his Diabolical Developer identity and appearing as Zen master, Martijn Verburg laid out dos and don'ts for Java developers in parables at JavaOne 2015 in San Francisco. He even dressed the part, in traditional Zen black pants, and shirt and sandals.

Verburg, CEO at jClarity Ltd. -- a London-based seller of app performance diagnostic services -- adapted the session, with permission, from the writings of Qi the Scribe on The Codeless Code site, which presents illustrated fables, or Zen koans, on the art and philosophy of software development.

In each fable Verburg told, a Zen software master teaches his students, or monks, the core elements of software development. Most often, the monks learn their lessons the hard way. Here are some of those lessons for a Zen Java developer:

1. In the naming of names, be clear. In this fable, young monks invented a tribal language only they could speak. When someone new joined them, the language became useless. When writing object-oriented code in Java, it's important that the Java developer names things correctly. Be descriptive.

2. You are a programmer. Automate. In this fable, two young monks were charged with cleaning two koi ponds before the emperor's visit a few days hence. If the ponds were not clean, they would be beheaded. One monk gathered many tools and began manually digging out the weeds in the ponds. The other sat under a tree and read a book on HTML. The first monk worked for 72 hours straight, without sleeping. When just a short time was left and the ponds weren't clean, he cried out to the second monk. The second monk got up, borrowed a spade and dug a channel between a nearby clear, running creek and each pond. The clear water flowed into the ponds and cleaned them.

Don't cling to development tools you know when automated tools are available, Verburg said. An upgrade may bring some short-term cost and pain, but an automated tool will save money and hardship down the road. It's easy to make a case for automation because it's a cost-saving device. The only downside is that some sys admins may lose their jobs.

3. The path to the answer is as important as the answer. In class, one brilliant student could answer complex questions in a snap. A second student, however, worked through the processes involved and eventually came up with an answer. Which one did the master value most? The second monk.

Verburg tends to lean toward the process-oriented, diligent developer when hiring. "We are careful to hire only the developer who can work through a process and communicate what was done to the team," he said. Software development is a team effort. Even a brilliant developer, who can jump to the end solution without going through a long process, has to be able to describe the steps needed to produce the solution.

4. The whole system matters. The monks can build perfect planks, but they learn in this fable that planks alone can't build a bridge.

"I've learned the hard way that to focus more on end-to-end test for the whole system, on integrational system tests," Verburg said. Developers can't just focus on the application or component, because systems are interdependent. For example, fail to inspect activity between two components, and one could get the ports wrong. Then, the systems administrator can't open it and the developer ends up looking bad.

5. Write as little code as possible, and don't believe you can write perfect code. Two interrelated tales give that advice about perfectionism and a means to better code. A Java developer was dismayed because other developers could always break his code -- no matter how much code he wrote -- and another sought to create perfect code. In both cases, their resistance to reality is futile. Perfect code does not exist. As for beating hackers, Verburg suggested that developers can minimize damage done by writing as little code as possible.

If there is a decent solution out there, especially if it's open source, use it.
Martijn VerburgCEO at jClarity

6. Heroes die young. The ninja approach to software development leads to burn out, yet many organizations still stick with it. They'll have a "tiger" team that's called in when there's a fail. "Then, they pat you on the back for saving the day with your 72 hours of nonstop work," Verburg said. "If this is what your organization does, go find another organization to work for."

7. Lead by example. Verburg recalled the uncorrected monk, who made the same mistakes again and again for years. When his teacher complained to the master, the master laid the blame on the teacher for not leading by example.

Do not say, "I'm the team leader and don't have time to run tests," Verburg said.

Finally, Verburg asked the audience if they tended to write programs themselves, rather than use existing ones. For example, have you ever written your own date-and-time program or domain-specific language? Break that habit, he advised. "If there is a decent solution out there, especially if it's open source, use it," he said. Use it even if you need to tweak it, and you'll save time and get more projects done well and quickly.

Next Steps

Java technology turns 20

Building a collaborative software development team

Java trends in 2015

PRO+

Content

Find more PRO+ content and other member only offers, here.

Conference Coverage

News from JavaOne 2015

Join the conversation

6 comments

Send me notifications when other members comment.

By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Please create a username to comment.

Which of the seven Java developer tips do you find most helpful? Why?
Cancel
I find #3 most useful - the path to the answer is as important as the answer. Maybe it’s because of my background in mathematics, but I’ve always thought that there was more value in working out a solution, and in what was learned as I worked out a solution. For one, it promotes better problem solving skills.
Cancel
Tough call but I like # 5 best.   Developers need to realize they are not gods, and I think when they do, they begin to take less major risks, but when they do, to do so with good coverage.
Cancel
Tip 5 stands out for me which says "write as little codes as possible" & also that there's nothing as 'perfect codes', many thanks for all the tips.
Cancel
All tips are very helpful. I'd vote for #4 because it appeals to the business reasons of software development. Thinking of the system as a whole, as a product intended to solve particular problems. If that isn't met the rest doesn't really matter.
Cancel
These are some useful tips that can be applied to many different undertakings, not just Java development.
Cancel

-ADS BY GOOGLE

SearchSoftwareQuality

SearchCloudApplications

SearchAWS

TheServerSide.com

SearchWinDevelopment

DevOpsAgenda

Close