• Shipping is really hard and you have to make it your main priority

• Shipping doesn’t mean deploying code, it means making your leadership team happy

• You need your leadership team to trust you in order to ship

• Most of the essential technical work is in anticipating problems and creating fallback plans

• Scale back your implementation work as you approach launch so you’re free to jump on last-minute problems

• You should constantly ask yourself “can I ship right this second?”

Really intresting comments

This question reminds me of the first time I met a blind programmer. I asked him how he managed to code, and he replied with something that stayed with me: a good programmer should organize software in such a way that every piece of code has a clear and logical place. The organization should be so intuitive that anyone could build a mental model of the structure and navigate it easily, even without seeing it.

Our design goals are safety, performance, and developer experience. In that order.

Contrary to popular belief, simplicity is also not the first attempt but the hardest revision

code, like steel, is less expensive to change while it's hot.

Safety

NASA's Power of Ten — Rules for Developing Safety Critical Code

• Use only very simple, explicit control flow for clarity.

• Put a limit on everything. Fail Fast

• Assertions detect programmer errors. The only correct way to handle corrupt code is to crash.

• Assertions are a safety net, not a substitute for human understanding.

  • Build a precise mental model of the code first.

  • encode your understanding in the form of assertions,

  • write the code and comments to explain and justify the mental model to your reviewer,

  • and use VOPR as the final line of defense, to find bugs in your and reviewer's understanding of code.

• No memory may be dynamically allocated (or freed and reallocated) after initialization.

• Declare variables at the smallest possible scope, and minimize the number of variables in scope.

• Good function shape is often the inverse of an hourglass: a few parameters, a simple return type, and a lot of meaty logic between the braces.

• Centralize control flow. When splitting a large function, try to keep all switch/if statements in the "parent" function, and move non-branchy logic fragments to helper functions.

• Centralize state manipulation. Let the parent function keep all relevant state in local variables, and use helpers to compute what needs to change, rather than applying the change directly.

Developer Experience

• Add units or qualifiers to variable names, and put the units or qualifiers last, sorted by descending significance. latency_ms_max rather than max_latency_ms.

• Callbacks go last in the list of parameters.

• Order matters for readability (even if it doesn't affect semantics). On the first read, a file is read top-down, so put important things near the top. The main function goes first.

• Don't overload names with multiple meanings that are context-dependent.

With a sufficient number of users of an API, it does not matter what you promise in the contract: all observable behaviors of your system will be depended on by somebody.

Testcontainers is an open source library for providing throwaway, lightweight instances of databases, message brokers, web browsers, or just about anything that can run in a Docker container.

The best components are those that provide powerful functionality yet have simple interface.

Do not add layers of abstractions for the sake of an architecture. Add them whenever you need an extension point that is justified for practical reasons.

Сборник различных сценариев автоматизации и справочных материалов

Есть инструкция для почтового сервиса в кластере

• https://www.ultratechnology.com/1xforth.htm

Don't leave openings in which you are going to insert code at some future date when the problem changes because inevitably the problem will change in a way that you didn't anticipate. Whatever the cost it's wasted. Don't anticipate, solve the problem you've got.

The emerging golden age of home-cooked software, barefoot developers, and why the local-first community should help build it

perfect programming language.

Best programming language of all time

WTF Notebook gives me a place to park the impulse to fix it now, damn it! until I have more context for deciding what to work on first. Instead, for two weeks, I just write things down.

In many other languages, you have to not only evaluate testing libraries, but also write your tests in a style that complies with that library’s expectations. Gophers are blessed to have a thoroughly adequate solution out-of-the-box, and even further blessed to have an active ecosystem where folks are making in-depth testing a walk in the park.

Однажды в конце декабря, когда воздух пахнет сгорающими над городом фейерверками, а улицы полны паникующих из-за цен на горошек, я решил научить программированию бомжа...
Фрустрация от когнитивной сложности — это то самое неприятное чувство, которое возникает, когда не можешь разобраться в какой-то запутанной фигне. В результате для любого человека процесс программирования переполнен страданием. Нормальный человек боль не любит и прогать бросает

Innovation tokens and whatnot.