from bouncepaw:

Alex tells us that, for him, baking and cooking are easier than programming and soldering, because the errors there average out. As for me, this is completely inverse.

In programming, an error never fixes itself. You can observe it and fix it, you can write tests. You can run the program multiple times. It's you who fixes it, and you can understand how it's done. It's measurable!

Meanwhile, cooking is a nightmare. Burning something is routine for me. Is that too much or too little oil? For how long do I fry? What do I do with these spices? Do they really affect the taste? And to observe something, I can't rely on symbolic things like text. No, I have to look (is this color good? No idea!), smell (as if I know the difference) and taste (nothing more inaccurate).

I'm happy when something can be cooked with a timer. 15 min for buckwheat? I'm in. I'm more happy when the time is short. 4 min for this thin kind of spaghetti? Already boiling water!

I mean, even boiling water is not simple. My parents told me to wait until the correct bubbles appear. I'm waiting for the scary ones. Also, salt is supposed to make it boil faster. How much salt do I add?

And I didn't even talk about plants, which Alex also considers easy. They're not 😭

Totally agree!

Беру любой JSON и вижу, как его можно упростить, убрав лишнюю вложенность. Вдвойне обидно, что на эту вложенность кто-то тратил время, а она не нужна!

Первая — программист закладывает абстракции там, где не следует.

Бритва Оккама ?

Вторая проблема — наоборот: программист не оставляет шанса поправить его код.

Бывает, проблему можно поправить функцией или макросом, но в код тянут библиотеку. Или можно купить готовое решение, но тимлид говорит: мы напишем свое через три месяца. Или разработчик насмотрелся видосов со свежей конфы и хочет проверить чужие идеи.

если в процессе обсуждения архитектуры вы пришли у выводу, что в проекте потребуется настоящее горизонтальное масштабирование — вам не обойтись без конечных автоматов (так-то лучше вообще любую бизнес-логику строить именно на конечных автоматах, но в автономной системе можно подкостылить и без них, а вот в кластере — уже никак)

Так или иначе, если вы хотите оказаться готовым отмасштабироваться в горизонталь — стройте критические процессы на конечных автоматах и полностью асинхронно

Зато асинхронные взаимодействия поверх FSM — сделают в дальнейшем масштабирование безболезненным, ведь в такой парадигме не имеет никакого значения, на какой ноде выполнится код, отвечающий на запрос.

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/

Functions that are part of your project’s source code but can never be
reached in any execution are called “dead code”, and they exert a drag
on codebase maintenance efforts.
Today we’re pleased to share a tool named deadcode to help you identify them.

This belief is, for me, not some abstruse theoretical assertion, but a deeply felt belief that essentially any question I might care to ask (about computers) has a comprehensible answer which is accessible with determined exploration and learning.

Free Encyclopedia of Programming Languages.

Генерирует фотку экрана с кодом, который вставит пользователь

Никита рассказывает про текст и кодировки

The Go standard library is full of bad design choices from the perspective of safety of use.

The core idea is to canonicalize things. Both x < y and y > x mean the same, and, if you usethem with roughly equal frequency, you need to spend extra mental capacity to fold the two versionsinto the single “x tiny, y HUGE” concept in your head.

PRQL is a modern language for transforming data

Интересная замена SQL. Запросы для аналитики данных станет писать намного проще. Не думаю, что для чего-то другого этот проект подойдёт. Условный CRUD проще написать, используя именно SQL запросы, здесь PRQL излишен.

Выделите джуниору части проекта, где он будет главным, через него будут решаться все вопросы связанные с ними. При срочной необходимости, можно всё сделать самому, но в штатном режиме хозяин кода - он.

Everything you need to know about monorepos, and the tools to build them.

Решение для серверсайд рендеринга

Заметки о том, как писать и оформлять код на Си

If you want a single piece of advice to reduce your bug count, it’s this:
Re-read your code frequently. After writing a few lines of code (3 to 6 lines, a short block within a function), re-read them. That habit will save you more time than any other simple change you can make.

Языки программирования как люди

Для всех, кто знал SQL, но подзабыл

Я ещё так никогда не удивлялся регулярному выражению

Рич Хикки рассказывает о различиях простоты и лёгкости в контексте проектирования и написания программ.

Говорит, что многие выбирают лёгкость, забывая про простоту. Со временем комплексность превращается во что-то такое, что сложно поддерживать и в чём сложно разобраться новичкам.

Нужно стремиться искать лёгкие способы делать простые программы.

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