Comments 62
Отличная статья, с элементами философии и психологии. С автором согласен полностью, нужен опыт что бы понять такие "невидимые" вещи, и этому нас не учат, а добываем такие знания опытным путем.
12. Самый быстрый способ освоить что-либо — это начать учить других
До сих пор восхищаюсь своей женой. Она после двух месяцев изучения немецкого языка с нуля взяла, как репетитор, ученика-школьника тоже с нуля. Я недоумевал, но и ученик и его родители были очень довольны. Т.е., она готовилась к очередному уроку, изучая для него новый материал и передавала его ученику (пока не забыла, наверное). Для этого надо иметь педагогический талант.
Точно так и есть - начинаешь кого-то обучать, а у него ещё 100500 вопросов по теме, а ты "ни ухом не рылом" и начинаешь юлить - "так это мы чуть позже разберём", "здесь не будем углубляться", а сам яростно чешешь репу где, же инфу искать???))
Правило учителя - нужно быть лишь на шаг впереди ученика
Цитата из «Робинзон Крузо», Даниеля Дефо:
"я должен признать, — думаю, что к тому же выводу придут все, поступающие по тому же принципу, — что, истолковывая ему различные вещи, я сам обучался многим вещам, которые я не знал или которых я раньше понастоящему не обдумывал, во которые естественно приходили мне на ум, когда я углублялся в них, чтобы растолковать их бедному дикарю. "
Браво! Я иногда фантазирую, как бы я пошёл преподавать, и в итоге содрагаюсь от ужаса, как бы я готовился к каждой лекции или уроку.
Разговор 2-х преподавателей:
- Ну и группа мне в этом году попалась тупая!
- А что так?
- Представляешь себе, объясняю теорему - не понимают! Объясняю второй раз - не понимают!! В третий раз объясняю. Сам уже понял. А они не понимают...
Режет слух 4 пункт. Как это у вас читаемость и ястность противопоставлена продуманности? Какая-то странная продуманность у вас
В оригинальной статье - "clever code", ближе к "заумный" чем к "продуманный" в этом контексте.
хитроумный
Я тоже сперва склонялся именно к "заумный", но всё же автор в этом пункте говорит о том, что большинство программистов стремятся писать clever код, и что это должно отражать их компетентность. Заумный код вряд ли будет отражать компетентность, так что в итоге я решил, что всё же имеется ввиду просто очень продуманный и грамотный код. Тут просто нет слова, которое бы точно отражало смысл - что-то между "заумный" и просто грамотный.
The instinct to write clever code is almost universal among engineers. It feels like proof of competence.
Я тоже сперва склонялся именно к "заумный", но всё же автор в этом пункте говорит о том, что большинство программистов стремятся писать clever код, и что это должно отражать их компетентность.
Так в оригинале же написано не "It is proof of competence", а "It feels like proof of competence", то есть, насколько я понимаю, не "является подтверждением компетентности", а "выглядит как подтверждение компетентности". Так вот, по моему скромному мнению, заумный код именно что выглядит как подтверждение компетентности, так что, считаю, перевод "clever" как "заумный" тут вполне уместен.
Не looks like, а feels like. To есть речь о субъективном ощущении человека. То есть люди считают, что продуманный код должен подтверждать их компетентность. Это логичное продолжение предыдущего предложения, подтверждающее стремление человека писать хороший код. Или вы действительно считаете, что большинство программистов прям вот стремятся писать именно заумный код, а не хорошо продуманный?
Меня только это остановило от использования термина "заумный", так как люди по своей природе чаще стремятся к простоте и реже к заумности. А в случае кода, скорее, к его реально продуманной структуре, а не заумной.
Хотя взглянуть на это можно и под другим углом.
Меня только это остановило от использования термина "заумный", так как люди по своей природе чаще стремятся к простоте и реже к заумности.
Не в IT )))
Тоже думаю, что "заумный" больше подходит в этом контексте. Как предлагали выше, "хитроумный" или даже "хитросделанный" скорее нет, так как было бы "tricky".
"Продуманный " я бы точно не охарактеризовал как "feels like", потому что он обычно такой продуманный в том числе потому, что прост в понимании, а это чаще всего все-таки "it is".
P.S. и да, я не носитель, но скорее всего было бы "well thought" или "well tailored code".
Меня только это остановило от использования термина "заумный", так как люди по своей природе чаще стремятся к простоте и реже к заумности.
Вот зря Вы так думаете. Люди, в целом, стремятся меньше думать, а не чтобы было просто, и потому при решении задач, как правило, используют только хорошо знакомые им методы, зачастую невзирая на то, что эти методы, в общем случае, могут плохо подходить для решения поставленной перед ними конкретной задачи. Особенно отчётливо это проявляется в условиях недостатка времени. Также необходимо отметить, что субъективные критерии простоты у каждого разные.
Кому-то просто — это многокилобайтный жуткий солитёр из if ($_ ~= /regexp1/) { … } ($_ ~= /regexp2/) elsif { … } … else { … }, в котором можно запросто запутаться и не найти концов, а кому-то просто — это массив хэшей, в которой ключом каждого хэша является регэксп, а значением — ссылка на анонимную функцию, соответствующую тем самым { … }, и цикл по ключам из хэшей этого массива, который находит первый успешно отработавший регэксп и дёргает анонимную функцию, на которую тот указывает.
А в случае кода, скорее, к его реально продуманной структуре, а не заумной.
"Хорошая мысля приходит опосля" (с). Сначала, как правило, быстро выкатывается какой-нибудь страшный, но работающий уродец, чуть менее, чем полностью состоящий из полностью заумного кода, а вот уже потом, если будет время подумать, из него пытаются сделать красивого белого лебедя.
Может "перемудрённый"?
Отличная статья. По сути в очередной раз мы убеждаемся в том, что надо не костенеть, а оставаться человеком ...
Чаще всего прирост производительности возникает благодаря исключению лишней работы,
а не добавлению новой
о !
а меня за такой подход пытались унизить в треде
https://habr.com/ru/articles/983266/comments/#comment_29347972
теперь буду ссылаться на опыт опытного гугловода.
Поддерживаю вас, а то сначала напишут на реакте, а потом говорят "давайте на расте перепишем, будет быстрее"
Быстрее то может и будет, но надо не такты процессора оптимизировать а архитектуру и "работу", количество вычислений
напишут на реакте
на расте перепишем
хотел бы я на это посмотреть))
Быстрее то может и будет, но надо не такты процессора оптимизировать а архитектуру и "работу", количество вычислений
Мне казалось, что для программиста это уже базовое правило по-умолчанию, которое даже произносить не надо. Ну то есть это где-то на уровне "надо проверять написанное".
Собственно, сейчас же в школах/вузах рассказывают про алгоритмы, а на собеседованиях спрашивают про всякие там сортировки и хеш таблицы. Логично, что люди с этими знаниями, дальше их применяют в работе.
И получается фокус совсем не на том, к сожалению
Смысл от того что твоя функция стала выполняться быстрее если она вызывается произвольное N( допустим пару тысяч раз на больших проектах )
А должна вызываться 1 раз О(1)
Т.е алгоритм в коде видят, а в архитектуре нет
Но разве это не базовое требование почти на все вакансии? Собственно, если необходимо отсортировать автомобили по скорости и вывести 10 самых быстрых, то это необходимо делать в условной базе с индексом (или в горячем сервисе, который вернет, как и база, первые 10 элементов в массива/дерева/списка, а не будет запрашивать всё, потом сортировать и так далее)?
Собственно, все собеседования в стиле system design требуют таких предположений. Ну а Live Coding неявно подразумевает, что навык может быть применен и вне собеседования..
Вас продвигает не код, а люди
Полностью поддерживаю. Устраиваться в крупную организацию, чтобы просто писать код нет смысла. Зато там можно найти массу талантливых и полезных друг другу людей.
Редкая статья, у которой готов подписаться под каждым пунктом. При всём моём занудстве. И даже отсортировано почти в том порядке, который у меня в голове. От самого важного к тому, что попроще, но не менее очевидно.
ну кое к чему все-таки можно придраться
например к:
Будьте решительны, не тяните с релизом — можно исправить неудачную страницу, но нельзя исправить пустую
С одной стороны - да, а с другой - "не бывает второго шанса произвести первое впечатление"
Если ваш полусырой прототип, который вы решительно решили поскорее презентовать потенциальным инвесторам/покупателям, упадет пару раз прямо во время презентации, то это может крайне негативно повлиять на ваши будущие доходы.
Если ваш сервис ложиться из-за "хабраэфекта" после публикации рекламной статьи, то это может сильно повлиять на доверие пользователей к вашему сервису в будущем.
И так далее.
Решительность - это хорошо, но про разумный баланс с осторожностью забывать тоже не стоит.
Gabe Newell says: "Late is just for a little while. Suck is forever"
Как обычно в жизни, выкручивать вещи на свой лад можно сколь угодно :)
Если ваш сервис ложиться из-за "хабраэфекта" после публикации рекламной статьи, то это может сильно повлиять на доверие пользователей к вашему сервису в будущем
FOMO сильнее чем осторожность.
Если пастухи правильно пасут стадо, то оно не замечает огрехов или прощает.
Иначе говоря, ширнармассы клюют на вау эффект, даже если не могут сразу эффективно использовать
Ажиотаж от упущенной возможности перебивает рациональную оценку надёжности. Большинство пользователей не делают выводов из технических инцидентов, если маркетинг достаточно агрессивный.
Я могущество маркетинга объяснил бы так: он льется постоянно, а технические инциденты раз случились и забываются. Даже когда система тебя бесит (как пользователей Windows сейчас)... а куда ты денешься?
Главное не допускать поголовно негативных сентиментов в сообществе, так как это уже стадия потери репутации. Из простых примеров: качество драйверов AMD. Поскольку даже легкая раздробленность, например медленная выкатка обновлений/фич Windows, заставляет людей сомневаться и между собой до покраснения ругаться. Итог: из FUD имеем uncertainty и doubt, что "может это только у меня такое негативное отношение, а у остальных все хорошо".
Я именно так и делаю.
Например, у тебя сотни дарксторов, с которых курьеры развозят заказы. Запускаешь что-то новое сперва на одном на минуты, потом на часы, дни, недели. Как только часы работает - идёшь на следующий не похожий на первый.
В процессе выгребаешь кучу бизнес улучшений и устраняешь баги, только половину половину из которых закрыл бы тестами. И баги не только технические. Самые больные - бизнес баги. Например, часть опытных курьеров уходит домой на время теста, т.к. их заработок после изменений проседает, хотя средний по всем остаётся прежним. А у вас новый год на носу и вас просто завалило заказами. Не запустив такое не выгребешь.
Это ещё далеко не MVP. Прототип, который компактен и разрабатывается практически интерактивно.Новая фича или устранение бага от 5 мин. до часов. Если фича бизнесу не залетела - просто выбрасываешь. И так 5-10 экспериментов каждый день. Альтернатива - погруммить с продактами, оценить трудоёмкость, разработать модель, как новая фича повлияет на основные бизнес метрики и прогнать её на ретро данных, приоретизировать, запланировать реализацию, разработать (+ 5 микросервисов к текущему огороду), протестировать, разработать дизайн AB, дождаться сбора данных по результатам теста, обсудить на ретро как мы 2 месяца делали ненужную никому фичу и как этого избежать в дальнейшем.
Второй путь - обычный для корпораций. Как вам 42 участника и регулярные встречи пол года по продукту, который сделали за 4 дня 2 человека по первой схеме? Без аналитиков, продактов, тестировщиков. В режиме пет проекта, в свободное от основных задач время. Вот на самом деле сделали на этой неделе. Ещё чуть подкрутим и запустимся на следующей.
8 дет в гугле проработал - есть и другие уроки: как присвоить продуктовые достижения других, как изображать бурную деятельность в отчетах и мало чего делать, как чужими руками удавить конкурента.
С удовольствием бы прочел такую статью. Уважаю когда рассказывают об обратной стороне медали
Любой фаанг это, в основном, про "кукушка хвалит петуха, за то что хвалит он кукушку" на перф ревью.
Адекватный народ бежит оттуда из-за этого цирка, несмотря на стоки и прочее.
У меня достаточно много друзей и коллег экс-гуглеров чтобы выработать иммунитет на фаанги...
так у него треть пунктов, как подлизнуть, чтобы тебя заметили - просто не так явно выражается)
Какой-то индустиский поток сознания. Чопачомхоккейсмячом.
Статья должна называться: Дядя Addy Osmani научит жить.
Как-то слишком часто упоминается решение сбоев в 3 часа утра. Это гугл вообще, или как? Кубер они для кого писали)
Когда старший разработчик говорит «я не знаю», он не показывает слабость, а разряжает обстановку
Ауф
Пропущено: делайте так, чтобы у конечного пользователя почти не было возможности добраться до конечной(настоящей) техподдержки и программистов.
Будьте решительны, не тяните с релизом — можно исправить неудачную страницу, но нельзя исправить пустую
К чему привел такой "прекрасный" подход, отлично описано в другой статье на Хабре еще от 2018 - "Почему новый дизайн Gmail такой медленный".
С его слов, все это происходит в силу того, что в Google не предусмотрено никаких наказаний за подобные «промахи».
В стенах компании активно поощряют запуски (launch) — публичные релизы чего-либо. И то, что продукты могут содержать лишь половину необходимых фич, не работать, работать только из-под Chrome и прочее — это никого не волнует, ведь их создателям за это ничего не грозит. Это — норма.
Смысл подобный действий заключается только в одном — в продвижении по службе, поскольку без крупных запусков дальше определенного уровня пройти не удастся. Вот мы и получаем в итоге сотни ненужных приложений-чатов, бесконечные редизайны и перезапуски — иначе отдельные личности не смогут получить повышение.
На самом деле, данная статья подходит под многие сферы деятельности
7. Лучший код — это тот, который не пришлось писать
18. Чаще всего прирост производительности возникает, благодаря исключению лишней работы, а не добавлению новой
"Лозунг у них был такой: «Познание бесконечности требует бесконечного времени». С этим я не спорил, но они делали из этого неожиданный вывод: «А потому работай не работай — всё едино». И в интересах неувеличения энтропии Вселенной они не работали. По крайней мере, большинство из них. «Ан масс», как сказал бы Выбегалло. По сути, задача их сводилась к анализу кривой относительного познания в области её асимптотического приближения к абсолютной истине. Поэтому одни сотрудники всё время занимались делением нуля на нуль на настольных «мерседесах», а другие отпрашивались в командировки на бесконечность. Из командировок они возвращались бодрые, отъевшиеся и сразу брали отпуск по состоянию здоровья. В промежутках между командировками они ходили из отдела в отдел, присаживались с дымящимися сигаретками на рабочие столы и рассказывали анекдоты о раскрытии неопределённостей методом Лопиталя. Их легко узнавали по пустому взору и по исцарапанным от непрерывного бритья ушам. За полгода моего пребывания в институте они дали «Алдану» всего одну задачу, которая сводилась всё к тому же делению нуля на нуль и не содержала никакой абсолютной истины. Может быть, кто-нибудь из них и занимался настоящим делом, но я об этом ничего не знал."
Мне понравился пункт
15. Когда метрика становится целью, она перестаёт быть метрикой
Такое просто и элегантное решение, но почему-то формулировка в явном виде от меня постоянно ускользала.
Действительно, можно же основные целевые показатели дополнить парными, которые будут друг друга компенсировать... вместо того, чтобы высчитывать сложные коэффициенты, почти никак не связанные между собой.
Действительно, можно же основные целевые показатели дополнить парными, которые будут друг друга компенсировать...
см BSC, она же ССП. Именно "задуманный оригинал", а не надерганные куски типа "отдельного KPI" (честно говоря, я в оригинале не читал, а первый прочитанный русский перевод Каплана канул в лету вместе с диском, даже автора перевода не помню.)
Рассматривайте свои технические выборы как организацию, имеющую небольшой бюджет «токенов инноваций»
Это что, объяснение для тех, кто привык пользовался токенами LLM? Кажется, я фатально устарел и скоро перестану понимать такие аналогии :)
в 2 часа утра, в 3 часа утра
Может быть всё-таки ночи, а не утра? :)
15. Когда метрика становится целью, она перестаёт быть метрикой
Этот пункт просто великолепный! Я давно думал, что можно сделать с метриками, чтобы они потом не давили меня метриками. А тут красивый вариант - две ортогональные метрики, и сразу визуально виден баланс, золотая середина. Видно, что если хотите сильно одно, потеряете в другом. А если хотите и то, и другое, то надо от каждой метрики отступить, и дать подышать разработчикам
Они раньше узнавали о возникающих возможностях, быстрее наводили мосты, получали рекомендации на злачные места и основывали предприятия с людьми, с которыми выстроили доверительные отношения.
Нет, "злачное место" здесь не годится. И в оригинале нет такого даже близко.
gramota.ru
Злачное место (шутл.-ирон. и устар.) – место, где пьют, играют, предаются разврату. Слово злачный – производное от злак – в старославянском языке имело значение 'богатый растительностью, изобилующий злаками; сытный'. Злачное место – выражение из заупокойной молитвы («...в месте злачне, в месте покойне...»); первоначально злачное место 'место упокоения праведников'. Переносное значение этого выражения – «веселое место» или «сытное место» (таким местом в старой России мог быть кабак). Со временем это выражение приобрело отрицательную окраску – место, где предаются кутежам, разврату.
Спасибо за ликбез. У меня этот термин всегда в первую очередь ассоциировался с удачным местом, богатым на возможности и ресурсы, если как-то коротко описывать. В таком смысле я его всегда и использую. Честно, с трудом припоминаю употребление в контексте какого-то разврата, кабаков и т.д. Ладно, раз уж такое оно не однозначное, заменю на перспективные.
21 урок, который я усвоил за 14 лет работы в Google