wbharding

The relevant trend that covid has accelerated is giving workers more autonomy. I don't think humans are good at figuring out how to resist the perils that come with it. Absent willpower, or a job that's inherently aligned with one's natural interests, human nature inevitably drifts toward distraction.

I think that's partly because so many people yearn for more human connection, which in covid times is often expressed as unnecessary Slack conversations. Also, because humans are naturally wired to be drawn toward whatever is most recent; until a few hundred years ago, if an event happened nearby you, that was always the most important thing to which attention should be directed. Finally, I don't think that "avoiding distraction" is even a goal for many people, especially if they're meh about their job or they feel watching current social trends are more important/interesting than their job.

I doubt there is a generalizable solution for these "perils of autonomy." But if eventually we move away from the synchronous messaging that pervades modern office culture, that would be a step in the right direction. Slack needs a mode that debounces messages so they're delivered en masse once per hour unless a box is checked that the message is urgent.

In the future, when more people work as independent contractors, that ought to help too. This isn't a problem that a manager will step in and fix by imposing a new policy, as the story seems to imply.

Much truth to these tactics for maximizing attention, esp exercise. Not mentioned is the #1 attention killer in my experience: working on boring tasks.

I’ve found productivity maximized when I make time to work on an interesting project every day or two. Making progress on enjoyable tasks gets me started with the momentum to tackle the nasty, boring ones.

My conclusion is ironic in that I’m the CEO of Amplenote, a note taking/todo list app built to ensure “urgent” or “important” tasks get scheduled to the calendar. I consider myself more disciplined than the average bear, but I’ll be damned if I can focus my attention for more than half the day on tedious tasks.

Meanwhile, when running down a feature or bug fix that will directly help me as a user, I can often focus for 12 hours of programming. I think dogfooding is central to the best products because it begets genuine interest, thus attention, from its developer/users.

It looks like the link they provide for comparing the source of 3.0 and 2.7 is busted on Github, but you can get a sense for the scope of this on GitClear's Open Repos https://www.gitclear.com/open_repos/ruby/ruby/releases. Looks like about 4x more repo evolution has gone into this version than previous.

See also: list of the biggest tickets tackled in 3.0: https://www.gitclear.com/open_repos/ruby/ruby/release/pendin...

Props to you, that’s a fun game, even on mobile. I’m guessing the wife must’ve loved it.

The world has been hard up for terminology to describe what’s bad about the forces that have dragged down SSC and driven Weiss away from NYT. “Cancel culture” was a good start, as evidenced by those who have been rankled by the suggestion of its existence. My fave part of this essay is that it offers a shiny new tool, “orthodox privilege,” that allows us to enumerate the case for a countervailing force against this age of outrage.

This has sufficient public momentum to prove that a plurality believes the current system does the public more harm than good. Of course, removing cops will reduce harm done by cops to the public. But it will also reduce harm done by cops to law breakers. Intuitively, I would expect the law breakers to benefit disproportionately, since the cops stated mission was to prevent law breaking and all.

Statistics I've read suggest that US cities have been getting progressively safer over the past generation. It's interesting to wonder if our generation of safety has allowed us to forget that "order" and "justice" are not intrinsic qualities of humanity (nor any other animal group). Looking forward to seeing how Minneapolis will go about delivering consistent justice with no bad actors enforcing it. Will also be interesting to see which types of law breakers emerge as the winner from decimation of their traditional adversary.

Full disclosure: I am CEO of a productivity/note taking app (Amplenote) that arguably competes with Roam.

Roam & Zettelkasten share a user base thick with academics. Productivity doesn't tend to be their stated end goal. Their goal is more often to arrange thoughts into webs of knowledge. They allow connected ideas, like wikis, except with zero forethought put into how the ideas should be organized. People really like being able to start writing without figuring out how to organize the thing they're about to write.

The goals that the R&Z community will benefit everyone as they seep into the broader ecosystem. It's (purported to be [1]) a powerful experience if you have the time to build a visualized network of your thoughts and see how they connect together. But it's not very similar to getting things done.

Incidentally, our app, Amplenote, allows bidirectional linking like Roam, and is focused specifically on helping users get things done (e.g., https://www.amplenote.com/classic_todo_lists_always_fail). In the real world, our product has allowed us to build three businesses that profitability sustain our team of 20. We have zero hype in part because we spend most of our time working. When a relevant comment like this one comes up, I don't see it until 12 hours later. C'est la vie when trying to actually get stuff done.

[1] Haven't had time to actually try out networked notes, but we're planning to add it to Amplenote later this month. Will develop an original opinion on them then.

This project is now up to 75 supporters and $800 monthly sponsor estimate, which should be a good enough starting point to start talking to devs. Thanks a bunch, HN!

If anyone is curious to see what people think about Linux touchpads currently, here are some of the preliminary results with 9000 responses counted thus far:

https://public.amplenote.com/HbcoZf/touchpad-results-prelim

Average satisfaction looks to be around 2 of 5. People are excited about multi-touch, especially the double finger right click.

Ugh: my web host is weak. If the page won't load for you, you can see its native version at https://public.amplenote.com/LiTtaTWY3GfzzhF26Exu8tXx

My company GitClear has invested some years into this very wish. We came up with "commit groups", described here https://www.gitclear.com/review_code_faster

During development phase, our service has been priced at $30 user/month which is too expensive for a diff viewing tool, but we're going to start offering a free version in next couple weeks that will offer access to commit groups.

Here are some other experiments we've been working on to try to reduce cognitive load spent reviewing commits: https://www.gitclear.com/blog/diff_viewer_updates

I believe a lot of what makes reviewing code so time-intensive is that traditional diff viewers aren't recognizing moved or find/replace code, so devs still have to waste a lot of cognitive attention parsing what are effectively no-ops.

Mildly interesting how this story has gotten 130 points in two hours but is still placed beneath numerous other HN front page stories with less points in more time. Not least since the incentives of YC would be to want this story dead. In the 5 mins it took me to login on mobile it dropped from 15 to 25.

While I recognize the prevalence of Goodhart's law among smart thinkers, it fails to meet my "important truth" threshold because it's not hard to find counterexamples:

* In baseball, batting average and OPS are metrics that are richly rewarded. Players who successfully strive to improve their average/OPS will help their team win more, and they'll get richer for it.

* In finance, ROI is rewarded, and investors whose ROI is higher will generally be more successful

* In sales, "conversions" is a useful metric that salespeople strive toward and are validly rewarded for improving

* In software, if a metric like "story points" (as decided by group via planning poker) could be generated consistently for every issue worked on, there's no apparent reason that developers or teams would be worse off if developers used "story points completed" as a goal to strive toward

I suspect the prevalence of folks citing Goodhart's law is because it is usually true. But this may just be a consequence of the frequent disparity between "metrics available" and "desired underlying phenomenon." There's no fundamental reason that they can't be the same.

This is a terrific question, and a topic I've thought about quite a bit while we've built our product (context: as the OP, I've toiled on "how to prove metrics are signal-bearing" for a couple years now).

The problem we always end up at is "what measurable output can we rely upon to tell the story that a project's fortunes are improving"? To date, its been challenging to find a compelling answer. This may be why I'm unaware of any study that addresses the question.

One possible workaround would be to take experts in the field, and try to translate their qualitative interpretation into input that drives a metric. e.g., if Andrew Clark from React could list three directories that harbor disproportionate tech debt in their project, we could calibrate our Open Repo Directory Browser to identify the factors that were unique to that directory. This could then help managers pick out when and where its appropriate to make payments to reduce their tech debt.

Unfortunately, the prominent open source developers aren't answering my emails at this point. And even if they did, it's still a long road to translate qualitative expert opinion into provable long-term benefits. But I think the environment for making that leap is as ripe as ever. We just need to keep working toward figuring out the most desirable+measurable outputs.

I think we're all rooting for the narrative that it's possible to get ahead working 9-5. But it's hard for me to ignore the survivorship bias at play here. Yes, if your company has a market cap in the billions, you probably don't need to be grinding on the weekends anymore. If you've built a company with amazing programmers and predictable revenue (e.g., dhh/Jason Fried) you probably don't need to grind weekends.

But when you're at the front lines, striving to create something new, you'll be competing against very motivated entrepreneurs. These entrepreneurs will often have more resources than you, and zero aversion to working weekends. In those circumstances, Tobi's lifestyle probably isn't going to cut it. When an entrepreneur is working to create that spark, it pays to be completely obsessed, sometimes for years.

Thankfully, very few of us are on the front lines struggling to launch something momentous. Tobi once was, but he was smart and surrounded by great people, and now he's in scaling mode, which seems like a much different beast. I'm grateful that he and other successful tech leaders don't force their teams to work as hard as they needed to in the early days.

As the blog author, you can believe I struggled to distill Open Repos down to a concise soundbite. What makes it hard is that we've built it cover many bases, and we're hoping that customer feedback will lead us in the directions that are most valuable. Here's what it is so far:

* A free product

* A product that collects per-release statistics such that A) maintainers save time summarizing their release B) devs who are evaluating a lib upgrade can hone in on the specific difference between their version (e.g., 1.0.1) and the current version

* A product that makes it possible to browse through all the commits being made to a repo in visual fashion (i.e., to learn code style or stay in the loop on changes) and to discover repos where interesting code is being written

Per Michael Seibel's recent recco on Twitter, this isn't an AI solution and we're not an AI company. Approximating code evolution is hard enough without it.

Thanks for letting us know. We're embedding a note to become the blog page, so presumably reader mode isn't hip to that. Curious if you can get it to work from this page (the note that is source of the blog)? https://public.amplenote.com/28y8CL5tsLYsGPN6HUguMpJF

Edit: Actually I'm pretty sure this alternate page also uses JS, so if JS is turned off, it's probably not going to work either. Not sure off the top of my head how to work around that.

The Evernote detractors camp has grown to epic proportions in the past year, which is warranted, but I strongly disagree with the contingent of detractors who claim that Evernote's downfall was having the audacity to raise their prices, or limit the scope of their free version. So many of the customer rants I read are focused on this aspect, and it misses the point. Good products are entitled to charge a price for their use.

The reason Evernote is dying is because it wasn't a good product. Nobody could fix the long-term tech debt they accumulated, which grew to become regular bugs in the product. And rampant feature bloat.

There are a slew of able replacements to Evernote now available. The landscape of note taking software in 2019 is a very different place than it had been when Evernote started. For them to beat back companies like Notion (and imho Amplenote) would have required heroics on par with what it took to build the company in the first place. Simply getting sync right is itself profoundly challenging for a company with their legacy [1]. It's years of infrastructure decisions, and a consistent dedication to an unpleasant development task. Newer competitors (incl free options like Google Docs/Keep) were ready and waiting to do better.

[1] I've spent the last couple years trying to build an Evernote replacement. Sync for us is very tough, but must be a pit of despair for companies liked Evernote who built their note content out of HTML

I wrote an essay about this topic a couple months ago that you might find applicable https://www.amplenote.com/blog/what_makes_long_term_personal...

The essay describes exactly half of the what has helped me, which is to create processes that make it a little bit easier to procrastinate on long-term goals and then pick them up again later. But the other half, which sounds especially applicable to your situation, is to pick a goal that will continue to be worth pursuing. This is much harder than most people expect.

A few years ago I started a "goal of the month" list with some friends. In January, we picked 12 goals we'd pursue during the year. For the first few months, it was gravy -- everyone completed their goal and had a satisfying summary ("I did this, I learned this") they shared with the group afterwards. But, around the 6th month, the failures began. Between the 9-12th months, our cumulative success rate was lower than 50%. It was mystifying, because everyone had purported to spend hours of time carefully choosing their 12 goals in January.

In my case, I tried to pick easy goals for month 9-12. For November, I picked the goal "bowl a 200" because what could be more fun or easy than going bowling (though I've never bowled above 150, so there was a hill to climb). Still, by the time 11 months passed, there had developed 100 things that were more interesting to me than bowling a 200. I willed myself to go bowling one time that month, and scored 125. ¯\_(ツ)_/¯

We tweaked the rules for the list the following year so you set 12 months worth of goals, but you could substitute a goal if your original choice was no longer interesting. Again, by the 9th month, everybody was substituting like crazy. The goals list experience taught me that my friends and I are woefully bad at choosing goals that will still be interesting to us 6+ months in the future.

Fast forward to today, and I've been working on Linux touchpad drivers for about two years now (e.g., https://bill.harding.blog/2019/03/25/linux-touchpad-like-a-m...). My "success" on this project has been made possible because I have a good system to allow myself to procrastinate, and because every time I use my Linux laptop, I continue to hate how the touchpad works. I am forced to face that unpleasantness over and over again, with no escape. So in this case, there is a goal that has remained important to me because it involves a part of my life that remains constant, and remains frustrating.

Which is to say, if you can find a problem that is going to continue to eat away at you for years, I think you're barking up the right tree. If your goal is one of whimsy or interest, your best bet is to scope your solution so it can be completed in 6 months or less, because chances are your human interest will be somewhere else past that point.

I've always thought the Evernote sync issues got much less attention than they deserved. Both myself and my co-founder were repeatedly burned by Evernote sync when working on notes between mobile and desktop. Sync was the foremost reason we began working on a replacement.

We picked "sync" and "security" as the two core values we wanted to put most focus on when building our note app (https://www.amplenote.com/).

It's curious to me that Notion has so little to say about the effort they put into sync and security -- these seem like such essential features to a great todo app, and I don't think either can be done right unless it is an active, top-tier priority.

Here's where the code updates are slated to happen: https://gitlab.freedesktop.org/wbharding/libinput

For those who would like to follow this project as it unfolds, we intend to work from https://gitlab.freedesktop.org/wbharding/libinput

I'll also setup an easy means subscribe to text updates about this project soon. Check https://bill.harding.blog for updates on that.

Hmm, I should create a way to do that. My tentative plan had been to email the folks who had left comments on the bill.harding.blog post when I had news to report. But then I posted this update this morning without mailing them, so that plan didn't work very well. I think this might just be the kind of thing we have to hope HN will continue to upvote when updates get posted? Or check back at bill.harding.blog in the next few months. Since it looks like there should be enough devs to get started, that implies I'll be posting another update within the next quarter at least.

Wow, this community is so good. Three hours after posting and I've already got a few interested emails from experienced devs looking to lend a hand here. So, it _looks_ like we should have the opp to move forward with something in the weeks to come. Would still be nice to get a couple more emails from knowledge-heavy Linux devs, since that's not a strength of mine. (bill -at- staticobject.com)

I also haven't heard from anyone with connections to OSS projects at Google/MS. I've assumed (perhaps incorrectly) there are departments at smart tech cos that selectively contribute to high impact OSS projects (dev resources or other)? Even if not for contributing resources, would be valuable to get a bit of talk time from those that have successfully executed a project like this before.

Appreciate the actionable ideas re: config file.

As far as the broader configurability questions, it's not so much that I want options libinput doesn't have (though that's a little bit of it).

It's more that I want the default behavior to be good enough where accessing the options aren't necessary (e.g., Macbook). In the event that the default options aren't that good, I want visual settings to tune the experience. Gnome 3 with libinput currently provides two options. Neither is pointer acceleration.

Since much of what I hope to improve the "feel" of default behavior, I don't think this could be as straightforward as "submit a PR to libinput." I think it could end up being a lot of work to get the default experience feeling great. The number of folks with interest in this esoteric subject seems to me like evidence of that.

As I've seen more responses here, I started getting curious about how screen size impacts results with that game, so I ran a few test runs on my desktop. I'm finding that my score varies by around 30-40% depending on the size of the viewing window, with smaller windows being better. So the results I posted, for 15" screens, figure to be lower than what folks would score with a 13" screen (or if using 15" with small viewing window).

Not to say that others won't be better at the game than my control runs, but I think that's going to contribute to some pretty high variance among ad hoc results reported here.

Wow, that's impressive! I wonder if screen size impacts score on that test? Both my test laptops were 15", which probably means more space between the bubbles.

At any rate, I'd be curious to know if libinput is your driver in use? If you don't know, `cat /var/log/Xorg.0.log | grep "input driver"` should indicate the answer

> It comes across as too "I'd like to run this project if you want to help out and here's how we will run it". Instead, I think what you need to do (if you could) is start the technical work yourself and get others to help out.

I so wish that I had the time to start the technical work myself. But I'm currently experiencing the misfortune of trying to run three products at the same time for my day job (as a CEO/developer).

But I care about touchpads (or at least, not relying on Macbook) too much to do nothing. So even though it sucks that I can't just make time to work on setting up the project myself, at least this effort holds the possibility that like-minded folks will join me to make that happen.

That's not a bad idea, though that Peter is already full time employed on behalf of working on this plus other kernel projects. Perhaps seeing the enthusiasm for his project may increase his interest in working on it more. He's been a great help to me in emails thus far.

According to the chat rep at Porkbun (the web host for this site), "it appears the site may have received spam complaints." Which I think is their way of saying they can't handle this much traffic. Actively working all possible angles to get the blog restored with them, but this backup version seems to be holding up so far.