Live data from Hacker News

Maybe people do care about performance and reliability

buttondown.email

161–170 of 280 posts

Re: Maybe people do care about performance and reliability

#161

I agree with the author that we can make local changes, and I think we should. However, I disagree with the author on global changes. I think we can do them. In fact, I think local changes can grow to global ones, or close to it. Here's my personal plan: like many of you, I want to make money off of my FOSS projects. However, instead of going the donation route, I'm taking an entirely different tack. I am setting mys…

what on earth do you mean by "professional"? and how can your software be "expensive" if it is also FOSS?

or is this satire?

Re: Maybe people do care about performance and reliability

#162

I'm going to pre-emptively link Casey Muratori's Refterm Lecture Part 1[0], because invariably when this topic comes up people are all "but optimization takes time and we gotta push the new features right now or the market will eat us." Computers are so ludicrously fast these days that in the majority of cases you do not need optimization at all. You do need de-pessimization though. https://www.youtube.com/watch?v=pg…

The hilarious thing about the whole RefTerm thing is the armies of people defending Microsoft by saying that Casey is some sort of Dark Wizard and that his skills are magic and unique, which is why nobody else can reproduce his approach.

Before I saw that video, if you had asked me to write a terminal I would have made one with essentially the same design as Casey. I didn’t even think that there is another way! Like… just draw the grid of chars. What else is there to do?! Why add extra steps?

Microsoft added extra steps.

Re: Maybe people do care about performance and reliability

#163

Earlier quoted context omitted.

“Save” vs “Save as” is such a terrible convention…

It is, because arguably the more common case is wanting to save a snapshot under a different name and continue editing the original . "Save as", unfortunately, does the opposite.

I, personally, want save to act like committing a transaction. I don't like making changes to something and having every key typed or item clicked on be an immediate change to the file. The common case for me is to start making changes, then save them when I'm ready, sometimes as another file name. At least 30 years of this behavior has been ingrained into my workflows. We have undo, but I'd also like to have a revert changes option that acts like rolling back a transaction. The simple rollback is to just close the file without saving, but that doesn't work if every change big or small is a commit.

Re: Maybe people do care about performance and reliability

#164

I agree with the author that we can make local changes, and I think we should. However, I disagree with the author on global changes. I think we can do them. In fact, I think local changes can grow to global ones, or close to it. Here's my personal plan: like many of you, I want to make money off of my FOSS projects. However, instead of going the donation route, I'm taking an entirely different tack. I am setting mys…

what on earth do you mean by "professional"? and how can your software be "expensive" if it is also FOSS? or is this satire?

[dead]

Re: Maybe people do care about performance and reliability

#165

I agree with the author that we can make local changes, and I think we should. However, I disagree with the author on global changes. I think we can do them. In fact, I think local changes can grow to global ones, or close to it. Here's my personal plan: like many of you, I want to make money off of my FOSS projects. However, instead of going the donation route, I'm taking an entirely different tack. I am setting mys…

what on earth do you mean by "professional"? and how can your software be "expensive" if it is also FOSS? or is this satire?

You open source it, but offer a commercial license with warranty and support contract. Many organisations require support contracts, so won't use the free version even if they are internally capable.

Re: Maybe people do care about performance and reliability

#166

Earlier quoted context omitted.

> at least for websites We could start by stopping using these stupid pointless frameworks that provide little functionality but reams of overhead.

How much of it is frameworks like React vs boatloads of trackers and other ad-related stuff?

From my experience looking at sites for improvement opportunities, if the site is ad-monetized, it's the ads, otherwise the frameworks are multiple times the tracking stuff (analytics etc). Oh, and of course google tag manager is used to load analytics and nothing else, because you need those extra 240kb of JS to feel complete :(

Re: Maybe people do care about performance and reliability

#167

I agree with the author that we can make local changes, and I think we should. However, I disagree with the author on global changes. I think we can do them. In fact, I think local changes can grow to global ones, or close to it. Here's my personal plan: like many of you, I want to make money off of my FOSS projects. However, instead of going the donation route, I'm taking an entirely different tack. I am setting mys…

what on earth do you mean by "professional"? and how can your software be "expensive" if it is also FOSS? or is this satire?

Normal_gaussian got it right. The support and liability contract would be the expensive part, not the FOSS.

Notice that I said that I will be expensive, not the FOSS. I meant that my services will be expensive.

Re: Maybe people do care about performance and reliability

#168
post #141

Earlier quoted context omitted.

I've had similar experience working on a B2B product that we sell to financial institutions. As the end users got a taste for our UX, they began to threaten resignation if they had to go back to the old system. Word of mouth and human competition are a hell of a thing. Once a branch manager sees how efficiently someone across the street is running their business (which is effectively identical due to mountainous regu…

You have to care about the product and customer very deeply to achieve this. So many miss this, and the big boys don't only miss the forest for the trees, they can't see the leaves either. Total, narrow, limited scope. Then big boys win by Hulk Smash. Startups win by leaves and forest.

I think this is ultimately what won over our users and why they championed our product so hard. A manager at a factory would use their budget to buy our software off their approved vendors list, get it going in a couple of weeks, and within months they were among the top performing factories. As word spread and other sites adopted our product the same trend happened.

And we cared deeply about the end users. One of the best things I did was get our development teams on-site with users. We had lunch with them, saw how they used our software, and took back tons of ideas for improvements and features that we released frequently and often. I got to know a number of our users on a first name basis and would use some of them to try out new features before we released them to the rest of our customers. It was awesome.

SAP is still the 800lb gorilla and probably always will be. It was neat to work in an environment where we cared this deeply about our users that they fought to be able to use our software.

Re: Maybe people do care about performance and reliability

#169

Earlier quoted context omitted.

I'm sorry, I did phrase "companies are using JS-based apps" poorly. I meant it to mean that software vendors were delivering JS-based apps. That "(...)" you used is pulling a lot of weight. You deleted all the other context I had and stitched together two paragraphs. The explosion of JS apps is a cost saving measure for vendors that given real choice, I don't think many consumers would opt for. The point is once you…

JS apps have bounded the crappiness at the bottom end of SW competence. For example MS Teams can now be run in a browser tab where the bad stuff it can do (on purpose or thru security holes) is bounded by the sandbox and it works on Linux, unlike predecessors.

The security sandbox is a fair point. Although, embedding a web browser brings in a whole lot of extra surface area so you need to update regularly to stay secure. Electron's defaults have historically favored developer-friendliness over security and require a level of diligence from the app developer, as well. It's gotten better, for sure.

The Linux point is interesting. I have a Linux workstation I use regularly (in addition to a macOS laptop) and sometimes the desktop integration is nice to have. I just also struggle to believe a company worth 10s of billions building tools for software developers couldn't solve the problem in any other way. It feels a bit like we let companies off the hook. Whatever misgivings people have about the UI consistency, we have plenty of Linux desktop software that runs well and developed on far smaller budgets. I could live with resource-hogging vendor software if there were open protocols or APIs in place to supplant with something of my own.

Re: Maybe people do care about performance and reliability

#170

The author says that he's not a product manager and doesn't have a particular insight. As a PM, I can share how I think: The main question is "does it matter?" The answer depends case by case. For example, if I am the PM for TurboTax Premier desktop software, I know that it's latent - but it probably doesn't matter in a way that deserves prioritization. Sure, my clients would like for the forms to load faster, but th…

The tax software situation you're describing sounds totally reasonable, but it does seem indicative of a shortcoming in the market. Like, is there really a fundamental reason why the same feature set couldn't possibly be developed while also being faster for customers and not requiring more developer resources per feature? In some cases I could see that being the case: if the core task fundamentally requires signific…

// and how much is attributable simply to accumulated bloat or other things that might fall under the vague label "technical debt."

(I am the person you're responding to) - I do think that very often it indeed falls into the vague label of "tech debt" but not all debt needs to be repaid.

For example - let's say I am writing a new Turbo Tax feature and I can do it quickly by leveraging 4 existing APIs. My feature is "slow" because each API does its own complex IO operations, many of which are redundant across the 4 calls.

Is that technical debt? I have the opportunity to create a new API that optimizes the IO for my use case, and it would be 4x faster. But, it may never be "worth it" to do that because my feature is seldomly used and is still fast enough for the user to not lose productivity. So I would say that's not really a tech debt, just a technical tradeoff that was made.

In general, I find that a lot of latency comes from (a) reuse of suboptimal pieces/frameworks that accelerate development and (b) not taking the time to optimize. There are times when these are tech debt, and there are times when these are fine.

Post reply on HN