This article is courtesy of TechTarget.

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.

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.

Check out the original article over at TechTarget.