Friday, August 21, 2026

Hold Our Own Ideas Loosely

 I had a long conversation with Claude.ai. It was mostly about interview techniques for hiring software engineers, but as is my habit, it got philosophical.

At one point I complained about timed programming tests. One problem I have with them is that it pushes you to code so you don't run out of time. So the first idea you have on the solution approach is generally the one you stick with. But a good engineer will consider multiple approaches. A *really* good engineer might be dissatisfied with their current solution set and bounce ideas off a collaborator to get fresh thinking. A timed test pretty much precludes any of this and only measures if the best solution pops into their mind within the first 30 seconds. That's not what I hire for.

At another point I mentioned that in my F2F interview, I ask for two solutions to a problem that we investigate together. I expressed surprise at the number of candidates who can only think of one solution, and keep trying to dress it up in different clothes as their second.

Claude crystallized those two observations with "Hold our own ideas loosely." This really resonated with me strongly for several reasons:

  • Avoid "not invented here". We want good ideas no matter where they came from. Leave your ego at the door.
  • Closely related: Avoid attachment. Once you've invested in your idea, don't hold it too stubbornly, especially in the face of new information. Don't fall victim to the sunk cost fallacy.
  • Don't let your first idea blind you to further thinking. Re-frame the problem in different ways. (In a previous post I described falling victim to this in ... wait for it ... a timed coding test.)
  • Embrace collaboration. Two minds will usually produce a better solution than either one in isolation. Some of my most rewarding work experiences came from working with another engineer where our final solution was a wonderful synthesis of our two starting points. I find that exhilarating, not demeaning.
Anyway, sometimes Claude comes up with a gem, and this one kind of hit home.

DIGRESSION:

I don't want to overplay Claude's insight or creativity here. When prompted on who they were quoting, Claude responded basically that they modified a well-known maxim "strong opinions, weakly held". Claude didn't know they were producing a clever twist. It just did what LLMs do - summarizing a concept into statistically-likely words. It had the concept, which was close to the "strong opinions" concept, and generated similar text. The cleverness came from the good writers included in the training data.

Monday, June 29, 2026

Precision Tools from Innocraftsman

In addition to being a software developer, I'm also a little bit of a DIY handyman. Not a very good one - I'm not one to make things *look* good, just function well. But mostly, I just love tools.

A while ago, I got Innocraftsman's mini drill press. Note, this is a VERY small drill press, intended for precision work. I splurged and got the model with the brushless DC motor and the better belt. I've only used it once, but again, I love the precision and quality of the tool. And my wife, an artist and a maker, has used it quite a few times. Color us a satisfied customer.

Another thing I didn't have is a nice vise. I have a cheap one with a suction cup bottom, and it's OK, but sometimes the heart wants what it wants. So I ordered Innocraftsman's 2-Inch Universal Precision Sine Adjustable Angle Vise. No, I don't need it. I don't do the kind of work it was intended for. But dammit, I WANT it. :-)

So, what did I receive? A box of ballpoint pens. They have a custom inscription on them in Spanish. And there's a lot of them, I would guess 500. Obviously shipped from China, so something got mixed up in the process.

I contacted Innocraftsman and we did a little bit of detective work - I found out where UPS picked it up from. The logistics company presumably got a large container from China and re-shipped each product, but put my label on the wrong box. Somebody else presumably got my vise, and we didn't have a lead on where it might have gone.

Fortunately, Innocraftsman didn't make a fuss, they just shipped me a new one, and it arrived yesterday. Even though I haven't used it yet, I just love looking at it and manipulating its controls.

AND I have a box of pens. Anybody want a pen? ;-)

So credit to Innocraftsman for making awesome precision tools, and credit for making good on a problem that wasn't their fault. Thanks!

Thursday, April 2, 2026

lsim and ldraw

Huh. I've never really talked about lsim here. Strange since I'm fairly pleased with it. I made an allusion to it here, but didn't really talk about it. Hmm ... maybe it's because it's a pretty niche project - of no particular use to anybody except me.

HAH! Like that's ever stopped me.

LSIM

Lsim is a hardware logic simulator. You specify a set of devices, like NAND gates, latches, LEDs, and switches, and specify how they connect. Lsim then simulates the circuit. The non-NAND logic devices are simply composites of NAND gates; my goal is to design a simple CPU using only NANDs.

It's a tool that only I could love. There's no GUI. No blinking lights. No wave forms. It's pure text, both input and output. It's a pain to describe the circuit with the little language I devised, and it's a bigger pain to interpret the output to see if it does what it is supposed to. I'm so proud.

Claude has helped me with lsim, mostly by reviewing it for me and finding bugs. I think I had it write one or two little utility functions (who remembers how to write vararg code?), but 99% of it is mine. The code reviews saved me much debugging time. Thanks Claude!

Some day I might make a blog post about its internals - it has a few interesting aspects - but let's skip that for now.

Anyway, my biggest problem has been interpreting the output of LSIM. I find I need to look at a properly-drawn circuit diagram so that I can visually trace signals and verify that the printout is doing what I want. But drawing logic circuits is hard, and it's even harder to ensure that the diagram matches the circuit given to lsim.

LDRAW

So I started the ldraw project. This is a GUI drawing tool that lets me draw a circuit diagram using the devices that lsim supports. It can then export an lsim input file containing the lsim commands to define the devices and connect them. Now I can create a circuit and know that the lsim commands match the drawing. Saves time and is much less error-prone.

It is NOT a general-purpose tool with a large library of standard parts. It is intended to be used with lsim, so it only supports the lsim components.

A few quick notes:

  • It's Javascript and CSS that lives inside a single html file and runs in the chrome browser.
  • It was written by Claude.ai. I used the chat interface (Opus 4.6 in "extended thinking" mode).
  • I "vibe coded" it, a term I don't like, but I don't like "hallucination" either. Coiners of new lingo don't come to me for advice.

Regarding the "vibe coding", I don't know Javascript, and I've never learned the libraries or environment of a browser. Sure, I could have learned it - what, maybe a week or two? - but I also have no interest in GUI work. I.e. it would be a chore. This is my hobby; I avoid chore work whenever possible. So I have not reviewed Claude's code.

Claude has. After every significant phase of development, I ask Claude to: "Perform a deep review for bugs, paying special attention to state management and potential opportunities to make the code more maintainable." Even though it just finished coding, it always finds a few things. One time it decreased code length by about 400 lines by replacing identical repeated code with a few helper functions.

And, of course, I've tested it. Given the nature of the program, most bugs show up pretty quickly. 

I'll post a few interesting details about the methodology we used in a different post.

WHY NOT CLAUDE CODE?

An obvious question: why use the chat interface and not Claude Code?

I tried CC for a different project. It failed. I had asked it to take my lsim language and convert it to a netlist that lcapy could use. Seemed like an easy enough project. CC cranked for an hour or two (with me having to be there the whole time to tell it to keep going). It kept getting errors from lcapy, and having to reverse-engineer the lcapy code to understand why. At the end it declared success. I fired up lcapy with the resulting .sch file, and it was complete garbage.

Now maybe this was just a fundamentally hard problem, and the web interface could not have done any better. Or maybe I didn't use it well (it was my first time trying it). But I can tell you this: using CC wasn't particularly fun. I enjoy the back-and-forth that the chatbot gives me. At the risk of over-anthropomorphizing a chatbot, it feels collaborative instead of directive.

It even laughs at my jokes. (Sort of...)


Tuesday, March 31, 2026