Principles
The ideas behind how I build software. They grow out of the values on my About page and the work on this site.
Security is not a feature
It's a constraint that shapes every architectural decision, from input validation to deployment. Most teams bolt security on at the end; I build it in from the first line of code, so what ships both works and can be trusted.
In practice that means thinking about how a system could be attacked before deciding how it should be built, and treating a security fix as part of the work, not a follow-up ticket.
Never trust input
Every boundary is a place where something unexpected can arrive: a form, an API route, a query parameter, a packet. I validate at each one, on the server, even when the client already checked.
The same habit applies to data. In my timetable system every constraint is validated before a schedule change is committed; in my network lab every header byte is parsed against its RFC instead of being assumed correct.
Least privilege by default
People and components should get only the access they need. My school scheduling system has four roles, from administrator to teacher, each seeing only what it has to; Blackhole Academy separates students, instructors and admins into different applications.
Secrets follow the same rule: they stay on the server, never in a public bundle, and nothing gets more permissions than its job requires.
Interfaces should disappear
The best UI is the one the user doesn't notice, intuitive enough to feel invisible. If someone has to think about the interface, it is getting in the way of what they came to do.
That is why I care about performance, accessibility and responsive layouts: they are what make an interface feel effortless on any device.
Hard problems aren't solved alone
My training at 42 Luanda taught me that the hardest problems rarely get solved alone. Its peer-to-peer model taught me to build with people, not around them.
Several of my projects were built in teams, and I still prefer to review, pair and ask early rather than work in isolation.
Measure the outcome
I judge work by what it changes, not by how much was built. A timetable system is worth it when timetable conflicts go away; a data pipeline is trustworthy when it checks and reports its own data quality after every run.
Wherever I can, I make results visible: tests, quality reports, clear outcomes. That way the next decision is based on evidence rather than on assumptions.