jckzlg

In this case the mountain is web-hosted git repos? This particular mountain already has at least 3 ski lifts you might have heard of called GitHub, GitLab, and Bitbucket.

When I say “matter” I’m not being normative, I’m saying that this particular tool’s value add has nothing to do with its discoverability on the World Wide Web. Sourcehut’s website is a signpost not an advertisement. The set of users who are put off by the design but would have otherwise used the tool is negligible. Comparing sourcehut’s design to Stripe is like comparing a Camry to a dune buggy.

You misunderstand my point, which is that only “genuine attempts” matter in this particular case. Sourcehut is clearly working to stay away from the lightspeed, attention-shaping, zillions of fundamentally distracted users zeitgeist. You’re critiquing it from within a paradigm that it’s somewhat explicitly separating itself from. This is the whole reason sourcehut looks the way it does and that we’re even having this conversation. What you’re saying is 100% correct in terms of design but also missing the forest for the trees.

The sourcehut landing page has ~300 words on it. Those words could be literally arranged in a giant spiral and still not require 3-4 genuine attempts to learn what sourcehut does. This comment is a total caricature of the actual and tangible benefits of a well-thought-out UI. Sourcehut is an engineering tool and its landing page is not designed to harvest registrations and clicks. The lack of design is not a failure of design, it’s just that design is not that important on this particular website.

I honestly don't understand this comment, what is wrong with reading it from top to bottom? The very top of the landing page has a list of high-level reasons to use sourcehut, and then the rest of the landing page is just a detailed list of features. Is there some other "efficient" way to read a website that involves some non-linear sequence of jumps around the page?

There's some pretty low-hanging fruit on sourcehut's landing page (like vertical spacing) but it really does take 5 seconds to learn why to use sourcehut. It's right at the top with a bold header that says "welcome to sourcehut" and a literal bullet list of reasons.

I'm late to the party but I just stumbled on something Ursula K. Le Guin said that I think is the perfect answer:

"When action becomes unprofitable, gather information. When gathering information becomes unprofitable, sleep."

I have struggled with similar issues for years. I have a kinda weird take on the topic, but I think it might be helpful. I think the “persistence paradigm” we’re living through causes these sort of psychological short circuits where we forget that what we’re doing is building our minds and not building some external edifice or monument that we can point to as our “knowledge”. There is never going to be a moment where you can point at your stack of notebooks or answers to textbook questions or list of books you’ve read and say “I’ve done it, I’ve learned so much”. The widespread behavior of persisting moments of our lives out into cyberspace has sort of bled into our psychologies. I think this is partially why you see so many people struggling with these sorts of questions.

So the short answer I think is to focus on a process of daily improvement instead of some systematic program for self study. Just read 60 minutes a day, journal 30 minutes a day, and place absolutely no restrictions on the subject matter. For a while I also burned my notebooks every 30 days, that was really helpful. These days I actually do record a lot of my thoughts but I try not to get bogged down too often in the systemization of the practice.

The issue here in my opinion is not that someone would “run apps in the cloud from your editor”, it’s that a software engineer would need or want an entire SaaS product for such a trivial task.

I almost entirely agree, and I think the word "favor" wasn't the best choice. My opinion is that many developers will often consult Google or Stack Overflow before consulting a manpage or documentation or will only briefly consult documentation before a Google search. I'm definitely guilty of this, especially when I'm under a tight deadline, but I think it's a behavior that should be avoided when possible. Navigating documentation and/or manpages forces you to engage with the structure of the tool you're using, Google and Stack Overflow do not.

> In general this is against our principles. We prefer to teach people how to use powerful tools rather than make less powerful tools that are easier to use.

I agree deeply with the ethos this statement represents. It's hard for me to formulate at the moment what I think this "ethos" is exactly, but I think it's really important. I'll try to explain by example. I think we should favor manpages over Stack Overflow, documentation over Google, composable CLI tools over monolithic IDEs, etc. I think that every engineer on a team should have read the most popular O'Reilly book (or some equivalent) for each of the tools the team works with. Of course, these "rules" are not commandments and we should always strive to be prudent.

Sometimes I'm accused of being cranky for these sorts of opinions, and I guess I might be, but I also see so much time and money wasted because nobody in an organization understands basic tools like SSH or how to use systemd.

The other day there was a developer tool on the front page of hacker news that lets you "run apps in the cloud from the comfort of your own editor". This is in my opinion a sign of the techpocalypse.

Edit: s/UPPERCASE/italics/