My Software North Star

78 points by kristoff

Lanny

The ultimate goal is to maximize utility for the end user; everything else exists in service of it, and that’s my north star for making software.

I applaud and thank the developer that lives up to this standard, but I know I don't and I think there are valid reasons to have commitments in software other than the end user. Two notable ones for me:

Professionally I write software to feed my family. I do advocate for end users, more than most!But when push comes to shove I'd be lying if I said I had more loyalty to the consumers of the crud app I get paid to work on than to my family and therefore the company that pays me (within limits).
Perhaps more interestingly, outside of work my north star is "is the work gratifying to me?", that can be artistically, aesthetically, or intellectually. That almost always lines up with what I believe to be the interests of my end user, but I have to admit both the possibility that I'm just wrong about what maximizes utility for my end users (indeed there have been plenty of cases where I have asserted I know what users need better than the users self-describing their needs, anyone who builds a product knows this is necessary but there's an undeniable hubris to it) and that if there are a few pet issues where even if you actually proved to me beyond reasonable doubt that, say, an animated hamburger menu somehow was the design decision that maximized user utility, I'd still exert authorial control and and deprive users of that utility because at the end of the day I believe I have a right to assert my aesthetic preferences in the face of all opposition in my own creative output

k749gtnc9l3w

And then outside the trade-offs, it's not always that you can define true «end users»… How to treat making a part of software user-hostile to make sure the user doesn't use it to do absurd stuff damaging users of their work?

(I have been in the discussions of building something specifically to be there to make sure some specific extremely highly Goodhart-able reporting — with a pretty large splash damage radius for this Goodhart-ing — is forever «not yet» working despite any wishes of the user of the software)

lightandlight

I have a similar approach.

Even if a tool is not "lovable", like a screwdriver, it's still very reliable for a very long time. My Phillips head screwdriver permanently has its Phillips head. It's not as if 1% of the time when I take it out of the toolbox to find it has a flat head, and I have to try again by returning it to the toolbox. And I'm not subject to endless variations of handle designs. I just get to use the tool I bought until it breaks.

I want more software to be like that.

avh-on1

What do you mean by "tools that are not loveable, like screwdrivers"?
- lightandlight
  
  The article mentions "software you can love" and links to https://softwareyoucan.love/. I'm riffing on my interpretation of that concept, and comparing software to physical objects.
  
  A custom guitar, for example, is first carefully crafted then makes its way to an owner who will cherish it, both for the craftmanship and for how the instrument actually plays. https://softwareyoucan.love/ feels like it skews more to this side of the analogy.
  
  But there are also many tools that are completely mundane, lacking craftsmanship or charm (not "loveable"), yet perform so well that we take them for granted. Like screwdrivers.
  - kristoff
    
    I think that limited scope, highly effective software can be loved by its users. Think about how much passion people put in their pocket multi-tools.
    
    Johz
    
    Similarly, a kitchen knife is just a knife, but I still have my favourite kitchen knife at home that I use for basically everything. I think you can definitely "love" (for want of a better word) well-made, dependable simple tools.
  - k749gtnc9l3w
    
    nobody is able to maintain it, let alone add new features
    
    fixing all bugs
    
    I am not sure how fixing all the bugs without eventual scope-freezing is supposed to work
  - ohrv
    
    It doesn’t matter if your blockchain has no bugs, if it’s a rugpull
    
    You could even fit all three into this: making your /s/blockchain/thing/ more efficient does not matter if you introduce new bugs, but that only matters if it’s not a rug pull!
  - alterae
    
    and this post is how i learn tiger style has a website now
  - HugoDaniel
    
    This is an maximalist utilitarian viewpoint of software, a lot of tools fit this purpose (most notoriously LLMs). I am glad that someone is able to put things in such a plain and direct way even if personally I do not abide to any of this, because a lot of software devs that should be driven by utilitarianism (either contractually or purposefully or whatever else) fail to recognize it.
    
    Now arguably the reasons that brought the majority of us into software are none of these, and when utilitarianism hits us in the face like a brick, remembering those same reasons that made us tickle way back then can be a safe harbor.
  - deevus
    
    I noted that there is no requirement that software be written solely by a human. It's interesting to me at least, since Kristoff is (AFAIK) a core developer on Ziglang.
    
    I'd like to think that I can create software using AI-assisted development that fits these requirements.
    
    For me there is this duality. I enjoy hand-writing code. I also enjoy finishing things. Sometimes they fight.
    
    I am sorry for bringing AI into this. But it's hard to put aside given:
    
    Kristoff's tight coupling to the Zig community
    
    Zig's strong stance in this regard
    
    I keep proselytising Ziglang anyway
    
    kristoff
    
    This post is not really about which tools are better or worse for achieving the goal, it's about motives: your end goal should be making useful software and not overfit any of the sub-goals, nor think that all that matters is your developer experience.
    
    I mentioned the (insane) memory-safety blog post that was shared here yesterday because to me that is an example of overfitting, but Rust can be a great tool for achieving the ultimate goal if it feels good in your hand.
    
    If you think that AI helps you writing software, then use it, but make sure to evaluate the end outcome against the ultimate goal, and nothing else.
    
    deevus
    
    Thanks for the considered reply.
    
    Aks
    
    I'd say the point 3 implicitly says against those tools. All they seem to make is unmaintainable spaghetti.
    
    orib
    
    It's interesting. Until very recently, nobody had thought to label their software as being built without massive amounts of theft from artists and engineers or without massive environmental damage.
    
    It's a shame that this has changed.
    
    xq
    
    I guess there's a reason this is published on Loris' personal blog, not on ziglang.org.
    
    Just because you're with a project which has a clear stance towards LLM based code doesn't mean everyone in the project shares this stance for this, or all projects.
    
    This isn't specific to Loris in general, but it makes sense to evaluate such a decision on a case-by-case basis.
    
    singpolyma
    
    "AI assisted" development is created by a human so I'm not sure exactly what you're getting at.