# Eugene Leontev The Engineer > Eugene The Engineer. Innovate, Code, and Inspire since 1984. Empathetic engineer, pragmatic code and critical thinking. People-oriented approach to software development. ## About Eugene Leontev is I fix slow, expensive backends | 100× latency gains, 100K MAU in 3 months | Fintech · PostgreSQL · AWS | Remote | Empathetic engineer, pragmatic code and critical thinking. People-oriented approach to software development. - Role: Fractional CTO & Lead Backend Engineer ## Key Topics - Ruby on Rails - PostgreSQL - Redis - AWS - Fintech - 100x latency gains - 100K MAU in 3 months ## Posts ### The Hat Technical Leaders Refuse to Wear URL: https://madmatvey.github.io/posts/the-hat-technical-leaders-refuse-to-wear/ Date: 2026-06-13 *Why technical depth stops being your bottleneck after Staff level – and what replaces it* --- Ask ten engineering managers what's missing in most technical leaders, and nine of them will say the same things: stronger architectural thinking, better system design instincts, deeper platform knowledge. They're wrong. Not slightly wrong. Directionally wrong in a way that causes real career damage. When you look not at individual opinions but at the repeating signal across engineering leadership research, practitioner communities, and organizational studies – a different answer emerges. Consistently, across seniority levels and company types, the same gap shows up: **Not architecture. Not coaching. Not strategy.** **The Ambassador Hat. The ability to influence without formal authority.** Most technical leaders never develop it. Most don't even recognize it's missing. And that gap quietly becomes their career ceiling. --- ## The Hat Metaphor I find "hats" useful here because the metaphor is literal: you put them on and take them off depending on the situation. A good technical leader isn't one type of person – they're someone who can wear different hats fluidly, and who knows *which* hat the moment requires. There are five hats that matter in engineering leadership: **Architect Hat** – system design, technical decisions, trade-off analysis, code quality, platform choices. This is what almost all engineers start with and what most continue developing indefinitely. **Operator Hat** – execution, reliability, incident ownership, delivery, keeping things running under pressure. The person who is accountable when the system is on fire at 2am. **Coach Hat** – developing people, giving feedback, creating career paths, building team capacity. Multiplying through others rather than direct output. **Strategist Hat** – roadmap alignment, long-term technical direction, connecting engineering decisions to business outcomes, making bets. **Ambassador Hat** – organizational influence without formal authority, stakeholder alignment, communication across functions, navigating political reality, coalition-building. The fifth hat is the one engineers almost universally underdevelop. (I wrote about the broader hat metaphor earlier in [Top 5 Leadership Hats for Engineering Managers](/posts/leadership-hats/). This post is about the one hat that post didn't name explicitly – and why it matters more than the rest combined at senior levels.) --- ## What the Research Actually Shows A 2025 study on engineer-to-leader transitions identified three recurring failure modes in new technical leaders: - Reverting to technical tasks when things get hard - Refusing to delegate - Trying to solve organizational problems with technical solutions The last one is the most revealing. When an engineering leader faces friction – a misaligned roadmap, a conflicted stakeholder, a team that isn't executing – their instinct is to go back to what they know. Better tooling. A cleaner architecture. A new process doc. More technical clarity. But the problem isn't usually technical. Research on what actually distinguishes strong software leaders identified five core skill clusters: People Management, Communication, Delegation, Strategic Vision, and Organizational Influence. Architecture didn't make the list as a primary differentiator. Programming didn't either. Separately, research on open-source leadership found that communication skills and the ability to unite people around shared goals predicted leadership emergence *better than technical contribution*. In communities built explicitly around technical merit, the person who rises isn't always the best coder. It's the person who can align others. This is uncomfortable for engineers. It contradicts the implicit worldview most of us built our careers on: that technical excellence is the primary driver of advancement. It is – until it isn't. --- ## The Architect Trap Here's what actually happens when senior engineers move into leadership roles. They keep wearing the hat they're best at. The Architect Hat is comfortable. It's the hat that got them promoted. It's the hat where they feel competent and confident. And frankly, it's the hat their team often *wants* them to wear – because a technically strong lead who stays hands-on makes the team's daily work easier. So new leaders go deep on system design. They review architectures. They get into PRs. They become the senior-most technical executor on the team rather than the leader of the team. This isn't laziness or bad intent. It's a rational response to the incentive structure. Engineering culture rewards technical depth visibly and immediately. It rewards organizational influence slowly and indirectly. The Architect Hat dominates because nobody explicitly tells you it needs to shrink. --- ## How the Hat Distribution Actually Changes The uncomfortable truth is that the *right* hat distribution looks radically different at each level. And most technical leaders don't adjust. **Junior Leader (new manager or tech lead)** You're still close to the technical work. Architect Hat is dominant, and that's appropriate. - 70% Architect - 20% Operator - 10% Coach **Engineering Manager (running a team)** The shift starts here. Coach Hat needs to grow substantially. Operator Hat remains important. Architect Hat should be shrinking – not disappearing, but shrinking. - 25% Architect - 35% Coach - 25% Operator - 15% Ambassador **Director of Engineering** Now you're managing managers, influencing cross-functional strategy, and operating in rooms where your authority is *never* formal. Ambassador Hat becomes critical. Strategist Hat emerges. Architect Hat drops to a minority role. - 10% Architect - 20% Operator - 30% Strategist - 40% Ambassador **CTO** At this level, the Architect Hat is almost irrelevant to daily function. The CTO who is primarily a system designer is a liability to the organization. The job is organizational alignment, board communication, engineering culture, capital allocation, and cross-functional trust. - 5% Architect - 20% Strategist - 50% Ambassador - 25% Coach Most engineers making the leadership transition accept the Coach Hat shift intellectually. They know they need to develop people. Almost none of them accept the Ambassador Hat shift. Because it feels like giving up the thing that made them successful in the first place. --- ## What the Ambassador Hat Actually Is Let me be specific, because "organizational influence" is easy to dismiss as corporate soft-skill language. The Ambassador Hat is the operational capacity to: - Walk into a room with product, finance, or the board and *change what happens* without having technical authority over anyone in it - Frame engineering decisions in terms that resonate with non-engineers without dumbing them down - Navigate competing priorities between teams without escalating every conflict - Build enough trust with stakeholders that they advocate for your team's needs in rooms you're not in - Know which battles to fight, which to concede, and which to reframe entirely This is not charm. It's not politics in the pejorative sense. It's the skill of operating at the intersection of technical reality and organizational reality – and getting coherent outcomes from that collision. And it compounds. A strong Ambassador builds coalitions that survive individual decisions. They create organizational environments where good technical work can actually happen, because the organizational conditions support it. Without Ambassador capacity, technically excellent leaders watch great architectural work get killed by misaligned stakeholders, defunded by a board that doesn't understand the value, or quietly undermined by other functions who don't trust engineering. --- ## Why Engineers Systematically Avoid It The Ambassador Hat is hard to develop for reasons that are structural, not personal. **It's invisible work.** When an engineer fixes a complex bug, there's a commit. When an architect designs a system, there's a document. When an Ambassador navigates a stakeholder misalignment and prevents a six-month roadmap detour – there's nothing to show for it. The catastrophe that didn't happen leaves no artifact. **It requires tolerating ambiguity without resolution.** Technical problems have correct answers, or at least better and worse answers. Organizational influence operates in a space where the feedback loops are long, the causation is unclear, and success sometimes looks like nothing changing dramatically. **It feels like compromise.** Engineers who care deeply about technical quality often experience stakeholder management as capitulation – explaining themselves to people who don't understand, making trade-offs they didn't want to make, softening positions to build coalitions. It can feel like lowering standards. It isn't. It's operating at a different level of system. **The cost is delayed.** An engineer who avoids the Ambassador Hat can perform very well at senior and staff level for years before hitting the ceiling. The reckoning comes late, which makes the causal connection hard to see. --- ## The Career Ceiling Formulation Here's the formulation I keep coming back to: > Most technical leaders spend years improving the hat they already have. Their career is limited by the hat they refuse to wear. The Architect Hat ceiling – the point where more architectural skill stops producing more career outcomes – arrives at roughly senior or staff level. After that, the limiting factor shifts. And the hat that limits nearly every technical leader at director and above is not the Strategist Hat and not the Coach Hat. It's the Ambassador Hat. Because almost every engineer voluntarily develops the Architect Hat. Very few consciously develop the Ambassador Hat. So the gap compounds over time, and it becomes invisible until the promotion doesn't happen, or the leadership role doesn't feel right, or the organization keeps going around them on decisions they should be shaping. --- ## What Developing It Actually Looks Like Practically, developing Ambassador capacity looks like: **Speaking the language of the room you're in.** Not simplifying – translating. The same infrastructure decision that needs technical precision in an engineering review needs business-outcome framing in a board discussion. This is a skill, and it's learnable. **Building relationships before you need them.** Ambassador capacity is relationship capital. It's accumulated in low-stakes moments and deployed in high-stakes ones. Engineers who only engage with stakeholders when there's a conflict are constantly operating at zero balance. **Creating wins for other functions.** Organizational influence compounds when other teams have reasons to advocate for you. Engineering leaders who understand what product, finance, or operations actually need – and who occasionally prioritize those needs – build durable cross-functional trust. **Learning to frame trade-offs, not just identify them.** Technical leaders are good at seeing trade-offs. Ambassadors are good at *presenting* trade-offs in ways that make the right organizational decision obvious. Those are different skills. --- ## The Point If you're an engineering leader, the honest question is: which hat are you avoiding? Not which hat you're bad at – that's easy to identify. Which hat do you actively resist developing, because it feels like it conflicts with your identity as a technical person? For most engineers, the answer is the Ambassador Hat. And the longer you avoid it, the more it becomes the thing that limits everything else you're capable of. The career ceiling isn't usually technical. It's the hat you refuse to wear. --- *This article is based on research across engineering leadership transitions, practitioner communities, and organizational studies. The "Leadership Hats" framework is a practical model, not a rigid taxonomy – the percentages are directional, not prescriptive.* Hitting a leadership ceiling and can't tell which hat you're refusing to wear? [Connect on LinkedIn](https://www.linkedin.com/in/eugeneleontev/). Fractional CTO engagements, limited to a few teams per quarter. --- ### The Level 3 Trap: Eight Levels of Product-Minded Engineering URL: https://madmatvey.github.io/posts/the-level-3-trap-eight-levels-of-product-minded-engineering/ Date: 2026-06-12 *They were the most productive team I'd ever seen building the wrong things.* --- I worked with a fintech team of eight engineers running 40+ tickets a sprint. Velocity was healthy. PRs merged daily. Standups were efficient. Nobody was slacking. Their core activation metric had been flat for three quarters. The team wasn't broken. They were stuck – at a level nobody had a name for. I've since developed an eight-level framework I use to assess every engineer I work with. Not as a hierarchy of seniority titles, but as a map of where someone's instincts actually fire when they get a new task. Most teams stall at Level 3. It feels like mastery. It isn't. It's the edge of the map. --- ## Level 1 – Problem Discovery **Junior instinct:** "The user wants X." **Product-minded instinct:** "Why do they want X?" The gap between these two sentences is the entire career of most engineers who never cross into product thinking. **Artifact of mastery:** you threw away a feature you already built because one user conversation revealed the wrong assumption underneath it. This level isn't about saying no to stakeholders. It's about holding the problem loosely enough that evidence can change it. The engineers who struggle here treat requirements as immutable. The ones who've internalized Level 1 treat them as hypotheses with an expiration date. --- ## Level 2 – Outcome Thinking **Average engineer:** "I closed the ticket." **Product-minded engineer:** "What changed after we shipped?" The release isn't the end of the work. It's the beginning of measurement. I've watched teams celebrate sprint completions while the metric they were supposed to move didn't budge. The ticket system recorded success. The product recorded nothing. Level 2 engineers ask what signal they're waiting for before they merge. They know the difference between *shipped* and *worked*. They'll reopen their own PR if the instrumentation was wrong. --- ## Level 3 – User Empathy The most underrated level. Almost every team stalls here permanently. You've earned it when you can complete this sentence in under five seconds: **"The user is frustrated because..."** Not from reading a ticket. From watching sessions. From reading the angry emails. From taking one support shift. Level 3 feels like mastery. It isn't. I see this constantly: engineers who can articulate user pain with genuine specificity, who've done the research, who care – and still can't connect that empathy to business tradeoffs, experiment design, or the courage to kill their own work. They've reached the edge of the map and mistaken it for the destination. The fintech team I mentioned? They were here. Deeply. Genuinely. They could describe user frustration in detail. They just couldn't translate it into *what we should stop building*. That's the trap. --- ## Level 4 – Economics This is where Staff-level engineering actually begins. You've canceled a technically elegant solution because the ROI wasn't there. You've defended an ugly fix through business impact, not code elegance. Impact / Effort appears in your mental stack *before* Code Quality. Level 4 is uncomfortable because it requires saying "this isn't worth doing" when the technical solution is beautiful. It requires advocating for the hack that ships this week over the refactor that ships next quarter – when the data supports it. Engineers who operate here stop optimizing for elegance in isolation. They optimize for leverage. --- ## Level 5 – Fast Experimentation You validated a hypothesis before writing a single line of production code. You threw away a week of work without drama. You were publicly wrong and adjusted. Most teams optimize for delivery. Discovery exists precisely to avoid building the wrong thing. Level 5 engineers treat code as one of several tools – not the default tool. They'll run a concierge test, a fake-door experiment, a prototype in a spreadsheet, a shadow deployment. They measure the cost of being wrong in days, not quarters. The fintech team shipped constantly but experimented rarely. Every ticket was production code. Every hypothesis was a feature. That's expensive discovery. --- ## Level 6 – Product Communication The underrated career multiplier. Almost nobody develops it intentionally. You're here when people use *your framing* to describe a problem. Not because you're the most senior, but because you articulated it most clearly. Level 6 isn't about being loud in meetings. It's about making the invisible visible – turning a vague product tension into a decision frame that others can act on. The best Level 6 engineers I know write better than most PMs. They draw the system. They name the tradeoff. They make the meeting shorter. This skill compounds across an entire organization. One engineer who can frame problems well changes how ten other people think about them. --- ## Level 7 – Ownership Nearly impossible to fake. - Woken up at 3am for a prod incident you caused - Fixed your own release under pressure, not someone else's - Felt shame about a decision from six months ago - Felt pride about one from two years ago I've been paged at 3am for a migration I wrote that took down a payments queue. That incident is the reason I can identify Level 7 engineers in a twenty-minute conversation. You've stopped saying: "That's not my responsibility." You're saying: "This affects the product." Ownership isn't heroics. It's the accumulated weight of decisions you made, outcomes you tracked, and failures you didn't outsource. Engineers at this level don't need permission to care. --- ## Level 8 – AI Orchestration The 2026 separator. You've delegated to an AI agent, gotten a bad output, and understood the problem was your *context*, not the model. Now you spend more time on: - **Problem definition** - **Context creation** - **Output validation** ...than on writing code. Level 8 isn't about using Copilot. Everyone does that. It's about treating AI as a collaborator whose output quality is a function of how well you defined the task. The engineers who've internalized this don't chase model benchmarks – they chase context architecture. (I wrote more about this in [The AI Model Is No Longer The Bottleneck](/posts/the-ai-model-is-no-longer-the-bottleneck/).) Building got cheap. Choosing what to build got expensive. Level 8 engineers know which side of that equation they're paid for. --- ## The Final Test When you get a new task, what fires first? | Instinct | First question | |---|---| | Engineer | "How do we build this?" | | Senior | "What's the architecture?" | | Product-minded | "Why does this matter?" | | Product-minded in the AI era | "Is this even the highest-leverage problem we could be solving right now?" | That last question is the most valuable engineering skill of this decade. AI makes building cheap. **Choosing the right problem is getting more expensive.** --- ## What I See in the Field At a workshop I ran for 60+ senior Ruby engineers last year, the pattern was consistent. The engineers asking that last question were mostly already in leadership roles or actively moving into one. The ones shipping the most code were often building the least impactful things. The Level 3 trap is real. It's just invisible until the metric doesn't move. You can have high velocity, strong empathy, clean code, and a flat activation curve – all at the same time. The dashboard won't tell you you're stuck. Only the outcome will. --- ## Where Does Your Team Actually Operate? This framework isn't a grading rubric for performance reviews. It's a diagnostic. When I work with founders and CTOs on fractional engagements, the first thing I map isn't the org chart – it's where the senior engineers actually sit on this scale. The gap between perceived seniority and operational level is often the reason metrics don't move despite healthy sprint velocity. If you can't tell where your team operates, that's the gap worth closing before you hire another engineer. --- What level does your team actually operate at – and what broke because of it? Scaling a technical team and can't tell where your senior engineers sit on this map? [Connect on LinkedIn](https://www.linkedin.com/in/eugeneleontev/). Fractional CTO engagements, limited to a few teams per quarter. --- ### How We Reduced PostgreSQL Query Time from 250ms to 20ms URL: https://madmatvey.github.io/posts/how-we-reduced-postgresql-query-time-from-250ms-to-20ms/ Date: 2026-06-11 *A production story about wrong indexes, escaped prisoners, and the query rewrite nobody wanted to do.* --- There's a particular kind of engineering pain that doesn't show up in sprint planning. It accumulates quietly. A slow query here, a timeout there, a database CPU spike that costs you $20 to paper over. You file it under "technical debt," pay the bill, and move on. Until one day you can't anymore. This is that story. --- ## The Background Our backend is a Rails API on top of PostgreSQL, running at 8–10k RPM during the day with peaks around 25k RPM. The database lives in Amazon RDS — a `db.t3.xlarge`, 4 vCPU, 16GB RAM. T-type instances in RDS work on a credit model: run below your CPU baseline and you bank credits; hit a spike and you spend them. In theory, it's elegant cost management for bursty workloads. In practice, we were slowly bleeding the credit balance dry. For a while, we just topped it up. $20/month felt like a rounding error against our total infra spend. But the thing about gradual degradation is that it rarely stays gradual. It compounds. Database latency bled into endpoint response time. Endpoint response time bled into user experience. And I found myself in a pattern I recognized: putting out fires instead of writing code. One day I wrote as much in our daily standup. Went to the project manager, explained the situation, and asked for dedicated time to actually investigate rather than patch. Got the green light. Opened New Relic. What I saw confirmed the suspicion. --- ## Finding the Suspect The New Relic timeline told a clear story: during peak load, response times regularly spiked past 1000ms. The yellow band — Postgres time — was swallowing most of it. Some requests were spending the majority of their lifecycle waiting on the database. That narrowed the problem considerably. This wasn't a Ruby performance issue or a background job congestion. Something in the SQL layer was broken. I installed [PgHero](https://github.com/ankane/pghero) to read from `pg_stat_statements`. This is one of the most underused diagnostic tools in the Rails/Postgres stack — it gives you query-level statistics aggregated over time: total time, average time, call count. The default sort by Total Time is exactly where you want to start. It surfaces the queries that matter, not just the ones that are slow in isolation. Slow queries in PgHero are flagged at >100 calls/day and >20ms average. Our top offender wasn't borderline. It was averaging **250ms** and running hundreds of times per hour during peak load. I pulled the `EXPLAIN ANALYZE` output into [explain.depesz.com](https://explain.depesz.com) and found what I was looking for: an Index Scan flagged red. The query was hitting an index on `created_at` — a broad, time-ordered index covering the entire table. Around **500,000 rows** scanned to return **40 results**. That's not a query. That's a haystack search. --- ## Understanding the Data Shape The query was for an in-app feature — a lottery-style mechanic where users bet internal currency. Each "battle" record has a status (e.g., `waiting_for_players`, `completed`, `cancelled`) and a bet amount. The query was looking for open battles where the bet didn't exceed the user's current balance. Here's what the data actually looked like: - **~500,000 total battle records** in the table - **~40 records** with status `waiting_for_players` at any given moment The existing index covered the full table by `created_at`. The query was doing a sequential scan through half a million historical records to find 40 active ones. The selectivity was catastrophically wrong. The fix was a **partial index** — an index that only exists for the subset of rows that matter: ```ruby add_index :arena_battles, :bet, where: "status = 'waiting_for_players'", name: "index_arena_battles_on_bet_partial_status" ``` This index covers only the 40 active records. It weighs **40 kilobytes** versus the original index at **40 megabytes**. We deployed the migration. The endpoint response time dropped from ~250ms to ~30ms within hours. We celebrated. Too early. --- ## The Regression Four days later, the latency was back. Postgres has a query planner. The planner decides which index to use based on statistics it collects about data distribution. After a period of writes and reads, the planner had looked at both indexes and decided — incorrectly — that reverting to the old `created_at` index was more efficient. It wasn't. But statistics lie, especially when data distribution is extreme. We were back to 250ms. The standard playbook when a planner makes a bad decision: 1. Tune Postgres statistics/cost settings 2. Upgrade Postgres (we were on 9.6.11 — bumping to 9.6.15 was worth trying) 3. Look more carefully at what query Rails is actually generating The third path led somewhere interesting. --- ## The Accomplice Rails was generating this: ```sql SELECT "arena_battles".* FROM "arena_battles" WHERE "arena_battles"."status" = 'waiting_for_players' AND (arena_battles.bet First published on [Habr](https://habr.com/ru/articles/509406/) in 2020. An earlier version with the detective metaphor lives [here](/posts/sql-optimization-or-criminal-tracking/). Working on a Rails/Postgres system showing early signs of this pattern? [Connect on LinkedIn](https://www.linkedin.com/in/eugeneleontev/). --- ### The AI Model Is No Longer The Bottleneck URL: https://madmatvey.github.io/posts/the-ai-model-is-no-longer-the-bottleneck/ Date: 2026-06-04 For the last year, developers have been arguing about models. Claude. GPT. Gemini. DeepSeek. Benchmarks. Leaderboards. Context windows. The assumption underneath every comparison is always the same: **better model → better outcome.** I spent months believing this. I tested each one. Every time a new benchmark dropped, I reconsidered my stack. Every time the internet declared a winner, I reran my workflows to check. Sometimes it helped. Mostly it didn't. Because the real bottleneck wasn't reasoning quality. It was how the agent interacted with my codebase. --- After enough production work with AI-assisted development, you start noticing something uncomfortable: The biggest productivity differences rarely come from switching models. They come from switching workflows. --- ## Most AI coding discussions are happening at the wrong layer A model does not: * Collect context from your repository * Navigate large, messy, real-world codebases * Manage long-running, multi-step tasks * Decide which files are actually relevant * Organize tool usage against your project structure The agent does. The workflow does. The interface does. Try asking an IDE assistant to reason coherently about a 300k-line Rails monolith – 12 years of accumulated context, three authentication systems, no clean module boundaries, and half the domain logic living in callbacks. You don't hit a model limitation first. You hit an agent limitation. The model is waiting for context it was never given. This is why the same model can feel dramatically different depending on where you run it. Same engine. Different vehicle. When developers argue "Claude is better than GPT for coding," they're often measuring the vehicle, not the engine. --- ## The model is becoming a commodity Most frontier models are now "good enough" for the majority of engineering tasks. The differences still matter. But they're getting smaller than most people think. Meanwhile, the workflow differences are getting larger. I ran the same model through two different agent setups on a high-traffic Rails codebase. Same model. Same repository. Different agent configuration – specifically how context got assembled before each request. The difference wasn't marginal. One setup generated suggestions I had to rewrite before they were usable. The other generated changes I could ship. The time I spent reviewing and correcting AI output dropped by roughly half – without touching the underlying model. A mediocre agent running a strong model will consistently underperform a well-designed agent running a mediocre one. That's not a hot take. That's been my production reality. --- ## Lock-in is the new tech debt Most AI coding tools quietly assume: * Their editor * Their workflow * Their pricing model * Their ecosystem Tool lock-in in AI development follows the same pattern as vendor lock-in in cloud infrastructure. Invisible – until the pricing changes. Until the product gets deprecated. Until the provider pivots and you're no longer the priority. By then your team has built workflows around it. Your engineers have formed habits around it. Your onboarding assumes it. The switching cost is always higher than teams estimated upfront. And nobody accounts for it when choosing their AI stack. They optimize for "best model support today." Not for "what happens when the model landscape looks completely different in six months." --- ## Open systems age better The longer I work in engineering, the more I trust boring abstractions. PostgreSQL. Linux. Git. The reason isn't features. The reason is optionality. Open systems survive because they let you swap components without rebuilding everything around them. Your AI toolchain should have the same property. --- ## Why I ended up using [OpenCode](https://opencode.ai/go?ref=S98551RPHS) Not because it has the best model. It doesn't have one. That's the point. [OpenCode](https://opencode.ai/go?ref=S98551RPHS) is built on a different assumption: **Models are replaceable. Your workflow isn't.** It runs in the terminal. Works across multiple providers. Supports local models. Doesn't force a specific editor. Keeps the agent layer architecturally separate from the model layer. That design decision matters more to me than another benchmark screenshot. Because whatever model is "winning" benchmarks today will look different in six months. The workflow you've built, the habits your team has formed, the agent configuration that actually fits your codebase – that's durable. So are the skills you encode around it. I contributed to the [Security & Systems](https://github.com/TheArchitectit/awesome-opencode-skills#security--systems) section of [awesome-opencode-skills](https://github.com/TheArchitectit/awesome-opencode-skills) – a curated list of OpenCode skills you can install, share, and swap without rebuilding your stack every time the model leaderboard shifts. --- ## The most expensive AI mistake is optimizing the wrong layer I've seen this pattern before. In backend systems work. Teams spend weeks debating: * Which database * Which cloud provider * Which framework While the actual bottleneck sits somewhere else entirely, invisible, compounding. AI tool adoption is following the same pattern. Teams spend cycles on which model, which benchmark, which provider. Meanwhile the real questions aren't getting asked: * How does context get assembled for your specific codebase? * How does the agent navigate large, messy, real-world repositories? * How do engineers review AI-generated changes at scale without losing oversight? * What happens when your primary provider has an outage or changes pricing? * How do you avoid lock-in as the model landscape continues to shift? If those answers are weak, switching from Claude to GPT won't save you. It's the same lesson I've learned repeatedly from production systems: **The biggest bottleneck is usually not where everyone is looking.** --- Also on [LinkedIn](https://www.linkedin.com/pulse/ai-model-longer-bottleneck-eugene-leontev-yerlf/). --- ### I Built a Local AI Scorer for My LinkedIn Posts URL: https://madmatvey.github.io/posts/ai-system-linkedin-content-analysis/ Date: 2026-05-11 LinkedIn gives you data. Signal? Not always. For months I stared at the native analytics dashboard trying to answer one simple question: *what content actually moves me toward the kind of people I want to work with?* Not “what got impressions.” Not “what got dopamine.” Actual signal. Because look — dashboards love showing numbers. Numbers feel smart. But most analytics are basically a car dashboard that proudly tells you the wheels are spinning without explaining why you're driving into a ditch. So I built my own evaluation pipeline. Not because “AI”. Because I got tired of guessing. --- ## The actual problem LinkedIn analytics tells you what happened. It rarely tells you: * which topics attract CTOs and founders specifically * what kind of posts generate inbound conversations * where you're drifting into content noise * whether you're building positioning or just farming engagement You get metrics. You don't get decisions. Different thing. --- ## What the system does ### 1. Pulls full post content LinkedIn exports are kinda funny. You get links, timestamps, reactions. But not the actual thing people read. So I use Playwright to scrape every post body into PostgreSQL. Because analyzing “engagement” without content is like debugging production from CPU graphs only. Good luck with that. --- ### 2. Scores posts against a real goal This is the part most “AI analytics” tools quietly skip. You first need to define: **what does “good” even mean?** My goal is simple: > attract inbound opportunities from CTOs, founders, and technical leadership. So every post gets scored across six dimensions: * audience fit * technical depth * problem clarity * business impact * inbound potential * signal vs filler Each score comes with rationale. No magic black box nonsense. Basically I wanted something closer to: “why this worked” instead of “congrats, number go up.” --- ### 3. Maps topics against outcomes Every post gets classified into topic buckets: * backend scaling * system design * engineering leadership * AI engineering * hiring * reliability * CTO/founder perspective * etc Then I compare that against engagement and inbound patterns. And honestly, some results were uncomfortable. Some high-effort posts performed terribly against the actual goal. Meanwhile some simple posts with: * one real production problem * one non-obvious insight * one strong opinion ...worked significantly better. Which is a useful reminder: Effort is not value. Alignment is. --- ## Stack Nothing exotic, honestly. * Ruby 4 * PostgreSQL + pgvector * Sequel * Playwright * RubyLLM * Ollama * local models * Solid Queue No hosted AI APIs. No “AI SaaS platform”. No VC-funded abstraction lasagna. Just boring infrastructure solving a concrete problem. Funny how often that still works. --- ## The interesting part The biggest lesson was not about models. I used open-source models end-to-end. The important part was the evaluation contract. Meaning: * what “good” means * what success means * what dimensions matter * what drift looks like Honestly, this is where many AI projects go sideways. Teams spend weeks debating models like they're choosing a religion. Meanwhile nobody clearly defines: * goals * scoring * failure modes * feedback loops So the system produces statistically sophisticated confusion. --- ## The broader pattern This architecture works almost anywhere you have: 1. a defined goal 2. historical data 3. a scoring system Content strategy. Lead scoring. Hiring funnels. Support quality. Sales messaging. Engineering reviews. Same loop every time: > define good → score reality → detect drift → refine Basically production engineering, just applied to decision systems. --- ## Five questions before building production AI 1. What exactly are you optimizing for? 2. How do you measure “good”? 3. What taxonomy are you using? 4. What score is acceptable without review? 5. How do you detect drift over time? If these answers are vague, the model is not your bottleneck. The thinking is. --- This is also why I increasingly distrust generic “AI strategy” conversations. A lot of them sound impressive right until you ask: “Okay. What exact business decision improves because of this?” And suddenly the room becomes quieter than a Kubernetes cluster after someone accidentally deleted production. --- ### Single-Threaded on the Outside, Multithreaded on the Inside URL: https://madmatvey.github.io/posts/redis-is-single-threaded/ Date: 2026-03-04 Every Rails developer has heard it: *"Redis is single-threaded."* Few people know exactly what that means. And fewer still know that it's only half the story. Redis serialises command execution on a single main thread. That part is true. But I/O, persistence, and memory management have been running on separate threads and processes for years. Since Redis 6.0, even network reads and writes are handled by a dedicated pool of I/O threads. At 8 I/O threads, throughput improves by 37–112% on multi-core hardware. This distinction matters in practice. When you misunderstand Redis's execution model, you misconfigure it. Misconfigurations in production mean either lost Sidekiq jobs, blocked event loops, or quietly filling memory with no TTLs. This article walks through how Redis actually works, and how to use that knowledge to configure Redis correctly in every part of a Rails application. --- ## The Common Misconception The phrase "Redis is single-threaded" leads engineers to two wrong conclusions: First, that Redis is therefore slow or poorly suited for concurrent workloads. Second, that because it's simple under the hood, a single instance with default configuration is fine for everything. Both are wrong. Redis's command serialisation is a deliberate architectural decision. It eliminates lock contention entirely. There are no mutexes around data structures, no deadlocks, no context switches between competing threads trying to access the same key. A single serialisation point is not a bottleneck when that point can process hundreds of thousands of commands per second. The speed of Redis comes from three things: data lives in RAM, there is no lock overhead, and the event loop is extremely efficient at managing thousands of concurrent connections with almost no CPU waste. "Single-threaded" is not the reason Redis is fast. It's a side effect of the architecture that makes Redis fast. --- ## What Is Actually Happening Inside Redis A running Redis process is composed of several distinct execution layers. ### The Event Loop and I/O Multiplexing The main thread runs a tight event loop built on the Reactor pattern. Instead of assigning a thread to each client connection, Redis uses the operating system's notification mechanisms to watch all connections simultaneously: `epoll` on Linux, `kqueue` on BSD and macOS, and `select` as a fallback. The loop does not block waiting for a client to send data. The OS notifies Redis the moment a socket has data ready to read. This allows one thread to efficiently serve tens of thousands of simultaneous connections. The cost of managing a connection that is idle is nearly zero. This is what makes the single-threaded model viable. The thread is never sitting idle waiting for network I/O. It is only ever doing actual work: parsing commands and executing them. ### I/O Threading Since Redis 6.0 Before version 6.0, the main thread was responsible for the entire request lifecycle: reading the socket, parsing the command, executing it, and writing the response back. This worked well, but on multi-core hardware it left significant CPU capacity unused. Redis 6.0 introduced a dedicated pool of I/O threads. These threads now handle socket reads and writes, freeing the main thread to focus exclusively on command execution. The main thread still executes all commands serially. But the heavy lifting of network I/O is now parallelised. To enable this: ``` # redis.conf io-threads 4 io-threads-do-writes yes ``` A reasonable starting point is one I/O thread per two CPU cores, leaving headroom for the main thread and OS work. Benchmarks from the Redis authors show a 37–112% throughput improvement with 8 I/O threads under high-connection, high-throughput workloads. ### Persistence Mechanisms Redis's persistence does not happen on the main thread. **RDB (point-in-time snapshots):** Redis calls `fork()`. The child process writes the entire dataset to disk while the main process continues serving requests. The Linux kernel's copy-on-write semantics mean the child gets a consistent view of memory without duplicating it upfront. Pages are only copied when the main process writes to them. **AOF (Append-Only File):** Every executed command is appended to an in-memory buffer. A background thread handles flushing this buffer to disk with `fsync`. The `appendfsync` configuration controls the trade-off: `always` gives the strongest durability guarantee, `everysec` gives a one-second data loss window with much better performance, `no` delegates flushing to the OS. ### Lazy Memory Freeing Deleting a large key — a sorted set with a million members, or a hash with complex nested values — is an O(N) operation. Before Redis 4.0, this happened synchronously on the main thread, causing latency spikes. Since Redis 4.0, `UNLINK` offloads memory deallocation to a background thread. The key is immediately removed from the keyspace (so subsequent lookups return nil), but the memory is freed asynchronously. For large keys in production, prefer `UNLINK` over `DEL`. ### The Full Picture A production Redis process at any moment may have: - The **main thread** executing commands serially - **N I/O threads** reading and writing sockets in parallel - A **forked child process** writing an RDB snapshot - A **background thread** flushing the AOF buffer or compacting it during rewrite - A **background thread** freeing memory from recent `UNLINK` calls This is not a single-threaded application. It is a coordinated multi-layered system with a single point of command serialisation. --- ## Atomicity and Transactions Every Redis command is atomic. `INCR`, `SETNX`, `LPUSH` — none of these can be interrupted mid-execution by another client. Because all commands execute on the main thread serially, there is no partial state. `MULTI/EXEC` provides a form of batched execution: commands queued inside a `MULTI` block are executed as a unit without interleaving from other clients. However, this is not a transaction in the database sense. There is no rollback. If a command within the block fails at runtime, the others still execute. For true atomic multi-step logic, Lua scripts are the right tool. A script executed with `EVAL` runs entirely on the main thread without interruption. This makes it suitable for patterns like atomic increment-with-TTL for rate limiting: ```ruby # Atomic rate limit check: increment counter, set TTL on first call RATE_LIMIT_SCRIPT = limit end ``` `WATCH` combined with `MULTI/EXEC` provides optimistic locking: if a watched key is modified by another client before `EXEC` is called, the entire transaction is aborted and returns `nil`. This is useful for read-modify-write patterns where you need to detect concurrent modification. --- ## Pub/Sub, Lists, and Streams Redis is not only a key-value store. It provides three distinct mechanisms for inter-process communication, each with different guarantees. **Pub/Sub** is fire-and-forget. Messages are delivered to all subscribers currently listening on a channel. If no one is subscribed, the message is dropped. There is no persistence, no replay, no acknowledgement. This is what Action Cable uses to broadcast WebSocket messages between Puma workers: it works because the subscriber (the Action Cable server) is always running. **Lists with LPUSH/BRPOP** are how Sidekiq implements its job queue. `BRPOP` blocks until an item is available, then pops it atomically. If the worker process crashes after popping but before finishing the job, the job is lost unless Sidekiq's visibility timeout and retry logic account for it. This is why Sidekiq requires `noeviction` — if Redis evicts a job under memory pressure, it disappears silently. **Redis Streams** are a persistent, ordered log with consumer groups. A message written to a stream stays there until explicitly deleted. Consumer groups allow multiple workers to divide a stream between them, with explicit acknowledgement (`XACK`) required before a message is considered processed. For event sourcing, audit logs, or any pattern requiring durable delivery and replay, Streams are the right choice — not Pub/Sub. | | Pub/Sub | Lists (Sidekiq) | Streams | |---|---|---|---| | Persistent | No | Yes (until consumed) | Yes | | Delivery guarantee | None | At-least-once (with retries) | At-least-once | | Consumer groups | No | No (single queue) | Yes | | Replay | No | No | Yes | | Rails use case | Action Cable | Sidekiq | Event sourcing, audit logs | --- ## The Right Topology: Separate Redis Instances per Role The most consequential configuration decision in a Rails application is not what data to cache or how to structure keys. It is whether to use one Redis instance for everything or separate instances per role. Different parts of a Rails application have fundamentally incompatible requirements: | Component | Eviction Policy | Persistence Needed | Notes | |---|---|---|---| | `Rails.cache` | `volatile-lru` | No | Losing cache is acceptable | | Sidekiq | `noeviction` | Yes (AOF) | Losing a job is a bug | | Action Cable | `noeviction` | No | Pub/Sub state is transient | | Sessions | `volatile-lru` | Optional | Logged-out users are acceptable | | Rate limiting | `volatile-lru` | No | Keys have TTLs by design | If you run Sidekiq and your cache on the same Redis instance, you must choose one eviction policy for both. Choose `volatile-lru` and Redis may quietly delete Sidekiq jobs when memory is under pressure — only volatile keys (those with TTLs) are eligible, but Sidekiq keys typically have no TTL, so they would survive until Redis actually fills up and errors. Choose `noeviction` and Redis will start returning errors on cache writes instead of evicting stale entries. There is no eviction policy that is correct for both roles simultaneously. The minimum viable production setup is two Redis instances: one for persistent data (Sidekiq, sessions) with `noeviction` and AOF enabled, and one for cache with `volatile-lru` and no persistence. A complete setup uses four: ``` redis-cache → Rails.cache, rate limiting (volatile-lru, no AOF) redis-queue → Sidekiq (noeviction, AOF enabled) redis-cable → Action Cable (noeviction, no persistence) redis-sessions → Session store (volatile-lru, optional AOF) ``` In your Rails environment configuration: ```ruby # config/environments/production.rb # Cache store config.cache_store = :redis_cache_store, { url: ENV["REDIS_CACHE_URL"], expires_in: 1.hour, error_handler: ->(method:, returning:, exception:) { Sentry.capture_exception(exception) } } # Action Cable adapter config.action_cable.cable = { "adapter" => "redis", "url" => ENV["REDIS_CABLE_URL"] } ``` ```ruby # config/initializers/sidekiq.rb Sidekiq.configure_server do |config| config.redis = { url: ENV["REDIS_QUEUE_URL"] } end Sidekiq.configure_client do |config| config.redis = { url: ENV["REDIS_QUEUE_URL"] } end ``` --- ## Connection Pooling in a Puma Application Puma runs multiple threads per worker. By default, 5 threads per worker process. Without a connection pool, each thread opens its own TCP connection to Redis. With three Redis-backed components (cache, Sidekiq client, Action Cable), that is 15+ connections per worker, most of which sit idle most of the time. The `connection_pool` gem solves this by maintaining a fixed pool of connections shared across threads. A thread checks out a connection, uses it, and returns it to the pool. ```ruby # config/initializers/redis.rb REDIS_POOL = ConnectionPool.new( size: ENV.fetch("RAILS_MAX_THREADS", 5).to_i, timeout: 3 ) do Redis.new( url: ENV.fetch("REDIS_CACHE_URL"), reconnect_attempts: 3, reconnect_delay: 0.5 ) end ``` ```ruby # Usage anywhere in the application REDIS_POOL.with do |redis| redis.setex("session:#{id}", 3600, payload) end ``` The `redis-client` gem (the default since redis-rb 5.0) also ships with built-in connection pooling. Configure it explicitly rather than relying on defaults: ```ruby Redis.new( url: ENV["REDIS_URL"], reconnect_attempts: 2, reconnect_delay: 0.2, reconnect_delay_max: 0.5 ) ``` --- ## Redis Across All Rails Components Here is what correct Redis usage looks like across the standard Rails application stack. ### Rails.cache ```ruby # app/models/product.rb def self.featured(limit: 10) Rails.cache.fetch("products:featured:#{limit}", expires_in: 30.minutes) do where(featured: true).includes(:category).limit(limit).to_a end end # Fragment caching with automatic versioning # app/views/products/show.html.erb ``` Always set `expires_in`. Keys without TTLs accumulate silently until the instance hits `maxmemory`. ### Sidekiq ```ruby # app/jobs/report_generator_job.rb class ReportGeneratorJob < ApplicationJob queue_as :default sidekiq_options retry: 5, dead: false def perform(user_id, report_params) user = User.find(user_id) report = Reports::Generator.call(user, report_params) ReportMailer.with(user: user, report: report).send_report.deliver_now end end # Enqueue ReportGeneratorJob.perform_later(current_user.id, params.to_unsafe_h) ``` Sidekiq requires `noeviction` on its Redis instance. Set `maxmemory-policy noeviction` and configure memory alerts at 70–80% usage. A full Redis with `noeviction` returns errors on writes — it does not silently lose data. ### Action Cable ```ruby # app/channels/notifications_channel.rb class NotificationsChannel < ApplicationCable::Channel def subscribed reject unless current_user stream_for current_user end def unsubscribed stop_all_streams end end # Broadcasting from a job or model callback NotificationsChannel.broadcast_to( user, { type: "notification", message: text, timestamp: Time.current.iso8601 } ) ``` Action Cable uses Redis Pub/Sub. The channel subscription is maintained per Puma worker. When a message is broadcast, it is published to Redis, and all Puma workers subscribed to that channel receive it and forward it to their WebSocket clients. ### Rate Limiting with Rack::Attack ```ruby # config/initializers/rack_attack.rb Rack::Attack.cache.store = ActiveSupport::Cache::RedisCacheStore.new( url: ENV["REDIS_CACHE_URL"] ) # Throttle API calls by IP Rack::Attack.throttle("api/ip", limit: 100, period: 60) do |req| req.ip if req.path.start_with?("/api/") end # Throttle login attempts by email Rack::Attack.throttle("login/email", limit: 5, period: 300) do |req| req.params["email"]&.downcase if req.path == "/sessions" && req.post? end # Block abusive IPs permanently Rack::Attack.blocklist("block bad actors") do |req| BlockedIp.exists?(ip: req.ip) end ``` Rate limiting keys have TTLs by design, so the cache instance with `volatile-lru` is appropriate here. --- ## Failure Modes and Anti-Patterns These are the most common ways Redis becomes a production incident. **`KEYS *` in production.** This is an O(N) operation that blocks the event loop for every client while it scans the entire keyspace. On an instance with 10 million keys, this can take seconds. Use `SCAN` with a cursor instead — it iterates incrementally without blocking: ```ruby # Never do this in production redis.keys("user:*") # Do this instead cursor = "0" loop do cursor, keys = redis.scan(cursor, match: "user:*", count: 100) keys.each { |key| process(key) } break if cursor == "0" end ``` **Storing large serialised objects.** Values over 1MB indicate a design problem. Redis is optimised for small, frequently accessed values. Storing an entire serialised ActiveRecord object with all associations defeats the purpose of caching — you are just moving database load to Redis without the durability guarantees. **Missing TTLs on cache keys.** Memory fills up without warning. Every key written to a cache instance should have an expiration. Use `redis-cli --bigkeys` and `redis-cli info memory` periodically to audit key sizes and memory pressure. **`BLPOP` without a timeout.** A blocking pop with no timeout holds a connection indefinitely if the queue is empty. This consumes a slot in the connection pool. Always specify a timeout: ```ruby # Risky: blocks forever if queue is empty redis.blpop("queue:jobs") # Safe: returns nil after 5 seconds redis.blpop("queue:jobs", timeout: 5) ``` **Shared Redis for Sidekiq and cache.** Covered above — the eviction policy mismatch will eventually cause data loss. The cost of a second Redis instance (even a small one) is far lower than debugging missing jobs. **No reconnect logic.** Network blips happen. Configure reconnect attempts on your Redis client and ensure your application handles `Redis::CannotConnectError` gracefully rather than returning 500s. --- ## When Not to Use Redis Redis is the right tool for a specific set of problems. It is not the universal answer. Do not use Redis when: - **Your dataset exceeds available RAM.** Redis is an in-memory store. Exceeding `maxmemory` either blocks writes or starts evicting data. If your working set does not fit in RAM, use a disk-backed store. - **You need complex queries.** Redis does not support joins, aggregations, or full-text search. These belong in PostgreSQL or Elasticsearch. - **You need ACID guarantees.** `MULTI/EXEC` provides atomicity and isolation, but not durability in the relational sense. Financial transactions, inventory management, anything where partial writes have business consequences — use PostgreSQL. - **You are on Rails 8 with modest requirements.** Solid Cache and Solid Queue are SQLite-backed alternatives that remove the operational dependency on Redis entirely. For applications that do not require sub-millisecond cache latency or very high job throughput, they are a legitimate choice. --- ## Production Checklist Before deploying a Rails application that uses Redis, verify each of these. **Instance configuration:** - Separate Redis instances for Sidekiq (`noeviction`, AOF enabled) and cache (`volatile-lru`, no AOF) - `maxmemory` explicitly set on all instances — never rely on OS default - `maxmemory-policy` explicitly set and matched to the role of the instance - `io-threads` configured for the number of available CPU cores (Redis 6+) - `bind` set to an internal network interface — never expose Redis to the public internet **Application code:** - `ConnectionPool` used for all direct Redis access outside of Rails.cache and Sidekiq - All cache keys written with `expires_in` - `SCAN` used instead of `KEYS` anywhere key iteration is needed - `UNLINK` used instead of `DEL` for large keys - Lua scripts used for any read-modify-write pattern requiring atomicity - `BLPOP` calls have a timeout argument **Observability:** - Memory usage alerts configured at 75% of `maxmemory` - Latency monitoring: `redis-cli --latency-history -i 5` - Connection count tracking: `redis-cli info clients` - Slow log reviewed regularly: `redis-cli slowlog get 25` - Keyspace statistics monitored: `redis-cli info keyspace` --- ## Conclusion Redis's "single-threaded" reputation is a shorthand that obscures more than it explains. Command execution is serialised on one thread — and that is a deliberate, correct design decision that eliminates an entire class of concurrency bugs. Everything else: network I/O, persistence, memory management — is concurrent. Understanding this changes how you configure Redis. It explains why I/O threads matter on multi-core hardware. It explains why `UNLINK` exists and when to use it. It explains why a Lua script gives you atomicity guarantees that `MULTI/EXEC` alone does not. In a Rails application, Redis touches nearly every layer: cache, background jobs, WebSocket broadcasting, session storage, rate limiting. Each of those roles has different durability and eviction requirements. The correct architecture is not one Redis instance that tries to satisfy all of them — it is separate, purpose-configured instances that each do their job well. The operational cost of running two or three small Redis instances is low. The cost of debugging a production incident caused by eviction policy mismatch or a blocking `KEYS *` call is not. --- ### When Loading Data Isn't Simple: Decisions Under Uncertainty URL: https://madmatvey.github.io/posts/ux-when-initial-app-loading/ Date: 2026-02-04 We were working on a **mental health support app for men**, delivered as a **Telegram Mini App**. From a product perspective, the requirement was straightforward: on first launch, the user should immediately see the *correct* screen, in the *correct* language, with the *correct* state. From an engineering perspective, this turned out to be a problem of coordinating data under real constraints. The app itself is a **React + TypeScript SPA**. The backend is built on **Supabase**, using PostgreSQL and Supabase Edge Functions. Authentication is handled via Telegram WebApp init data. You can see the app here: 👉 [https://t.me/menhausen_app_bot/app](https://t.me/menhausen_app_bot/app?startapp=REF_195202) --- ## 1. The Actual Problem We Faced On the very first load (no local cache), the UI was rendered before user data was fully available. This led to a set of issues that were immediately visible to users: - brief display of the wrong screen - incorrect language before preferences loaded - onboarding or survey screens flashing and then disappearing - UI state changing after the first render Technically, the root cause was simple: **user data was split across ~10 API calls**, each responsible for its own slice of state. Those calls were: - sequential in some cases - parallel in others - dependent on authentication timing - subject to network latency and edge execution time End result: ~2–3 seconds before the app actually knew who the user was. --- ## 2. Why Partial Loading Didn’t Work Here We initially tried to reason in terms of *critical* vs *non-critical* data. That approach failed quickly. In this app: - onboarding state affects routing - language affects text rendering - subscription status affects available flows - progress and check-ins affect the first visible screen In practice, **almost all user data influenced the first render**. Trying to load “just enough” data introduced: - additional code paths - race conditions between “fast” and “full” sync - UI churn after render At that point, the problem wasn’t performance – it was **state correctness**. --- ## 3. The Key Decision: Aggregate at the Database Instead of trying to orchestrate many requests at the application level, we moved aggregation **into PostgreSQL**. The idea was simple: - fetch *all* user-related data in **one request** - return it as a **single serialized JSON object** - block UI rendering until that data is available At the core of this approach is a PostgreSQL function: ```sql CREATE OR REPLACE FUNCTION get_user_data_as_json(p_user_id BIGINT) RETURNS JSON AS $$ DECLARE result JSON; BEGIN -- aggregation logic result = json_build_object( 'user', json_build_object( 'id', p_user_id, 'name', 'John Doe' ) ); RETURN result; END; $$ LANGUAGE plpgsql STABLE; ``` Inside the function, data from multiple tables is aggregated using: - `json_build_object` - `json_agg` - `json_object_agg` - explicit `COALESCE` handling for empty arrays and nulls From a database perspective, this turned out to be very fast. Data aggregation itself consistently took ~4–40 ms. ## 4. Where the Time Actually Went An important observation: the PostgreSQL function execution was not the bottleneck. Most of the remaining latency came from: - Supabase Edge Function startup - network overhead between client → edge → database Even with that overhead, the total time dropped dramatically because: - we removed ~9 extra round trips - serialization happened once, close to the data - the client received a ready-to-use JSON payload Instead of coordinating 10 responses, the app now waits for one. ## 5. Client-Side Flow After the Change The client logic became intentionally boring: 1. Authenticate via Telegram WebApp data 2. Call a single Edge Function 3. Receive full user state as JSON 4. Render the first screen No background sync. No “fast critical data” path. No UI reconciliation after render. If the new RPC-based path fails, the system falls back to the legacy multi-request flow. This fallback was kept deliberately to reduce migration risk. ## 6. Trade-offs We Accepted Explicitly This approach is not free. What we gained: - initial load time dropped from ~2–3 seconds to ~300 ms - no UI flicker - correct screen and language on first render - dramatically simpler client logic What we accepted: - more logic inside PostgreSQL - schema changes require updating the function - we always load more data than strictly necessary - the fallback path must remain tested and working For this application size and domain, that trade-off was acceptable. ## 7. What This Reinforced for Us A few practical lessons stood out: - PostgreSQL is extremely good at JSON aggregation when used intentionally - Fewer requests often matter more than faster individual requests - Blocking render until state is correct can improve perceived performance - Edge function overhead can dominate latency once database work is optimized - Explicit null and empty-state handling is critical for new users Most importantly: *simplifying the data-loading model reduced both bugs and cognitive load.* ## Conclusion This was not about discovering a clever trick. It was about aligning the data-loading strategy with how the UI actually depends on state. By moving aggregation into PostgreSQL and switching from ~10 API calls to one serialized JSON response, we made the system faster, more predictable, and easier to reason about. For apps where the first screen depends on many intertwined pieces of user state, “load everything, then render” can be the simplest and safest choice. This is not a universal pattern. But in this case, it matched the reality of the product better than any partial solution ever did. --- ### Why an AI Assistant Won’t Replace Your Architectural Thinking URL: https://madmatvey.github.io/posts/ai-assited-coding-statement/ Date: 2025-11-03 You open Cursor, describe a feature, and watch as it confidently generates a bunch of code. It runs. It even looks clean. But then, a quiet voice inside says: > “This doesn’t really fit into my project…” Welcome to the reality of AI-assisted development – a space where models can write code impressively fast, but can’t think architecturally for you. --- ## AI can code, but it can’t design Modern AI assistants are trained mostly on LeetCode problems, open-source snippets, and a limited number of corporate codebases. They’re great at recalling typical implementation patterns, but they don’t actually understand your domain model, your dependencies, or your business constraints. That is why the same prompt can produce a perfect example on paper, yet feel misaligned with the system you’re building. The model isn’t wrong; it’s just generic. To make AI truly helpful, you need to bring something it lacks: **a mental blueprint of what you’re trying to build.** --- ## The key is decomposition Effective AI-assisted development begins with decomposition — the ability to break down your goal into atomic, well-defined steps. Instead of asking: > “Write an authentication system.” Try: - “Create a User model with email and encrypted password.” - “Add a JWT service for token generation and validation.” - “Implement middleware to check for valid tokens.” - “Write request specs for login and signup.” Each of these tasks is small enough for an AI to handle reliably. But the architecture that ties them together — that part is your job. Think of the AI as a brilliant intern: fast, creative, and sometimes reckless. It thrives when you give it small, clear, self-contained tasks. --- ## Why decomposition changes everything Without decomposition, AI tends to suggest default, most common solutions — not necessarily the best ones for your case. When you understand your system at a granular level, you can: - Use the AI to speed up repetitive or mechanical work. - Reserve human focus for the parts that require trade-offs, intuition, and architecture-level decisions. - Keep the implementation consistent with your existing patterns and technical vision. This mindset shifts development from “writing code” to **composing systems.** --- ## Learning from the model, not through it Because language models were trained on millions of public code examples, you can actually learn from them — observe common idioms, explore new libraries, or study best practices. But treating AI as a mentor is very different from treating it as an architect. When I build something new, I often ask: > “How would you structure this module?” Not because I want to copy the code, but because I want to see another way of thinking. That’s where the learning happens. --- ## The real skill: thinking like a system designer AI tools like Cursor, Copilot, or Codeium are not replacing software engineers. They are reshaping what “engineering” means. Your value now lies in being the **orchestrator**: - mapping out the big picture, - defining the boundaries, - and guiding AI through small, precise steps that align with your architecture. Before you start coding with AI, take 10 minutes to: 1. Sketch your system’s structure. 2. Write down a task tree down to the function level. 3. Let the AI handle the leaves of that tree, but you keep ownership of the trunk and the roots. --- ## Takeaway AI can write your code, but only **you** can decide what’s worth building and how it should fit together. The clearer your decomposition, the smarter your assistant becomes. So next time you open your AI IDE, remember: > **AI writes code, but the architect is still you.** --- ### 90% of Startups Die Because the Customer Doesn’t Feel Pain URL: https://madmatvey.github.io/posts/startups-will-die/ Date: 2025-10-13 Every month, thousands of new ideas emerge around the world. People quit their jobs, find partners, hunt for investments, open Figma and Notion, order logos and domains. But nine out of ten startups never even get to an MVP. They burn out, collapse, or quietly vanish like a sandcastle after the tide. ## Why Does This Happen? The answer is painfully simple — **founders fall in love with their idea.** This infatuation blinds them. It gives an illusion of clarity and meaning: > “I *definitely* know what the market is missing.” > “This feature will revolutionize the industry.” > “We’ll just build it and show it.” And instead of cold analysis — warm enthusiasm. Instead of research interviews — a quick prototype. Instead of hypothesis testing — the phrase: *“Well, I’d use it myself!”* Three months, \$50,000 and 200 sleepless hours pass — and suddenly it turns out that the market is saturated, the audience doesn’t feel pain, and even its own team doesn’t understand the product. Thus the “dream” becomes an expensive hobby, and the “startup” becomes a case study on what **not** to do. --- ## The AI Trap Even those who say “we’ll do it smartly” stumble into another trap — **chaos when working with AI.** Today, ChatGPT and dozens of other tools allow a founder to literally “assemble” a product out of thin air: an idea, JTBD (Jobs To Be Done), metrics, landing page, pitch deck — all in one day. It sounds beautiful. In practice, however — the neural network loses context, every prompt lives separately, structure collapses, and in the end the founder sits before a pile of documents: strategy, features, competitors, brand… and nothing fits into a system. It becomes an **informational kaleidoscope** instead of a product. Many pieces, but no whole. The reason is the absence of process. AI is a powerful tool, but without structure it turns into noise. --- ## The Solution — a Systematic Validation Framework The solution is a **structured framework of idea validation** that helps you go from intuition to a conscious concept. ### Example Logic 1. **Context** — articulate what the idea is, what pain it addresses, why now. Not just a description — an honest attempt to answer: who has pain and why it matters to me. 2. **Research** — gather reality. Market, trends, competitors, analogous solutions, reviews. Not to seek confirmation, but to look for refutation. 3. **Elaboration** — structure insights. Define key scenarios, features, metrics, JTBD. Turn “chaos” into a system. 4. **Assembly** — bring everything together into a coherent story: who the user is, what they do, why it matters, how we measure it. At this stage, the idea first looks like a product. 5. **Tuning** — check for integrity: do hypotheses contradict each other, is the value clear, is the MVP ready? Each stage uses artifacts from the previous one. It’s like a constructor — if you pull out one part, everything collapses. Not perfect, but better than nothing. Because this approach gives you not just a plan, but an **architecture of thought**, where AI helps you *think*, rather than replacing thinking. --- ## Benefits of This Approach - You don’t lose months on guesses - You minimize the risk of “falling in love” with an invalid idea - You save money, resources, and belief in yourself - You get a system where every artifact is logically linked to the previous one - You turn AI from an idea generator into a **strategic cofounder** --- ## From Chaos to Clarity As a result — not an abstract “I have an idea,” but a concrete **“I have a validated product concept”** that you can show to investors, designers, and developers. You see weak spots before the market does. You validate hypotheses before writing code. You arrive at an MVP not by intuition, but by logic. The main benefit: the journey from a raw idea to a validated concept takes **days, not months**. And this is not about speed for speed’s sake — it’s about clarity, confidence, and focus. While others burn through budgets trying to “refactor architecture,” you are already testing the product with the first users. That’s the difference between **chaos and system.** Between **an idea and a product.** Between **“we tried” and “we did it.”** [Original article in Russian](https://nasuta.ru/2025/10/13/90-%d1%81%d1%82%d0%b0%d1%80%d1%82%d0%b0%d0%bf%d0%be%d0%b2-%d1%83%d0%bc%d0%b8%d1%80%d0%b0%d1%8e%d1%82-%d0%bf%d0%be%d1%82%d0%be%d0%bc%d1%83-%d1%87%d1%82%d0%be-%d0%ba%d0%bb%d0%b8%d0%b5%d0%bd%d1%82%d1%83/) --- ### When a Job Interview Turned Into a Cybersecurity Investigation URL: https://madmatvey.github.io/posts/recruiter-hacker/ Date: 2025-08-18 ## **When a Job Interview Turned Into a Cybersecurity Investigation** It began innocently, as many modern phishing attempts do: a message on LinkedIn. The sender claimed to be a recruiter representing a blockchain-based company. Their tone was professional, the position sounded legitimate, and the conversation quickly moved to scheduling an interview. During that first meeting, something felt off. --- ### **A Suspicious Request** The interviewer asked me to share my screen and run a project from a GitHub repository they provided. On the surface, this seemed like a technical test – standard in developer hiring. But the push to execute unfamiliar code live on my system raised red flags. I declined, offering vague reasons and buying time. After the meeting ended, I launched the code – not on my personal machine, but in a secure, isolated Docker container. What I uncovered confirmed my suspicion: this wasn’t a hiring test. It was a trap. --- ## **Unpacking the Code: A Purposefully Obscured Threat** The downloaded script was deeply obfuscated. Reading through it felt like decoding a secret message. Once deobfuscated, it revealed a clear and calculated strategy to collect system information: hostname, user ID, OS platform, and user directories. But this was only the surface. The code made network requests to an external server, silently sending back collected information. It attempted to create hidden files on the system and invoked modules that could execute shell commands – actions that clearly pointed toward malicious intent. What stood out most was how passively this malware could operate. It needed no user interaction after launch. It embedded timers to re-trigger its operations at intervals. This wasn’t just malware – it was persistent, silent surveillance. --- ## **Behind the Code: Two Payloads, Two Strategies** Further analysis showed that this was not a single-piece exploit but a dual-payload delivery. ### **Payload One: Sophistication in Simplicity** The smaller of the two scripts had one job: reconnaissance. It mapped out the system it ran on, silently building a profile of the user and environment. Lightweight but cunning, it laid the groundwork for something bigger. ### **Payload Two: Full-Scale Extraction** The second payload was the real threat – large, detailed, and aggressively targeted. It scanned for wallet files, browser data, keychains, saved passwords, and browser profiles. It understood different operating systems and adjusted its behavior accordingly. It mimicked what you’d expect from a state-sponsored espionage toolkit or a high-level financial cybercrime operation. Crypto wallets like Exodus, Atomic, and Bitcoin Core were in its sights. It searched through Chrome, Firefox, Brave, and even privacy-centric browsers. Files like `wallet.dat`, `keychain.db`, and login caches were targets. It didn’t just observe – it harvested. --- ## **What Made This Attack So Dangerous** This wasn’t someone experimenting or learning how to phish. This was a well-planned infiltration tactic: * **It masked itself as a hiring process.** * **It avoided detection using heavy obfuscation.** * **It deployed in layers, ensuring some functionality even if parts failed.** * **It targeted highly sensitive data with a focus on cryptocurrency.** * **It had mechanisms to remain operational over time.** But perhaps most dangerous of all? It relied on **trust**. The trust we extend when someone contacts us professionally. The trust we place in standard workflows like interviews and tech tests. The trust that, when not questioned, becomes a vulnerability. --- ## **Lessons from the Incident** This experience wasn’t just an investigation – it was a wake-up call. Here are a few principles I took away: ### **1. Trust Is Earned, Not Given** Especially in remote hiring scenarios, validate identities and verify context. Just because someone uses LinkedIn and speaks in professional jargon doesn’t mean they’re legitimate. ### **2. Never Run Unverified Code on Your Machine** If you must test code from unknown sources, do it in a controlled, isolated environment. Containers, virtual machines, or cloud sandboxes are your best friends here. ### **3. Obfuscation Is a Red Flag** In professional projects, clear code is king. If someone gives you obfuscated or minified scripts as a "test project," consider it a major warning sign. ### **4. Monitor Your Systems – And Your Gut** Set up basic network monitoring tools. Watch for outbound traffic spikes or strange connections. And above all, if something feels off, it probably is. --- ## **The Broader Implications: Cybercrime Is Evolving** We often think of malware as something you catch by clicking on shady links or downloading pirated software. But as this incident shows, cybercrime is evolving. Attackers now exploit **professional norms and social engineering** to infiltrate systems. This was not about brute force or technical exploits – it was about psychological manipulation. A believable recruiter. A seemingly normal interview. A request that, in other contexts, would have seemed routine. What we’re witnessing is a shift in how attacks are launched: less "hacking" in the classic sense, and more infiltration through familiarity. --- ## **What You Can Do – Today** If you're a developer, engineer, or someone who regularly evaluates code: * **Containerize everything** when running unfamiliar scripts. * **Log your network activity** and look for POST requests or strange heartbeat calls. * **Review your system regularly** for hidden files or unknown processes. * **Avoid sharing your screen** when running code during interviews unless you're 100% sure of the source. * **Push for better cybersecurity education** in your company or team. --- ## **Bonus: A Prompt for Safer Code Evaluation with AI** If you're working with AI assistants or security tools to analyze suspicious code before running it, here's a prompt that can guide them to help you safely: ### 🛡️ **Step-by-step Cybersecurity Threat Analysis Prompt** ```markdown You are a **cybersecurity expert** specializing in **risk analysis of running untrusted code on local machines**. I have a project I want to run locally, but I need your help to **analyze and prepare a secure environment for execution**. We will proceed **step-by-step**, and **you must pause after each step**, asking if I'm ready to move forward. --- ### 🔍 Step 1: Static Analysis (PAUSE AFTER THIS STEP) Your task: - Perform a **static analysis** of the provided project. - Identify: - Malicious or risky dependencies - Suspicious scripts (e.g. `postinstall`, `eval`, encoded strings) - Dangerous system calls or file manipulations - Network usage or unexpected ports - Obfuscation or anti-debugging techniques 📌 **Output:** - Detailed report of all potential risks - What should be manually reviewed before execution - Indicators of malicious behavior - A clear summary at the end ❗ **STOP HERE** and ask me if you should proceed to the next step. --- ### 🧪 Step 2: Risk Summary - Explain what **risks to the host machine** may arise from executing the project normally. - Highlight: - File system access - Network activity (inbound/outbound) - Persistence mechanisms - Privilege escalation vectors ❗ **STOP HERE** and ask me if you should proceed to the next step. --- ### 🐳 Step 3: Safe Execution via Docker Container Provide a full **Docker setup** to simulate local execution **securely**, including: - Non-root user inside container - No access to host filesystem or Docker socket - Restricted CPU and memory resources - Simulated user environment to mimic a real local machine (e.g., mounted fake `$HOME`, fake `/tmp`, etc.) - Logging of **all file writes, system calls**, and **network traffic** - Ability to **observe behavior** inside container (e.g., with `strace`, `tcpdump`, auditd, or similar tools) 📌 Include: - `Dockerfile` - `docker run` command with correct flags - Instructions for monitoring and logging ❗ **STOP HERE** and ask me if you should proceed to execute the project inside the container. --- ### 🧭 Step 4: Monitoring and Execution Strategy - How to run the project **safely** in the container - How to monitor its behavior live - What artifacts to extract and analyze after execution - How to know if the project attempted something malicious --- Only provide **code, commands, and explanations**. Never run or assume execution has occurred. You may begin with **Step 1 – Static Code Analysis**. Let me know what you find, and **wait for my approval** to move on. ``` You can paste this into your AI assistant or security platform to begin a safe review of any unknown codebase. When in doubt, **treat every script as a potential threat** until proven otherwise. --- ## **Final Thoughts** This story could have ended very differently. Had I run the code on my personal machine without a second thought, my credentials, wallets, and private files might have been silently exfiltrated before I ever knew something was wrong. What saved me wasn’t just technical expertise – it was intuition, caution, and a habit of treating every unfamiliar request with a layer of skepticism. The next time a recruiter asks you to run a project mid-call, pause. Investigate. Protect yourself. Because in today's world, **cybersecurity isn't just a technical concern – it's a survival skill.** --- ### How to Formulate Prompts in Cursor: The TARS Technique URL: https://madmatvey.github.io/posts/tars-prompting/ Date: 2025-07-09 ## How to Formulate Prompts in Cursor: The TARS Technique (Task, Assumptions, Requirements, Specification) > **TARS** is a simple yet powerful technique that helps developers accurately formulate requests to AI in the Cursor editor and get results that are actually helpful rather than needing rework. > TARS stands for **Task, Assumptions, Requirements, Specification**. In this article, I’ll show you how to use this approach to formulate effective, predictable, and reproducible prompts when developing in Ruby (and beyond). --- ## 📌 Why Is This Important? In AI tools like Cursor, the model doesn’t “read your mind.” The more precisely we explain the context of a task, the better the result. But in real development, time is limited and tasks are often messy. That’s where TARS comes in: it helps structure a prompt so that the model can "think like an engineer." --- ## 🔧 Components of the TARS Technique ### 1. **Task** Formulate what exactly you want the model to produce. As if you were explaining the task to a teammate. **Bad:** "make it nice" **Good:** "optimize this SQL query to run faster on a 10 million row table" > 💡 It’s better to frame the task as action + result. --- ### 2. **Assumptions** Set the boundaries of the task: what’s already in place, which technologies are used, what can be ignored. This helps the model avoid guessing and focus properly. **Examples:** * “This is Rails 7, Postgres 15, Rubocop is already configured” * “You can use ActiveRecord but not raw SQL” * “Input data is always valid, edge cases not considered” --- ### 3. **Requirements** Clear constraints or goals for the output. What is critical, and what is optional? What must **not** be done? **Examples:** * “Code must pass existing tests” * “Do not include third-party gems” * “Maintain readability and follow the project’s style guide” --- ### 4. **Specification** Output format, structure, style — how should the result look? **Examples:** * “Answer in the form of a single Ruby method, no explanations” * “Format as a comment for a Pull Request” * “Return a Markdown document with sections: Context, Code, Test” --- ## 🧠 Prompt Example Using TARS Let’s say you want AI to help optimize a background task in Sidekiq. Here’s how the prompt might look: --- ``` TASK: Optimize the background task for sending notifications, which slows down under a load of more than 10k jobs. ASSUMPTIONS: - The app runs on Ruby on Rails 7 - Using Sidekiq + Redis - Notifications are sent via HTTP using Faraday - Retry logic is already implemented - Database is PostgreSQL 15 REQUIREMENTS: - No message loss allowed - Performance must scale across worker nodes - No third-party gems - Tests must not break SPECIFICATION: Response should be a single method `NotificationSender.perform`, followed by an explanation of the architectural decisions. ``` --- ## ✅ What Does the TARS Approach Give You? * **Fewer follow-up questions.** The model understands the task immediately and doesn’t drift into “fantasy mode.” * **Better code quality.** Responses are closer to production-level. * **Documentability.** This kind of prompt can be saved to `.cursor/prompts` as part of the project’s history. * **Transferability.** You can hand it off to another developer — and they’ll instantly be in the loop. --- ## 💡 Tips for Use in Cursor * Use **`ask` mode** to clarify a single aspect (e.g. rephrase a part of the condition) * Use **`agent`** if you want a full implementation, especially with a detailed specification * **Background** mode is handy for checking assumptions and spotting weak spots in the idea * For PR discussions — simply paste the entire TARS block into the commit comment --- ## 📎 Template You can use this template in `.cursor/prompts/tars_template.md`: ```md TASK: ASSUMPTIONS: REQUIREMENTS: SPECIFICATION: ``` --- ## 🏁 Conclusion The TARS technique is not bureaucracy — it’s a way to think clearly and formulate AI requests in a way that makes them maximally useful. Try using it in combination with Cursor, and you’ll notice a clear improvement in result quality. --- ### Ruby gem 'gasfree_sdk': Send USDT Without TRX on TRON URL: https://madmatvey.github.io/posts/introducing-ruby-gasless-sdk/ Date: 2025-06-08 If you're building Web3 applications on **TRON**, and especially dealing with USDT TRC‑20, you know the hassle: you need **TRX** to pay for **bandwidth** and **energy**, or buy and burn it—even for free transfers! With **`gasfree_sdk`**, you can use your own USDT to cover those fees, and your users **don't need to buy or rent TRX** at all. --- ## ⚡ Why Gasless USDT Transfers? * **Zero TRX needed** – No more buying TRX or estimating resources. * **Use USDT directly** – Fees are deducted from the USDT you're sending. * **Simplified UX** – Lower friction for onboarding and micro‑transfers. ### What’s changed on TRON? 1. **Tron network introduced “Gas‑Free” USDT transfers**: Justin Sun announced a feature enabling USDT to cover gas costs directly—no TRX required ([cryptotimes.io][1], [coincodex.com][2], [ironwallet.io][3], [the-blockchain.com][4], [coinscan.com][5], [chainwire.org][8]). 2. **Press coverage confirms launch**: Multiple outlets like Crypto Times, Crypto News Flash, The Blockchain News, and more noted that “Gas Free” would start in late Feb 2025, letting wallets and dApps send USDT without TRX ([cryptotimes.io][1], [binance.com][7]). 3. **Pilot rollouts have begun**: Wallets like IronWallet and Tonkeeper Pro now support gasless USDT-TRC20 transactions, confirming user benefits ([coincodex.com][2]). --- ## 🚀 What `gasfree_sdk` Lets You Do 1. **Backend signs USDT meta-tx** You pay using USDT, and all TRX energy/bandwidth is covered transparently. 2. **Integrated with Gelato Relay** The script handles EIP‑712‑style signing and payload preparing for gasless relay. 3. **True “gasless UX”** Your users only interact with USDT—they never touch TRX. --- ## 🛠️ How It Works ### 1. Install ```bash gem install gasfree_sdk # or in Gemfile: gem 'gasfree_sdk' ``` ### 2. Configure ```ruby require 'gasfree_sdk' GasfreeSdk.configure do |config| config.api_key = "your-api-key" config.api_secret = "your-api-secret" config.api_endpoint = "https://open.gasfree.io/tron/" end ``` ### 3. Initialize ```ruby client = GasfreeSdk.client # Get supported tokens puts "Supported Tokens:" tokens = client.tokens tokens.each do |token| puts " #{token.symbol} (#{token.token_address})" puts " Activation Fee: #{token.activate_fee}" puts " Transfer Fee: #{token.transfer_fee}" end # Get service providers puts "\nService Providers:" providers = client.providers providers.each do |provider| puts " #{provider.name} (#{provider.address})" puts " Max Pending Transfers: #{provider.config.max_pending_transfer}" puts " Default Deadline: #{provider.config.default_deadline_duration}s" end ``` ### 4. Get your Gasless USDT address ```ruby user_private_key = "your-private-key" user_address = "your-address" puts "\nGasFree Account Info:" account = client.address(user_address) puts " GasFree Address: #{account.gas_free_address}" puts " Active: #{account.active}" puts " Nonce: #{account.nonce}" ``` ### 5. Prepare Meta-Transaction ```ruby token = tokens.first provider = providers.first deadline_int = Time.now.to_i + provider.config.default_deadline_duration message = { token: token.token_address, serviceProvider: provider.address, user: user_address, receiver: "TQ7ew8mijfJoQ2qSAqSXmjUx1KbB96oMqc", value: "100000000", # 100 USDT (6 decimals) maxFee: "2000000", # Activation fee + transfer fee deadline: deadline_int.to_s, version: 1, nonce: account_nonce } ``` ### 6. Sign the message ```ruby sig = TronEIP712Signer.sign_typed_data(user_private_key, message) ``` ### 7. Send It ```ruby sdk_message = { token: message[:token], service_provider: message[:serviceProvider], user: message[:user], receiver: message[:receiver], value: message[:value], max_fee: message[:maxFee], deadline: message[:deadline].to_i, version: message[:version], nonce: message[:nonce] } request = GasfreeSdk::Models::TransferRequest.new( sdk_message.merge(sig: sig) ) ``` ### 5. Verify & Monitor ```ruby response = client.submit_transfer(request) puts " ✅ Transfer submitted successfully!" puts " Transfer ID: #{response.id}" puts " State: #{response.state}" puts " Estimated Fees:" puts " Activation: #{response.estimated_activate_fee}" puts " Transfer: #{response.estimated_transfer_fee}" # Monitor transfer status puts "\nMonitoring Transfer Status:" 5.times do status = client.transfer_status(response.id) puts " State: #{status.state}" puts " Transaction Hash: #{status.txn_hash}" if status.txn_hash break if %w[SUCCEED FAILED].include?(status.state) sleep 2 end ``` ## ✅ Use Cases * Wallets & dApps wanting **seamless USDT pickups** * **Micro‑payments** where TRX friction kills UX * Platforms enabling **DAO votes** or community payouts --- ## 📢 TRON Gasless News Coverage * "**Tron to Enable Gas-Free USDT Transfers Next Week**" — Crypto Times & others confirm feature by Justin Sun ([mpost.io][6], [binance.com][7], [the-blockchain.com][4], [cryptotimes.io][1]). * "**Tron Introduces 'Gas-Free' USDT Transfers**" — detailed blog coverage on full removal of TRX gas ([coinscan.com][5]). * "**Gasless USDT‑TRC20 Transactions in Tonkeeper Pro Are Now Live**" — live support in wallets confirms real rollout ([chainwire.org][8]). --- ## 📝 Contribute & Feedback Want to add features or tweak behaviors? [PRs welcome in the repo](https://github.com/madmatvey/gasfree_sdk). Ensure you include tests! --- ## 💡 Final Thoughts TRON is now officially **gas-free for USDT transactions**, and `gasfree_sdk` empowers Ruby devs to leverage this natively. Send USDT, not TRX—streamlined, low-cost, and easy. --- ## 📚 References * [cryptotimes.io](https://www.cryptotimes.io/2025/02/26/tron-to-enable-gas-free-usdt-transfers-next-week/?utm_source=madmatvey.github.io) * [coinscan.com](https://www.coinscan.com/blog/tron-introduces-gas-free-usdt-transfers-eliminating-trx-gas-costs?utm_source=madmatvey.github.io) * [chainwire.org](https://chainwire.org/2025/03/14/gasless-usdt-trc20-transactions-in-tonkeeper-pro-are-now-live/?utm_source=madmatvey.github.io) [1]: https://www.cryptotimes.io/2025/02/26/tron-to-enable-gas-free-usdt-transfers-next-week/?utm_source=madmatvey.github.io "Tron to Enable Gas-Free USDT Transfers Next Week" [2]: https://coincodex.com/article/64700/tonkeeper-gasless-usdt-trc20-transactions/?utm_source=madmatvey.github.io "Tonkeeper Pro Enables Gasless USDT-TRC20 Transactions for Seamless ..." [3]: https://ironwallet.io/news/tron-eliminates-fees-for-usdt-transfers/?utm_source=madmatvey.github.io "Tron Eliminates Fees for USDT Transfers - ironwallet.io" [4]: https://www.the-blockchain.com/2025/02/25/tron-aims-to-restore-low-cost-usdt-transfers/?utm_source=madmatvey.github.io "Tron Launches Gas-Free USDT Transfers Amid Rising Fees" [5]: https://www.coinscan.com/blog/tron-introduces-gas-free-usdt-transfers-eliminating-trx-gas-costs?utm_source=madmatvey.github.io "Tron Introduces 'Gas-Free' USDT Transfers, Eliminating TRX Gas Costs" [6]: https://mpost.io/gasless-usdt-trc-20-transactions-now-live-on-tonkeeper-pro/?utm_source=madmatvey.github.io "Gasless USDT-TRC-20 Transactions Now Live On Tonkeeper Pro" [7]: https://www.binance.com/en/square/post/16158576819553?utm_source=madmatvey.github.io "TRON and El Dorado Test First Gasless Tether Transactions" [8]: https://chainwire.org/2025/03/14/gasless-usdt-trc20-transactions-in-tonkeeper-pro-are-now-live/?utm_source=madmatvey.github.io "Gasless USDT-TRC20 Transactions in Tonkeeper Pro Are Now Live - Chainwire" --- ### How I Hired a Fast AI Junior Developer for $192 a Year URL: https://madmatvey.github.io/posts/ai-junior/ Date: 2025-02-03 ### **How I Hired a Fast AI Junior Developer for $192 a Year** I've been coding for 25 years, constantly looking for ways to speed up development. Recently, I found a tool that completely changed how I write code. For just $192 a year, I essentially "hired" an AI junior developer—Cursor.ai with Claude 3.5. Now, instead of writing code myself, I focus on setting tasks, reviewing, and making corrections. #### **How My Workflow Changed** I used to break down large tasks, prioritize them, and manually write the code. Now, I assign these tasks to [Cursor.com](https://cursor.com). It writes the code, covers it with tests, fixes bugs, and I only step in to guide and review the results. In the end, about 80% of the code is good to go, and I fine-tune the remaining 20%. #### **What AI Does Best** It excels at tasks with a clearly defined expected outcome. But there are some quirks: - It struggles when it's unclear which library versions to use, especially if APIs have changed. - Sometimes, it modifies parts of the code I didn’t ask it to touch, showing unexpected "initiative"—which can be either useful or frustrating. But at times, it really impresses me! For example, I once asked it to analyze my code for potential race conditions, and it not only highlighted unexpected issues but also suggested fixes based on existing patterns in my project. #### **How My Role Has Changed** I feel like I’ve hired a super-fast junior dev who works 24/7 and gets things right about 80% of the time. My productivity has increased 2-3 times. I get more done and, more importantly, I have more time to think things through and even take breaks. #### **Is $192 a Year Worth It?** For me—absolutely. It's a fully justified investment. I used to have a Copilot subscription but canceled it because it was more of a distraction than a help. Who would I recommend it to? Pretty much anyone! I even saw a 5-year-old girl build an AI-powered chat with Harry Potter just by giving Cursor.ai commands—without knowing anything about web development. This is mind-blowing and has potential across many fields. The key is learning how to set tasks properly. Once you do, AI won’t get in your way—it’ll actually help you. --- ### Top 5 Must-Read Books for Engineering Leaders URL: https://madmatvey.github.io/posts/top-five-books-for-engineering-leaders/ Date: 2024-09-26 **Top 5 Must-Read Books for Engineering Leaders** As an engineering leader, it's crucial to not only refine your technical skills but also grow as a leader who can inspire and manage high-performing teams. Here are my top 5 recommended books that every engineering leader should dive into, each offering unique insights into leadership, team dynamics, and the organizational culture needed to drive success. Whether you're managing a small squad or overseeing large projects, these books will give you the tools you need to lead with confidence and agility. --- ![The Five Dysfunctions of a Team](/assets/img/top5books/01-partick-lencioni.jpg){: width="170" height="350" .w-30 .right} ### 1. **The Five Dysfunctions of a Team** by Patrick Lencioni [Find it on Amazon](https://amzn.to/4gCHsBs) This book is an absolute essential for any leader, especially in the world of engineering. Lencioni’s **"The Five Dysfunctions of a Team"** provides a compelling narrative that highlights common pitfalls every team faces. He presents the five dysfunctions—absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results—as barriers that prevent teams from achieving success. For engineering leaders, it offers actionable insights into fostering collaboration and building trust within a team, while maintaining the agility necessary to adapt in fast-paced environments. This book truly embodies the spirit of flexible leadership and effective team management. --- ![The Fearless Organization](/assets/img/top5books/02-the-fearless-organization.jpg){: width="170" height="350" .w-30 .right} ### 2. **The Fearless Organization** by Amy C. Edmondson [Find it on Amazon](https://amzn.to/3N1F1uQ) Creating a culture of **psychological safety** is a cornerstone of high-performing teams, especially in innovative fields like engineering. In **"The Fearless Organization,"** Amy Edmondson digs deep into the concept of psychological safety and why it’s crucial for fostering innovation. She emphasizes that when team members feel safe to speak up, share ideas, or admit mistakes, it leads to greater creativity and problem-solving capabilities. This is a must-read for leaders aiming to cultivate an environment where bold, fearless innovation can thrive. --- ![Radical Candor](/assets/img/top5books/03-radical-candor.jpg){: width="170" height="350" .w-30 .right} ### 3. **Radical Candor: Be a Kick-Ass Boss Without Losing Your Humanity** by Kim Scott [Find it on Amazon](https://amzn.to/4gHKkNi) Kim Scott’s **"Radical Candor"** is a perfect guide for engineering leaders who need to master the balance between giving direct feedback and showing genuine care for their team members. The concept of radical candor revolves around being both **challenging and empathetic**, which is essential in high-stakes technical teams where precision matters, but so does the wellbeing of your team. Scott offers practical advice on how to build strong relationships while keeping accountability high—an ideal read for managers aiming to lead with compassion and integrity. --- ![Team of Teams](/assets/img/top5books/04-team-of-teams.jpg){: width="170" height="350" .w-30 .right} ### 4. **Team of Teams: New Rules of Engagement for a Complex World** by General Stanley McChrystal [Find it on Amazon](https://amzn.to/3ZEgrr5) In **"Team of Teams,"** General Stanley McChrystal shares his experiences from military leadership, focusing on the need for adaptability in complex and unpredictable environments. This book introduces the idea that leadership in today’s fast-paced, interconnected world requires decentralized decision-making and cross-functional teamwork—concepts that directly apply to engineering leadership. If you’re managing multiple teams or working across disciplines, this book will teach you how to **deconstruct traditional hierarchies** and create agile, autonomous teams that can handle uncertainty with grace. --- ![Leaders Eat Last](/assets/img/top5books/05-leaders-eat-last.jpg){: width="170" height="350" .w-30 .right} ### 5. **Leaders Eat Last** by Simon Sinek [Find it on Amazon](https://amzn.to/4ehHwF5) Simon Sinek’s **"Leaders Eat Last"** explores the importance of leadership driven by service and **selflessness**. He argues that the best leaders put the needs of their team first, which in turn fosters loyalty, trust, and exceptional team performance. For engineering leaders, this book is an inspiring read about the moral responsibility of leadership, where creating a **supportive and trusting culture** isn’t just good ethics—it’s good business. It’s about **building a team that is both resilient and highly motivated**, even in the face of technical challenges. --- Each of these books provides a unique perspective on leadership, from managing interpersonal dynamics to fostering innovation and trust. As engineering leaders, the ability to adapt and grow, while supporting your team, is the key to long-term success. These reads will help you master the art of leadership and prepare you for whatever challenges may come your way. --- **Do you have other books you’d recommend to fellow engineering leaders? Let me know in the comments below!** --- ### Product-Minded Software Engineer: Key Asset for Teams URL: https://madmatvey.github.io/posts/product-minded-engineer/ Date: 2024-08-30 In today's fast-paced tech industry, being a skilled developer is no longer enough. The most successful engineers are those who take a deep interest in the product itself. These "product-minded" engineers are not just focused on coding; they care deeply about the "why" behind product decisions, user behavior, and the overall success of the business. They thrive on being involved in product discussions and often possess qualities that would make them excellent product managers, should they ever decide to shift gears. I've had the privilege of working with many talented product-minded engineers, and I consider myself one as well. In companies aiming to build world-class products, these engineers elevate their teams to new heights of impact. ### Why Product-Minded Engineers Are Critical Sherif Mansour, a Product Manager at Atlassian, has written extensively about the importance of product-minded engineers. He emphasizes that these engineers are essential to building successful products and scaling product management efforts. Jean-Michel Lemieux, Head of Engineering at Shopify, echoes this sentiment, defining product engineers as those who are deeply engaged with the "why" of the product. They are driven by empathy and a desire to create magical user experiences, balancing technical execution with product vision. ### Key Traits of Product-Minded Engineers So, what makes an engineer truly product-minded? Based on my experience, here are nine traits that these engineers typically exhibit: #### 1. Proactive with Product Ideas and Opinions Product-minded engineers don't just execute on specifications; they actively engage with product ideas. They challenge existing plans and offer alternative approaches that might better serve the product's goals. #### 2. Interest in Business and User Behavior These engineers have a strong curiosity about how the business operates and how the product fits into the broader picture. They delve into user data, striving to understand how the product impacts users and contributes to the company's success. #### 3. Curiosity and the "Why?" Mindset Understanding the "why" behind product decisions is a hallmark of a product-minded engineer. They constantly ask questions to grasp the reasoning behind every feature and milestone, seeking out answers on their own or from product managers and other stakeholders. #### 4. Strong Communication and Relationships with Non-Engineers Product-minded engineers build strong relationships across teams, frequently interacting with non-engineers to learn about their perspectives. They are effective communicators who are genuinely interested in understanding how different disciplines contribute to the product. #### 5. Offering Product and Engineering Tradeoffs These engineers uniquely navigate the intersection of product and engineering. They suggest tradeoffs that optimize both product impact and engineering effort, often proposing entirely new features that balance these considerations. #### 6. Pragmatic Handling of Edge Cases While some engineers overlook edge cases or get bogged down by them, product-minded engineers strike a balance. They assess the importance of edge cases and suggest pragmatic solutions that minimize engineering work while maintaining product quality. #### 7. Quick Product Validation Cycles Product-minded engineers seek early feedback on their work, even before a feature is fully developed. They organize informal tests, like hallway testing or team bug bashes, to validate that their work aligns with user needs. #### 8. End-to-End Product Feature Ownership These engineers take full responsibility for their features, from conception to post-launch analysis. They track how their features perform in the real world, making it a priority to understand and improve user outcomes. #### 9. Strong Product Instincts Through Repeated Learning Cycles With each project, product-minded engineers refine their understanding of what makes a product successful. They apply these learnings to future projects, becoming go-to advisors for product managers and driving more impactful product decisions. ### Tips for Becoming a More Product-Minded Engineer If you’re an engineer working on a user-facing product, here are some actionable steps to develop your product-minded skills: - **Understand Your Company's Business Model:** Learn how your company makes money, which parts of the business are most profitable, and how your team’s work contributes to overall success. - **Build a Strong Relationship with Your Product Manager:** Product managers appreciate engineers who show interest in the product. Establishing a good rapport with your product manager can lead to mentorship and greater involvement in product decisions. - **Engage in User Research and Cross-Disciplinary Collaboration:** Get involved in user research, customer support, and other areas where you can learn more about the product. Collaborate with designers, UX specialists, and data scientists to broaden your understanding. - **Propose Well-Researched Product Suggestions:** Once you have a solid grasp of the product and business, take the initiative to suggest improvements. Make sure your suggestions are backed by data and consider both product and engineering tradeoffs. - **Seek Regular Feedback from Your Product Manager:** To refine your product skills, ask for feedback from your product manager on your contributions and areas for improvement. By cultivating these traits and taking these steps, any engineer can enhance their impact and become a more valuable, product-minded contributor to their team. --- ### Evolution of Problem Solving: Newell and Simon's Impact URL: https://madmatvey.github.io/posts/human-problem-solving/ Date: 2024-07-26 ["Human Problem Solving" by Allen Newell and Herbert A. Simon](https://amzn.to/3yflZ04) is a seminal work in cognitive psychology that explores the processes humans use to solve problems. Here are some key ideas and conclusions from the book: 1. **Information Processing Theory**: The authors propose that human problem-solving can be understood in terms of information processing. They suggest that the mind functions like a computer, processing information through a series of steps and rules. 2. **Problem Space**: Newell and Simon introduce the concept of a "problem space," which consists of all possible states and actions that can be taken to move from the initial state to the goal state. Effective problem-solving involves navigating this space efficiently. 3. **Heuristics and Strategies**: The book emphasizes the use of heuristics, or rules of thumb, in problem-solving. Heuristics are strategies that simplify decision-making and can lead to quicker solutions, although they are not guaranteed to be optimal. 4. **Means-Ends Analysis**: One of the key heuristics discussed is means-ends analysis, which involves breaking down a problem into smaller sub-problems and addressing the differences between the current state and the goal state step-by-step. 5. **Representation of Problems**: The way a problem is represented or framed can significantly impact the ability to solve it. Effective problem solvers are adept at transforming problems into more manageable representations. 6. **Role of Memory**: Memory plays a crucial role in problem-solving. The authors discuss the importance of short-term and long-term memory in storing and retrieving information relevant to the problem at hand. 7. **Expertise and Skill Development**: The book highlights the differences between novice and expert problem solvers. Experts have more sophisticated and organized knowledge structures, which allow them to recognize patterns and apply more effective strategies. 8. **Simulations and Models**: Newell and Simon use computer simulations to model human problem-solving behavior. These simulations help to illustrate how different strategies and heuristics can be applied to solve problems. 9. **Experimental Evidence**: The authors provide experimental evidence to support their theories, demonstrating how people solve problems in controlled settings and how their models can predict human behavior. 10. **Implications for Artificial Intelligence**: The insights from this book have significant implications for the field of artificial intelligence (AI), as understanding human problem-solving can inform the development of intelligent systems that mimic human thought processes. Overall, ["Human Problem Solving"](https://amzn.to/3yflZ04) is a foundational text that offers a comprehensive framework for understanding how humans approach and solve problems. It bridges cognitive psychology and artificial intelligence, providing valuable insights into both fields. --- ### Top 5 Leadership Hats for Engineering Managers URL: https://madmatvey.github.io/posts/leadership-hats/ Date: 2024-07-16 When considering possible leadership styles for an Engineering Manager, it's essential to recognize that different situations and team dynamics may call for different approaches. Here are several leadership styles, described using my top 5 hats, each combining multiple styles to fit the role: ### 1. Enthusiastic Scientist Researcher: - **Combination of Styles**: Transformational Leadership and Coaching Leadership - **Characteristics**: As an enthusiastic scientist researcher, I inspire and motivate the team by creating a vision for the future and encouraging innovation. I also focus on personal and professional development, providing guidance and support to help team members grow and excel. - **When to Use**: Ideal for times of change or when pursuing ambitious new goals that require creative solutions and out-of-the-box thinking, while also fostering a culture of continuous learning and curiosity. #### Example: The company is transitioning to a new, cutting-edge technology stack. Ensure a smooth transition while fostering a culture of continuous learning and innovation. You can organize a series of workshops and hackathons to introduce the new technology. Encourage team members to experiment, share their findings, and collaborate on innovative projects. The team quickly adapted to the new technology, leading to improved performance and innovative solutions. The culture of continuous learning and curiosity was strengthened, boosting overall team morale and productivity. ### 2. Technical Nerd Perfectionist: - **Combination of Styles**: Transactional Leadership and Pacesetting Leadership - **Characteristics**: As a technical nerd perfectionist, I focus on structured tasks, clear goals, and high performance standards. I lead by example, setting high expectations for technical excellence and meticulous attention to detail. - **When to Use**: Effective in environments requiring high levels of accuracy and technical expertise, where quality and performance are paramount. Suitable for achieving fast-paced progress and meeting specific performance metrics. #### Example: A critical mobile app backend needs optimization due to performance issues. Reduce average response time and improve the user experience. You can meticulously analyzed the existing code, identified weak sub-queries, and optimized the database indexes. Conducte rigorous testing to ensure the changes were effective and error-free. The average response time dropped from ~250ms to ~20ms, significantly enhancing the user experience. The app's performance improved, leading to increased user satisfaction and retention. I have [a post about that case](/posts/sql-optimization-or-criminal-tracking/) ### 3. Empathic and Inspirational Leader: - **Combination of Styles**: Servant Leadership and Visionary Leadership - **Characteristics**: As an empathic and inspirational leader, I prioritize the needs of the team, offering support and removing obstacles to help them succeed. I also provide a clear, compelling vision of the future and inspire the team to work towards it. - **When to Use**: Best in situations where team cohesion and individual growth are essential, and when motivating the team through empathy and inspiration can drive success. Ideal for fostering a positive and inclusive work environment. #### Example: The team is experiencing low morale due to a recent setback. We should boost team morale and foster a positive, inclusive work environment. Make one-on-one meetings with each team member to understand their concerns and provide support. Also, you can organize team-building activities and regularly share positive feedback and success stories. Team morale improved significantly, leading to increased collaboration and productivity. The supportive and inclusive environment helped team members feel valued and motivated. ### 4. Meticulous and Persistent Detective Investigator: - **Combination of Styles**: Democratic Leadership and Autocratic Leadership - **Characteristics**: As a meticulous and persistent detective investigator, I dive deep into issues, uncover root causes, and develop detailed, effective solutions to complex problems. I encourage team participation in decision-making processes but also provide clear direction when needed. - **When to Use**: Useful in scenarios where persistent investigation and attention to detail are needed to troubleshoot and resolve intricate technical challenges. Effective when balancing collaborative problem-solving with decisive action. #### Example: A complex bug in the system is causing frequent outages. We have to identify and resolve the root cause of the bug. You can conducte a thorough investigation, analyzing logs and system behavior to pinpoint the issue. Collaborate with team members to test different hypotheses and solutions until the bug was resolved. The bug was successfully identified and fixed, resulting in a stable system with no further outages. The detailed investigation process also provided valuable insights into potential areas for future improvements. ### 5. Captain of a Pirate Sailing Ship: - **Combination of Styles**: Laissez-Faire Leadership and Transformational Leadership - **Characteristics**: As the captain of a pirate sailing ship, I lead with boldness, navigating through uncertainties with confidence. I trust my team's expertise and self-motivation, allowing them to take initiative while inspiring them to tackle challenges head-on. - **When to Use**: Ideal for dynamic and fast-paced environments where decisive action, strong leadership, and a united team are crucial for navigating through turbulent times. Suitable for fostering a spirit of camaraderie and resilience. #### Example: The company faces a major project deadline with tight resources and high uncertainty. Navigate the team through the challenges to meet the deadline. Take decisive action, prioritize critical tasks and reallocate resources efficiently. Inspire the team with confidence and bold leadership, fostering a spirit of camaraderie and resilience. The team successfully met the project deadline, delivering high-quality results despite the challenges. The experience strengthened the team's unity and ability to navigate future uncertainties with confidence. [Read more about parallels between sailing and product development](/posts/sailing-through-product-development/) ### Choosing the Right Style The best Engineering Managers often adopt a flexible approach, adapting their leadership style to fit the team's needs, the organization's culture, and the specific challenges at hand. Combining elements from multiple styles can also be effective. For example, a manager might use the enthusiastic scientist researcher approach to inspire innovation while applying the empathic and inspirational leader techniques to develop team members' skills. Which leadership style resonates most with your approach to management, and why? Feel free to write a comment below! --- ### Russian Programmer's Journey: Starting Anew Amidst Struggles URL: https://madmatvey.github.io/posts/russian-programmer-way/ Date: 2024-07-11 ### Before Matvey Sokolov had always been a man of precision and order. As a lead programmer for one of the most prominent tech companies in his country, he thrived on structure, deadlines, and the intricate beauty of code. His days were spent immersed in algorithms and problem-solving, guiding his team through the complex landscape of software development. The challenges were many, but they were the kind he was trained to face. The political climate had always been a background noise, something he could tune out. His world was built on logic and reason, far removed from the chaotic unpredictability of politics. That is, until the day it wasn't. It started with murmurs of unrest, rumors of a brewing conflict. The government, once seen as a distant entity, began to tighten its grip. New laws were passed, dissent was silenced, and the country teetered on the brink of war. Matvey, like many others, watched in disbelief as the situation deteriorated. Protests erupted, and with them came a wave of arrests. People were taken from their homes in the dead of night, their only crime being their willingness to speak out against the impending conflict. Matvey's own involvement was limited to a few cautious conversations with trusted friends. He was a man of logic, after all, and speaking out seemed a dangerous and futile endeavor. But when one of his closest colleagues was arrested for a social media post, the reality hit home. Silence was no longer a safe haven; it was a complicity he could not afford. One evening, as he sat in his small, cluttered apartment, the decision crystallized. He had to leave. It was not an easy choice. His life, his work, his identity were all rooted in this country. But the alternative was a slow, suffocating existence under an oppressive regime. He packed what little he could carry, said a tearful goodbye to his parents, and set off for the border. ### The Fall The journey was harrowing. Crossing the border meant bribing guards and navigating treacherous terrain. He arrived in a neighboring country with nothing but a backpack and a heavy heart. The bustling metropolis that greeted him was alien and unwelcoming. He was a stranger in a strange land, cut off from everything he had known. Finding work proved to be an insurmountable challenge. Despite his skills and experience, his credentials meant little in this new environment. Weeks turned into months, and his savings dwindled. Desperation gnawed at him, a constant reminder of his precarious situation. Matvey's mind, once sharp and focused, began to unravel. The uncertainty, the fear, the relentless stress—it all took a toll. He spent countless nights staring at the ceiling, haunted by what he had left behind and what lay ahead. The thought of returning home was a tormenting temptation, but he knew it was not an option. The regime's reach was long, and its retribution would be swift. One evening, as he wandered the city streets, Matvey stumbled upon a small park. It was a modest slice of green amidst the concrete jungle, a place where he could sit and lose himself in thought. It became his sanctuary, a place to escape the oppressive weight of his reality. But even in this refuge, the darkness followed. He found himself sinking deeper into despair, questioning every decision, every step that had led him here. ![The Fall](/assets/img/russian-programmer-way/02-the-fall.jpeg){: .normal } ### The Turning Point The turning point came unexpectedly. Matvey had always been a private man, his emotions tightly controlled. But one evening, as he sat in the park, the dam broke. Tears he had held back for months flowed freely, a cathartic release of pent-up anguish. He wept for his lost home, for the friends and family he had left behind, for the life he had been forced to abandon. It was in this moment of vulnerability that he found a glimmer of hope. The act of crying, of allowing himself to feel the full weight of his emotions, was a revelation. It was as if a fog had lifted, revealing a path forward. He realized that he had been so focused on survival that he had neglected the most important aspect of his journey: healing. With this newfound clarity, Matvey began to rebuild. It was a slow and arduous process, but it was a start. He sought out a local support group for refugees, finding solace in the shared experiences of others who had endured similar hardships. He reconnected with his passion for programming, volunteering his skills to help non-profits and small businesses. The work was fulfilling, a reminder of the purpose he had once found in his career. ### Rebuilding Rebuilding his life was not just about finding a job or a place to live. It was about reclaiming his identity, his sense of self. He immersed himself in the local culture, learning the language and customs. It was a way of asserting his presence, of refusing to be a mere shadow in this new world. There were setbacks, of course. Moments of doubt and fear that threatened to pull him back into the abyss. But each time, he reminded himself of the strength he had found in his darkest hour. He allowed himself to grieve, to feel the pain, but he did not let it consume him. Instead, he used it as fuel, a driving force to push him forward. Matvey's journey was far from over. The scars of his past would always be there, a reminder of what he had endured. But they were also a testament to his resilience, his ability to overcome. He knew that the road ahead would be challenging, but he was no longer afraid. He had found a way to turn his pain into purpose, to build a future from the ashes of his past. ![The Turning Point](/assets/img/russian-programmer-way/03-the-turning-point.jpeg){: .normal } ### Finding Hope As time passed, Matvey's efforts began to bear fruit. His volunteer work led to paid opportunities, and he eventually secured a position with a tech startup. It was a small company, but it was a start, a chance to rebuild his career. His colleagues were kind and supportive, many of them immigrants themselves who understood the challenges he faced. Matvey threw himself into his work, finding solace in the familiar rhythms of coding and problem-solving. It was a return to the order and structure he had once thrived on. But it was more than that. It was a way to contribute, to make a difference in a world that often seemed indifferent to his plight. Outside of work, Matvey continued to build connections within the refugee community. He became a mentor to others, sharing his experiences and offering support to those who were just beginning their own journeys. It was a way to give back, to turn his struggles into something positive. ### Embracing the Future The years passed, and Matvey's life slowly took shape. He found a modest apartment, a place he could finally call home. He made friends, built a new support network, and even began to explore the possibility of furthering his education. The wounds of the past were still there, but they were healing. One evening, as he sat on the balcony of his apartment, watching the sun set over the city, Matvey reflected on his journey. He thought about the man he had been before, the life he had lost, and the person he had become. It was a path marked by pain and loss, but also by resilience and hope. He realized that the true measure of a person was not in the ease of their life, but in the strength they found in adversity. He had faced unimaginable challenges, but he had not been broken. He had rebuilt his life, piece by piece, and in doing so, he had discovered a depth of strength and compassion he had never known. Matvey's story was one of many, a testament to the resilience of the human spirit. It was a reminder that even in the darkest of times, there is always hope. It was a message he carried with him, a beacon of light in a world that often seemed shrouded in darkness. ### The Power of Rest and Self-Care One of the most profound lessons Matvey learned on his journey was the importance of rest and self-care. In the relentless pursuit of survival and rebuilding, it was easy to neglect one's own well-being. But Matvey discovered that taking the time to rest, to nurture himself, was not a sign of weakness but of strength. He began to practice mindfulness and meditation, finding moments of peace amidst the chaos. He allowed himself the grace to step back when needed, to recharge and gather his strength. It was a delicate balance, but it was essential for his mental and emotional health. Caring for himself also meant acknowledging his emotions, allowing himself to feel the full spectrum of his experiences. He learned that it was okay to cry, to feel sadness and anger. These emotions were not burdens to be suppressed but aspects of his humanity to be embraced. By giving himself permission to feel, he found a deeper sense of healing. ![Rebuilding](/assets/img/russian-programmer-way/04-rebuilding.jpg){: .normal } ### The Role of Community Throughout his journey, the role of community became increasingly important. Matvey realized that he could not rebuild his life in isolation. He needed the support and connection of others. The refugee support group, his new colleagues, and the friends he made along the way all played a crucial role in his recovery. He also discovered the power of giving back. By helping others, he found a renewed sense of purpose. Whether it was through mentoring fellow refugees or contributing to community projects, Matvey found that acts of kindness and solidarity not only helped those around him but also brought him healing and fulfillment. ### A New Beginning As Matvey settled into his new life, he began to see his journey not just as a struggle but as an opportunity for growth. He had been forced to start over, to rebuild from scratch, but in doing so, he had discovered a resilience and strength he never knew he possessed. He continued to work in the tech industry, climbing the ranks and earning the respect of his peers. His expertise and leadership skills were recognized, and he eventually became a team leader once again. This time, his leadership was tempered with a deep sense of empathy and understanding, qualities forged in the crucible of his experiences. Matvey's personal life also blossomed. He formed deep and lasting relationships, built on mutual respect and shared values. He found joy in the simple pleasures of life, moments of connection and beauty that he had once taken for granted. ### Looking Forward Matvey's journey was a testament to the resilience of the human spirit. It was a story of loss and struggle, but also of hope and renewal. He had faced unimaginable challenges, but he had emerged stronger, more compassionate, and deeply grateful for the second chance he had been given. He knew that the future would hold its own set of challenges, but he was no longer afraid. He had learned that even in the darkest of times, there is always a way forward. It was a lesson he carried with him, a beacon of hope for the road ahead. As he looked out over the city, the sun dipping below the horizon, Matvey felt a sense of peace. He had come a long way from the man he had been, and he was proud of the person he had become. The journey had been difficult, but it had also been transformative. He had rebuilt his life from the ashes, and in doing so, he had discovered the true depth of his own strength. ![A New Beginning](/assets/img/russian-programmer-way/05-finding-hope.jpg){: .normal } ### Conclusion Matvey's story is a reminder of the power of resilience and hope. It is a testament to the human spirit's capacity to endure and overcome. In the face of unimaginable adversity, Matvey found a way to rebuild his life, to turn his pain into purpose. His journey is a beacon of light, a reminder that even in the darkest of times, there is always a way forward. In a world often marked by uncertainty and strife, Matvey's story offers a message of hope and perseverance. It is a call to embrace our emotions, to seek support and community, and to never give up on the possibility of a brighter future. For in the end, it is not the challenges we face that define us, but the strength and courage we find within ourselves to overcome them. --- ### Real Drivers of Quality Hiring: Beyond FAANG Complexity URL: https://madmatvey.github.io/posts/real-driver-of-quality-hiring/ Date: 2024-07-08 In the competitive landscape of talent acquisition, companies often find themselves caught in the allure of mimicking the hiring processes of tech giants like Facebook, Amazon, Apple, Netflix, and Google (FAANG). However, this cargo-cult approach—where companies adopt complex, resource-intensive hiring practices without understanding the underlying principles—often leads to wasted resources and missed opportunities. True motivation, aligned along key dimensions such as Leadership, Curiosity, Freedom, Goal, Comfort, Honor, Mastery, Order, Relatedness, Acceptance, and Status, offers a more effective path to quality hiring. ### Leadership: Inspiring Vision and Direction Effective leadership is pivotal in attracting and retaining top talent. Candidates are drawn to companies with leaders who inspire, set a clear vision, and provide direction. Leadership in hiring means not just filling positions but crafting roles that contribute to a larger mission, thereby attracting individuals who are motivated by purpose and eager to lead in their own capacities. ### Curiosity: Cultivating a Learning Culture Curiosity drives innovation and growth. Companies that prioritize curiosity in their hiring process look for candidates who demonstrate a thirst for knowledge and an eagerness to explore new ideas. This approach fosters a culture of continuous learning and adaptation, crucial in today's fast-evolving business environment. ### Freedom: Empowering Autonomy and Innovation Freedom in the workplace empowers employees to take initiative and innovate. Hiring practices should focus on identifying individuals who thrive in environments where they have the autonomy to make decisions and the flexibility to experiment. This not only enhances job satisfaction but also drives creativity and problem-solving. ### Goal: Aligning Aspirations with Organizational Objectives A goal-oriented hiring strategy ensures that both the company’s objectives and the candidate’s career aspirations are aligned. By understanding and integrating candidates' personal and professional goals, organizations can foster a sense of purpose and commitment, leading to higher engagement and performance. ### Comfort: Ensuring Well-being and Fit Comfort in the workplace is about more than physical amenities; it encompasses a supportive culture and a sense of belonging. Effective hiring processes consider the cultural fit and ensure that new hires will feel comfortable and valued in their new roles, which is critical for long-term retention. ### Honor: Upholding Integrity and Respect Honor and integrity are foundational to building trust within an organization. Hiring individuals who demonstrate strong ethical standards and respect for others contributes to a positive workplace culture. This dimension of motivation ensures that employees are not just skilled but also principled and reliable. ### Mastery: Encouraging Skill Development and Expertise Mastery is the drive to become exceptionally skilled and knowledgeable in one's field. Companies that prioritize mastery in their hiring practices seek candidates who are passionate about their professional growth and are committed to achieving excellence. This focus on skill development leads to higher productivity and innovation. ### Order: Establishing Structure and Clarity Order brings stability and clarity to an organization. Clear structures, processes, and expectations help employees understand their roles and responsibilities. In hiring, looking for candidates who appreciate and thrive in well-organized environments ensures smoother integration and consistent performance. ### Relatedness: Fostering Connection and Teamwork Humans are inherently social beings, and the need for relatedness—feeling connected to others—is crucial in the workplace. Hiring for relatedness involves selecting individuals who value collaboration and can build strong interpersonal relationships. This enhances teamwork, communication, and overall organizational cohesion. ### Acceptance: Creating an Inclusive Environment Acceptance is about fostering an inclusive environment where diverse perspectives are valued and everyone feels they belong. Companies should strive to hire individuals who not only respect diversity but also actively contribute to an inclusive culture. This leads to a richer, more innovative workplace. ### Status: Recognizing and Rewarding Contribution Status motivates individuals by acknowledging their contributions and achievements. Effective hiring processes identify candidates who are driven by recognition and are likely to strive for excellence. Recognizing and rewarding employees' efforts boosts morale and motivates continued high performance. ### The FAANG Fallacy: Complexity vs. Effectiveness Many companies fall into the trap of adopting FAANG-style hiring processes, characterized by multiple interview rounds, algorithmic assessments, and complex evaluations. While these methods may work for tech giants with abundant resources, they are often impractical and counterproductive for other organizations. These complex processes can lead to candidate fatigue, extended hiring timelines, and increased resource expenditure, ultimately burning out recruiters and hiring managers without necessarily improving the quality of hires. ### Conclusion: Embracing Authenticity in Hiring Instead of imitating the convoluted hiring practices of FAANG companies, organizations should focus on authentic, motivation-driven strategies that align with their unique values and goals. By emphasizing leadership, curiosity, freedom, goal alignment, comfort, honor, mastery, order, relatedness, acceptance, and status, companies can create a more effective and sustainable hiring process. This approach not only attracts high-quality candidates but also fosters a motivated, engaged, and high-performing workforce. In the end, true motivation and a deep understanding of what drives individuals will always trump superficial complexity. It’s time for organizations to break free from the FAANG imitation trap and embrace a more genuine, effective approach to hiring. ### P.S. What's [your level of motivation](/motivation-test/)? My results are available at the [link](/motivation-test/?result=53616c7465645f5fa87e69043acfe62fcc5dcbf1c063ba7c406ed4a7760049c1ed1c858f097ca3ce582c51a6897de980758ab944770280a78b7593261fe935dfdd521ccaffdcda0c52753d969e5c813831a9f86ff4d51396c79e443d0568a1e6e6763b31dfce42b74bc76da6ed2be4f5cab0420922ac53b36aafbda4075383732ce4741909484a118c02b09a1e63e3d27bc93fbcaf5a6e577d75a91cec81a8f8e0aa9843ace270c99f3177918419b4776908a7907d32c997abbf338f59650e6d1f06d2cb3068db37b11d938309c8835df029c3efe1d6e98673e235008494612526c47abb7d56bea1ae691408e5edbc73c64e3d21180c24a4cbbda77f69b7721becc3c6fc62815b01877b887888ab6289) --- ### Constructive Feedback: Why You Need It More Than Coffee URL: https://madmatvey.github.io/posts/constuctive-feedback/ Date: 2024-06-21 ### The Constructive Feedback Let's face it: feedback is like your mom’s advice about wearing a coat. You don't always want it, but deep down, you know it’s for your own good. In the tech world, regular constructive feedback is the secret sauce that turns code monkeys into code wizards. And no, we’re not talking about those vague "good job" pats on the back or the soul-crushing "this is garbage" rants. We're talking about the delicious, nutrient-packed smoothie of specific, actionable, and kind feedback. ### The “Aha!” Moments Imagine you’re a developer, happily typing away, confident that your code is a masterpiece. Then, BAM! Your teammate leaves a comment: “Hey, buddy, did you mean to create an infinite loop here, or are you just trying to break the space-time continuum?” It’s a moment of clarity. Your mind opens, the heavens part, and you realize, “Wow, I almost destroyed the universe… again.” Constructive feedback brings those “aha!” moments. It's like when you finally understand a meme weeks after everyone has stopped caring about it. That moment of enlightenment makes you better, sharper, and less likely to accidentally time travel with your code. ### The Ego Check We all need a little ego check now and then. Without feedback, developers can quickly transform into the mythical Code Dragon, hoarding their precious lines and guarding them with fire-breathing fury. Regular feedback keeps you humble and prevents you from turning into Gollum with his “precious” code. Instead of whispering sweet nothings to your Git repository, you’ll be part of a team that collaborates, improves, and collectively shines. ### The “Oops” Prevention Program Mistakes happen. Maybe you forgot to close a tag, or perhaps you accidentally deleted the main database (whoops!). Regular constructive feedback acts as your personal "Oops Prevention Program." It's like having a second pair of eyes, but without the creepy sensation of being watched. Your team’s feedback can catch those tiny errors before they balloon into full-blown disasters. It’s like having a friend who gently taps you on the shoulder and says, “Umm, I think you left the stove on.” Thanks to them, you avoid burning down the house (or the project). ### The Warm Fuzzies Good feedback isn't just about pointing out what’s wrong; it's also about celebrating what’s right. When someone says, “Hey, that’s a clever way to optimize that query,” it’s like receiving a gold star in kindergarten. You feel warm, fuzzy, and motivated to keep doing your best. Positive feedback builds confidence and morale, turning a stressed-out coder into a coding superstar. ### The Feedback Funnies Let’s be honest; sometimes feedback can be downright hilarious. Picture this: your teammate comments, “This code is like a box of chocolates… I have no idea what any of it does.” Or, “Did you write this at 2 AM after a Red Bull binge? Because it reads like it.” A little humor goes a long way in making feedback not just tolerable, but enjoyable. It reminds us that we’re all human, we all make mistakes, and we can all laugh about them together. ### The Special Explanation For Coders ```ruby class Developer attr_accessor :ego, :knowledge, :happiness, :code_quality def initialize @ego = 100 @knowledge = 0 @happiness = 50 @code_quality = "garbage" end def receive_feedback(feedback) case feedback.type when :constructive @knowledge += 10 @happiness += 10 @ego -= 5 improve_code_quality learn_from_mistakes have_aha_moments when :positive @happiness += 20 @ego -= 2 when :negative @happiness -= 10 @ego += 10 cry_in_corner else raise "Invalid feedback type" end end private def improve_code_quality @code_quality = "masterpiece" end def learn_from_mistakes @knowledge += 20 end def have_aha_moments @knowledge += 15 end def cry_in_corner @happiness -= 20 end end developer = Developer.new feedback = Feedback.new(type: :constructive) developer.receive_feedback(feedback) ``` Write in the comments if you notice an error in the code. ### Conclusion In the grand tapestry of the tech world, constructive feedback is the thread that holds everything together. It’s the difference between a lone coder scribbling away in a dark basement and a thriving team producing stellar work. So, embrace the feedback, laugh at the funny comments, learn from the critical ones, and remember: feedback is your friend (even when it’s telling you that your latest code could break the space-time continuum). Stay humble, stay curious, and never forget to thank your colleagues for saving you from your own infinite loops. Cheers to constructive feedback—it's more important than coffee, and that’s saying something! --- ### Protecting Your Treasure: The Hilarious Guide to Seed Phrases URL: https://madmatvey.github.io/posts/crypto-wallet-basic-security/ Date: 2024-06-18 ### Protecting Your Treasure: The Hilarious Guide to Seed Phrases Ahoy, digital adventurers! So you've got yourself a [Kraken wallet](https://www.kraken.com/wallet), huh? Ready to dive into the world of cryptocurrencies and swim with the big fish? But wait! Before you set sail, there's one thing you absolutely must get right: protecting your precious seed phrase. Don't worry, we're here to make it as fun and simple as possible. Arr, let's get to it! #### What in the Seven Seas is a Seed Phrase? Imagine you're a pirate (arrr!) and you've just buried your treasure chest filled with shiny crypto coins. Now, you need a map to find it again. In the world of crypto, that map is your seed phrase. It's a collection of 12-24 random words that unlock access to your digital fortune. Lose it, and your treasure could be lost to Davy Jones' locker forever! #### The Seed Phrase Treasure Chest Kraken wallet, your trusty vessel, generates this magical seed phrase when you set it up. Treat it like the Holy Grail, Excalibur, and your grandma's secret cookie recipe all rolled into one. Without it, no amount of begging, crying, or offering up gold doubloons will help you get your crypto back. #### How to Store Your Seed Phrase: The Do's and Don'ts **Do: Write It Down** Sure, you could tattoo it on your arm, but let's keep things simple. Grab a piece of parchment (or, you know, paper) and write down your seed phrase. Make multiple copies and stash them in safe places. Think of it like spreading your treasure map pieces around so no one scallywag can find it all. **Don't: Store It Digitally** Saving your seed phrase in a text file on your computer is like hiding your treasure chest in plain sight with a neon sign saying "FREE GOLD HERE!" Hackers are like digital pirates, and they love easy prey. Keep your seed phrase offline, away from prying eyes and sticky fingers. **Do: Use a Safe or Lockbox** Channel your inner spy and store your written seed phrase in a fireproof safe or lockbox. It's not as exciting as a buried treasure, but it's a lot more practical. Plus, you won't need a shovel to retrieve it! **Don't: Share It with Anyone** Not your best mate, not your parrot, and definitely not anyone claiming to be a Nigerian prince in your DMs. Your seed phrase is for your eyes only. Sharing it is like handing over the keys to your treasure chest and hoping they won't plunder it. #### The Seed Phrase Security Checklist 1. **Write it down:** Multiple copies, multiple safe places. 2. **Stay offline:** No digital storage, period. 3. **Use protection:** Safes, lockboxes, whatever keeps your seed phrase safe from fire and flood. 4. **Trust no one:** Your seed phrase is a secret treasure map. Guard it with your life! #### Seed Phrases: Your Crypto Ownership Guarantee Many top-notch wallets generate seed phrases to ensure your crypto assets are yours and yours alone. Alongside [Kraken wallet](https://www.kraken.com/wallet), wallets like [Trust Wallet](https://trustwallet.com/), [Coinomi](https://www.coinomi.com/), and [MetaMask](https://metamask.io/) also provide seed phrases when you set up your account. This unique string of words is your ownership guarantee, proving that your digital treasure is securely in your hands. Without it, accessing your assets would be impossible, making it the ultimate safeguard against loss or theft. So, whether you're using Kraken or any other trusted wallet, remember that your seed phrase is the key to your crypto kingdom. Guard it well, and your assets will always be safe! #### Got No Safe Place? Donate It! If you're scratching your head, wondering where to stash your crypto treasure safely, worry not! You can always send it my way as a generous donation. Think of it as putting your digital booty in a well-guarded vault. Plus, you'll have the satisfaction of knowing your crypto is in good hands, helping to support more fun and informative content like this. Just send your coins to the addresses below, and I'll make sure they're well taken care of. --- ### Discovering Your IKIGAI: Foundation of Strategic Job Search URL: https://madmatvey.github.io/posts/ikigai/ Date: 2024-06-14 ### Discovering Your IKIGAI: The Foundation of a Strategic Job Search Embarking on a job search without a clear understanding of yourself can feel like navigating a ship without a compass. To steer your career in the right direction, it is crucial to know what truly drives you. This is where the concept of IKIGAI comes into play. Derived from Japanese philosophy, IKIGAI refers to the intersection of what you love, what you are good at, what the world needs, and what you can be paid for. Understanding your IKIGAI can provide invaluable insights that guide your job search and career planning. #### My IKIGAI: Computer and Information Systems Manager For me, the IKIGAI test revealed that my ideal role lies in computer and information systems management. This includes planning, directing, and coordinating activities in fields such as electronic data processing, information systems, system analysis, and computer programming. Understanding this has been transformative in shaping my job search strategy and aligning my career goals. #### The Importance of Self-Knowledge in Job Search 1. **Clarity and Focus**: Knowing your IKIGAI brings clarity and focus to your job search. Instead of applying to every available position, you can target roles that align with your core passions, strengths, and values. This targeted approach increases your chances of finding a job that is not only satisfying but also sustainable in the long term. 2. **Enhanced Motivation**: When you pursue a career that aligns with your IKIGAI, your intrinsic motivation and enthusiasm naturally rise. This passion is evident to potential employers and can set you apart from other candidates. Your commitment and energy will shine through in interviews and your work performance, making you a more attractive candidate. 3. **Better Decision Making**: With a clear understanding of your IKIGAI, you can make more informed decisions about job offers and career moves. You'll have a solid framework for evaluating opportunities based on how well they align with your personal and professional goals. This reduces the risk of job dissatisfaction and burnout. 4. **Resilience in the Job Search**: The job search process can be daunting and filled with rejections. Knowing your IKIGAI helps you stay resilient and persistent. It serves as a reminder of your purpose and the bigger picture, keeping you motivated even during challenging times. #### How to Discover Your IKIGAI 1. **Self-Reflection**: Spend time reflecting on your passions, skills, and values. Consider what activities make you lose track of time, what you excel at, and what gives you a sense of fulfillment. 2. **Seek Feedback**: Talk to friends, family, and colleagues who know you well. They can provide valuable insights into your strengths and potential career paths you might not have considered. 3. **Professional Assessments**: Utilize professional tools and assessments, such as the [IKIGAI test](https://ikigaitest.com), to gain a structured understanding of your strengths and interests. These tools can provide a starting point for deeper self-exploration. 4. **Experiment and Adapt**: Sometimes, discovering your IKIGAI requires trying different roles and industries. Be open to new experiences and willing to pivot based on what you learn about yourself. #### **Share your IKIGAI results** at X: All right, boys and girls! It's time for you to know your ikigai purpose! Go share your results! 🧡https://t.co/bqyaDh745n pic.twitter.com/jIS6sdT4MG— Eugene Leontev 🇬🇪🇺🇦 (@EugeneLeontev) June 13, 2024 #### Conclusion Understanding yourself is the cornerstone of a successful job search. The IKIGAI test can help you uncover your true calling, providing a solid foundation for your career strategy. By aligning your job search with your IKIGAI, you increase your chances of finding a role that is fulfilling, sustainable, and aligned with your core values. For me, this journey led to the realization that my IKIGAI lies in computer and information systems management, guiding my job search and career planning towards roles where I can truly thrive. Take the time to discover your IKIGAI – it’s an investment that will pay dividends in your professional and personal life. --- ### The Man Who Killed Google Search: A Cautionary Tale URL: https://madmatvey.github.io/posts/the-man-who-killed-google/ Date: 2024-06-11 ## The Man Who Killed Google Search: A Cautionary Tale In Ed Zitron's thought-provoking article, "The Man Who Killed Google Search," we are taken on a deep dive into the decline of one of the world's most important tech products. The story is centered on the events of early 2019, when Google's internal team, led by Ben Gomes, was confronted with a "code yellow" — a crisis that signaled significant revenue shortfalls. The directive from Google's top brass was clear: prioritize growth at all costs, even if it meant compromising the integrity of the search product. The internal struggle is vividly illustrated through leaked emails, revealing the tension between the search and ads teams. Gomes, a long-time Googler, resisted pressure from Prabhakar Raghavan and other executives who prioritized ad revenue over user experience. This internal discord culminated in Gomes' replacement by Raghavan, a decision that many believe marked the beginning of Google's decline in search quality. Raghavan, who previously headed Yahoo's search during its downturn, implemented changes that prioritized short-term revenue gains over long-term user satisfaction. This included rolling back quality updates and making ads more indistinguishable from organic search results. The article highlights how these decisions have led to a search experience filled with spam and low-quality content, driven by aggressive SEO tactics and a relentless focus on revenue. Zitron argues that this shift is emblematic of a broader "Rot Economy" mindset in tech, where financial goals overshadow product integrity and user trust. The piece calls out the moral failings of tech leadership, particularly those with backgrounds in management consulting, who often prioritize profits over principles. In conclusion, Zitron's article serves as a cautionary tale about the dangers of growth-at-all-costs strategies in tech. It underscores the importance of maintaining a balance between revenue generation and product integrity, a balance that Google, under its current leadership, seems to have lost. This piece is a must-read for anyone interested in understanding the complexities and challenges of maintaining ethical standards in the tech industry. --- 1. [The Men Who Killed Google](https://www.wheresyoured.at/the-men-who-killed-google/) 2. [In Response to Google](https://www.wheresyoured.at/in-response-to-google/) I encourage you to think about what principles you would follow in a similar situation. Share your thoughts and ideas in the comments. --- ### Imposter Syndrome: How Employers Can Use It Against You URL: https://madmatvey.github.io/posts/imposter-syndrome/ Date: 2024-06-01 ### Introduction In 2022, I was working in a Russian company when suddenly war broke out, and I made the decision to leave the country and not return. I urgently started looking for a job abroad and literally fell into a trap. I found myself in a vulnerable position, in a country new to me, working for an outstaff company where work processes explicitly and implicitly reinforced my doubts about my qualifications and triggered imposter syndrome. In this article I will share how I recognised my condition, sought help and regained my productivity and mental health. I will share important points about imposter syndrome. If you feel that my story resonates with you, then feel free to give the article a like or dislike and share your stories in the comments. Imposter Syndrome is a psychological pattern in which individuals doubt their skills, talents, or accomplishments and have a persistent fear of being exposed as a "fraud." Despite evident success and external validation, those experiencing Imposter Syndrome often attribute their achievements to luck, timing, or other external factors rather than their own competence and effort. This phenomenon is characterized by chronic self-doubt, feelings of inadequacy, and a disconnect between one's perceived and actual performance. Imposter Syndrome is surprisingly common in the workplace, affecting employees across various industries and levels of experience. Studies indicate that nearly 70% of people will experience imposter feelings at some point in their careers. High-achieving individuals, particularly those in competitive or high-pressure environments, are especially susceptible. The prevalence of Imposter Syndrome can lead to significant psychological stress, impacting both personal well-being and professional performance. Employers, whether intentionally or unintentionally, can exploit employees' Imposter Syndrome to their advantage. Recognizing the signs of self-doubt and insecurity, some employers may leverage these feelings to manipulate employees, extracting more work without adequate compensation or recognition. This exploitation can take various forms, such as undervaluing contributions, delaying promotions, overloading employees with tasks, and fostering an environment where fear of failure is omnipresent. Understanding these dynamics is crucial for both employees and employers to foster healthier, more equitable workplaces. ![AI draws lack of feedback](/assets/img/imposter-syndrome/02-lack-of-feedback.png){: .normal } ### Understanding Imposter Syndrome In many companies in post-Soviet countries, part of the working culture involves attributing achievements and successes to some abstract collective rather than to the contributions of specific individuals. This mentality, a remnant of the Soviet Union, has persisted. When I found a job in a company with offices all over the world, I was hopeful. However, I soon realized that the entire management consisted mostly of people who had grown up in the Soviet Union. Naively, I expected that the legacy of communist propaganda had weathered out of the minds of those who had linked their business with Western countries. Instead, I found myself in an environment where my individual contributions were often overlooked, and the pervasive culture of collective credit reinforced my doubts about my qualifications, exacerbating my imposter syndrome. For instance, every couple of weeks, I had to call a manager whom I only interacted with during those calls. The manager, with a stern tone, demanded to see the tasks in the customer's JIRA and pretended to write something down. Despite these regular check-ins, I never received any feedback. At the time, I perceived it as typical micromanagement. In a well-developed remote working culture, such checks are not required; employees are responsible for their results to the team and to the users of the product they develop. And such checks simply increase the pressure on the employee, leave them without feedback and trigger the development of impostor syndrome. #### Symptoms and Characteristics Imposter Syndrome manifests in various ways, often leading individuals to question their abilities and fear being exposed as frauds. Common symptoms include: - **Persistent Self-Doubt:** Constantly questioning one's skills and qualifications, even in the face of evidence to the contrary. - **Attributing Success to External Factors:** Believing that achievements are due to luck, timing, or the efforts of others rather than one's own abilities. - **Perfectionism:** Setting excessively high standards and feeling like a failure if those standards are not met. - **Fear of Failure:** Intense anxiety about making mistakes or not meeting expectations, leading to avoidance of challenges. - **Overworking:** Compensating for perceived inadequacies by putting in extra hours and effort, often leading to burnout. - **Discounting Praise:** Dismissing positive feedback and assuming others are simply being kind or deceived. #### Common Triggers and Contributing Factors Several factors can trigger or exacerbate Imposter Syndrome, including: - **Workplace Culture:** High-pressure environments and competitive atmospheres can amplify feelings of inadequacy. - **Transitions and New Roles:** Starting a new job, receiving a promotion, or taking on new responsibilities can trigger self-doubt. - **Perfectionist Tendencies:** Individuals with perfectionist tendencies are more likely to experience Imposter Syndrome. - **Social Comparisons:** Comparing oneself to colleagues, especially in a social media-driven world, can heighten feelings of inadequacy. - **Early Family Dynamics:** Childhood experiences, such as high parental expectations or sibling rivalry, can contribute to imposter feelings. - **Lack of Representation:** Underrepresented groups in the workplace may feel additional pressure to prove themselves, leading to heightened imposter feelings. #### Impact on Employee Performance and Well-Being Imposter Syndrome can have profound effects on both employee performance and overall well-being: - **Decreased Productivity:** Constant self-doubt can lead to procrastination, over-preparation, and difficulty in making decisions, all of which hinder productivity. - **Burnout:** The relentless drive to prove oneself can result in overworking and burnout, impacting both physical and mental health. - **Stifled Innovation:** Fear of failure can prevent employees from taking risks or suggesting new ideas, stifling creativity and innovation. - **Career Stagnation:** Reluctance to seek promotions or new opportunities due to self-doubt can lead to career stagnation. - **Reduced Job Satisfaction:** The ongoing stress and anxiety associated with Imposter Syndrome can lead to decreased job satisfaction and a negative work experience. - **Mental Health Issues:** Chronic feelings of inadequacy and stress can contribute to anxiety, depression, and other mental health issues. ![AI draws inderstanding the issue](/assets/img/imposter-syndrome/03-inderstanding-the-issue.png){: .normal } ### Employer Exploitation of Imposter Syndrome After a while, my direct manager suggested I call about an important issue but didn't specify what it was. During the call, he informed me that the project I was currently working on would soon collapse, and everything was going poorly, urging me to leave it and prepare for an interview for a new project. When I asked him how he knew something was wrong with the project, he didn't provide any specifics, simply repeating that the project would soon close and everything was bad. I told him I needed some time to think and make a decision. I then talked to the team members on the project and discovered that nothing of the sort was planned; instead, the project was set to gradually develop and even expand its activities. It was then that I clearly understood how the 'outstaff' model works: they sell me as a developer to a project, evaluate my performance, and if I deliver well, they manipulate the situation to sell me to a more expensive project where they will earn three times more for my services while offering me only a 5% increase in remuneration. #### Recognizing Imposter Syndrome in Employees Employers who are attuned to their employees' behaviors can often recognize signs of Imposter Syndrome. Indicators include: - **Frequent Self-Deprecation:** Employees may downplay their accomplishments or frequently question their own abilities. - **Reluctance to Take Credit:** Employees might attribute their successes to others or to external factors, rarely accepting praise. - **Overworking:** Employees with Imposter Syndrome often work excessive hours, feeling they need to constantly prove their worth. - **Avoidance of Challenges:** They may shy away from new projects or responsibilities due to fear of failure. - **Perfectionism:** An insistence on flawlessness can be a sign, as these employees may struggle to accept mistakes or imperfections. #### Manipulative Tactics Used by Employers Employers can exploit these vulnerabilities to manipulate employees, extracting more work and loyalty without fair compensation or recognition. Common tactics include: ##### Undervaluing Work and Achievements - **Minimizing Contributions:** Employers may downplay the significance of an employee's work, making them feel that their efforts are not particularly valuable. - **Insufficient Praise:** Giving little to no recognition for accomplishments can perpetuate feelings of inadequacy. ##### Delaying or Denying Promotions and Raises - **Promising Future Rewards:** Employers might use the promise of future promotions or raises to keep employees motivated without actually following through. - **Stringent Criteria:** Setting excessively high or vague standards for advancement can keep employees in a state of perpetual effort without reward. ##### Overloading with Work and Unreasonable Expectations - **Excessive Workloads:** Assigning more work than is reasonable, knowing the employee will strive to meet these demands in an attempt to prove themselves. - **Unclear Expectations:** Giving ambiguous or constantly changing expectations can keep employees off balance and feeling inadequate. ##### Leveraging Fear of Failure and Self-Doubt - **Micromanagement:** Overly scrutinizing work can exacerbate self-doubt and the fear of making mistakes. - **Creating a Fear-Based Culture:** Emphasizing the negative consequences of failure rather than fostering a supportive environment can keep employees anxious and compliant. ![AI draws employer exploitation](/assets/img/imposter-syndrome/04-employer-exploitation.png){: .normal } ### Consequences for Employees After realizing that I was being over-pressured, not given feedback, and manipulated, I decided to look for a new job and leave the 'outstaff' company. To my shock, I discovered that my contract required a notice period of two months! This practice raised many questions about how the agreements were legally formalized and how detailed the hiring managers were in negotiating the terms of employment. Despite this setback, I spent the next two months actively going on interviews and responding to job vacancies. My efforts paid off: I received five job offers and ultimately chose the one that offered the clearest terms and conditions along with decent pay. At my next job, the first few months seemed like a typical experience in a product company. However, just a couple of days after my probationary period ended, the CTO abruptly fired our team leader, stating, "I've always disliked the way you work." This was a huge red flag, indicating that the company didn’t value its people or understand how to provide constructive feedback. My concerns were soon confirmed: the company's work culture was fear-driven. In the year I spent there, I clearly understood the team's purpose only once. The feedback I received was always vague, with comments like, "Overall, you seem to be doing something, but it feels like you need to do more and better." When I tried to clarify what exactly was expected, I was told, "We expect different things from a senior," without any specifics. Unfortunately, I didn't have the resources to re-enter the job market at that time. I was dealing with grief in my family, as my mum had passed away after a sudden illness, which consumed most of my energy. I endured at this company for nearly another year before quitting in March 2024. Upon leaving, I provided detailed feedback to the HR director and decided to take a breather to rest and regain my energy. #### Mental Health Implications Imposter Syndrome can significantly impact an employee's mental health, leading to: - **Anxiety:** Persistent self-doubt and fear of being exposed as a fraud can cause chronic anxiety, making it difficult for employees to relax and feel secure in their roles. - **Depression:** The constant pressure to perform and feelings of inadequacy can contribute to depression, marked by feelings of hopelessness, lack of motivation, and a negative self-view. - **Low Self-Esteem:** Employees with Imposter Syndrome often struggle with low self-esteem, believing they are less competent or deserving than their peers. - **Stress:** The ongoing stress of trying to meet unrealistic expectations and the fear of failure can lead to physical symptoms such as headaches, insomnia, and other stress-related conditions. #### Career Stagnation and Burnout The pressure and self-doubt associated with Imposter Syndrome can hinder career progression and lead to burnout: - **Avoidance of Advancement:** Employees may avoid seeking promotions or new opportunities due to fear of not being good enough, leading to career stagnation. - **Overworking:** In an attempt to prove their worth, employees often work excessive hours, which can result in physical and emotional exhaustion. - **Burnout:** The relentless effort to meet high standards and the lack of recognition or reward can lead to burnout, characterized by fatigue, cynicism, and reduced professional efficacy. - **Underutilization of Skills:** Self-doubt may prevent employees from fully utilizing their skills or taking on roles that match their capabilities, limiting their professional growth and potential. #### Decreased Job Satisfaction and Productivity Imposter Syndrome can adversely affect job satisfaction and overall productivity: - **Diminished Job Satisfaction:** The lack of recognition and the constant pressure to prove oneself can lead to decreased job satisfaction, making work feel unfulfilling and stressful. - **Reduced Engagement:** Employees struggling with Imposter Syndrome may become disengaged, feeling disconnected from their work and less motivated to contribute. - **Procrastination:** Fear of failure and perfectionism can lead to procrastination, where employees delay tasks to avoid the anxiety associated with potential mistakes. - **Inefficiency:** The tendency to overprepare or excessively check work can make employees less efficient, slowing down their overall productivity. - **Interpersonal Strain:** The stress and self-doubt associated with Imposter Syndrome can strain relationships with colleagues, leading to conflicts and a less collaborative work environment. ![AI draws consequences for employees](/assets/img/imposter-syndrome/05-consequences-for-employees.png){: .normal } ### Strategies for Employees to Combat Exploitation As I write this article, I am in the process of overcoming imposter syndrome. I was laid off exactly three months ago. In the chapter below, titled [Knowing When to Leave a Toxic Workplace](/#knowing-when-to-leave-a-toxic-workplace), I will describe how it happened for me. In a nutshell, I was fired after I sought clarification about the company's communication and management practices. I asked if this way of communicating and managing the team was standard practice or if it was an excessive anomaly. I also questioned why the promised annual remuneration review had been ignored after a year, and everyone seemed to pretend it had never been mentioned. I found the corporate management standards in the company's documentation, which had a link to a Russian-language resource with a roadmap for developing team leader competencies ([tlroadmap.io](https://tlroadmap.io/)). I suggested that our team leader explore ways to assess my personal effectiveness and build professional relationships within the team, attaching links to this resource. Instead of discussing possible improvements to company processes that would enhance teamwork, I was informed that it was my last day on the job. Thus, I left an environment that was toxic to me, and I am grateful for that decision. Thank you!!! I now have a compelling story about how creating productive conflict can quickly confirm or dispel doubts about cultural fit. #### Recognizing and Addressing Imposter Syndrome The first step in combating Imposter Syndrome is to recognize and address it: - **Self-Awareness:** Identify the patterns of self-doubt and recognize when they arise. Understanding the triggers and symptoms is crucial for addressing them. - **Reframe Negative Thoughts:** Challenge and reframe negative self-talk. Replace thoughts of inadequacy with positive affirmations about your skills and accomplishments. - **Acknowledge Achievements:** Keep a record of your successes and contributions. Regularly review this list to remind yourself of your capabilities and achievements. #### Building Confidence and Self-Advocacy Confidence and self-advocacy are essential in overcoming Imposter Syndrome and avoiding exploitation: - **Set Realistic Goals:** Break tasks into manageable steps and set achievable goals. Celebrate small victories to build confidence over time. - **Self-Advocacy Training:** Learn to advocate for yourself by negotiating for fair compensation, seeking promotions, and asking for recognition when deserved. - **Continuous Learning:** Invest in your professional development. Gaining new skills and knowledge can boost confidence and reduce feelings of inadequacy. #### Seeking Support from Mentors and Peers Support from mentors and peers can provide valuable perspective and encouragement: - **Find a Mentor:** Seek out a mentor who can offer guidance, share their experiences, and provide constructive feedback. A mentor can help you navigate challenges and build confidence. You can [reach out to me for a mentor service at getmentor.dev](https://getmentor.dev/mentor/evgeniy-leontev-667) - **Peer Support Groups:** Join support groups or professional networks where you can share experiences and receive encouragement from others facing similar challenges. - **Open Communication:** Foster open communication with colleagues. Sharing your feelings can reduce the sense of isolation and provide mutual support. #### Establishing Clear Professional Boundaries Setting clear boundaries is crucial for maintaining a healthy work-life balance and preventing exploitation: - **Work-Life Balance:** Prioritize work-life balance by setting clear boundaries between work and personal time. Avoid overcommitting and ensure you have time to recharge. - **Learn to Say No:** Practice saying no to unreasonable requests or workloads. Politely but firmly decline tasks that exceed your capacity or undermine your well-being. - **Communicate Boundaries:** Clearly communicate your boundaries to your employer and colleagues. Ensure they understand your limits and respect them. #### Knowing When to Leave a Toxic Workplace Recognizing a toxic workplace and knowing when to leave is vital for long-term well-being: - **Assess the Environment:** Regularly assess your work environment. If it is consistently toxic, exploitative, and detrimental to your mental health, it may be time to consider leaving. - **Look for Red Flags:** Be aware of red flags, such as consistent undervaluing of your work, lack of support, and unfulfilled promises of promotions or raises. - **Prepare for Transition:** If leaving is necessary, prepare for the transition by updating your resume, networking, and exploring new job opportunities. Ensure you have a support system in place during the transition. ![AI draws strategies for employees to combat exploitation](/assets/img/imposter-syndrome/06-strategies-for-employees-to-combat-exploitation.png){: .normal } ### Recommendations for Ethical Employer Practices I have experienced working with companies whose cultures were not conducive to talented and hardworking individuals thriving and discovering their abilities. I’ve studied numerous examples of how organizations dominated by fear-based cultures fail and how to transform such cultures. A valuable resource I found is ["The Fearless Organization: Creating Psychological Safety in the Workplace for Learning, Innovation, and Growth"](https://amzn.to/3Vo0Ucp). I highly recommend it to anyone who considers themselves an ethical employer focused on innovation and productivity. #### Creating a Supportive Work Environment A supportive work environment is crucial for fostering employee well-being and productivity: - **Open Communication:** Encourage open, transparent communication where employees feel safe to express concerns and share ideas without fear of judgment. - **Psychological Safety:** Foster an atmosphere where mistakes are viewed as learning opportunities rather than failures. Ensure employees feel safe to take risks and innovate. - **Inclusive Culture:** Promote diversity and inclusion, ensuring all employees feel valued and respected regardless of their background or identity. #### Providing Regular, Constructive Feedback Constructive feedback helps employees grow and feel recognized for their contributions: - **Regular Check-Ins:** Schedule regular one-on-one meetings to provide feedback, discuss progress, and address any concerns employees may have. - **Specific and Actionable:** Offer specific, actionable feedback that employees can use to improve their performance. Avoid vague or overly critical comments. - **Balanced Approach:** Balance constructive criticism with positive reinforcement. Recognize strengths and achievements while providing guidance on areas for improvement. #### Promoting a Culture of Recognition and Appreciation Recognition and appreciation are key to motivating employees and reducing feelings of inadequacy: - **Public Acknowledgment:** Regularly acknowledge and celebrate employee achievements in team meetings, newsletters, or through company-wide announcements. - **Incentive Programs:** Implement incentive programs, such as Employee of the Month awards, bonuses, or other rewards to recognize exceptional performance. - **Peer Recognition:** Encourage peer-to-peer recognition programs where employees can acknowledge and appreciate each other’s contributions. #### Encouraging Professional Development and Growth Supporting professional development helps employees build confidence and advance their careers: - **Training Opportunities:** Provide access to training programs, workshops, and courses that enable employees to develop new skills and stay updated with industry trends. - **Career Pathing:** Offer clear career paths and development plans. Work with employees to set goals and provide the resources needed to achieve them. - **Mentorship Programs:** Establish mentorship programs that pair experienced employees with those seeking guidance and growth, fostering knowledge sharing and professional development. ![AI draws Recommendations for Ethical Employer Practices](/assets/img/imposter-syndrome/07-recommendations-for-ethical-employer-practices.png){: .normal } ### Conclusion Reflecting on my journey, I've realized the importance of recognizing and addressing imposter syndrome. My experiences in various work environments, particularly in companies with fear-based cultures, have taught me valuable lessons about self-worth and the necessity of a supportive workplace. Leaving a toxic workplace was one of the best decisions I made. It allowed me to seek out an environment where my contributions are valued and where I can grow both personally and professionally. My story is a testament to the power of standing up for oneself and finding a work culture that aligns with one's values. For employees facing similar challenges, I encourage you to recognize your worth and seek environments that nurture your talents. For employers, fostering a culture of psychological safety and constructive feedback is crucial for innovation and productivity. Addressing imposter syndrome is not just about individual well-being but also about creating workplaces where everyone can thrive. Let’s work together to build supportive and empowering work environments for all. #### Summary of Key Points Imposter Syndrome is a prevalent issue in the workplace, characterized by persistent self-doubt and fear of being exposed as a fraud despite evident success. It affects employees' mental health, career progression, and overall job satisfaction. Employers can exploit these vulnerabilities through manipulative tactics, such as undervaluing work, delaying promotions, overloading employees, and leveraging fear and self-doubt. However, both employees and employers can take steps to address and mitigate the impact of Imposter Syndrome. #### The Importance of Addressing Imposter Syndrome Addressing Imposter Syndrome is crucial for creating healthier, more equitable workplaces. Employees who struggle with Imposter Syndrome may experience significant mental health challenges, including anxiety, depression, and burnout, which can hinder their professional growth and productivity. On the other hand, supportive and ethical employer practices can help alleviate these feelings, fostering a positive work environment where employees feel valued and motivated. By recognizing and addressing Imposter Syndrome, employers can enhance employee well-being, satisfaction, and performance, ultimately benefiting the entire organization. #### Call to Action for Both Employees and Employers Both employees and employers have a role to play in combating Imposter Syndrome and fostering a supportive work environment: - **Employees:** Recognize and address your own Imposter Syndrome by building confidence, seeking support from mentors and peers, establishing clear boundaries, and knowing when to leave a toxic workplace. Advocate for yourself and your achievements, and invest in your professional development. - **Employers:** Create a supportive work environment that promotes open communication, psychological safety, and inclusivity. Provide regular, constructive feedback and recognize and appreciate employees' contributions. Encourage professional development and growth through training opportunities, career pathing, and mentorship programs. By working together, employees and employers can mitigate the effects of Imposter Syndrome, leading to a more positive, productive, and fulfilling work experience for everyone involved. #### Useful Resources and Further Reading - [The imposter phenomenon: Recent research findings regarding dynamics, personality and family patterns and their implications for treatment.](https://psycnet.apa.org/record/1994-17499-001) **American Psychological Association (APA)** - [Overcoming Imposter Syndrome](https://hbr.org/2008/05/overcoming-imposter-syndrome) **Harvard Business Review (HBR)** - [Overcoming Imposter Syndrome: Strategies For Building Confidence In Your Career](https://www.forbes.com/sites/forbesbusinessdevelopmentcouncil/2024/01/17/overcoming-imposter-syndrome-strategies-for-building-confidence-in-your-career/) **Forbes** - [Feel Like a Fraud? At Times, Maybe You Should](https://www.nytimes.com/2008/02/05/health/05mind.html) **The New York Times** - [Imposter Syndrome](https://www.psychologytoday.com/intl/basics/imposter-syndrome) **Psychology Today** - [Having imposter syndrome when you're the boss is hard, but weirdly it might make you better at your job](https://www.businessinsider.com/managing-imposter-syndrome-when-you-are-the-boss-2021-10) **Business Insider** - [What is imposter syndrome and how can you combat it?](https://www.ted.com/talks/elizabeth_cox_what_is_imposter_syndrome_and_how_can_you_combat_it) **TED Talks** - [How To Deal With Imposter Syndrome For Self-Taught Developers](https://annadaya.medium.com/how-to-deal-with-imposter-syndrome-for-self-taught-developers-f490d6a314c0) **Medium** - [Inside the Upside of Imposter Syndrome: Science Says You're More Charming, Sensitive, and Socially Adept Than You Think](https://www.inc.com/jeff-haden/how-imposter-syndrome-can-improve-social-skills-sensitivity-charisma-success-research-science.html) **Inc.** - [People in the U.S. Think They Are Better Than They Actually Are. People in Asia Don’t](https://www.scientificamerican.com/article/people-in-the-u-s-think-they-are-better-than-they-actually-are-people-in-asia-dont/) **Scientific American** --- ### Sailing Through Product Development URL: https://madmatvey.github.io/posts/sailing-through-product-development/ Date: 2024-05-12 ## Parallels Between Steering a Sailboat and Leading a Small Team ### Introduction Brief Overview of My Background: I have a deep passion for both sailing and programming, with extensive experience in both fields. As a sailor, I have spent years navigating the seas, learning valuable lessons in decision-making, adaptability, and leadership. In my programming career, I have led small teams in developing innovative software solutions, using my technical expertise and strategic thinking to deliver successful projects. In this blog post, I will explore the similarities between steering a sailboat and leading a small team in product development. Despite their apparent differences, both activities share fundamental principles of planning, execution, and teamwork. By drawing on my experiences in sailing and programming, I aim to provide valuable insights and practical tips for individuals involved in both fields, highlighting the universal lessons that can be learned from these experiences. ### Setting the Course: Planning and Preparation Preparedness to cope with a variety of unpredictable events plays a critical role in planning a sea crossing. You must keep the "error chain" in mind and prioritize tasks and attention on those aspects that move the state of your crew and boat towards the next level of the "error chain". At this level of preparation, the following are important: a trusting team environment, well-done boat maintenance, several sources of weather forecasts from which you select the worst-case scenario as likely, and a set of navigational nautical charts. Charting a course is akin to setting clear goals in product development. Just as a sailor charts a course to determine direction and avoid obstacles, setting clear goals in product development guides the team's efforts and ensures everyone is working towards the same objectives. Considering weather conditions is crucial in sailing to anticipate changes and adjust the course if necessary, similar to understanding user needs in product development. Understanding user needs is essential to develop solutions that address real problems and provide value to customers. Preparing the boat before setting sail is essential for a safe and successful journey, much like planning the project roadmap in product development. Planning the project roadmap ensures that the team is equipped with the necessary resources and direction to deliver a high-quality product on time. ![Setting the course](/assets/img/sailing-development/02-preparations-planings.png){: .normal } ### Navigating the Waters: Execution and Adaptation Sailing: When sailing, it is essential to constantly adjust the sails to effectively manage the wind and maintain the desired course. Similarly, environmental monitoring is essential to predict changes in wind direction, avoid collisions with other boats and avoid obstacles such as rocks, shoals or reefs. Product Development: In product development, agile practices such as iterative development, continuous testing, and adapting to feedback are essential. Iterative development allows for the product to evolve gradually, incorporating new features and improvements based on user feedback. Continuous testing ensures that the product meets quality standards throughout its development lifecycle. Adapting to feedback helps the team to respond to changing requirements and market conditions, ensuring that the product remains relevant and valuable to users. ![Navigating the waters](/assets/img/sailing-development/03-navigating-the-waters.png){: .normal } ### Managing the Crew: Team Dynamics and Leadership Sailing: The role of the captain in sailing extends beyond steering the boat. A captain must motivate the crew, fostering teamwork, and resolving conflicts. Motivation is crucial to keep the crew engaged and focused, especially during long journeys or challenging conditions. Fostering teamwork ensures that each crew member understands their role and works together towards a common goal. Resolving conflicts is essential to maintain harmony on board and ensure that everyone can work together effectively. Product Development: In product development, effective leadership, communication, and collaboration within a small team are key to success. Leadership sets the direction and vision for the team, inspiring them to achieve their goals. Communication ensures that team members are aligned and informed, reducing misunderstandings and promoting transparency. Collaboration encourages the sharing of ideas and expertise, leading to innovative solutions and improved outcomes. Together, these elements create a strong team dynamic that can overcome challenges and deliver high-quality products. ![Managing the crew](/assets/img/sailing-development/04-managing-the-crew.png){: .normal } ### Weathering the Storms: Challenges and Resilience Sailing: Facing storms, rough seas, and unexpected challenges is part of the thrill and challenge of sailing. Storms can test the crew's skill and endurance, requiring quick thinking and decisive action to keep the boat safe. Rough seas can be physically demanding, requiring strength and stamina to navigate through. Unexpected challenges, such as equipment failure or navigation errors, can test the crew's resourcefulness and ability to adapt to changing circumstances. Despite these challenges, facing them head-on can lead to a sense of accomplishment and strengthen the bond between crew members. Product Development: Similarly, in product development, there are common challenges that teams often face. Scope changes can disrupt project timelines and require careful management to ensure that the project stays on track. Technical issues, such as bugs or compatibility issues, can delay progress and require troubleshooting to resolve. Market shifts, such as changes in consumer preferences or competitive landscape, can require the team to pivot their strategy and adapt their product to meet new demands. By anticipating these challenges and having a plan in place to address them, teams can overcome obstacles and deliver successful products. ![Weathering the storms](/assets/img/sailing-development/05-weathering-the-storms.png){: .normal } ### Celebrating Success: Achievements and Reflection Sailing: Reflecting on the satisfaction of reaching a destination, winning a race, or overcoming a tough challenge is a rewarding experience in sailing. Whether it's the thrill of crossing a finish line after a grueling race, the sense of achievement of reaching a distant port, or the camaraderie forged through facing and overcoming a tough challenge at sea, these moments are what make sailing such a fulfilling pursuit. They remind us of our capabilities, the strength of our team, and the power of perseverance. Product Development: Similarly, in product development, celebrating milestones, learning from failures, and continuous improvement are crucial for success. Celebrating milestones, whether it's completing a major feature or reaching a significant user base, helps to recognize the hard work and dedication of the team. Learning from failures is essential for growth, as it allows the team to identify areas for improvement and avoid making the same mistakes in the future. Continuous improvement is key to staying competitive and ensuring that the product meets the evolving needs of users. Together, these practices foster a culture of innovation and excellence, driving the team towards greater success. ![Celebrating success](/assets/img/sailing-development/06-celebrating-success.png){: .normal } ### Conclusion Recap of the Parallels: The parallels between sailing and leading a small team in product development are striking. Both activities require careful planning and preparation, the ability to adapt to changing conditions, effective leadership and communication, and the resilience to overcome challenges. In sailing, navigating the seas requires charting a course, adjusting to the weather, and preparing the boat. Similarly, in product development, setting clear goals, understanding user needs, and planning the project roadmap are essential. Both activities also require constant adjustment and monitoring to navigate obstacles and achieve success. Encouragement for Readers: I encourage readers to apply the lessons from sailing to their own team leadership and product development practices. Just as a captain motivates their crew and fosters teamwork, effective leadership and communication are crucial in guiding a small team towards success. By adapting to feedback and continuously improving, teams can navigate through challenges and reach their goals. Remember, it's not just about reaching the destination, but also about enjoying the journey and learning from the experiences along the way. So set sail with confidence, and may the wind be at your back in your team leadership and product development endeavors. ![Conclusion](/assets/img/sailing-development/07-conclusion.jpeg){: .normal } ### Call to Action Have you ever noticed similarities between your experiences in sailing and your work in product development? I'd love to hear your thoughts and stories! Share your experiences or insights on the analogy between sailing and product development in the comments below. Let's continue the conversation and learn from each other's experiences! --- ### Optimizing SQL Queries or Tracking Dangerous Criminals URL: https://madmatvey.github.io/posts/sql-optimization-or-criminal-tracking/ Date: 2020-07-03 I believe that virtually every project using Ruby on Rails and Postgres as its main backend tools is in a constant struggle between development speed, code readability/maintainability, and project performance in production. I will share my experience balancing these three pillars in a case where readability and performance suffered initially, but in the end, I managed to achieve what several talented engineers had unsuccessfully attempted before me. The whole story will take several parts. This is the first one, where I'll talk about what PMDSC is for optimizing SQL queries, share useful tools for measuring query performance in Postgres, and remind you of one useful old cheat sheet that is still relevant. Now, after some time has passed, in hindsight, I realize that I didn't expect everything to work out in this case. Therefore, this post will be more useful for bold and less experienced developers than for super-seniors who have seen Rails with raw SQL. ## Background At Appbooster, we focus on promoting mobile applications. To easily propose and test hypotheses, we develop several of our applications. The backend for most of them is a Rails API and Postgresql. The hero of this publication has been developed since the end of 2013—just after `rails 4.1.0.beta1` was released. Since then, the project has grown into a fully loaded web application that runs on several servers in Amazon EC2 with a separate database instance in Amazon RDS `(db.t3.xlarge with 4 vCPU and 16 GB RAM)`. Peak loads reach 25k RPM, with an average load of 8-10k RPM during the day. This story began with the database instance, or more precisely, with its credit balance. ![RDS Credit balance low](/assets/img/sql-optimization/rds-credit-balance-low.png){: .normal } How a "t" type Postgres instance works in Amazon RDS: if your database operates with an average CPU utilization below a certain threshold, credits accumulate in your account, which the instance can spend on CPU consumption during high-load hours—this allows you to avoid overpaying for server power and cope with high loads. More details on what and how much you pay using AWS can be found in [our CTO's article (RU)](https://medium.com/@kelion/%D0%BE%D0%BF%D1%82%D0%B8%D0%BC%D0%B8%D0%B7%D0%B8%D1%80%D1%83%D0%B5%D0%BC-%D1%80%D0%B0%D1%81%D1%85%D0%BE%D0%B4%D1%8B-%D0%BD%D0%B0-amazon-aws-81354d27dfaa). At some point, the credit balance was depleted. For some time, this was not given much importance, as the credit balance could be replenished with money—this cost us about $20 per month, which is not very significant compared to the overall expenses for renting computational resources. In product development, the focus is usually on tasks formulated from business requirements. Increased consumption of CPU resources by the database server falls under technical debt and is covered by small expenses for purchasing credit balance. One fine day, I wrote in the daily summary that I was very tired of extinguishing the periodic "fires" that occurred in different parts of the project. If this continues, the burned-out developer will spend time on business tasks. On the same day, I approached the project manager, explained the situation, and asked for time to investigate the causes of the periodic fires and make repairs. After receiving approval, I began to collect data from various monitoring systems. We use New Relic to track the overall response time over the course of a day. The picture looked like this: ![Newrelic dashboard screenshoot](/assets/img/sql-optimization/newrelic.png) The yellow highlighted part on the graph represents the response time taken by Postgres. As can be seen, sometimes the response time reached 1000 ms, and most of the time, it was the database that was pondering the response. This means we need to look at what's happening with the SQL queries. ## PMDSC is a simple and understandable practice for ~~any tedious~~ task of optimizing SQL queries. - Play it! - Measure it! - Draw it! - Suppose it! - Check it! ### Play it! Perhaps the most important part of the whole practice. When someone mentions "Optimizing SQL queries," it tends to provoke yawning and boredom in the vast majority of people. When you say "Detective investigation and tracking down dangerous villains," it engages and sets you in the right mood. So, it's important to get into the game. I enjoyed playing detective. I imagined that database problems were either dangerous criminals or rare diseases. And I imagined myself as Sherlock Holmes, Lieutenant Columbo, or Dr. House. Choose the hero to your liking and go ahead! ### Measure It! ![Measure it! PGhero](/assets/img/sql-optimization/pghero_screenshoot_measure_it.png) For analyzing query statistics, I installed [PgHero](https://github.com/ankane/pghero). This is a very convenient way to read data from the `pg_stat_statements` extension for Postgres. We go to `/queries` and look at the statistics of all queries for the last day. The default sorting of queries is by the `Total Time column` - the proportion of total time the database processes the query - a valuable source in the search for suspects. `Average Time` - how long, on average, a query takes to execute. `Calls` - how many queries were there in the selected time frame. PgHero considers slow queries those that were executed more than 100 times per day and took on average more than 20 milliseconds. The list of slow queries is on the first page, right after the list of duplicate indexes. ![PGhero Queries](/assets/img/sql-optimization/pghero_queries.png) We take the first one in the list and look at the details of the query, where you can immediately see its explain analyze. If the planning time is significantly less than the execution time, it means there is something wrong with this query, and we focus our attention on this suspect. PgHero has its way of visualization, but I preferred using [explain.depesz.com](https://explain.depesz.com/) by copying the data from explain analyze there. ![Explain Analyze](/assets/img/sql-optimization/explain_analyze.png) One of the suspect queries uses an Index Scan. The visualization shows that this index is not efficient and is a weak point—highlighted in red. Great! We have examined the suspect's tracks and found an important clue! Justice is inevitable! ### Draw it! Let's draw a set of data used in the problematic part of the query. It will be useful to compare it with the data covered by the index. A bit of context. We were testing one of the ways to retain users in the application—something like a lottery where you can win some internal currency. You place a bet, guess a number from 0 to 100, and take the whole bank if your number is closest to what the random number generator got. We called it the "Arena," and the draws were called "Battles." ![Battles SQL visualisation](/assets/img/sql-optimization/battles_sql_visialisation.png) In the database at the time of the investigation, there were about five hundred thousand records of battles. In the problematic part of the query, we are looking for battles where the bet does not exceed the user's balance and the status of the battle is "waiting for players." We see that the intersection of sets (highlighted in orange) is a very small number of records. The index used in the suspected part of the query covers all created battles by the created_at field. The query goes through 505,330 records, selects 40 of them, and filters out 505,290. It looks very wasteful. ### Suppose it! We make a hypothesis. What will help the database find forty records out of five hundred thousand? Let's try to create an index that covers the bet field, but only for battles with the status "waiting for players" — a partial index. ```ruby add_index :arena_battles, :bet, where: "status = 'waiting_for_players'", name: "index_arena_battles_on_bet_partial_status" ``` [Partial index](https://www.postgresql.org/docs/10/indexes-partial.html) - exists only for those records that meet the condition: the status field is equal to "waiting_for_players" and indexes the bet field - exactly what is in the query condition. It is very beneficial to use this index: it takes up only 40 kilobytes and does not cover battles that have already been played and are not needed for our selection. For comparison - the index index_arena_battles_on_created_at, which was used by the suspect, takes up about 40 MB, and the battles table is about 70 MB. This index can be safely deleted if it is not used by other queries. ### Check it! We deploy a migration with a new index to production and observe how the response of the endpoint with battles changes. ![Battles SQL visualisation](/assets/img/sql-optimization/deploy_new_partial_index.png) The graph shows when we deployed the migration. In the evening of December 6, the response time decreased by about 10 times, from ~500 ms to ~50 ms. The suspect in the trial received the status of a prisoner and is now in jail. Excellent! ### Prison Break A few days later, we realized that we were celebrating too early. It seems the prisoner found accomplices, developed and executed an escape plan. ![Battles SQL visualisation](/assets/img/sql-optimization/prison_break.png) In the morning of December 11, the Postgres query planner decided that using the fresh partial index was no longer beneficial and started using the old one again. We are back to the "Suppose it!" stage. We are gathering a differential diagnosis, in the spirit of Dr. House: - Maybe we need to optimize Postgres settings; - Perhaps, perform a minor update of Postgres to a new version (9.6.11 -> 9.6.15); - Or maybe, carefully study which SQL query Rails is forming? We checked all three hypotheses. The last one led us to the next accomplice. ```sql SELECT "arena_battles".* FROM "arena_battles" WHERE "arena_battles"."status" = 'waiting_for_players' AND (arena_battles.bet The original article was published in the Russian-speaking community Habr in 2020. The translation into English was done with the help of GPT-3. The original article can be found [here](https://habr.com/ru/articles/509406/). --- ### My life path or how I've become a Ruby developer URL: https://madmatvey.github.io/posts/about/ Date: 2019-11-03 In fact, I started developing a lot sooner than I started earning a living at it. And it is likely that most of the "Get into IT after thirty" stories are the result of the good work of talent hunters and numerous attempts to find employment in the marketplace. Perhaps after reading this article you will feel the "inner developer" in you or, on the opposite, you will realise that this is not your story at all. I will tell you the story of my search. Hi! My name is Eugene and I started making money developing software products at the age of 33. ## Start: Siberia, school, BASIC > Some Indians count their commercial product development experience together with experience from past lives. So you might get the resume of a 25 year old candidate with 15 years of development experience. My story is more about a hobby that evolved into a profession. I grew up in a small Siberian town, where the most popular profession was a drilling rig operator. I got a personal computer only in 11th grade, and Internet access was via modem on telephone line - slow and expensive. ![Siberian town](/assets/img/city_center_of_Noyabrsk.png){: .normal } In high school, I liked to stay after school in the computer lab to play `Command & Conquer: Tiberian Sun` online with friends. The first programming language I saw was BASIC. It was fun to digging into the code of a snake game the older kids had written. I even represented the school at the city programming contest. However, the Olympiad story did not inspire me - the problems there are usually too "synthetic". ## A recording studio and my first website in PHP In my first university (none of which, by the way, I never finished) I studied `C/C++`, and even managed for a while to teach evening classes and extracurricular groups programming in these languages and earn money on students who were too lazy to write their own term and laboratory work. One day my classmates gifted me a domain name and a year of hosting, where I ran a website written in `PHP`. There, friends shared their creations with headlines like ["Why are space cockroaches afraid of Russian boiling water?](https://web.archive.org/web/20041207180526/http://punkov.net/bred/jam/38.php) ![Production studio](/assets/img/about/first_production.jpeg) My first production job was in a recording studio, where I created radio commercials and hosted live shows. Then I was in charge of sound in the concert hall for a long time. Then the production became again the editing studio of the radio station. At the radio station, I also managed to finalise the website on `Wordpress` and get the servers up for `internet broadcasting`, because I was passionate about it and wanted to be useful. ## Moving to Samara: I want to earn money by programming. I moved to Samara in 2015. It was easier to find interesting work there. I had time to work in the sales of industrial fittings and in the sales of CRM systems for business. At that time, I finally decided that I would be more useful in developing digital solutions for real-world problems. Once again I took a free web-development course at [CodeNameCRUD.ru](https://web.archive.org/web/20210117215521/https://codenamecrud.ru/) (russian version of [The Odin Project](https://www.theodinproject.com/)) and began to look for job offers in this field. I worked at a cryptocurrency startup for six months, and in the end, from the second run, [Appbooster](https://appbooster.com/) and I found each other useful, and I spent three and a half years surrounded by a great team achieving results in developing a high-loaded product. > `Ruby` `Ruby on Rails` `JavaScript` `React Native` `Swift` `Objective-C` `Java` `PostgreSQL` `Redis` `Sidekiq` `Ansible` `Circle CI` `Redash` `Ubuntu Server` `AWS` `Git` ## Production mindset Now a quick test question for anyone who wants to go headfirst into development: "Do you notice your production mindset?" For example, you take a big project and divide it into logical parts. You analyse each part and think about how to replace the complex with the simple. If you have this quality, its development will sooner or later increase your value in the market. Especially in the IT field. To find out your strengths and weaknesses and understand how you will be useful to the market, you can use the [MBTI test](https://www.16personalities.com/free-personality-test/6a7f9e5fa9c8b). After taking the test, I realized that I am by nature a "[crazy inventor](https://www.16personalities.com/entp-personality)", like Dr. Emmett Brown from Back to the Future. And for me to be of maximum value, I need a large degree of freedom in what I do and a small team to discuss and frame crazy ideas into options for the future. Without a norm of "man-hours" or lines of code per month imposed from above. ![marsovo pole](/assets/img/na_marsovom.png) ## And the main question is: "How do I start from scratch!?" - To put together a good CV, you will need completed projects completed from scratch. Descriptive text in essay format is unlikely to interest anyone. To do this, set up a github profile - for a developer this is the resume; - Study what programming languages are used to create what you are interested in; - Take at least one course in this language (there are plenty of free ones), and keep your brain in gear - constantly educate yourself (I purposely do not use the word "learn"); - Find an open-source project in this language and try to improve it. ### You will not be noticed only if you stop trying. Good luck! --- ### How to staying alive if you are an ENTP? URL: https://madmatvey.github.io/posts/what-is-entp-and-mbti/ Date: 2018-01-18 ​Hi! My name is Eugene. I'm an ENTP. This post about how to staying alive and even enjoy life in such circumstances :) Well, what is ENTP? Extraversion, iNtuition, Thinking, Perception abbreviation, used for description personal typology Myers–Briggs Type Indicator (MBTI). A fairly popular and time-tested technique for self-knowledge and building strong teams. There is not much information on this technique on the Russian-speaking Internet, but there are several free tests and the translation of the book "Do What You Are" by Paul Tieger with detailed examples of how awareness of your strengths and weaknesses can help you improve your quality of life and find yourself! www.16personalities.com free test with a fun set of celebrities or art heroes with the same personality type. For example, Captain Jack Sparrow, Adam Savage from Mythbusters and Thomas Edison - ENTP. The minus of this test is that the results are called by some unclear roles, for example, entp there is called "Debateur". Which to say the least is not the most striking feature. The service is developed by the community, so the main thing to take from this test is to make the first approximation in order to understand yourself. First of all, your MBTI personality type. ![16 personalities](/assets/img/16personalities_entp.png) The Keirsey Temperament Sorter is designed to determine the type of temperament - one of the most stable personality characteristics. The technique was developed in 1956 by David Keirsey, a professor at the University of California, who has been teaching and psychotherapeutic practice for thirty years. ru, en. For consolidation and understanding of brightness, there are forgiven and 70 questions in this test. The results of each test are saved, you can return to them if you remember the link. My results is – http://psytests.org/result?v=kei28hWsSo2r (ru) "Do What You Are" by Paul Tieger ru, en chapter from Paul Tieger’s book, “Do What You Were Born.” ENTP here are called in general: "Entrepreneurs of life." ![Life as an ENTP](/assets/img/life_as_an_entp.jpeg) --- ## Links - About: https://madmatvey.github.io/about/ - Twitter: https://x.com/EugeneLeontev - GitHub: https://github.com/madmatvey - LinkedIn: https://www.linkedin.com/in/eugeneleontev