Writing and notes
Things I’m learning by building.
Honest notes from the desk: the small decisions, mistakes, and discoveries behind my work in software, mobile development, research, and technical leadership.
ANDROID6 min read
What Kotlin Changed About the Way I Build Android Apps
When I first moved from Java to Kotlin, I expected shorter code. What I did not expect was how much easier it became to express the intent of an application. Null safety, data classes, and extension functions removed a lot of noise from my day-to-day work.
The bigger lesson was not about syntax. It was about making the safe path the easy path. A good language feature is valuable when it helps the whole project stay understandable several months later.
BACKEND5 min read
Start With the Problem, Not the Framework
It is tempting to choose a stack before understanding what a product actually needs. I have done that more than once. The result is usually a collection of impressive tools solving a problem that was never clearly defined.
Now I begin with a plain sentence: who is this for, and what should become easier for them? That answer guides the database, API, and interface decisions far better than a list of trending technologies.
LEADERSHIP4 min read
The CTO Work Nobody Sees
Technical leadership is often described as architecture and big decisions. Those matter, but much of the real work is quieter: clarifying priorities, documenting choices, removing blockers, and helping someone feel confident enough to own a problem.
A team moves quickly when people understand why a decision was made. I try to make that context visible, even when the decision itself looks small.
AI RESEARCH7 min read
My First Research Presentation Was More Practical Than I Expected
Preparing research for ICOIICS 2025 taught me that a good idea is only the beginning. The difficult part is explaining the problem clearly, showing what was tested, and being honest about what still does not work.
That discipline has followed me into product development. Measurements do not replace intuition, but they keep intuition honest.
JAVASCRIPT5 min read
Small Interfaces Deserve Serious Attention
A button label, an empty state, or a loading message can feel too small to discuss. In practice, these are the moments users notice most. They are looking for reassurance that the system understood them.
I have started treating these details as part of the product logic, not decoration added at the end. A clear interface is often the result of clear thinking behind it.
OPEN SOURCE4 min read
Why I Keep Building Small Side Projects
Side projects give me room to follow curiosity without pretending every experiment needs to become a business. A small programming language, a utility app, or a rough prototype can teach a lesson that a polished project hides.
Some experiments are abandoned. That is not wasted time. They become a personal library of patterns, mistakes, and ideas to revisit later.
PYTHON6 min read
Making an API Boring Is a Good Thing
The best API I have worked with was not clever. Its names were predictable, its errors were useful, and its behavior was consistent. That made it easy for another developer to use without reading the entire implementation.
I prefer spending time on validation, response shapes, and documentation before adding complexity. Boring systems are easier to test, operate, and trust.
CAREER5 min read
Learning to Code Without Waiting to Feel Ready
I started with tutorials, but tutorials can create a comfortable illusion of progress. The first real jump happened when I tried to build something without knowing exactly how it should work.
Being stuck became part of the process. Search, documentation, failed attempts, and asking better questions taught me more than collecting another course ever did.
PRODUCT4 min read
A Feature Is Not Finished When the Code Compiles
Compilation answers one question: does the code fit the language? It does not tell us whether the feature is understandable, useful, or resilient when a real person uses it differently than expected.
I now consider testing, copy, edge cases, and feedback part of finishing. Shipping is a technical event, but usefulness is the real milestone.
DATABASES5 min read
The Database Decisions I Wish I Made Earlier
Early projects taught me that changing a schema later is possible but rarely free. Names, relationships, and constraints become part of every layer above them.
I do not try to predict the future perfectly. I do try to write down assumptions, keep migrations small, and choose names that will still make sense when the original context is forgotten.
STUDY4 min read
Balancing Engineering Study With Real Projects
Classroom learning gives me foundations, while personal projects give those foundations friction. Algorithms make more sense after debugging a slow feature. Networking feels more real after an API fails in an unexpected way.
The two kinds of learning strengthen each other when I let them. I try to connect every abstract idea to something I can build or explain.
REFLECTIONS3 min read
Build Things You Can Explain
There is a useful test for any project: can I explain what it does, why it exists, and where it might fail? If I cannot, the system is probably carrying more complexity than it needs.
Clear explanations are not only for presentations. They make collaboration easier, improve documentation, and reveal gaps in our own thinking.