I’m Jeff Hanson—a technical writer, published author, and software architect. I turn complex APIs, systems, and engineering concepts into clear documentation that helps people understand, integrate, and maintain software.
From the first integration to a complex system migration, I help turn technical knowledge into documentation people can act on.
Getting-started guides, API explanations, integration walkthroughs, and examples. Help developers understand prerequisites, expected behavior, and the next step.
System overviews, architecture decision records, migration guides, and runbooks. Explain dependencies, tradeoffs, and operational procedures without losing the technical substance.
Tutorials, technical explainers, and learning material that connect concepts to practical use. Adapt the depth and vocabulary to developers, product teams, or business stakeholders.
My published work spans enterprise architecture, Java management, application integration, and more than 50 in-depth industry articles for developer publications including JavaWorld, DevX, and IBM developerWorks.
A multi-author guide to web services architecture and business strategy for architects, developers, and IT leaders. Includes my contribution on .NET and J2EE.
A practical guide to enterprise mashups, covering integration strategies, application patterns, security, and implementation with code examples.
An in-depth treatment of Java management architecture, instrumentation, distributed services, notifications, and remote management.
Many original links to my articles are archived or unavailable following changes to their publishing platforms. The book catalogs and surviving articles below provide independently hosted records of my authorship and examples of my technical writing.
An introductory guide to HDFS architecture and its major subsystems. Original article preserved on IBM’s server.
A concise discussion of enterprise mashup design choices and common integration pitfalls.
These publications are presented as historical writing samples; technical details reflect their original publication dates.
I approach documentation as a product: define the audience, organize the information around real tasks, and review the technical details with the people responsible for the system.
Start with the reader’s task, then provide the context and detail needed to complete it. The same system may need a quick-start guide for a developer and a decision brief for a business leader.
One architectural choice, explained differently for the people who implement it and the people who approve it.
Keep the external API contract separate from the internal data model. When storage changes, update the mapping layer rather than asking every client to change with it. Record which behaviors are part of the contract and test them explicitly.
A stable interface can let us improve the system behind it without forcing connected applications to change at the same time. The tradeoff is additional work to maintain that boundary. Choose it when protecting integrations is worth that cost.
New example prepared for this site. Not a prior publication or client deliverable.
My documentation work draws on hands-on experience with enterprise commerce, insurance, financial software, and platform engineering. This is the technical foundation behind my writing.
Enterprise commerce systems, web services, API integration, and Java microservices. Work across development, deployment, and technical architecture.
Distributed reinsurance architecture using Java enterprise technologies, service-oriented integration, XML, and industry-standard data exchange.
Java-based banking and online bill-payment software, including financial protocols and enterprise application integration.
Platform infrastructure and word-processing software, with responsibilities spanning analysis, design, implementation, and testing.
I’m a technical writer and published author with a software engineer’s understanding of what sits behind the page. My focus is making technical information accurate, useful, and appropriate for its audience.
I offer technical writing and documentation services alongside software development and architecture consulting. I can work with engineers to explain an existing system, build practical learning material, or document a new API as it takes shape.
Outside software, I play guitar, work with wood, and spend time outdoors. I enjoy building things—whether the material is code or lumber.
Connect on LinkedIn ↗Tell me who your readers are, what they need to accomplish, and where your documentation falls short. Include your goals and timeline, and we can start with a focused conversation.
Technical writing · Documentation · Developer education