<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Mentoring on vnykmshr</title><link>https://blog.vnykmshr.com/writing/tags/mentoring/</link><description>Recent content in Mentoring on vnykmshr</description><generator>Hugo</generator><language>en</language><lastBuildDate>Mon, 13 Apr 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.vnykmshr.com/writing/tags/mentoring/index.xml" rel="self" type="application/rss+xml"/><item><title>The compiled person</title><link>https://blog.vnykmshr.com/writing/the-compiled-person/</link><pubDate>Mon, 13 Apr 2026 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/the-compiled-person/</guid><description>&lt;p&gt;I stopped being able to explain why I knew. That&amp;rsquo;s how I found out I&amp;rsquo;d been compiled. The patterns still fire, the fixes still land, but the source files are gone. No debug symbols, no way to step through my own reasoning.&lt;/p&gt;
&lt;p&gt;A junior asked me how I&amp;rsquo;d known the bug was in the retry logic before I&amp;rsquo;d even read the function. I&amp;rsquo;d skimmed twenty lines. The answer was somewhere in my head. I tried to retrieve it and got nothing. Just the conclusion. The shape was right. I couldn&amp;rsquo;t tell you which pattern fired or where I&amp;rsquo;d learned it.&lt;/p&gt;</description></item><item><title>The invitation</title><link>https://blog.vnykmshr.com/writing/the-invitation/</link><pubDate>Wed, 18 Mar 2026 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/the-invitation/</guid><description>&lt;p&gt;First PR to an open source project, you&amp;rsquo;re proving you can read. That you studied the codebase, matched the style, understood why things are the way they are before suggesting they should be different. Most people skip this. Most PRs show it.&lt;/p&gt;
&lt;p&gt;The second and third, you&amp;rsquo;re proving you&amp;rsquo;ll stay. Maintainers have seen hundreds of drive-by contributions. One PR, gone forever. The ones who come back are rare enough to notice.&lt;/p&gt;</description></item><item><title>Garbage context in, garbage code out</title><link>https://blog.vnykmshr.com/writing/garbage-context-garbage-code/</link><pubDate>Sat, 07 Mar 2026 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/garbage-context-garbage-code/</guid><description>&lt;p&gt;LLMs are exactly as good as what you feed them.&lt;/p&gt;
&lt;p&gt;Experienced engineers feel like the gap between them and everyone else just got smaller. Someone with six months of prompting can ship something that looks like what took years to learn how to build. That&amp;rsquo;s the wrong read.&lt;/p&gt;
&lt;p&gt;The output looks the same if you don&amp;rsquo;t look closely. The architecture doesn&amp;rsquo;t. The failure modes don&amp;rsquo;t. When traffic spikes and that generated code hits a path nobody thought about, the years show up.&lt;/p&gt;</description></item><item><title>The senior who stopped coding</title><link>https://blog.vnykmshr.com/writing/senior-who-stopped-coding/</link><pubDate>Tue, 20 Jan 2026 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/senior-who-stopped-coding/</guid><description>&lt;p&gt;The terminal closes slowly.&lt;/p&gt;
&lt;p&gt;First it&amp;rsquo;s one meeting. Then a few more. Then you&amp;rsquo;re &amp;ldquo;senior&amp;rdquo; and your calendar is the job. Code reviews replace coding. Strategy replaces shipping. You advise. You guide. You no longer build. Seen this happen. Almost happened to me.&lt;/p&gt;
&lt;p&gt;The problem is not the meetings. The problem is losing touch with the trade. Architecture diagrams don&amp;rsquo;t show you the queries that fan out under load. Sprint planning doesn&amp;rsquo;t show you the retry logic that fails silently. You can&amp;rsquo;t review what you can&amp;rsquo;t recognize.&lt;/p&gt;</description></item><item><title>The first five minutes</title><link>https://blog.vnykmshr.com/writing/system-design-interviews/</link><pubDate>Mon, 30 Jan 2023 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/system-design-interviews/</guid><description>&lt;p&gt;The prompt lands. A senior engineer, capable and prepared, starts drawing boxes. Load balancer, service tier, message broker, cache. Three minutes in, they are talking about shard counts.&lt;/p&gt;
&lt;p&gt;The design is not wrong. It is not a design either. It is a collection of patterns assembled against a problem that has not been defined.&lt;/p&gt;
&lt;p&gt;A system design prompt is deliberately loose. &amp;ldquo;Design a notification system for ten million users&amp;rdquo; has four different answers depending on what kind of notifications and which ones can be lost. &amp;ldquo;Design a URL shortener&amp;rdquo; has one shape at a thousand users and a different one at a billion. The looseness is the test. A person doing this work in production would not touch a whiteboard until the brief was tight enough to design against. The candidate who treats the interview as a different kind of activity from the work has missed what the interview is for.&lt;/p&gt;</description></item><item><title>The crossover</title><link>https://blog.vnykmshr.com/writing/the-crossover/</link><pubDate>Wed, 23 Sep 2020 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/the-crossover/</guid><description>&lt;p&gt;The second cloud migration lands on the roadmap in a staff meeting. On paper it looks like the first one. A target provider, a rough timeline, a named lead. I read the slide and expect the same work.&lt;/p&gt;
&lt;p&gt;It is not the same work.&lt;/p&gt;
&lt;h2 id="the-first-time"&gt;The first time&lt;/h2&gt;
&lt;p&gt;The first migration was easy to agree to. Our local datacenter had frequent outages and every one of them carried a physical tax &amp;ndash; somebody drove over, pulled a cable, power-cycled a router. The DC had a support team, but the parts that mattered to us were ours to maintain. Cloud was the way forward and every one of us knew it. The decision did not take a meeting.&lt;/p&gt;</description></item><item><title>The compiler as first reviewer</title><link>https://blog.vnykmshr.com/writing/the-compiler-as-first-reviewer/</link><pubDate>Wed, 18 Jul 2018 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/the-compiler-as-first-reviewer/</guid><description>&lt;p&gt;When I joined, a few of us who had recently come in would skip the daily standups. Clock in, clock out, heads down. The rest of the team wasn&amp;rsquo;t sure what we were working on. This went on for a while. We were reading the existing codebase and quietly rewriting pieces in Go &amp;ndash; proving it could handle production before anyone had to commit to it.&lt;/p&gt;
&lt;p&gt;That changed when Go got formally introduced. The direction came from above &amp;ndash; Go was the language for the new services. Now it wasn&amp;rsquo;t a side experiment, it was the stack. And the PRs were coming in faster than anyone could review them all.&lt;/p&gt;</description></item><item><title>Clean designs</title><link>https://blog.vnykmshr.com/writing/clean-designs/</link><pubDate>Thu, 28 Oct 2010 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/clean-designs/</guid><description>&lt;p&gt;Two years ago I walked into a classroom in our office. Not a meeting room. An actual classroom, whiteboard, rows of chairs. The company had hired an instructor to teach the new hires Java. Two hours a day, three days a week, for three months.&lt;/p&gt;
&lt;p&gt;The training gave me syntax. Objects and classes. How inheritance works. What an interface is. The words for the things you do in code. Every week we wrote a small program and the instructor reviewed it.&lt;/p&gt;</description></item></channel></rss>