Good analogy, and cool story. IME real-world events rarely follow such a linear narrative but I found your company from your profile, and like that its blog -- https://www.hrvey.com/blog -- shares insights from an "entrepreneurial journey" perspective. Congrats!

Thanks, this was a nice read.

And closing with...

> Bookkeeping can be as annoying as debugging, but in the end I'm really grateful that I understand how each detail works.

... hits home for me, haha. Never thought I was going to understand - let alone like - bookkeeping. What maybe helped, was me making my own bookkeeping app, it also forced me to understand the rules.

> It doesn't matter how well you code if people can't understand the user interface

The variation on it I like to emphasize is: it also doesn't matter how "readable" your code is if the user/customer finds it broken, so stop trying to optimize for readability as the primary criterion.

{correctness, usability} to the customer > code maintainability > code readability

I agree with your point. However, I think I look at it from a slightly different perspective.

When it comes to any code I produce (with the exception of some learning projects), I try to keep it: effective, efficient and simple. In that order.

Effective is essentially what you were saying about correctness and usability from the user perspective. Peter Drucker would say to be effective is to "do the right thing." This is always an outward focused item. Does it impact the user in the right way? Does it solve the right problem? Etc. This is hands down the most important thing. Nothing else matters if you're doing the wrong thing.

In contrast, efficiency is to "do the thing right." Once you're doing the right thing, minimizing your costs, increasing your quality, making it so your code doesn't "consume the whole world" all fall under this category. Poor efficiency can negatively impact the effectiveness of your code. "It does this really cool thing, but it takes far too long to load so I can't use it."

Then lastly, keep it simple. That is not to say ignore the natural complexity of the problem, but rather to keep the solution to the essential complexity of the problem. Keeping things only as complex as they need to be covers a whole lot of dimensions in software. It makes things more explicit and understandable, it helps with code readability, and code re-usability. It decreases the surface area of what needs to be maintained. All good things for the health of the dev and the project.

It's all in that order for specific reasons. They move outside in. As the dev, I'm not the most import person with respect to the code I'm writing. The user is, and so the code needs to be purposeful to them (efficacy). Efficiency is more about the product, making sure it works properly. Keeping things simple, although it impacts efficacy and efficiency, is largely a positive for me and helps me maintain sanity.

I think it's important to note that it's all of these things, not just one of them. We'll approach tradeoffs in a prioritize way, but we're striving for the three of them. Obviously a very difficult task. But I find that approaching engineering this way has helped me grow a lot as an engineer.

Anyway, first time post here. Your comment made me think of this. Thanks for coming to my tedtalk.

You put it quite elegantly. Especially here:

> Keep the solution to the essential complexity of the problem.

Thanks!

I disagree. All else being equal, readability is the most important criteria. And readability is the greatest contributor to maintainability. Next to that, being "well-organized" is what makes something maintainable.

If your code is correct but unreadable or disorganized, it will be hard to extend.

If your code is incorrect, but organized and readable, it will be easy to fix.

If your code is incorrect and organized, but unreadable, it will be hard to fix and extend, but easy to make it more readable, thus more extensible and fixable.

If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable.

And code is always incorrect.

> If your code is incorrect and disorganized but readable, it will be hard to fix and extend, but easy to refactor, thus more extensible and fixable.

The state you want to reach is "fixed", not merely "fixable". I've seen too many people applying your reasoning staying perpetually stuck in the broken-but-"fixable" state because they prioritize "readability" higher, and I'm saying your users don't care about that. They want a fixed (read: correct) state.

> And code is always incorrect.

This makes a strawman of my argument.

> The state you want to reach is "fixed", not merely "fixable".

And my argument is that readable code is the most direct route to that state.

> > And code is always incorrect.

> This makes a strawman of my argument.

It would if it was actually part of my argument, and not a cheeky parting shot.

Here's the straightforward version. In my experience, the most productive way to approach code is to assume that at some point a bug will be found, or you will have to extend it. You may disagree, of course, but my views all flow from this assumption.

> And my argument is that readable code is the most direct route to that state.

Which has absolutely nothing to do with my point.

Nobody is arguing whether you should keep your codebase readable. The question is whether that should be prioritized over correctness.

The situation is: your codebase is already as readable as possible, but you've now discovered a problem for which you're failing to come up with a readable solutions. [1] I'm saying, when that happens, you need to be willing to just bite the darn bullet and go with the ugly-but-correct solution so that your customers actually get their problems addressed. Don't just leave it as a dangling "known issue" or leave some silly hack in there just to "keep the code readable". Your customers/users won't applaud you for keeping your buggy codebase readable. Of course you can feel free to make a ticket or leave a TODO in case you're hitting a blind spot or someone better comes along in the future. But for now, solve the dang problem first, because your customer isn't paying you for source code, but for the end product. (Well, unless your customer is paying you to ship source code to them, in which case you should ignore me.)

[1] To be crystal clear (and hopefully avoid more strawmen...), I'm saying you (and your team/company/etc. as applicable) need to actually do your best to implement a readable solution first, and THEN fall back to an unreadable one if you fail to do that despite your bona-fide attempts. For some reason (maybe it makes it easier to argue over the internet? maybe it's just more convenient?) people love to strawman "you should prioritize correctness over readability" as "you should go with the first solution you like whether or not it's ugly; feel free to leave a TODO for some poor soul to polish it later". Which has emphatically never been what I've been saying, but that's what people appear to respond to.

It feels like your argument is a bit of a strawman itself. I'm hard-pressed to come up with a situation where the code is broken but readable, and the quickest way to fix it is to make it less so.

Sure, there are times when I don't know or don't have the time to come up with the best structured solution, but have to put something out there that just works. I would argue that's where you should strive to make it even more readable, because the uncertainty means the odds of having to revisit it later are even greater.

Your code might need to be: usable, fast to market, readable, maintainable etc. You have to optimize for whatever conditions you need.