Philipp Bondarev
Python developer
Sometimes the path into IT doesn’t start with a team or mentors, but with lonely attempts to understand why your program won’t run.
That’s how the journey of Philipp, a Python developer, began — learning the profession entirely on his own. Today, he is responsible for the architecture of complex systems.
This is his story about self-education, discipline, and the philosophy of “necessity and sufficiency.”
— How did you start your journey in development?
Many people are lucky to begin their careers “under the wing” of experienced colleagues. I, however, had to figure everything out on my own — though this isn’t something extraordinary.
My path felt like moving in the dark: a constant struggle with the sensation of drowning in a flow of new information. You’re banging your head against the ice, trying to grasp what you’ve just read. Every single step and line of code feels like a weight of responsibility.
Eventually, I realized that it’s completely normal to not understand something new on the first try. Only when you accumulate a critical mass of knowledge do parallels with already familiar concepts start to form naturally.
— How did you come to programming?
Everyone enters the world of development in their own way. In my case, the trigger was the inefficiency of processes in the design bureau where I had worked for seven years. There were no programmers around, so I armed myself with articles and books.
I began creating internal applications that turned out to be quite useful for our department. They were in demand and genuinely enjoyable to work on — which helped me quickly shift my focus from my main job in the bureau to solving engineering tasks through software.
Although I must say, the experience I gained in the bureau later helped me a lot in development.
— What changed when you first took on a large-scale system?
Three years later, I was offered the chance to work on a much larger system. For a moment, I had a timid hope of joining a team of more experienced colleagues — I really lacked the simple ability to discuss everyday developer problems with someone.
But… I turned out to be the only backend engineer, and on top of that, the one performing the duties of a system architect. All decisions were on my shoulders, and I couldn’t discuss most things in public chats due to an NDA.
— How did you deal with having no colleagues you could ask for advice?
Sometimes you can discuss very specific questions in communities, but as I said, NDA limits that as well. So I make most decisions myself.
What helps is one principle I learned back when I was working as an engineer — the principle of “necessity and sufficiency.” Everything else grows out of this like a crystal forming around a seed.
— How does this principle show up in your day-to-day work?
Over five years on the project, I’ve been through many stages — from excitement and eager adoption of new concepts to giving in to user requests (users here being other developers and managers), even when it messed up the code. I swear, sometimes I felt almost physical pain looking at what came out from under my “pen.”
But with time, things stabilized.
Someone needs an endpoint “by yesterday”? Okay, let’s do it.
They ask to postpone testing and jump straight to implementing authorization? I don’t think it’s a good idea, but I’ll rethink the requirements and use ABAC instead, where ACL is enough…
— What does working solo mean to you?
Working solo is about finding balance between an “ideal” solution and a “working” one.
When you have a team, they stop you in time.
When you’re alone, it’s easy to get carried away and build countless layers of abstractions and “adapter-manager-gateways” with a whole k8s cluster running on a single machine.
Mastery here is in foreseeing problematic development paths and avoiding them with minimal overhead.
— What helps you avoid overengineering and stop in time?
I always come back to the question: “Is what I’m about to do truly necessary, and is what I’ve already done sufficient?”
Ask yourself: how often have you spent time splitting two abstractions just so one could be replaced later? How often do the chosen technologies actually change?
Why build a universal repository if the entire project uses just one data source?
Most of the time, the answer to all these questions is negative—or close to it.
— Is simplicity a compromise or maturity?
I understand the desire for elegance and the instinct to cushion every possible fall. But very often it’s unnecessary.
At the same time, I’m not calling for abandoning common principles — generations of developers forged them through struggle and late-night tears. They paid too high a price for us to simply discard them.
What matters is learning to stay on that thin line between what’s necessary and what’s sufficient.
— And if you had to summarize your entire path with one piece of advice - what would it be?
Don’t let the excitement you had at the beginning fade away.
Curiosity for everything new should pull you out of bed each morning and send you hunting for knowledge, satisfying the natural hunger of a thinking human.
Programming is the unique craft that lets you combine the strict logic of engineering with the burning inspiration of creativity.
We take care of the search for a solution for you.
Inform us about your needs. We will call you for a first chat after receiving your request.