Wrong Mansur

#podcasts I’ve decided to post systematically about the podcasts I find useful and inspiring. These shows often touch on tech, self-development, or unique stories that resonate with me. Here are some recent episodes I’d highly recommend: 🎙 Как недостаток превратить в силу? Арсен Томский о роли смыслов, трудном детстве и особой миссии This episode dives into the incredible story of Arsen Tomsky, the founder of InDrive, and explores the company’s mission and values. InDrive stands out as more than just a business—it’s a movement, originating in Siberia (Yakutsk) and now one of the top 3 apps in its industry, with over 200 million downloads and operations in 45+ countries. Tomsky’s journey is deeply inspiring. He openly discusses his childhood struggles, including his experience with stuttering, and how he transformed what some might see as a disadvantage into a powerful symbol of authenticity. His story is a testament to the idea that anyone, regardless of location or personal challenges, can make a global impact. 🎙 Асель Машанова: Как за 5 лет создать компанию с годовым оборотом в 6 млрд тенге? I came across this episode while exploring nFactorial’s most popular shows, and it did not disappoint. What stood out to me were her insights into operations and decision-making at the top management level. She also shared simple yet effective advice about nutrition, steering clear of trendy supplements and focusing on basics. Arman, the host, is phenomenal—his thoughtful questions, attentive listening, and engaging style make him one of the best interviewers I’ve come across. 🎙 «Про семью — в разряде хобби». Как собеседуют топ-менеджеров в США These series are a real gem. The point here is on interviewing senior and top-level specialists in tech, providing feedback on their responses, and showcasing what makes a great interview. I found the recruiter’s questions and the constructive feedback incredibly valuable. The host’s voiceovers added another layer of depth, h

recently, I started taking Matt Pocock’s course “Claude Code for Real Engineers”. the idea I liked is that when working with coding agents, engineering fundamentals become even more important. It’s less about writing every line of code yourself, and more about clearly defining the task, guiding the process, and checking the result. I want to start a small series of posts about engineering concepts that I use in my work and life. the first one is Red-Green-Refactor. Red-Green-Refactor comes from TDD — Test-Driven Development. It is a simple cycle: first, you write a failing test (Red), then you write the minimum code to make it pass (Green), and after that you improve the code without changing its behavior (Refactor). what I like about this idea is that it makes you think about the expected behavior before implementation. You first define what the code should do, what cases it should cover, and how you will know that it works. Only after that you start writing the solution. i found this useful in many cases: at work, in pet projects, and also during interviews. For example, when you have a live coding session, it’s often better to start with test cases. It shows the interviewer that you care about quality and edge cases, and the session goes smoother because you already have a clear picture of the problem in your head. You are not randomly trying to solve something, you are moving step by step: define the behavior, make it work, then improve it. i think this approach becomes even more important when working with AI coding agents.

the second concept i liked is Tracer Bullets that comes from Progmatic Programmer. most LLMs tend to code horizontally. they build layer by layer: first models, then services, then UI, and only at the end you see if everything actually works. it can feel productive, but the problem is that feedback comes too late. tracer bullets push you to do the opposite: build a small vertical slice that goes through the whole flow. not the final version. not the perfect architecture. just one thin path that works end to end. for example: one screen, one API call, one database operation, one result back on the screen. what i like about this idea is that planning becomes more grounded. you are not trying to guess everything in advance. you quickly see the real problems: missing requirements, unclear data, wrong assumptions, integration issues. after that, it is much easier to plan the next steps. i think this is especially useful when working with AI coding agents. instead of asking an agent to build a big feature at once, i prefer to start with a tracer bullet first. small working flow → feedback → improve. it keeps the agent on track, and keeps me in control of the direction. here is do-work skill example by Matt: https://github.com/ai-hero-dev/cohort-003-project/blob/live-run-through/.claude/skills/do-work/SKILL.md