About me
I'm Marcin, a software engineer writing about the parts of software development that don't usually make it into tutorials.
I've worked on everything from greenfield products to large legacy monoliths. Along the way, I learned that knowing how to write code is only one part of the job - and often not even the most difficult one.
You can understand Java, Spring, databases, testing, architecture, and all the usual technical concepts, and still open a vaguely described task on Monday morning and think:
Okay... where do I even start?
Large features get messy. Requirements are incomplete. Existing code doesn't behave the way you expected. The technically perfect solution doesn't always make sense for the project. You make assumptions, change your mind, discover something three layers deeper than you wanted to, and occasionally realize that the decision you were completely confident about two days ago wasn't that great after all.
That's the side of software engineering I want to write about.
There's already enough content called “10 things every senior developer should know” or “5 Spring Boot tricks that will 10x your application performance.” Some of it is useful, but it rarely resembles what an ordinary day working on a real product looks like.
Software development gets romanticized sometimes. I think it's closer to being a car mechanic than people like to admit.
The mechanic comes home with oil on his hands and dirty clothes. Our mess just isn't physical. It's hidden in half-understood requirements, old code, awkward integrations, production bugs, questionable decisions, unfinished migrations, and that one feature everyone is afraid to touch.
And that's fine. That's the job.
Why I write
I try to write the way I would have wanted someone to write to me when I was starting out.
Not to sound clever. Not to impress other developers with terminology. And definitely not to turn a simple idea into an architecture lecture just because I can.
If something can be explained simply, I want to explain it simply.
KISS applies to writing too.
My goal is for a post to leave you with something you can actually take back to a project: a different way to approach a task, a mistake you can avoid, a question worth asking before you start coding, or sometimes just an idea that might save you from learning something the painful way.
I'm particularly interested in everything that happens around the code: understanding tasks, breaking down larger features, making technical decisions, working with existing systems, reviewing code, dealing with uncertainty, keeping context, and figuring out what the actual problem is before reaching for an implementation.
That part matters even more now that AI can produce increasingly large amounts of code for us. Writing syntax is getting cheaper. Knowing what should be built, why, where it belongs, what can go wrong, and whether the result actually makes sense isn't.
There will still be code
This isn't going to be a blog about software engineering without any software.
I'll also write about technical experiments, small proof-of-concepts, architecture ideas, things I've recently explored, and projects worth documenting. Some of them will come with code and GitHub repositories.
Sometimes a post might simply exist because I spent a weekend investigating something interesting and wanted to document what I learned - even if I'm the only person who ever comes back to read it.
That's probably the simplest description of this blog:
notes, mistakes, experiments, and lessons from building software in the real world.