Software Engineer in
Jyväskylä, Finland
I'm Henri Leinonen, a software engineer at Airbus Defence and Space, working with complex software systems in a high-reliability environment.
Getting the code to work is only part of the job. I want to understand how the system fits together, why earlier decisions were made, and what a change means beyond the code in front of me. I question technical decisions when needed, including my own.
I'm increasingly interested in software architecture and technical ownership: making reasoned trade-offs and staying responsible for how a solution holds up over time. Reliability and maintainability matter, as does leaving a system understandable for the next person. My technical interests include Java/JVM and AI-assisted software engineering.
I tend to gravitate toward difficult technical problems, especially when someone needs to take responsibility and move things forward. I like getting to the bottom of a problem before choosing a solution. The work that interests me most has meaningful real-world impact, where people need to be able to trust the software.
- Clear communication is part of engineering, not separate from it.
- Always be proactive and take ownership of your work.
- Most problems are not technical, they are people problems. Build an environment where it is possible for your team to succeed.
- Understand the domain. I mean really understand it.
- Make it as clean and simple as possible without over-engineering. It is probably not your money you are spending.
- Minimize dependencies unless they add real leverage.
For over a year, I spent much of my free time building PiecesHub with a friend. It was a collaborative coding platform for junior developers, educators and communities. We took it from an idea to a substantial working product. I'm no longer actively developing it.
We handled the work from planning and implementation to testing and infrastructure. That meant deciding what to build, who it was for, and how much complexity we could reasonably take on.
The project taught me about architecture, security, infrastructure and product decisions. Owning a larger technical system made the connections between those areas concrete: a choice in one part could create work or constraints somewhere else. Those lessons still influence how I approach engineering.
> dir /articles
| 03-04-2026 | building-projects-is-not-enough.html | 3.7kb |
| 03-04-2026 | dont-be-asshole-theory-career-growth.html | 4.1kb |
Before moving into software engineering, I worked as a mathematics teacher. That background still shapes how I work. I value clear explanations, sharing knowledge, and building a common understanding before jumping into solutions. Explaining a difficult idea often exposes gaps in my own understanding, too. I see that as useful engineering work, not an interruption to it.
I sometimes review portfolios, CVs, and project descriptions. Not as a formal mentoring service, but because I think the industry benefits when junior developers learn to present their work clearly.
If you want feedback, make it easy for me to help. Include:
- A link to your portfolio or GitHub
- Your current level (student, junior, mid)
- What kind of feedback you are looking for
I appreciate specific, thoughtful messages that show you are genuinely interested in connecting.
> contact
"I am not actively looking for new roles, but I appreciate inspiring conversations."