Every time I post a new behavioral experiment, or share a personal resolution of some kind, I get a few emails telling me not to be so strict with myself.

They always say something like “It’s not good to be so hard on yourself!” or “We shouldn’t be forcing ourselves to do things!”

This is a common thing to hear in our improvement-focused culture. I used to think it was a reasonable caution, but now I think it’s generally bad advice.

It seems well-meaning in most cases—people sometimes do go overboard with exercise, frugality, and personal efficiency. But I think it’s much more common for people to go under-board in some or all of those areas, and you can bet the person giving you a hard time is one of them.

We often hear about the importance of “balance” in our self-improvement efforts. But what exactly are we balancing? Good behaviors and bad ones? Are we looking for lives that are equal parts wisdom and recklessness?

Can you imagine someone saying “I don’t think we should force ourselves to brush our teeth every day. You have to live a little!”

Automatic headphone equalization

Иван Кудряшов рассказывает об учении Эпикура, показывая, как оно может помочь современному человеку стать счастливее

• Приложения для сбора хайлайтов из статей и книг не помогают запоминать прочитанное

• Для того, чтобы запоминать прочитанное не нужна хорошая память

• Лучший способ запомнить прочитанное — понять то, что ты прочитал

• Чтобы на самом деле понять прочитанное, нужно приложить усилия

• Объясняй другим идеи, чтобы лучше понимать и запоминать их

• Заведи блог

• Участвуй в сетевых дискуссиях

• Откажись от автоматизации

Your brain does not process information, retrieve knowledge or store memories. In short: your brain is not a computer

A Git client for simultaneous branches on top of your existing workflow.

• Виртуальные ветки !!! (Теперь, если нашёл внезапный баг, не относящийся к текущей задаче, его исправление можно сразу же переместить в новую ветку, не теряя текущие изменения)

• Отмена действий, сквоши, смена коммитов местами перетаскиванием!

A source-control branching model, where developers collaborate on code in a single branch called ‘trunk’ *,
resist any pressure to create other long-lived development branches by employing documented techniques. They
therefore avoid merge hell, do not break the build, and live happily ever after.

Trying to make the case for permanent irrevocable digital identities, which unfortunately today, by de-facto, are email addresses.

A linter for Go that finds nil panics. It found several potential nil panic in Betula and Mycorrhiza codebases that I didn't bother fixing.

• https://github.com/uber-go/nilaway/

Доклад с описанием истории электронной почты и некоторыми техническими подробностями

Рома рассказывает о неочевидных функциях StreetComplete.

Видео о том, как писать понятный код

Коллекция карт

OK, your program works. You've tested everything in sight. It's time to ship it. So you make a release version.

And the world crumbles to dust.

You get memory access failures, dialogs don't come up, controls don't work, results come out incorrectly, or any or all of the above. Plus a few more problems that are specific to your application.

Now what?

That's what this essay is all about.

Клавиатурный тренажёр, благодаря которому я печатаю на Воркмане