Лучшее описание, что я встретил в интернете:<\/p>\n
Хороший код — это код, понятный младшему инженеру. Отличный код — код, понятный первокурснику computer science. Лучший код — его отсутствие.<\/p>\n
Но, к сожалению, на работе я часто встречаю мнение: Я пишу слишком сложный код, потому, что я опытный и крутой инженер и мои коллеги его не понимают. Что делать?<\/p>\n
Учиться писать простой код, что же еще!<\/p>\n", "date_published": "2021-06-10T17:30:59+03:00", "date_modified": "2021-08-08T03:28:32+03:00", "_date_published_rfc2822": "Thu, 10 Jun 2021 17:30:59 +0300", "_rss_guid_is_permalink": "false", "_rss_guid": "98", "_e2_data": { "is_favourite": false, "links_required": [], "og_images": [] } }, { "id": "49", "url": "http:\/\/blog.sergeykopylov.ru\/all\/kak-schitat-horosho-li-rabotaet-razrabotchik\/", "title": "Как считать, хорошо ли работает разработчик?", "content_html": "
В первый год своей работы разработчиком в компании я сильно переживал, что не могу состредоточиться и программировать целый день, 8 часов. Я от силы мог программировать часов 6, и кое-как писать что-то в оставшиеся часы. На следующий день я приходил и переделывал тот ужас, что написал вчера вечером. Я вечно отвлекался, открывал Хабр, ВК, что-то ещё и боялся, что разработчик из меня так себе.<\/p>\n
Но потом я понял, что в этом сила, а не слабость. Когда меня просили сделать что-то новое, что ни я, ни кто-то другой в компании не делал, я уже знал, куда смотреть, я уже читал статью на эту или смежную тему. Или после нескольких дней мучительного подхода к задаче, я прозревал, что проблема в том, что мне нужно сделать много рутинной работы и её можно автоматизировать, и сделать гораздо быстрее. Как и все последующие похожие задачи. Оказалось, что работа разработчика — это творческая работа, а не просто написание кода.<\/p>\n
В итоге я пришёл к чему-то такому: первые пару часов я читаю Хабр и узнаю что-то новое, часто пробую это прямо сейчас. Потом приступаю к задачам, анализирую их и выбираю те, которые могу и хочу сделать прямо сейчас, а в последние пару часов читаю переписку, отвечаю коллегам и общаюсь с ними вживую по их и моим проблемам и вопросам. И лишь в пятницу, раз в неделю, рассказываю, что получилось, что не получилось и куда я намереваюсь двигаться дальше. Таким образом, за несколько лет не возникло ни одного вопроса о моей результативности, а релизы выходили регулярно и с хорошим качеством, и мы не проседали, когда архитектура ещё не была готова к новой сложной задаче.<\/p>\n
Однако, если смотреть со стороны, кажется, что я почти не работал. Я много сидел и думал перед компьютером, перебирал библиотеки, которые можно использовать вместо того, чтобы написать свою реализацию, читал статьи и письма. Если бы контроль был ежедневным, то не был бы доволен никто — ни начальник, ни я.<\/p>\n
Более того, часто в начале недели было больше желания узнать новое и подумать над решением, а программировать ближе к концу. В таком ключе результат первых трёх дней был бы нулевым: ведь я ещё не написал ничего толкового!<\/p>\n
Так что рецепт простой:<\/p>\n