9 тяжёлых уроков, которые я усвоил за 18 лет разработки

С оптимизацией вообще веселая штука. Один раз был такой неоптимальный код, что так и просил его оптимизировать. В итоге через пару часов его удалось ускорить в 10 раз. С 0,1 секунды до 0,01. И выполнялся он на форме ручного ввода данных. Один раз.

Я прочитал книгу Seven Languages in Seven Weeks несколько лет назад, и она открыла мне множество вариантов только потому, что показала способы решения задач, доступные в других языках.

Вот только большинство промышленных задач решаются не языками, а экосистемой библиотек в них. По сути, эффективность разработчика зависит в большей степени от количества и качества готовых решений, предложенных в этих экосистемах, нежели от самих языков. А это пласты знаний посерьезнее "7 языков за 7 недель".

Хорошие советы. Особенно про эго, в первый раз вижу, что кто то об этом написал. Приятно, что где то есть такие люди.

У разработчиков раздутое эго. Это факт.

Чтобы обобщать подобные вещи, да ещё представлять их как факт — требуется недюженное эго ;-) Так что выучил ли автор урок номер 1 — тот ещё вопрос.

Языки — это инструмент. Вы знаете только молоток? Тогда все проблемы похожи на гвозди

П.1. Проглотите его и выслушайте то, что другие люди скажут о вашей работе.

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

Это всё приходит с опытом, конечно. Но часто лучше делать маленькие и функциональные, реиспользуемые блоки, из которых можно собрать решение конкретной задачи (пусть и каждый раз заново!), чем большой, абстрактный и универсальный монолит, который вроде и решает 90% задач, но оставшиеся 10% в него настолько плохо вписываются, что начинаются большие проблемы. Либо копировать и менять под задачу этот монолит (нельзя скопировать лишь кусочек, оно слишком абстрактное для этого), либо продолжать раздувать код для покрытия новых редких случаев, которые в 90% использоваться не будут.

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

Если вы собираетесь потратить ещё два дня только на то, чтобы сделать код идеальным, но он может пойти в производство прямо сейчас, то есть шанс, что он должен быть в производстве прямо сейчас.

Ранняя оптимизация является проблемой, потому что в конечном счёте вы тратите много времени и усилий на то, что, возможно, не нуждается в оптимизации.

Вот моё личное правило: если код повторяется в двух местах, он отправляется в функцию (метод, модуль); вы поняли идею.

И, абстрагировав код сразу, вы сразу будете иметь к нему доступ.

4. Вы будете учиться всю свою карьеру