If you write Java for a living - this is worth a read. The core idea: stop letting technical scaffolding drown out business logic. Use Result types, sealed interfaces, composition. The language subset you actually need is smaller than you think. What you get is structure and predictability. Code that reads like a spec, not like a framework tutorial. For me that's the difference between craftsmanship and engineering.
How much of your code is actually about your business? Open any service method. Count the lines. How many describe what the business does? How many are null checks, try-catch blocks, type conversions, framework annotations? In most Java codebases, technical ceremony dominates. Business logic hides between the scaffolding. When you measure language features against business value, something unexpected happens: most of them become unnecessary. Records for data. Sealed interfaces for alternatives. Lambdas for composition. Pattern matching for dispatch. That's most of it. The rest -- inheritance hierarchies, checked exceptions, mutable state, reflection -- serves the technical ceremony, not the business. When the useful subset is small: -- Learning curve compresses -- Code becomes predictable (one way, not three) -- "Which feature should I use?" disappears The result? Code that reads like a business process: check inventory -> calculate pricing -> place order Three lines. Each line is a business step. Less language, more business. Less art, more engineering. Sixth in the "We Should Write Java Code Differently" series: https://lnkd.in/dgKBTKcM #java #cleancode #softwarearchitecture #backend
