adam bien's blog

How to be Java Guru without knowing Java (at least in meetings) 📎

I posted some strategies for "experts" and called them VooDoo Consulting Style. The strategies were a common and language independent advices for "high end" consultants. In the Java-space, it is even easier to be an acknowledged guru - almost without additional effort. Writing code, or beeing productive is dangerous (something can go wrong). Sometimes it is easier to be a guru without coding:
  1. Before the initial project meeting go to jcp.org. List all JSR's learn some (5 are enough in general) numbers and headers.. If you have to do with more advanced developers - also read the abstract. Mention the JSRs during the meeting and enjoy the impact.
  2. If you project is going to be a realized with Java EE: Emphasize the verbosity of Java. Point to elegant languages like Python, or Ruby. (it is not necessary to know these languages - it is not very likely, that they will be used in a Java EE environment). If they are going to be chosen go to point 6.
  3. Mention JDK 1.7 (this strategy is very save -> most companies thinking now about upgrade to Java 5) and closures. In general it is enough only mention the term "closure" in the context of Java.
  4. Wait a random amount of time. Pick one of the vs. issues and try to initiate a dicussion; SOA vs. ROA, Ruby on Rails vs. Java EE, Thin vs. Rich, AJAX vs. Rich, Swing vs. SWT, Netbeans vs. Eclipse, Java EE vs. .NET, SOAP vs. REST and OSGI and JSR-277. The highlighted ones are more funny and the discussion longer.
  5. Use terms like Web 2.0-ish, SOA-ish etc. Don't  care about the meaning: no one is able to define them.
  6. Suggest more esoteric languages like Haskell, Scala,  or Fortress but not Malbolge for the realization. In general there is no reason to doing that (Java is working well), but why not?
  7. Don't forget code generation. Sometimes it is enough to initiate a discussion about MDA vs. MDSD. If nothing happens ask the developers about PIM, PSM and code transformation etc.
  8. Very important: mention things like team velocity, pair programming, ask about Xtreme-Programming, Agile, Scrum, Crystal, Test First, Mocking (the more the merrier).
In the contrary to the VooDoo Consulting Style, these strategies (or topics) change over time. So you have to update the list from time to time. Although such "gurus" survive several projects, it is relatively easy to find them. Just ask about the reasons for the decision  :-).