Nikolai Efimov

In my most recent role I noticed we had monitoring in place but it was barely useful. The Grafana dashboards existed, but they were thin — not enough metrics, no meaningful filters, missing business-critical gauges and counters, no response time charts for the flows that actually mattered. Nobody was asking me to fix this. It wasn't in my sprint, it wasn't in my job description in any explicit way. But I could see the gap and I understood why it mattered. I was genuinely curious about the business metrics myself — that's where it started. Not a sense of duty, just interest. I put together a proof of concept, brought it to my manager, then widened the conversation to a broader group. The feedback was positive, so I built it out. I want to be honest about the framing though: for a developer who understands the system, improving monitoring isn't some heroic act beyond the role — it's adjacent work that clearly serves the team and the business. It's not cold-calling clients. The line I think about is: does this create real value, and is there a reason someone else should own it instead of me? If the answer is no — I just do it. The friction I did encounter was practical, not political. My initiative was a "nice to have" — so when urgent priorities appeared, it moved to the back. That's correct. A prod bug beats a dashboard improvement. You have to be comfortable with your voluntary work being interruptible. The dashboards are now actively used by the business team. That's the only metric that matters.

One of the more technically interesting problems I solved was building a compliance alert service from scratch — a system that tracked whether companies had submitted required financial documents before regulatory deadlines, and notified them when something was missing or approaching a critical status. I was the sole developer on a small team, which meant I owned the architecture end to end — database design, microservice structure, third-party integrations, caching, everything. The core challenge was data volume and freshness. We had many companies, each with many documents, each with their own deadlines and statuses. The system had to fetch data from a third-party master system, compare it against our local records, and update statuses — green, yellow, red — depending on proximity to deadline. The first trade-off was sync frequency. Real-time updates were considered and quickly ruled out — the third-party system was too slow to handle that load, and from a business perspective daily accuracy was sufficient. So I built a cron job that ran once daily. The key design decision was making it idempotent — if the job crashed halfway through, restarting it wouldn't corrupt statuses or create duplicate records. Each run compared incoming data against existing state before writing anything. That made the system safe to re-run without manual cleanup. The second decision was around parallel processing. The cron job processed many companies simultaneously using Kotlin coroutines. I used structured concurrency to make sure failures were isolated — if one company's data fetch failed, it was logged and skipped without affecting the rest of the batch. Silent failures in a compliance context are dangerous, so this was non-negotiable. On caching — we served repeated intraday requests from cache rather than hitting the database every time. The risk in a compliance context is obvious: stale data. We handled this by always stamping responses with the exact moment the data was valid. Users always knew what they were looking at and when it was last accurate. The architecture held up. No major rewrites, no production incidents from the sync logic. Sometimes the right call is a simple, well-executed daily job rather than an elegant real-time system that creates more problems than it solves.

At one company I worked at, our team had more capacity than we were using. Not in a "push everyone to the limit" way — I value work-life balance and wasn't asking for that. But we were spending too much time waiting. Initiatives were stalled somewhere in the layers above us, and the team was sitting in limbo. In my experience, people don't mind working hard — they mind feeling irrelevant. And that's what was happening to the team's mood. I raised it directly with my manager in our regular 1-on-1. I told him I thought we had hidden capacity, that we could be building things that mattered, and that the current pace was bad not just for the company but for the team's motivation. He pushed back — his argument was about focus, not spreading attention across too many things in parallel. He had a point. But the issue wasn't parallelism. The issue was that there simply wasn't enough work coming through. He couldn't fully fix it. Some of it was above him. He acknowledged parts of what I said but couldn't move on it in any meaningful way. That conversation was the beginning of me deciding to leave. I need to feel that what I'm doing matters — that I'm contributing somewhere near my real capacity. Working at 50% doesn't feel safe or comfortable to me, it feels wasteful. For both sides. When I resigned, I told him honestly that this was part of the reason. He said he understood, though he partially disagreed. No hard feelings. I respected that he was direct back. Whether that was his genuine view or just the answer his position required — I don't know. But the conversation was clean. What I took from it: it's not enough to be able to raise disagreements. The company has to be able to respond to them. Culture fit isn't just about values — it's about whether the environment can actually adapt to you when it matters.

At a bank where I worked, we had a senior developer on the team who wrote code in a very old-fashioned style. Not just formatting — that can be fixed with a linter. This was a level above: structural choices, unnecessary constructions, patterns the rest of the team had moved away from. The whole team — four or five developers — shared the same concern. It came up repeatedly in code reviews. I was the one who pushed hardest for clean, modern practices, so I took it on directly. First in PR comments, but very quickly in person — we sat close to each other in the office, and I always prefer to have real conversations face to face rather than argue in comment threads. I told him clearly what I thought: that his approach had real drawbacks for maintainability and support down the line. He heard me. And he disagreed. His answer was essentially — I've always done it this way. Repeated attempts, same result. At some point I made a conscious decision to stop. I told him directly: I disagree, I've said what I wanted to say, I'm not going to keep pushing. And I ended it in a friendly way. The reasoning was simple. The code worked. The project was in a critical delivery phase. Escalating a style disagreement into a real conflict would have cost the team more than the imperfect code ever would. And beyond that — he had deep knowledge that the project genuinely needed. Winning the argument wasn't worth losing that, or the team's focus. One thing I was deliberate about: I didn't let this disagreement change how I treated his other contributions. I didn't start dismissing his technical opinions because I'd decided he was old-fashioned. That would have been my failure, not his. No regrets. I said what I believed. I chose the project over being right. And nothing broke.

Over the years I've worked closely with almost every function — product, design, QA, DevOps, analysts, project managers. And for a significant part of my career, in smaller teams without dedicated specialists, I played many of those roles myself. That shaped how I see cross-functional work — not as "engineering" interfacing with "other departments" but as one shared problem with different people covering different angles. The collaboration I remember most clearly was on a project where we had eight months to build a first version. The product manager set the tone early — everything documented in Confluence, all milestones mapped, epics defined, dependencies named, owners listed. It sounds basic but it's rarer than it should be. Any developer could open that document at any point and orient themselves — recall a decision, find the right person, check an alignment. It removed a whole layer of friction. The other thing that worked well was how we accepted features. Not screenshots, not "it works" in a chat message — real demos, live, with questions. Those sessions caught bugs early, surfaced edge cases, and created shared ownership of the outcome. When everyone has seen something working with their own eyes, the conversation changes. On working with non-engineers more generally — I genuinely enjoy it, partly because I spent years mentoring and learned to find the right level of explanation for whoever I'm talking to. With business people especially, I don't expect everything to land immediately, I don't feel friction when I have to rephrase, and I have zero sense that they're less valuable because they don't write code. Most IT-adjacent roles today are deeply technical in their own way. And when I do reach alignment with someone from a completely different background — when I've explained a technical constraint and they've actually understood the implication — there's real satisfaction in that. The people I collaborate with best, regardless of role, are those who take ownership of outcomes, not just their slice of the process.

Early in my career, about two months into a new job as a junior developer, I shut down a production system for 15–20 minutes. Around 50–100 internal employees lost access to a core business tool. I was trying to understand how the system worked — there was almost no documentation, and the only way to verify a small change was to restart the server and see. I thought I was on the dev environment. I wasn't.

The moment it happened, I felt it before I understood it. A vague unease that jumped from uncertainty to certainty fast — the more complaints came in from colleagues that the system was down, the clearer it became what I had done. I didn't try to fix it quietly or wait. I went to my manager immediately and told him exactly what happened. He said:

"just say it was you — we won't blame you, just tell us."

That response has stayed with me. We rolled back to the previous version quickly and the system recovered. Three things changed in me after that.

First — a junior developer who has been with a company for two months should not be able to restart a production server. That's not self-absolution, it's correct engineering. No documentation, no environment separation, no access controls. I now treat protection layers as non-negotiable on any team I'm part of — not as bureaucracy, but because I know what their absence feels like. Second — my manager handled it right. No punishment, just accountability and a fast solution together. That taught me how to behave when someone on my team makes a mistake.

Third, and most important — I had a feeling something was wrong before I pressed that button. I pushed through it. I learned that high stakes and uncertainty together are a stop signal, not something to push through. It's not about being slow or afraid to act. It's about one specific rule: if the stakes are high, don't move until you're 100% certain what you're doing. Delay is acceptable. Uncertainty at that moment is not.

On one project — a discovery project, essentially a prototype meant to prove certain theories and lay the ground for future development — we started in Kotlin. It was the language the team knew best, and for the early stages it worked fine. After about three months we had first results. And that's when the problem became visible: we were relying too heavily on native C calls, which was affecting the performance characteristics we were specifically trying to measure. If the performance data was distorted by the wrong tool, the whole point of the project was compromised. After a few discussions we made a hard call — build a parallel version in Rust. Not a rewrite exactly; we kept the Kotlin prototype as a reference point, a first working version. But we started fresh in a language none of us had real experience with. The reason was simple: without it we couldn't get clean results, and without clean results the project proved nothing. My immediate reaction was discomfort — this was new territory. But I've learned to read that feeling as a signal worth following rather than avoiding. We made sure we had realistic time for the switch, set a plan for the first steps, and put deadlines in place early. Structure matters most when things are uncertain — it keeps momentum when motivation alone isn't enough. It worked. We got the results we needed, on the right terms, because we were working in an environment that was actually suited to the problem. The broader lesson I carry from this: resistance to mid-project changes is usually about sunk cost, not logic. Three months of work felt significant. But the question was never "what have we already spent" — it was "what does this project actually need to succeed."

My honest starting point on this: if you're genuinely forced to choose between two critical deadlines, something already went wrong upstream. That situation is a symptom — of poor planning, unrealistic commitments, or priorities that were never properly defined. The right response isn't heroics, it's a conversation about what actually matters. That said — the scenario I faced most often wasn't two massive projects colliding. It was one high-priority project with a fixed deadline, and a constant stream of urgent internal requests that also had real expectations attached. A concrete example: we were in the middle of rewriting a loan application flow for a banking client — a fixed, non-negotiable deadline. At the same time, other internal teams were depending on us to adapt existing configuration logic. Both felt urgent. Both had people waiting. We escalated and made a clear call: the loan project goes first. The teams depending on the configuration work would have to wait. We didn't want to split focus and sacrifice quality on either. That decision came from the manager, as it should — it's a business call, not a developer call. Developers can and should lay out the tradeoffs clearly. But the final priority decision belongs to whoever is accountable for the business outcome. On overpromising — I've done it. Early in my career I did it regularly. Optimism felt like the right attitude. It isn't — not when deadlines are real. What experience taught me is to build in buffer before something unexpected happens, not after. And the moment you sense even a slight risk of delay, communicate it immediately. Not when it's certain. When it's possible. The review question I now ask after any deadline crunch: how did we get here? Because the crunch itself is rarely the real problem.