<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Code-Quality on vnykmshr</title><link>https://blog.vnykmshr.com/writing/tags/code-quality/</link><description>Recent content in Code-Quality on vnykmshr</description><generator>Hugo</generator><language>en</language><lastBuildDate>Sat, 07 Mar 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://blog.vnykmshr.com/writing/tags/code-quality/index.xml" rel="self" type="application/rss+xml"/><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>Node.js style guide</title><link>https://blog.vnykmshr.com/writing/nodejs-style-guide/</link><pubDate>Wed, 20 Feb 2013 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/nodejs-style-guide/</guid><description>&lt;p&gt;We&amp;rsquo;re a Node.js team of about 25 developers, most of them fresh out of college. Node was new to everyone. This is the style guide we put together to keep the codebase consistent.&lt;/p&gt;
&lt;p&gt;Based on &lt;a href="http://nodeguide.com/style.html"&gt;Felix&amp;rsquo;s Node.js Style Guide&lt;/a&gt; with our own picks where his guide left things open. Read Felix&amp;rsquo;s first &amp;ndash; this extends it.&lt;/p&gt;
&lt;h2 id="formatting"&gt;Formatting&lt;/h2&gt;
&lt;p&gt;2 spaces. No tabs. No discussion.&lt;/p&gt;
&lt;p&gt;Trailing whitespace: strip it. Your editor should handle this. If it doesn&amp;rsquo;t, fix your editor.&lt;/p&gt;</description></item><item><title>History as communication</title><link>https://blog.vnykmshr.com/writing/git-history-as-communication/</link><pubDate>Mon, 18 Feb 2013 00:00:00 +0000</pubDate><guid>https://blog.vnykmshr.com/writing/git-history-as-communication/</guid><description>&lt;p&gt;Most teams treat git history as a side effect. You work, you commit, whatever ends up in the log is the log. Merge commits pile up. &amp;ldquo;WIP&amp;rdquo; and &amp;ldquo;fix typo&amp;rdquo; and &amp;ldquo;actually working now&amp;rdquo; sit next to meaningful changes. The history is technically accurate but communicates nothing.&lt;/p&gt;
&lt;p&gt;The alternative: treat history as something you write, not something that happens to you. The commit log is the one piece of documentation that&amp;rsquo;s always in sync with the code &amp;ndash; because it &lt;em&gt;is&lt;/em&gt; the code&amp;rsquo;s changelog. If the history is incoherent, you&amp;rsquo;ve wasted that.&lt;/p&gt;</description></item></channel></rss>