thenotwish
I hope you like My Story
scroll to see it unfold :D
Chapter I
Who am I?
When people ask me what I do, the obvious answer is that I'm a software engineer. It sounds accurate, but it has never felt right.
For a long time I tried to find a title that fits me. I thought about calling myself a systems engineer because I naturally think in systems. Sometimes I felt more like a designer than a programmer. Eventually I realized I wasn't searching for a different title. I was searching for the reason I enjoyed engineering in the first place.
Programming was never the reason. Creating was.
Software just happened to become my canvas.
Chapter II
Understanding
Most people experience software only after it's written.
They see the interface, the features and the finished product. I spend far more time thinking about everything that exists before a single line of code is written.
Before I build anything, I want to understand what it's trying to become.
If I'm designing a website, I don't immediately think about React, Next.js or animations. I start by asking what the website is trying to communicate. Is it supposed to earn trust? Tell a story? Explain a product? Represent a person? Every answer changes the decisions that follow.
Programming isn't where my work begins. It begins with understanding the work.
Chapter III
Systems
I rarely think of projects as isolated pieces of software. I think of them as systems made up of many smaller decisions.
Every project has an identity.
Every decision should have a reason.
That mindset probably comes from how I learn naturally. I don't see projects as one large task to complete. I see them as a collection of smaller decisions and processes that gradually come together into something bigger. Whether I'm designing an architecture or organising my own workflow, I naturally build one intentional layer at a time.
I don't look for the perfect solution.
I look for the solution that will still make sense months later.
Chapter IV
Decisions Doc
A finished project isn't simply code that works.
It's code that somebody else can understand.
It's documentation that explains not only what happened but why it happened.
It's an architecture that feels intentional rather than accidental.
It's a design that supports the purpose of the product instead of decorating it.
One small habit illustrates this better than anything else.
While working on projects, I keep what I call a Decisions Doc. Whenever I make a technical decision that isn't immediately obvious, I write down why I made it. If I spend hours debugging an issue, I document not only the solution but the reasoning behind it.
I originally started doing this for myself.
Over time I realised I was really documenting for the next engineer.
Sometimes that next engineer is another developer. Sometimes it's simply me six months later.
Either way, the goal stays the same. Engineering should leave clarity behind it.
Chapter V
Craftsmanship
Craftsmanship isn't about perfection.
It's about caring enough to make intentional decisions, even when nobody will ever notice them.
I'm not interested in adding features that don't serve a purpose. I'm not interested in chasing every new framework simply because it's popular.
Reliability matters more than novelty. Maintainability matters more than complexity.
Sometimes the best engineering isn't adding something new. It's knowing what can be left out.
I don't want people to notice the effort.
I want them to notice the absence of friction.
Chapter VI
Design
People sometimes describe engineering as problem solving. I think that's true, but only partially.
Solving problems is important.
Creating thoughtful experiences is equally important.
A product communicates long before a user reads its documentation. Its typography, interactions, performance and reliability communicates before a single word is read.
Even the absence of unnecessary features communicates.
Every decision tells the user something about the people who built it. That's why I care about design just as much as implementation.
To me, design isn't limited to interfaces.
"Design is every intentional decision made before something exists."
~ wise word from me at 1:58 AM rethinking every decision that led me to writing this page.
Chapter VII
The Nerd
Outside of engineering, I find myself drawn toward subjects that explore how people think.
Philosophy, psychology and design have probably influenced the way I engineer more than any programming language ever has.
Understanding how people think changes how I gather requirements.
Understanding stories changes how I present them.
Chapter VIII
Partner
I use AI almost every day.
It helps me challenge assumptions, discover blind spots, debug difficult problems and even point out grammatical errors in this page.
But I don't see it as the source of creativity. For me, creativity begins with deciding what should exist.
That decision still belongs to the person creating it.
I believe its greatest value comes from strengthening human thinking rather than replacing it.
Chapter IX
Dream
If there's one thing I hope people remember after working with me, it isn't just that I was good at programming.
I hope they remember that I cared.
That I cared enough to understand before building , to document decisions instead of leaving mysteries behind , to choose maintainability over shortcuts.
I'm still a learner, and I know my understanding of engineering will continue to evolve.
But I hope one thing never changes.
I want to become the kind of engineer who leaves every system more thoughtful, more understandable and more reliable than it was before.
If, years from now,
someone opens a project I worked on and their only complaint is
the terrible jokes I left in the comments,
I'll know that I became the engineer I wanted to be.
End
Yes, I do Monkeytype to assert dominance.
No, it hasn't made me type my bugs any faster.
And I think good documentation deserves better jokes.