Back home

About the author

Software should be understood, not merely shipped.

I’m Salomon Nghukam, a software engineer based in Île-de-France and currently working at Société Générale. I work across software architecture and backend systems, and spend a lot of time thinking about the decisions that make software dependable after it reaches production.

Portrait of Salomon Nghukam
Currently
Société Générale - France
Working on
Architecture · Backend · Frontend
Writing about
What survives production

The work

Where I spend my engineering time

Software architecture

I mainly design backend systems with Java and Spring: service boundaries, APIs, data models, and operational constraints. Node.js is a secondary stack when it fits the problem.

Frontend stacks

Angular and React interfaces where component architecture, state, accessibility, API contracts, and maintainability shape the product experience.

Cloud reliability

Cloud platforms, automation, and infrastructure choices that help a system remain understandable under real pressure.

Independent projects

Designing products beyond the day job

Outside working hours, I develop personal product projects from the initial idea through product framing, interface design, technical architecture, and implementation. They give me a space to think about the complete experience rather than engineering in isolation.

I am keeping those projects private for now, but the work influences how I approach software: a product must be useful, understandable, and coherent-not only technically correct.

The writing

Why these field notes exist

I started this blog because the most useful engineering lessons rarely fit inside a tutorial. They live in generated code, configuration defaults, failed assumptions, production constraints, and the trade-offs made while a team is trying to ship responsibly.

My goal is to document those details while they are still concrete: what failed, why it failed, what the framework was actually doing, and which solution remained clear enough for the next engineer to maintain.

The shortest implementation is not always the simplest system. Understanding the hidden contract is usually more valuable than memorising the annotation.