Forem: Anton Reznik

Your Junior Deserved a Markdown Too

Anton Reznik — Fri, 13 Mar 2026 14:36:39 +0000

If we approached training junior engineers the same way we now approach training AI, creating specifications and dozens and hundreds of Markdown documents for them, and gave junior engineers the same margin for error and opportunities to prove themselves, we would have many more strong specialists.

Instead, we heavily filtered people (and continue to do so), not trusting them to participate in decisions, rejecting them due to a lack of experience, a suitable team fit, or specific soft skills. But we actively accept this from each new AI model and adapt to its specifics.

I was just thinking... 🤔

Impostor syndrome doesn't make you an impostor

Anton Reznik — Wed, 25 Feb 2026 08:25:20 +0000

Impostor syndrome doesn't make you an impostor

It just means you're aware of your gaps. And that awareness is what makes you better at your job

The mistake is confusing "I still have a lot to learn" with "I don't belong here"

Those are very different things

"No-news update" — how to stay in the loop without annoying your team

Anton Reznik — Mon, 23 Feb 2026 09:42:38 +0000

from the book "Think Like a CTO"

This is one of the ideas from the book (page 164, in the Russian edition) that I fully agree with from a team management perspective. When a team is working on a task - regardless of how complex or important it is - any manager would want to get some kind of feedback, even if there's no result yet and the work is still in progress.

Generally speaking, there are dedicated ways to handle this, like daily standups and other sync calls.

💡 But I've noticed that sometimes a team lead (like me) needs that "no-news update" even between those regular touchpoints.

From the developer's perspective, of course, being constantly pinged about a task is really annoying, distracting, and can even feel like a sign of distrust from management.

And that's exactly where I see the beauty of the "no-news update" idea:

📍 The control over status updates can effectively shift to the team member - and knowing that their manager needs to stay informed, they can proactively push status updates on their own as they work through the task.

I've done this myself - both with my own managers and sometimes with user groups: sharing what we're doing now and what we plan to do next. It works 👍

The book suggests updates every 30–60 minutes, which of course only fits critical and urgent situations - not everyday work across a backlog of tasks.

📖 Review of "Think Like a CTO" by Alan Williamson

Anton Reznik — Fri, 20 Feb 2026 15:42:23 +0000

I started reading it as an e-book, then ordered a print copy, read it in bits and pieces, and eventually read it cover to cover. The book gives a general overview of what a CTO does. Senior leaders at that level probably won't find anything new here, but it's a well-written set of reminders.

Some highlights

✨ The idea of the first hundred days in a new role is explained really well (see "The First 90 Days" by M. Watkins - a whole book on that topic). It's mostly about getting to know your team, processes, and existing practices.

✨ The author shares useful tips on building a 1-on-1 culture with your team members - including what NOT to talk about in those meetings. I actually put these tips to use at KP Tech.

✨ Most of the book is about working with people - building and managing a team. This shows the author as a real team player who values team results over personal status. I liked that.

On the technical side, the author keeps things high-level rather than going deep. But he still offers a few solid recommendations. For example, on page 256 (in the Russian edition) he briefly covers one of the trickiest parts of an app release cycle - handling database schema changes.

It's not a complete guide, but it works well for getting into the role or understanding it from the outside. For that purpose, I'd recommend it 👍

Why I keep a personal work log even when the team has a task tracker

Anton Reznik — Tue, 10 Feb 2026 01:20:43 +0000

In every project, I keep a simple table for myself: plans for the week/sprint and what I actually got done. Even when the team has a task tracker and everything is logged there

Why? This kind of log gives management visibility into my workload and hours if needed, but it helps me in other ways:
⭐️ it's a log of artifacts (links, decisions, changes)
⭐️ it's material for my resume and interviews
⭐️ and, unexpectedly important, it's something that keeps me grounded on bad days or when imposter syndrome kicks in

Last year I joined a development team to help with DevOps tasks and, as usual, started keeping this table. For the team, it was only useful for tracking my work hours, but it helped me see my accomplishments over time

In the moment, almost every task felt like routine work. Only looking back at the table helped me notice something worth paying attention to: in my first three weeks on the team, while onboarding on my own, I managed to build things the team still uses after I left

In those first three weeks, I created a modular CI/CD pipeline template from scratch and made it the company standard - a catalog of separate actions that can be assembled like building blocks with parameters, where developers just need to fill in a short list of variables for their project

During the same time, I also introduced and established the practice of recording architectural decisions (ADRs) for infrastructure and DevOps tasks, plus templates for standard projects across different languages and frameworks

So I recommend this method to others - keep your own activity log. Tasks in a tracker can get visually lost among all the tasks, sprints, and columns. Some real work might not even make it into the tracker. But your own log, even though it takes some extra time, stays with you and highlights your actual work

In the end, it turns into a conversation backed by data