A few years ago, I started noticing something strange: every time I heard an academic speak, I’d feel this irrational anger rise within me. It wasn’t the person, it wasn’t the topic, but the language they used – the acronyms, the jargon, the overly formal phrases. It took me a while to figure it out, but I think I finally get why.
Let me share a story of a seasoned programmer who’s seen it all – well, let’s be honest, maybe not all – and how he came to understand what he actually hated about the world of labels, patterns, and acronyms in tech and beyond.
4bce7f2
While studying at Kyiv-Mohyla Academy, I listened to countless songs on old mp3 players like iPods. Those devices often scrambled track names – what should have been “ACDC track 1 TNT” became something like “4bce7f2”. Some tracks were well-known and shared within the community; others were obscure mixes from local and non-local bands, some of them pure gold, but never recognized widely. I rarely remembered titles, yet I always remembered the flow. A few sounds were enough for me to predict the melody. Like GPT today, my mind could continue the sequence because immersion in music gave me intuition for harmony.
The same thing happened with programming.
I began with VB6, moved through Delphi, Pascal, C, and eventually settled on Python. Along the way, academic knowledge tried to impose itself: “Hey, you have this huge little city built by yourself? Forget that – don’t use goto, that’s a code smell. Forget declarative programming, learn OOP, use SOLID, follow Agile…”
I started writing code long before I knew there were patterns. Some I later learned formally, but most grew from solving problems directly.
Some of those rules helped me understand my own choices better. But I resisted chaining myself to them. Especially the way people understand Agile – but that’s another long story.
I instinctively understood that writing code one way made it unmanageable, another way made it clear. I was the architect, the programmer, and often even the “business” behind my own solutions. Modern markets don’t always value unprovable experience – and I get why – but I had plenty of it.
My strategy for any solution? Begin. Keep going. Refine until it works. Try to keep it as simple as possible.
How and WHY did frameworks come to the world?
Do you remember who the first programmers were, and how hard it was to earn that badge and master the technology? Most programmers came from an academic math background, and they carried a deep need – since computers were not easy for humans to handle – to define formal, unambiguous nature for every building block of computation, to label and patternize everything.
Rules like SOLID, CQRS, TDD, or DRY, Clean Code, etc were born from that mathematical instinct. They made knowledge easier to share, easier to measure, and easier to scale. They’re brilliant foundations – but they’re also chains.
Why chains? Because they break the ownership of code. Instead of building from atomic understanding, you inherit someone else’s formula.
Let me explain that further.
For most people it would be hard to follow me. Why? Because people love to label and get easy results. It’s a prehistoric survival instinct, and I don’t blame you, or your teachers – I blame the whole laws of our world, optimization of resources usage to normalize outcomes, as it where in simple life form, and as it is for businesses now, presenting an easy, strict path, but ultimately slowing down wider human progression.
The rise and fall of math skills xD
In school, math came easily. I even won local Olympiads. But eventually, I stumbled. Not from laziness – I hated memorizing formulas. Why? Just gut feeling. Only after a few decades have I understood what it was… In our schools math was taught as definitions + formulas -> manipulate them until you get the answer. That works for exams, but not for true understanding. I no longer owned knowledge – I outsourced it to the formula-makers.
Those people weren’t stupid – they were brilliant. But I resented learning this way. Humans build knowledge by assembling it from atomic ingredients, like traversing a graph of possible states.
Without that foundation, formulas become just a game. You don’t know how to build a wall from bricks – you only know how to place a 3m x 15cm wall, unaware of how the width affects its strength. Imagine you can’t adjust the width; all you can do is place a ‘wall block’ and play around.
It was very hard to get what the f vectors are, why we need matrices, or what img numbers mean. I have friends who were luckier: they were taught math by top scholars, people who understood that knowledge should be built from the most atomic things you could explain, step-by-step, so a person could not only solve the few tasks society requires to evaluate you and get you to university, but to UNDERSTAND and OWN knowledge, so you would be ABLE to solve problems by having the complete picture rather than by rote.
That’s where my math failed me. I couldn’t solve complex problems by just playing with formulas, while they could reconstruct the formulas from the bigger picture and reach sound conclusions.
Back to programming
The same applies to software. The inventors of CQRS, SOLID, Agile, and other paradigms were brilliant. Their work made learning easier, businesses happier, and code more consistent. But from my perspective, they also introduced dependency on labels. For some people, that’s comfort. For me, it’s a restriction.
Humans are pattern-recognizing machines.
See kx + b = c -> think Vieta. See 4 nested loops -> refactor. See more reads than writes in a streaming service -> reach for CQRS + Cassandra (Aerospace, whatever). Think of speed -> maybe bytecode. Nah, it’s too much, let’s write it in Assembly… Well, let’s go with C – C is enough.
We are always chasing the perfect state, perfect graph, perfect code, outstanding speed – perfect solution.
Have you heard the story of the plane that first broke the sound barrier, the Concorde? It shattered the sound barrier and pushed even further, but airlines soon realized passengers valued comfort over shaving a few hours off the trip. Speed lost to experience. Faster wasn’t better.
And here what I mean is perfect.
Perfect doesn’t always mean “fastest” or “cleanest”. Perfect depends on how wide-sighted you are and what you can lay into this word.
The engineer’s mindset
Want to iterate faster? Use an LLM. Oh, so you need working code? Learn Python. You got through the main problems, but now it’s speed that matters, right? Drop into Rust or C, adapt bottlenecks. Code unmanageable? Break it into blocks/roles/scopes. Architecture failing? Rethink, break, rebuild.
This is how an engineer’s mind really operates – not by saying “I learned SOLID,” quoting a few academic lines, and showing ten lines of code. Put yourself under extreme conditions, with business pressure and tight deadlines, and you’ll gain a very different experience of SOLID. Sure, it’s great when you’ve practiced for years, when your whole team is aligned, and when there’s enough time and budget to polish everything. But the outcome of such harsh training? Well, you’ll write clearer, more academically correct code, a bit faster. Congratulations – you’ve just saved a few CPU cycles on modern machines. Applause.
Closing thoughts
I could give you an easy outcome, more structured flow, not blaming brilliant engineers who are saving cpu cycles in an engineers mindset part (they’re REALLY brilliant and help every one at a scale). I could break this into manageable parts, with solid pathways, so you get easy best followage. Sure I could add AI, and pros and cons of its usage and gain much more popularity from that post. But I will leave you with your own, OWNED experience.
Think of songs. Think of Concorde. Think of labeling problems versus owning knowledge. To build good code, you don’t need every rule – you need a few guiding principles:
0. Be agile (in the literal sense, not the methodology).
1. Focus on the goal.
2. Design basic architecture.
3. Think about how data transforms states before writing code.
4. Think about who will manage it.
5. Don’t overengineer. Solve the most obvious scenario first, whatever messy it would be.
6. Prototype every handler in atomic form.
7. If a handler is too complex, break it down – create manageable parts.
8. If the architecture stops working – rebuild it.
9. Always keep in mind the global state of data transformation.
10. Scale only when you need to, 1-2 steps ahead, never more. Lost money is just bonus money; broken foundations are fatal.
Don’t hesitate to break rules or enforce structure where needed.
