Holly Cummins

I started my Java career using J2EE 1.2. I had questions. Why were there four classes and hundreds of lines of generated code for each bean? Why did compiling tiny projects take half an hour? It wasn’t productive, and it wasn’t fun. Those two often go together: things feel un-fun because we know they’re waste. Think about meetings where nothing is decided, status reports no one reads…

If un-fun is bad, what is fun? Is it good? And how do we get it? Fun can have different faces:

• Exploration (focused investigation)

• Play (for its own sake, no goal)

• Puzzles (rules and a goal)

• Games (rules and a winner)

• Work (a satisfying goal)

Java allows all of these—the work part is obvious, and anyone who’s debugged a Java program knows about the puzzle part. (Debugging isn’t necessarily fun, but finding the solution is great.) We learn through exploration (when we’re new to something) and play (when we know enough to do stuff).

Leaving aside the fun we can have with it, is Java inherently fun? Java is verbose compared to younger languages. Boilerplate isn’t fun, but some of it is fixable. For example, Lombok neatly generates getters and setters, as well as hashCode and equals methods (tedious and error-prone otherwise). Manually writing entry and exit trace is un-fun, but aspects or tracing libraries can instrument dynamically (and massively improve code readability).

What makes something fun to use? In part it’s about being expressive and understandable, but there’s more to it than that. I’m not convinced lambdas are generally shorter or clearer than class-based alternatives. But they’re fun! When Java 8 came out, developers dove into lambdas like kids in a ball pit. We wanted to learn how it worked (exploration) and the challenge of expressing algorithms in a functional style (puzzles).

With Java, the fun thing to do is often also the best thing (win). Autoinstrumenting trace bypasses un-fun, eliminating method-name copy-and-paste errors and improving clarity. Or consider performance. For niche scenarios, weird, complicated code is needed to scrape every inch of speed. In most cases, however, the simplest code is also the fastest. (Which is not necessarily true for languages like C.) The Java JIT optimizes code as it runs; it’s smartest for clean, idiomatic code. Straightforward code is nicely readable, so errors will be more obvious.

Misery-making code has a knock-on effect. Psychological research shows happiness and workplace success go together. One study showed that people with a positive mindset were 31% more productive than those with neutral or negative mindsets. You’ll achieve less using poorly designed libraries, and then you’ll continue to achieve less afterward because the bad code made you miserable.

Is “fun is good” an excuse to be irresponsible? Not at all! Consider whether everyone is having fun: everyone includes customers, colleagues, and future maintainers of your code. Compared to dynamically typed scripting languages, which can be fast and loose, Java already ticks the safe and responsible box. But the programs we write also need to be responsibly coded.

The good news is that for almost all boring tasks, computers can do the job faster and more correctly than people. Computers don’t expect to have fun (yet), so take advantage of them! Don’t accept tedium. If something seems un-fun, look for a better way. If there isn’t one, invent one. We’re programmers: we can fix boring.