dier

short answer: yes

it's recognition from the individual's perspective. think love languages. one person's recognition might be salary because they make $35,000/yr and another's isn't financial. they are doing this because retirement is boring.

in practice it is often a combination with different ratios.

as an employee it is advantageous to think about what makes you feel recognized and work with your manager on it. if it's monetary and they're stingy then your values won't align and you will be frustrated.

> Dropbox is also harvesting your data for various purposes. I hope your code isn't valuable, because it could be leaked or stolen by employees of Dropbox.

I always thought the encrypted repositories was a neat feature but never really understood what a use case for it would be. I guess this might be one. https://www.fossil-scm.org/home/doc/trunk/www/encryptedrepos...

> although I suppose it should let you know whether you could hope to change anything by changing human activity

This is the discussion. As I understand "climate change deniers" aren't denying things like the increase global temperatures or the rising of sea level. The science is clear that these are happening. They are denying that human behavior changed or changes anything. I agree it should be a moot point whether humans caused it or not as there are other reasons to make changes but being inconvenienced is hard and spending money isn't profitable. It's a lot easier to bike shed.

I've found worktrees[1] are a great tool for this use case.

"oh. i should fix this, but it doesn't have anything to do with what i'm currently solving." cd ../worktree-checkout, make a branch, do the fix, push, open a pr. then cd ../original-checkout and continue on. rebasing the fix into my wip when the PR is merged (or cherry-pick if you're confident) as needed.

1. https://git-scm.com/docs/git-worktree

I think the preference to squash and rebase instead of merge is because of Github, honestly. It flattens the history out when the history is not flat at all.

If Github's UI showed branches diverging, commits being made to that branch, then the merge back to trunk like gitk does then devs could visually see why it's valuable.

If you find commit messages useless, it's because you're making them useless.

It seems like the workflow where you get 20 "stuff" commits in a PR is to: git commit -am "stuff", test it, see that it doesn't work, make another change, hit up then enter on the shell window, test it, and so on.

If this is how you prefer to develop then I think testing first and squashing along the way might be better:

- initial change, test, worked? git add <files>, git commit -m "meaningful summary\n\n- meaningful note"

- small change: test, didn't work, git reset --hard

- another attempt: test, worked, git add, git add <files>, git commit --amend (new meaningful note)

If the steps you're taking to get to the end are meaningful or significant (maybe for a bisect in the future) then just commit with a meaningful message along the way.

More generally, I think it's more common create commit messages for "me", the writer, and not for the reader. Try instead writing commit messages (comments, documentation..) for an audience who doesn't have the context you have. For example: Nathan in 7 (or 2) years time who is tracking down the reason for a change you made which he suspects is the cause of a bug he's trying to fix.

Conflict: https://news.ycombinator.com/item?id=29170375

people who don't want to watch the video:

it's a pomodoro timer, but your "win" (with confetti) if you do the task in less time.

Like the other comments, the risk of losing data/access/etc is not enough.

The article even actively suggesting you DO NOT make backups of things.

    Now you’re ready to generate a new set of OpenPGP keys on the YubiKey, using the generate command:

        gpg/card> generate
        Make off-card backup of encryption key? (Y/n)

    Enter n to ensure that the private keys never leave the YubiKey, and enter the admin PIN when prompted:

I suppose this is why it's an Opinionated guide as my opinions on how the actual target of a "remote adversary" should go about balancing security with risk.

> This effectively makes paying consumer debts basically optional in the United States, contingent on one being sufficiently organized and informed. That is likely a surprising result to many people. Is the financial industry unaware of this? Oh no. Issuing consumer debt is an enormously profitable business. The vast majority of consumers, including those with the socioeconomic wherewithal to walk away from their debts, feel themselves morally bound and pay as agreed.

try it out, let us know how it goes.

That's the joke.

https://en.wikipedia.org/wiki/False_memory#Mandela_effect

It is picking the adventure over playing it safe. "You only live once so you just as well pick the once in a lifetime, most exciting, or whatever experience." What an author finds exciting and YOLOs may be above your risk tolerance.

For this article it's "Life is short so I'm going to favor doing the things I enjoy (releasing something at "it works!", add a feature because it sounds fun, wear socks that don't match) and not the things I don't enjoy (documentation, tests, collaborating/compromising with others...)"

This post is more than a month old. Twitter announced pricing tiers yesterday (March 29). From the first link on the blog post:

> Today we are launching new Twitter API access tiers! We’re excited to share more details about our new plans and what you should expect in terms of next steps and timeline.

> Free: For write-only use cases and testing the Twitter API (1,500 Tweets per month)

> $100: For hobbyists or students learning code (50,000 Tweets per month - posting limit at the app level)

> Current access plans including Standard (v1.1), Essential (v2), Elevated (v2), and Premium will be deprecated over the next 30 days, so we recommend that you migrate to the new tiers as soon as possible for a smooth transition. Any non-migrated developer accounts will be impacted by April 29th, 2023 at the latest.

It's not unmaintained. They were just putting it behind a pay wall.

I had assumed your comment as the standard hn opinion of "RSS is the greatest thing since sliced bread" but you literally mean "TLDR: use RSS".

Traditional goal setting doesn't take into account trade-offs. You should be aware and discuss those while goal setting.

From the example:

Company Goal: Make more money

Sales: We'll help make more money by focusing on closing deals in our pipeline

Product: We'll help make more money by focus on new and exciting product offering in an untapped market

On the surface these both line up to the goal of "make more money" but there were unspoken trade-offs which undermined execution:

- Product didn't focus on current offering causing sales to flounder

- Sales wasn't focused on pre-sales of new product so new product isn't helping the bottom line either.

With regard to rebase and fossil vs git when you have a small team of trusted developers rebase is harmful because you lose information that could help you understand the _why_ of something. In contrast if you are working with thousands of untrusted developers you need a way to increase the signal-to-noise at the cost of some granularity.

This comes about from their development styles (see: http://www.catb.org/~esr/writings/cathedral-bazaar/).

- Use fossil if you prefer the cathedral style of development SQLite is open source but does not accept contributions.

- Use Git if you prefer the bazaar style of development. You want to accept hit-and-run style contributions from anyone.

the devs seem to blame go-imap (https://github.com/emersion/go-imap). at a quick glance the library itself doesn't seem to have an open issue describing the problem.

curious if that author's (deprecated) protonmail bridge hydroxide (https://github.com/emersion/hydroxide) has the same problem.

i disagree. more of my data has been compromised due to attacks/leaks/etc on the host than has been compromised due to someone having access to my machine.