Teaching Java made me a better engineer

For a while I split my weeks between shipping backend systems and standing in front of a room of people learning Java for the first time. I assumed teaching would cost me coding time. I didn’t expect it to make me a better engineer.

You can’t fake understanding out loud

You can ship code you only half-understand. Copy a pattern, tweak it until the tests pass, move on. But you cannot teach something you only half-understand — the questions find the gaps immediately. Preparing a single lesson on, say, how Optional is meant to be used taught me more than years of quietly using it.

Once you’ve had to explain why something works, you write it differently.

Names are written for the next person

Beginners read code far more literally than we do. Watching a student trace through processData(d) and tmp2 line by line, lost, cured me of lazy naming for good. Now I write every name as if a tired person at 2 a.m. — possibly me — has to understand it with no context. Small methods, honest names, no cleverness that needs a footnote.

Errors are a conversation, not a verdict

New developers panic at a stack trace; it feels like the computer is angry at them. A lot of teaching is just reframing that: the exception is the program telling you exactly what went wrong and where. Slowing down to read it calmly is a skill. Teaching it to others made me far calmer reading my own.

If you can’t explain the layer, question the layer

The fastest way to find an over-engineered design is to try explaining it to a junior. If I can’t give a one-sentence reason for why a service, interface, or abstraction exists, that’s usually a sign it shouldn’t. Teaching is a ruthless filter for accidental complexity.

---

None of this is really about Java. It’s that explaining your work to a beginner forces a kind of honesty that day-to-day coding lets you skip. By day I build; by night I teach — and the teaching keeps making the building better.