The Zen of Java

1. explicit.compareTo(implicit) == 1. For example, one does not simply send a small text letter — instead, a MimeMessage created for a Session configured with Properties is sent over an SMTPTransport using PasswordAuthentication.
2. Frameworks over libraries. Remember the last time you were asked by an interviewer which libraries you have worked with? Me neither.
3. Build scripts should under no circumstances look like what they do, and still they should take several screens for the simplest tasks.
4. If an implementation is hard to explain, it is an established design pattern.
5. A team is more important than an individual. Because a team can do beautiful things like ERPs, CRMs, complex integrations, and an individual cannot. And would not.
6. Language constructs that explicate side-effects are frowned upon (checked exceptions). Dying amidst control flow is greeted (explicitly throwing runtime exceptions, calling methods on null).
7. A billion dollar mistake is too cheap to be addressed.
8. Never leave the sandbox. Using tools not specifically created for Java is prohibited. Ideally, the tools should be written in Java, too.
9. During code reviews, you can be ostracized for using too many interfaces, not using enough interfaces, using too many or too short methods, creating few huge methods, creating unnecessary abstractions, stuffing too many responsibilities into one abstraction, using convoluted OOP, being too procedural, etc.
10. You will be surprised how far you might go before you get working OO-compliant code that does what you need. Very, very far.
11. Accidental complexity is indistinguishable from inherent complexity.
12. If some of your classes do not have state, or do not couple behavior to it, or do not mutate that state with that behavior, then why do you use Java at all?
13. A field without a getter/setter pair is a waste of space.
14. Systems written in Java should consist of Handlers, Controllers, Managers, Services, Components, Helpers, Utils, Converters, Factories, Proxies, Pools, and their combinations, operating on Data, Infos, Items, Nodes, Models, Containers, Wrappers, and their combinations.
15. Nirvana is where all methods have zero arguments because all dependencies are injected. Since you are not there yet, the class critical for your current task has six overloaded methods with eight to fifteen arguments.
16. Won't writing this whole method using just one stream be a lot of fun?
17. Successfully passing a system design interview and answering all pattern-related questions wins you a chance to work on another shitty codebase.
18. Friends do not let friends develop in Java without an IDE. It is impossible anyway.
19. When facing unreadable and unmaintainable code, blame Java and propose using the current trendy substitute. Best case: nobody approves rewriting the system, and you continue thinking about yourself as an unappreciated genius. Worst case: a rewrite is approved, years are spent to get a stillborn system, inferior to the original in every aspect, written in a language nobody is interested in anymore.

-----

I think that from a practical point of view, Java is still one of the best languages out there, if not the best. Whenever I rationally choose a programming language for the backend, I almost always come to it. It's just… I feel so nostalgic about the times when I was programming in Perl, with this feeling that everything is possible and you are part of a community; with all its magic and succinctness and few safety nets…

Those were the days.