Pygmalion as a Software Developer - Kyle.au
KYLE.AU<br>PHILLIPS
Blog<br>Guides<br>Work<br>Projects<br>Notes
carved 0%
Pygmalion as aSoftware Developer<br>Kyle Phillips · July 2026<br>scroll — the carving follows
α the year it was perfect<br>Nosdesk was perfect for about a year. No bugs, no confusing workflows, nothing<br>missing. This was easy to achieve, because for most of that year it only existed in<br>my head.<br>I could see the finished product with complete clarity. A helpdesk that moved as<br>fast as the technician using it. Search that just worked. Tickets a whole team could<br>edit at once without stepping on each other. The version in the repository never<br>quite matched it. The real one had rough edges and half-finished features, and every<br>time I sat down to work on it, the gap between the two was the first thing I saw.<br>So I kept polishing instead of shipping. There's a comfortable logic to it: an<br>unshipped product can't disappoint anyone. As long as nobody uses it, the perfect<br>version stays intact, and you get to keep believing you're one refactor away from<br>it.
β the sculptor<br>There's an old Greek story about this. Pygmalion, a sculptor, is so put off by the<br>flaws of the people around him that he carves his ideal woman out of ivory instead.<br>She's flawless, because she's imaginary. He falls in love with the statue, and<br>eventually Aphrodite takes pity on him and brings her to life.<br>It's usually told as a romance. Swap the chisel for a keyboard and it's every side<br>project I've ever started.<br>Pygmalion gets one deal software developers don't: a goddess animates the statue for<br>him. He keeps the ideal exactly as he carved it, and it comes to life anyway.<br>There's no equivalent for the perfect repository sitting untouched on your MacBook.<br>Nobody is coming to breathe life into that. Products only come to life through use.<br>Until then it's ivory.
γ the statue talks back<br>Not long ago, Nosdesk went into the hands of its first real teams, and almost<br>immediately it started heading in directions I hadn't planned.<br>People asked for things I didn't think of, because the product now lives in<br>environments my imagination hadn't toured. They found uses for half-finished corners<br>and asked me to finish them properly. A couple of GitHub issues came in that refined<br>parts of a feature I was already reworking for the 1.1 release. A well-written issue<br>means more to a small project than most people realise. It says someone used the<br>thing, cared about where it fell short, and took the time to help. The roadmap I'd<br>sketched alone is now being steered by people who have been using the thing for a<br>fortnight, toward the changes that matter most to them, and it's exciting to watch.<br>This was the plan all along. I believe in the Unix philosophy: small pieces, cleanly<br>joined, each doing one thing well. I designed Nosdesk to be interoperable and<br>extensible from the start, because every helpdesk I'd worked in was a closed box<br>that couldn't be bent to do the things its own users needed. The architecture always<br>had room for other people's ideas. I just couldn't generate those ideas myself. The<br>requests coming in were design work I couldn't have done alone, from the only people<br>qualified to do it.
δ the other side of the counter<br>I've been on the wrong side of one of those boxes. Before Nosdesk existed, I spent<br>months trying to improve the helpdesk we ran at the school where I worked. I<br>followed up on issues, suggested fixes, and eventually solved one problem myself and posted the solution to the community forum. One of the lead developers told me<br>the repository wasn't the right place for questions. My fix never got a reply. I<br>wasn't attacking their product. I was trying to help finish it, and there was no way<br>in.<br>That's the trap of treating your ideal as the final form. Every user suggestion<br>becomes a deviation to defend against, and the people best placed to improve the<br>product, the ones living inside it eight hours a day, get treated as a nuisance.<br>Perfectionism assumes you're the sole author: there's one correct version, it lives<br>in your head, and every step away from it needs defending. But nobody designing<br>alone can account for every workflow their software will meet.
The product in your head isn't the product.It's the first hypothesis.
Once I actually believed that, the rest got easier. Shipping stopped feeling like an<br>admission that the perfect version would never exist. Feedback stopped feeling like<br>a verdict. A request for change isn't a critique of the vision; most of the time<br>it's the missing half of it, from someone who knows things about your product that<br>you can't.<br>Nosdesk today doesn't match the version I fell in love with in early 2025. It's<br>better. Not despite users pulling it in directions I didn't plan, but because of<br>them. It's turning into something more than what I wanted, which is a strange thing<br>to be glad about, but I am. The statue talks back. You'd be mad not to listen.<br>Venus rendered from the Scan the World 3D scan of the Venus de Milo · CC...