Victor Santos

Commands worth keeping around

Victor Santos — Wed, 03 Jun 2026 00:00:00 +0000

Commands worth keeping around</h1>
This is a running list of small commands that solve annoying development workflow problems.</p>

Stop Windows from content-indexing noisy folders</h2>

Some folders are useful to keep on disk but not useful to search through with Windows indexing. A good example is node_modules</code>: thousands of dependency files that can make indexing noisier than it needs to be.</p>

To tell Windows not to content-index a folder:</p>

attrib +I "C:\folder\not\to\index" /S /D
</code></pre>
What each part does:</p>

+I</code> sets the "not content indexed" attribute</li>
/S</code> applies it to files inside subfolders</li>
/D</code> applies it to folders too</li>
</ul>
This is especially useful for generated or dependency-heavy folders:</p>
attrib +I "C:\path\to\project\node_modules" /S /D
</code></pre>
This does not exclude the folder from OneDrive sync. It only tells
Windows Search not to content-index those files.</p>



Things to pay attention to when building web applications
Victor Santos — Tue, 02 Jun 2026 00:00:00 +0000
Things to pay attention to when building web applications</h1>
This is a running list of small details I do not want to forget when
building web applications.</p>
Some will be about forms. Some will be about accessibility,
performance, browser behavior, APIs, deployment, or anything else that
only becomes obvious after the product is in front of real users.</p>
Disable password manager suggestions on non-login text fields</h2>
If a field is for search, filtering, tagging, naming a project, writing a
note, or entering any text that is not authentication data, tell password
managers to leave it alone.</p>
The common attributes are:</p>

1Password: data-1p-ignore</code> or data-op-ignore</code></li>
LastPass: data-lpignore="true"</code></li>
Bitwarden: data-bwignore</code></li>
Dashlane: data-form-type="other"</code></li>
</ul>
In practice, I usually put the set on text inputs that should never open
a credential picker:</p>
<input
  type="text"
  name="project_name"
  autocomplete="off"
  data-1p-ignore
  data-op-ignore
  data-lpignore="true"
  data-bwignore
  data-form-type="other"
/>
</code></pre>
This is not a replacement for good form semantics. Login forms should
still use proper autocomplete</code> values like username</code>,
current-password</code>, and new-password</code>.</p>
The point is simpler: do not let authentication tooling interrupt fields
that have nothing to do with authentication.</p>


Building vss.dev as a code editor
Victor Santos — Sat, 30 May 2026 00:00:00 +0000
Building vss.dev as a code editor</h1>
I wanted my site to be</em> the thing it talks about. So instead of a hero
section and a wall of buzzwords, you're looking at an editor, and every
part of me is a file you can open.</p>
The constraint that made it fun</h2>
Content is plain markdown. The pages are pre-rendered to static HTML by
Zola</a>, so there's no front-end framework and
no client-side rendering to wait on. If I'm going to put this on a
résumé, the source should be as honest as the content: view-source and
it's all right there.</p>
That meant writing the editor chrome myself, including a file tree, tabs,
a command palette, and a syntax highlighter for the source view:</p>
function openFile(path) {
  if (!tabs.includes(path)) tabs.push(path);
  active = path;
  render();
}
</code></pre>
The one detail I care about</h2>
The editor chrome is monospaced. That's the costume. But the moment you
read a post, the words are set in a serif. Code is for machines; writing
is for people. Letting those two voices sit side by side is the whole
idea.</p>
What I'd tell past me</h2>

Ship the small version. A site you launch beats a redesign you don't.</li>
Constraints are a gift. "Plain markdown, no framework" killed a hundred decisions.</li>
Make the thing you'd want to find.</li>
</ul>
Want the short version of how I work? Read the five-minute rule</a>.</p>


Escaping the tutorial trap
Victor Santos — Sat, 18 Apr 2026 00:00:00 +0000
Escaping the tutorial trap</h1>
For a while I measured progress in courses finished. Neat checkmarks,
zero scars. The problem with tutorials is they remove the one thing that
actually teaches you: getting stuck</em>.</p>
The shift</h2>
I started a rule: for every hour of watching, an hour of building
something that wasn't in the video. Break it, fix it, look it up only
after I'd been confused on purpose.</p>

You don't learn to debug by reading about debugging.</p>
</blockquote>
What changed</h2>

I stopped fearing the red error text and started reading it</li>
My questions got sharper, and so did the answers</li>
I built things I could actually point to</li>
</ul>
The checkmarks felt good. The scars taught me more.</p>


Debugging by bisection
Victor Santos — Mon, 02 Mar 2026 00:00:00 +0000
Debugging by bisection</h1>
When something breaks and you have no idea where, don't read every line.
Cut the problem in half.</strong></p>

Comment out half the code. Does the bug survive? Now you know which half.</li>
Repeat. Each step throws away 50% of the search space.</li>
A bug hiding in 1,000 lines is about 10 halvings away from caught.</li>
</ul>
Same trick, different name. It lives in git bisect</code>, which binary-searches
your commit history for the one that broke things:</p>
git bisect start
git bisect bad            # current commit is broken
git bisect good v1.4.0    # this old one worked
# git checks out the midpoint; you test and mark good/bad
</code></pre>
Stop guessing. Start halving.</p>


The five-minute rule
Victor Santos — Tue, 10 Feb 2026 00:00:00 +0000
The five-minute rule</h1>
Before asking anyone (a teammate, a forum, a model), give yourself a
strict five minutes</strong> to write down three things:</p>

What I expected to happen</li>
What actually happened</li>
What I've already tried</li>
</ol>
Two outcomes, both good: half the time, writing it out is</em> the fix. The
other half, you've just authored a question people actually want to
answer.</p>

A good question is a debugged thought.</p>
</blockquote>

Victor Santos

Commands worth keeping around

Commands worth keeping around</h1> This is a running list of small commands that solve annoying development workflow problems.</p>

Things to pay attention to when building web applications

Building vss.dev as a code editor

Building vss.dev as a code editor</h1> I wanted my site to be</em> the thing it talks about. So instead of a hero section and a wall of buzzwords, you're looking at an editor, and every part of me is a file you can open.</p>

The one detail I care about</h2> The editor chrome is monospaced. That's the costume. But the moment you read a post, the words are set in a serif. Code is for machines; writing is for people. Letting those two voices sit side by side is the whole idea.</p>

What I'd tell past me</h2> Ship the small version. A site you launch beats a redesign you don't.</li> Constraints are a gift. "Plain markdown, no framework" killed a hundred decisions.</li>

Escaping the tutorial trap

Escaping the tutorial trap</h1> For a while I measured progress in courses finished. Neat checkmarks, zero scars. The problem with tutorials is they remove the one thing that actually teaches you: getting stuck</em>.</p>

What changed</h2> I stopped fearing the red error text and started reading it</li> My questions got sharper, and so did the answers</li> I built things I could actually point to</li> </ul> The checkmarks felt good. The scars taught me more.</p>

Debugging by bisection

The five-minute rule

Commands worth keeping around</h1>
This is a running list of small commands that solve annoying development workflow problems.</p>

Building vss.dev as a code editor</h1>
I wanted my site to be</em> the thing it talks about. So instead of a hero section and a wall of buzzwords, you're looking at an editor, and every part of me is a file you can open.</p>

The one detail I care about</h2>
The editor chrome is monospaced. That's the costume. But the moment you read a post, the words are set in a serif. Code is for machines; writing is for people. Letting those two voices sit side by side is the whole idea.</p>

Escaping the tutorial trap</h1>
For a while I measured progress in courses finished. Neat checkmarks, zero scars. The problem with tutorials is they remove the one thing that actually teaches you: getting stuck</em>.</p>

What changed</h2>

I stopped fearing the red error text and started reading it</li>
My questions got sharper, and so did the answers</li>
I built things I could actually point to</li> </ul>
The checkmarks felt good. The scars taught me more.</p>