Архив недели @terbiyarchitect
Понедельник
Всем привет! На этой неделе с вами Герман Тебиев @terbiyarchitect. Я работаю лидом front-end команды в @devexperts. Мой основной язык разработки — JavaScript & Co, а ещё я около полутора лет программирую на Clojure.
За рекомендацию меня сюда большое спасибо @GlafiraZhur!
Не буду тянуть и скажу, что неделя не будет особенно технической, простите деды! Позднее на неделе я дам более расширенное описание причин этого. Если говорить вкратце, то мне видится, что существующие проблемы разработки ПО лежат вне технической плоскости.
Я считаю, что мне очень повезло оказаться выступающим в конце года. В это время люди обыкновенно задумываются о планах на новый год, о том, как много они не сделал. Если цитировать кота Тома с мема, то: «Ребята, я в этом шарю».
При этом я не планирую вываливать на вас кучу списков и давать хоть какое-либо существенное количество советов. Мне больше хочется показать свой работающий механизм и посмотреть на ваши. Обычно люди не особенно охотно таким делятся.
Ориентировочный план на неделю (1/2):
ПН: Мой путь в разработке ПО.
ВТ: Личная продуктивность.
СР: Структура рабочего дня разработчика.
ЧТ: Прохладные отношения с асинхронностью. Команда и взаимодействие внутри её.
ПТ: Причины прекращения кодирования.
СБ: Задача на сложность расчерчивания листа.
ВС: Немного о неизвестной музыке и разная болтовня.
Тред (Герман Тебиев)
Ух, ща наверну тред!
Мой путь в разработке ПО.
Здесь мне хочется больше рассказать о становлении мышления, чем о конкретных происшествиях. Я люблю размышлять о всяком, так что будут отсылки к популярной культуре, не пугайтесь!
Два года назад у меня страшно бомбило из-за фильма. Вообще, это со мной бывает крайне редко. Один из моих прошлых начальников, который в течение определённого периода просил меня вести поминутный дневник рабочего дня, а потом отчитываться ему, хвалил меня за устойчивую психику.
Бомбило из-за простой, казалось бы, вещи. Крайне неудачной 9-й части фильма «Звёздные войны». Почему же она была неудачная? Да, повествование скомканное, но это же развлекательный фильм о победе добра над злом, чего это я взъелся?!
Взъелся я оттого, что двумя годами ранее 8-й фильм был для меня откровением. Откровением не в том смысле, что происходило что-то именно с точки зрения вселенной Лукаса, а в другом. В том, как точно показано то, с чем я сталкивался по жизни. Немного углубимся в аналогии.
Начинается новая трилогия с того, что молодые люди рождаются и растут на руинах некогда могущественной империи среди ржавеющих атрибутов прошлого. Продолжается тем, что они пытаются примерить на себя уже испробованные успешными предшественниками ролевые модели.
Результат, впрочем, оказывается маловоодушевляющим. Выясняется, что молодёжь опоздала к богатырям лет на двадцать. Последние выдохлись, разочаровались в былых идеалах и перешли в режим необременённого существования. Те, кто всё ещё что-то делает, истощены.
Я дважды бакалавр. Впервые образовываться я пришёл в 16 лет на «Менеджмент». После первого курса чувство собственной бесполезности стало обжигать, и я стал интересоваться разработкой. Второе образование техническое. Впечатления описаны в предыдущем твите.
В самом конце восьмого фильма Рей утаскивает книги, чтобы по ним начать учиться древним искусствам. Да, это моя тема. Я тот ещё книжный червь. Если не найден никто из живых, кто мог бы помочь, то мы воспользуемся замечанием почившего Мортимера Адлера:
Снова к фильмам. После 8-й части пройдёт лишь пара лет, и я получу впечатляющий ответ на вопрос, что же дальше?! Вышло однако следующее: «Герман, а хер его знает, мы откопали свадебного генерала, сейчас-то он всю молодёжь и отмудохает». В целом, ответ оказался недалёк от истины.
На первой своей работе разработчиком мне казалось, что устроено там дело как-то несерьёзно. Нам выдали jQuery, небольшой фреймворк, перерабатываемый Ruby в шаблоны покрупнее и сказали: «Ну, делайте». И мы начали. Но подождите, а как делать правильно-то?!
Ответов я не получил. Но сумел обучить нашим нехитрым делам целый новый офис удалённых разработчиков. Хорошие трое ребят из Ульяновска. Ещё успел отметиться голосом на автоответчике. Жажду знаний это не заглушало, и тогда я начал поиски классической литературы по разработке ПО.
Сама идея классической литературы стала зыбче для меня с тех времён. На лобовой вопрос интернет мне ответил какой-то невнятной солянкой на Stack Overflow. Кажется, что сама идея существования такого набора книг идёт ещё со школы, а та взяла её в нашем социалистическом прошлом.
Тогда я взялся за «Совершенный код». Хороших отзывов об этой книге я не слышал в последнее время, её называют нудной и очевидной. Видите, как наш мир впитал её? В начале книги есть рассуждение о метафорах. Это важный инструмент, мы им ещё воспользуемся в другие дни.
После перехода на новую работу я считал, что все чрезвычайно умны и начитаны, и не хотел отставать. Я шёл по известным изданиям, осиливая 6000 страниц технической литературы за год. Через некоторое время я всё же заметил, что так люди не делают, но решил не останавливаться.
Под конец подтвердилось, что нет пророка в своём отечестве, и желаемую мной дискуссию выстроить не удалось. Тогда я думал, что команды разработки выиграют, если будут организованы подобно древним философским обществам в поисках истины. Но вот миддл такого выстроить не может.
Тогда же я столкнулся с ещё одним вопросом, который попытался решить самоорганизацией. Процессы часто окружены бюрократией, которую легко забыть. За забывчивость можно было получить по шапке, а я такое не люблю. Чтобы избавить себя от этого, я разработал шаблон чеклиста.
Этот шаблон загружался в Todoist, а Todoist в лучших традициях излучателей информации болтался тонкой колонкой на каждом экране, где я работал. Тогда же стало заметно, что смысловая часть задачи совсем обделена вниманием, и нужно добавить ещё какой-то пункт.
Ничего приличного в голову не приходило, и закончил я так: «Понять, что необходимо сделать в задаче». Спустя многие применения этот пункт не только не отвалился, но и стал центральным во всей этой небольшой бюрократической системе. Она на удивление жива и несколько лет спустя.
В этом году я опубликовал её подробное описание: hackernoon.com/the-meticulous…. Теперь она называется «Тщательное кодирование». Возможно, я пробегусь по ней в один из дней.
По той причине, что проблемы разработки я стал решать самоорганизацией, я до сих пор не совсем чувствую себя именно программистом. Хоть я и возводил большие конструкции, и правил сложные ошибки, всегда это заканчивалось так: «Ух ты, а это я сделал?!»
На следующем месте работы я решил взять быка за рога. Сразу попросил закупить две книги: «Совершенный код» и «Чистый код», чтобы всем нам начать говорить на одном языке. Затея споткнулась о сильно выгоревшего тимлида. Тогда-то я и впервые услышал о скучности «Совершенного кода».
Тогда же я столкнулся с занятным явлением: натягиванием простого решения на сложную проблему. Задача состояла в разработке многостраничного парного списка котировок. Каждый список состоял из нескольких подсписков, дубликаты нужно было убирать. Требовалось много HTTP-запросов.
Моё решение умело обрабатывать все эти сложности, а также включало в себя прогреваемый кеш. То есть по мере использования приложения работало быстрее. Лучшие запросы — это несовершённые запросы, всё по заветам @igrigorik.
Единственной «проблемой» был объём этого решения — 3000 строк. То есть в моём представлении это не было проблемой, но высокопродуктивный исполняющий обязанности тимлида считал, что кода слишком много и всё переписал. У него вышло 800 строк. Только вот не работало.
Зарплата цвета #333 и привлечение давления сверху не способствуют выработке качественных решений. Я ушёл. В течение последующих нескольких лет я сменил пару работодателей, стал лидом и ощутил разные вариации на отсутствие менеджмента. Не рекомендую!
В Devexperts я пришёл в твёрдой убеждённости, что с уровня разработчика невозможно выстроить большую и качественную систему, но можно с уровня менеджмента. Надеюсь, что имеющиеся и поступающие знания и действия подтвердят справедливость моих идей.
До сих пор мне кажется, что практики работы в нашей отрасли достаточно зачаточные. Мы, конечно, используем клёвые инструменты от модных ребят с GitHub'а. Но видится мне, что для дальнейшего прогресса обратиться нужно к улучшению не техники, а организации нашей деятельности.
Об этом мы и поговорим. Своего выступления в @itunderhood я ожидал около двух месяцев, и это хорошо. Было над чем подумать, что попробовать.
Не утомила ли вас моя простыня?🙂
🤔
17.8% Утомила, пощади, злодей!🤔
38.3% Через боль к совершенству🤔
43.9% Хочется ещё!Тред (Герман Тебиев)
Начинается новая трилогия с того, что молодые люди рождаются и растут на руинах некогда могущественной империи среди ржавеющих атрибутов прошлого. Продолжается тем, что они пытаются примерить на себя уже испробованные успешными предшественниками ролевые модели.
Здесь предлагаю представлять себе открытые ветрам памятники Ленину и оставленные заводы. twitter.com/itunderhood/st…
@supervichka Да, вот статья про дебаггинг: hackernoon.com/3-sharpest-ins….
Не постесняюсь и вынесу повыше ссылки на статьи, упомянутые в одной из веток.
Дедовский метод дебаггинга. twitter.com/itunderhood/st…
@supervichka А эта про невероятную силу невнятно поставленных целей: hackernoon.com/the-immense-po….
Способ постановки больших целей, хорошо справляющийся с их неопределённостью. twitter.com/itunderhood/st…
@itunderhood @terbiyarchitect @devexperts @GlafiraZhur Давай про Clojure(Script) всю неделю пж
Пока в голове варится тред, задам пару вопросов.
Какой язык мне выбрать для моей следующей системы? Какие факторы могут повлиять на мой выбор? twitter.com/seminioni/stat…
@itunderhood Немецкий
Ответ во-первых, хороший, а во-вторых, не так далёк от правды.
Мне, правда, кажется, что он немного ангажированный. Что же намекает на это?..🤔🤔🤔 twitter.com/vgermaniu/stat…
@seminioni @itunderhood @terbiyarchitect @devexperts @GlafiraZhur Давай про closures в JS всю неделю пж
Для полной замкнутости нужно упоминание библиотеки Closure, которую использует ClojureScript. twitter.com/artwood/st…
Пока в голове варится тред, задам пару вопросов. Какой язык мне выбрать для моей следующей системы? Какие факторы могут повлиять на мой выбор? twitter.com/seminioni/stat…
Обратная сторона медали.
Какой язык выбрать новичку для карьеры? На какие факторы стоит обратить внимание? twitter.com/itunderhood/st…
@itunderhood а н г л и й с к и й
Если есть что-то, что я могу посоветовать без оглядки, то это учить английский, да. twitter.com/angelaZvdvsk/s…
@itunderhood Я бы посоветовал Go. Это современный, типобезопасный (с оговорками), не слишком сложный язык, на котором есть продакшены. Человек сможет и алгосики на нем поучить и тулу сделать и микросервис написать.
Первый достаточно убедительный и взвешенный ответ, спасибо! twitter.com/SharplEr/statu…
@SharplEr @itunderhood А если этот «новичок» — бывший дизайнер и хочет сам строить мобильные приложения? а если это аналитик, который хочет в data science? а если тянет AVRы программировать? :) ИМХО, сам язык вторичен, нужно выбирать исходя из своих задач и планов. twitter.com/shaukote/statu…
Хороший тред, из него можно почерпнуть много мыслей для размышления. Что я также и сделаю.🙂 twitter.com/shaukote/statu…
Небольшое предисловие перед планирующимся тредом о языках программирования и другими. Я не считаю своё мнение по этому вопросу окончательным и с удовольствием познакомлюсь с вашими. Я замечаю, что люди иногда настолько дорожат своим мнением, что соглашаются на одиночество.
Более того, излишняя уверенность в собственном мастерстве плохо масштабируется. По словам Билла Гейтса, он переписывал практически весь код, когда в Microsoft было меньше 10 человек. Думаю, мы бы не узнали о нём, продолжай он в том же духе.
«А что если моё мнение ошибочно?» — справедливый вопрос. Переживать из-за этого не стоит. Ошибки много раз помогали человечеству двигаться вперёд. Благодаря им появилась микроволновая печь, химиотерапия, стикеры и многое другое.
Кроме того, ошибка — это, возможно, единственный способ совершить по-настоящему прорывное открытие. По крайней мере, так писал уважаемый мыслитель от мира разработки ПО Джеральд Вайнберг.
Тред (Герман Тебиев)
В raw_basis_mat случайно помимо вращений подмешалось отражение. Отчего кватернион разворотило.
Если вам хочется немного почувствовать дух панк-рока, не выходя из комнаты, то знайте, что кватернионы рождались в акте научного вандализма. twitter.com/Nekrolm/status…
О языках программирования вообще и Clojure в частности
Я не очень много читал об архитектуре программного обеспечения, всего 3 книги, но послушал про неё много подкастов, пока гулял с новорождённой дочерью.
Вопрос, который мне казался настолько очевидным, что я ждал ответа на него всегда с первых страниц был таким: «Как выбрать язык, на котором должно быть написано ПО»? Каково же было моё удивление, когда такой вопрос вообще не рассматривался.
Как же так?! Разве это не первое, что мы должны решить?! Даже со всей этой опциональностью, пропагандируемой в «Чистой архитектуре» и ещё кое-где. Нам же нужно нанимать людей и что-то делать. Языки же должны отличаться чем-то друг от друга в вопросе технических характеристик.
Техническая литература безмолвствовала. Подкасты молчали. В одном из разговоров с коллегой с серверной части я прижал его своими расспросами и выяснил, что он никогда не упирался в производительность языка, чтобы думать о его смене. Хм.🤔
Я начал подмечать, что выбор языка имеет куда больше смысла в бизнес-контексте, чем в техническом. Хотите максимизировать вероятность найти кандидата под ваш язык? Смотрите в сторону Java. Хотите работать с начинающими разработчиками? Выбирайте низкий порог входа JavaScript'а.
Хотите собрать модных ребят? Тут возможны варианты. Если вас переполняет энтузиазм и вы истинно верите, что это язык будущего, то вкладывайтесь в Clojure. Нужна вера помощнее? Тогда Haskell со всей его элитарностью.
Вот как мы быстро перескочили от бизнеса к социальным вещам. Используя нишевые языки, вы делаете вашу лодку труднопокидаемой, но также несёте и дополнительные издержки в виде необходимости развивать экосистему или мириться с особенностями конкретных людей.
Многие часто выступают за то, что JS (и другие высокоуровневые языки с не очень, скажем так, удачным дизайном — тот же PHP) нельзя учить как первый язык, т.к. они (люди) подразумевают, что если ты первым изучаешь "более подходящий язык", то ты станешь более сильным программистом.
Вот в этом треде можно найти ещё несколько факторов для принятия решения: twitter.com/shaukote/statu….
Но так ли сильно отличаются разные языки друг от друга? В уже многократно упомянутом «Совершенном коде» есть отличная рекомендация: «программировать с использованием языка, а не на языке». По мере приобретения опыта в голове начинают формироваться идеи, применимые повсеместно.
Сразу оговорюсь и предостерегу от необдуманных решений. Перед тем, как всем рассказывать, как надо, почитайте всё же, что пишет сообщество и какие идеи провозглашает.
Сильно ли отличается по своей идее массив в JavaScript и вектор в Clojure? Идея в том, что это набор ячеек с доступом по индексу. И ладно, что в первом случае массив реализован с помощью Hashmap (или, возможно, настоящего массива), а во втором — при помощи дерева.
Прорывная идея и там, и там состоит в том, что эти массивы не требуют предустановки длины, как это требуется в некоторых других языках. А что насчёт тестов? Сильно отличается идея документирования своих ожиданий от языка к языку? Нет, суть остаётся та же.
Что насчёт разницы между Redux, Mobx, Recoil и ClojureScript'овским re-frame'ом? Кажется, у нас во всех этих случаях используется однонаправленный поток данных, акцентирование внимания на их изменении через лихо закрученные конструкции.
Щадить не буду, мы тут не в шашки играем, пойдём дальше. Какая разница между JavaScript'ым Event Loop'ом и еженедельным обзором задач в методологии продуктивности Getting Things Done? В общем, есть общие идеи в разных языках.
Если и есть за что мне любить Clojure, то это точно не за инструменты. Всё же разные JS-примочки с моментальной обратной связью: линтеры, форматтеры, вотчеры на тестах, позволяют двигаться куда увереннее. А как богаты возможности рефакторинга в WebStorm в сравнении с Cursive!
В последнем даже нет возможности извлечь кусок кода как функцию. И это в функциональном-то языке!
Люблю Clojure за следующее:
• Во-первых, это гомоиконично.
• REPL.
• :keywords как решение проблемы шакальных магических строк.
• Генеративное тестирование.
• Умение работать с бесконечностью через лень.
• Возможность использовать библиотеки Java.
Остановлюсь только на генеративном тестировании. В этой классной штуке вы описываете форму входных и выходных данных (привет, TypeScript!) функции, задаёте дополнительные проверки. Затем Clojure генерирует 1000 различных тестов на основании описания и запускает их. Мощь!!!
Есть один момент персональной боли в Clojure: там слабее деструктуризация по сравнению с JS. Если в JS мы имеем чудесный rest-оператор [...everythingElse], то в Clojure [...ага-ишь-чего-захотел] не сработает.
Спасибо за то, что дочитали!
Тред (Герман Тебиев)
@itunderhood Зависит от кучи факторов и желаний: Если учиться самому, то js имеет самый низкий порог входа – куча сайтов, интерактивных курсов, и результат работы виден очень быстро. Для самоучек и тех, кто хочет прыгать из старой профессии – самое то
Ещё один хороший тред развился. twitter.com/ValeriiZhyla/s…
@itunderhood Мне одному кажется, что сюда как минимум Groovy подойдет? А как максимум Скала (справедливости ради) и Котлин? Ну то есть кроме первого пункта, который надо читать "Во-первых, это лисп".
Я не специалист по широкому спектру языков, так что, думаю, не одному. Спасибо за наблюдение и замечание. Если есть ещё что-то добавить, то с удовольствием ретвитну. twitter.com/noraltavir/sta…
Вторник
@itunderhood Потому что нет такого вопроса. Язык вторичен по отношению к экостистеме и фреймворку.
Дерзкий заход и развёрнутый ответ внутри. twitter.com/unetwarm/statu…
@unetwarm @itunderhood Поэтому надо вводить парадигму BsDdd. Business data driven development.
Не слышал о такой, в чём её идея? twitter.com/burnmthfck/sta…
@noraltavir @itunderhood Подробно и с примерами, но не могу вспомнить где же все это найти. Или у меня глюки? И там же вроде было, что для крупных проектов поддержка важней и дороже самой разработки первой версии.
Немного напоминает Брукса и его «Мифический человеко-месяц», но точнее вспомнить не могу. У кого-то появляются более определённые ассоциации? twitter.com/LeonidMesnik/s…
@ValeriiZhyla @itunderhood Учить ли Джаву когда выучил js? Что вообще можно учить после того как обосновался в профессии через js
Тут всё зависит от ответа на вопрос «чтобы что?» Если хочется тихонько жить, не тужить, то можно продолжить постепенно углубляться в JS и его экосистему. Если хочется повысить свою ценность, то тут уже скорбь познания и архитектура или менеджмент.
Всё очень зависит от целей. twitter.com/sladkiy_59/sta…
Перед тем, как перейти к обещанной теме дня, личной продуктивности, ещё немного поразмышляю о полезности публикаций статей, похвалю HTML и CSS, да и сам немного похвастаюсь.
После того, как этим летом я созрел на оформление своих мыслей в несколько тысяч знаков, из LinkedIn постучали. В то время я находился в поиске работы, так что не сразу распознал, что стучат не с вакансией, а с другим предложением.
Мне написали из @Uploadcare и предложили написать статью для их блога. Предложили достаточно убедительно, и я согласился. Начали с того, что мне близко — с front-end’а.
Хотя я и относительно недавно прочитал в сумме около 1500 страниц про HTML и CSS и знаю тег <output>, экспертом в этих технологиях себя всё же не считаю. Есть в Твиттере ребята, которые очень хорошо пишут про них, и которыми я негромко восхищаюсь.
Многие же горазды ругать разработчиков HTML и CSS, говорить, что они не настоящие. Что сказать, попробуйте написать копирование данных из своих виртуализированных таблиц с сохранением форматирования. Днище оторвёт вместе с крышкой.
HTML и CSS — это разработка в терминах результата, а не в терминах действия. И там сейчас появляются ой какие классные штуки. Медиа-контейнеры для отдельных элементов, вложенная сетка, своя виртуализация, просто восторг!
Вернёмся к статьям. С августа этого года я написал две статьи для блога Uploadcare. Третья статья на подходе, но ещё не опубликована. Писал я про ленивую загрузку изображений, про их обрезку при помощи CSS.
Мне как-то неудобно просто сводить вместе уже имеющиеся знания. В обоих случаях я постарался нырнуть достаточно глубоко, чтобы добавить полезную информацию в общее понимание. Надеюсь, у меня получилось это сделать.
Ленивая загрузка изображений: uploadcare.com/blog/lazy-load…. Прошёлся по новинкам, прояснил неясности у соавтора спецификации. Показал, как делать размытую заглушку для лениво загружаемого изображения без помощи JavaScript.
Обрезка изображений при помощи CSS: uploadcare.com/blog/how-to-cr…. Отринул все хаки, так как пришло время, научился ставить изображение фоном тексту, нашёл ошибку в неофициальной спецификации MDN и CSSWG.
Тред (Герман Тебиев)
аргументный аргумент! pic.twitter.com/6Odhg0Brbj twitter.com/itunderhood/st…
Личная продуктивность
Это интересная тема. С одной стороны, я бы порекомендовал каждому что-то изучить по ней. С другой стороны, в приличном обществе говорить о таком не принято. Кому нравится смотреть на этих нервных людей, лихорадочно что-то учитывающих?!
Как бы мне не хотелось этого избежать, сейчас будет очень нудный тред. С другой стороны, это может быть тестом на то, готовы ли вы к такой организационной нудятине.😄 Второй мой ник, «турбобюрократ», на многое намекает.
На прошлой неделе в @AntiITUnderhood вещал @softskillpump. В какой-то момент он упомянул GTD, сказал, что это путь к выгоранию. Беседа не началась, но подумал, что в этом смысле я интересный парень, прошедший испытание травами, можно и развить тему. Так что «я не договорила!»
Какие цели стояли при строительстве системы личной продуктивности? Я уже особенно и не помню. Многое из того, что когда-то было для меня открытием, стало привычкой, мне уже трудно это заметить. Могу предположить, что мне не хотелось терять время даром и забывать важное.
Ещё я не люблю спотыкаться на простых вещах.
Достаточно мотивации, перейдём к описанию системы. Сразу скажу, что корреляция между продуктивностью и успешным успехом не так хороша, как хотелось бы, так что не охлаждайте скепсис!
Самый крупный блок — это простыня с планом на 3 года. Там скорее мироощущение в стиле «а хорошо бы то, хорошо бы это». Можем назвать это жизненными ориентирами. В этом году я написал третью такую простыню. Почерпнул практику в GTD.
Блок сильно меньше — план на три месяца. Вот это уже действительно ориентир, на который я работаю. Если сейчас все подводят итоги года, то у меня это уже четвёртый раз в 2021-м. Практика хорошая, с ней я познакомился в книге «12 недель в году».
Календарный год — не особенно удобная для планирования вещь. Слишком много поменяется, составлять подробные планы — пустая трата времени. Если желаемое за 12 недель получить не удастся, не страшно. Можно продолжить в следующие. Не всё же теряет смысл оттого, что вышел срок?😄
Ещё более мелкий блок — неделя. Тут у меня уже есть красивая Excel-табличка, в которой я веду прогресс по целям, фиксирую выполнение регулярных дел за каждый день. Это инструмент для сбора статистики для последующих размышлений.
Эти самые размышления еженедельно появляются неподалёку от планов на три месяца. Самое забавное — читать ожидания с прошлой недели в конце следующей, когда всё вышло по-другому в итоге.
При переходе ко дню инструментарий становится всё больше. Я давний пользователь Todoist, года с 2016-го регулярно вхожу в 1% самых активно жмакающих на галки пользователей. На прошлой неделе у меня выполнено 189 задач. За всё время пользования — 35 869.
Каждое буднее утро я сажусь перед ним и смотрю на всё, что планируется на сегодня. Что-то не будет выполнено однозначно, я перекидываю это на последующие дни. Остальное будет выполнено с большей вероятностью, я это оставляю.
Мой будний день расчерчен помидорами, то есть я не просто пользуюсь таймером, но использую целое расписание. Однажды я шутки ради решил прочитать книгу про Pomodoro (что там читать-то?!) и узнал о таком развитии техники. Кто бы мог подумать, что шутка так обернётся?!
Есть одна очень важная мысль, которая редко встречается в книгах по личной продуктивности: «для значительного повышения успеха выполнения конкретной задачи для неё нужно ясно определённое место и время».
Обычно люди накидывают себе из задач сущность в виде стека и пытаются полностью разобрать её. А вечером горько плачут: «Ах, какие мы непродуктивные, всего-то 700 задачек на день было!»
Для каждой назначенной на день задачи я с помощью тегов прописываю риски и пути их разрешения. Это позволяет задуматься о негативном варианте развития событий, подготовиться к нему. Плюс, набирается устойчивая коллекция рисков. Приходит понимание, что их не очень много.
Если по-честному относиться к ведению своей системы, то не обходится и без смешного. Я слушаю аудиокниги, в том числе и научпоп о медицине. У меня в течение дня есть определённые помидоры в расписании, они заложены под определённые книги. В общем, вот:
Мне надо было как-то вознаградить людей, дошедших сюда.😄
Если вы хотите выстроить свою систему, то определено лишь то, что нет такой методики, которая бы вам подошла сразу. Это хорошо отражено в книге «Путь джедая» от @cartmendum. К слову, он мне никогда в твиттере не отвечал.😐 Потребуется изучать разное и пробовать.
Хорошо то, что тут могут быть решения на любой масштаб. Можно начать с небольшого изменения собственной среды. Например, вы хотите начать читать после обеда, но сразу проваливаетесь в работу, так как забываете о своём желании. Положите перед обедом книгу на клавиатуру.
И вуаля, вы великолепны! Уже продуктивны, но ещё без невроза!
Книги, на которых я построил свою систему:
• Брайан Моран, Майкл Леннингтон «12 недель в году»
• Дэвид Аллен «Как привести дела в порядок» (Getting Things Done)
• Питер Брегман «18 минут»
• Клир Джеймс «Атомные привычки» (Почему не атомарные?🤔)
Отдельно хочу упомянуть книгу «7 навыков высокоэффективных людей» Стивена Кови. В своё время я думал, что её идеи уже и так повсюду, как идеи «Совершенного» или «Чистого кода», а там оказалось много неожиданного.
Ещё неплохой источник техник — это десять лет рефлексии на их счёт, рекомендую. Если сомневаетесь, то знайте, что декабрь 2031-го когда-то да всё равно наступит.
Говорить дальше можно долго, но делать мы этого не будем. Если у вас есть какие-то конкретные проблемы, то не стесняйтесь задавать вопросы, возможно я или прочие увлекающиеся темой сможем подсказать решение.
Тред (Герман Тебиев)
Говорить дальше можно долго, но делать мы этого не будем. Если у вас есть какие-то конкретные проблемы, то не стесняйтесь задавать вопросы, возможно я или прочие увлекающиеся темой сможем подсказать решение.
Ещё можно писать мне в личку @terbiyarchitect, если хочется сохранить анонимность, а вопрос есть. twitter.com/itunderhood/st…
@itunderhood @terbiyarchitect Классный тред, спасибо
Спасибо, что прочитали!🙂 twitter.com/politoHQ/statu…
Перед тем, как перейти к обещанной теме дня, личной продуктивности, ещё немного поразмышляю о полезности публикаций статей, похвалю HTML и CSS, да и сам немного похвастаюсь.
Днём было ещё немного про любимые мной HTML и CSS. twitter.com/itunderhood/st…
Вопрос, ответ на который поможет рассуждениям следующих дней.
В чём принципиальная сложность программирования по сравнению с другими занятиями?
Вспомогательный вопрос.
Почему front-end в малых масштабах принципиально понятнее back-end’а?
@itunderhood Наглядность
Если рассматривать человеческий организм как систему из частей со своими возможностями, то почему наглядность для нас так важна? twitter.com/zaeberg/status…
@itunderhood Я, к примеру, учился разбираться в аналоговых электросхемах. Там тоже все визуально видно и потому понятно. К примеру, это генератор, это усилитель, это обратная связь. А когда мне показывают код.... мда...
Я аж всхохотнул.😄 twitter.com/PavelVoronezh/…
@itunderhood А как вы временно оцениваете и планируете периоды отдыха и ничегонеделания? Интересен ваш опыт. мне например тяжело утром решить сколько мне вечером надо повтыкать в стену )
Ура, вопрос, спасибо! Я обычно не планирую этого. По умолчанию вечером у меня не слишком сложное дело — регулярное чтение, но если сил нет, то я его пропускаю. Спустя несколько дней захлёстывает возмущение отсутствием прогресса, и я его возобновляю. twitter.com/honeysusami/st…
Выходные — намеренно дикая территория. Если очень что-то нужно запланировать, то я это делаю и реагирую ответственно. Но многие вещи опциональны.
@itunderhood Программирование это про создание нового, в противоположность тиражирования чего-либо. Создавать новое всегда сложнее, и это не только про программирование на самом деле.
Тут можно придумать много исключений, но в целом я согласен. twitter.com/vaylen_spb/sta…
@itunderhood 1) в абстракции многим тяжело 2) логика тоже не всем легко даётся 3) нужен в целом нехилый бэкграунд (ну ок, если речь о среднестатистическом фронте - это опускаем)
Как фронтендеру мне, конечно, не нравится содержимое скобок, но пункты сами нравятся.🙂 twitter.com/ssidoryak/stat…
Вопрос, ответ на который поможет рассуждениям следующих дней. В чём принципиальная сложность программирования по сравнению с другими занятиями?
Мои ответы следующие:
У человека значительная часть головы отвечает за восприятие визуальных образов. Отсутствие таковых из коробки в программировании сильно сокращает наши мощности. twitter.com/itunderhood/st…
Если у кого-то рядом с вами отвалится и с грохотом упадёт зад, то всё будет понятно без каких-либо слов.
Если Developer Tools > Network > <Сортировать по полю Status> > Первый запрос > 500 Internal Server Error, то это посложнее.
Обратная связь, важнейший механизм корректирования наших действий, по умолчанию очень скуден. Его приходится дорабатывать самостоятельно. Часто даже после долгих лет обсуждений.
Чем TypeScript в IDE выигрывает перед проверкой на pre-commit hook? Тем, что у вас меньше шансов уйти в дебри, если вы реагируете на сигнал.
Аналогично узнать о прищемлённом пальце сразу лучше, чем через несколько часов, когда случатся необратимые разрушения.
Тред (Герман Тебиев)
Среда
@itunderhood Потому что существует изоморфизм между программами и теоремами, поэтому написание корректнных программ это тоже самое, что доказывать теоремы. Потому программирование столь же сложно как и математика. Помимо этого мы наперёд знаем, что часть задач, которые решает программист
Замечание про сложность в таком виде тоже очень хорошее, спасибо! twitter.com/SharplEr/statu…
@itunderhood Для начала давай рассмотрим такой вариант теста без написания макросов gist.github.com/serioga/23bbe9…
Сергею огромное спасибо за демонстрацию возможностей Clojure и помощь! twitter.com/serioga/status…
@mudasobwa @itunderhood @vaylen_spb @immedetablya Мне все-равно на суть разговора. Но я сделал картинку. pic.twitter.com/iAUH16RuPJ
Я выполнил все свои планы в этом аккаунте. twitter.com/atnimak_/statu…
Ещё немножко о продуктивности, но уже с точки зрения именно разработки. Есть одна практика, которая меня ужасно раздражает, но которая даёт отличные результаты — прочитать весь написанный код перед коммитом.
Раздражает она меня потому, что я уже всё же сделал почти, только закоммитить осталось. Прям ломает!
Отличные результаты она даёт потому, что какая-нибудь нежелательная ерунда всегда да пролезет. И эту ерунду удаётся обнаружить и убрать.
Способ постановки больших целей, хорошо справляющийся с их неопределённостью. twitter.com/itunderhood/st…
Если кому-то интересен краткий пересказ механики из статьи, то ищите его в следующем твите. twitter.com/itunderhood/st…
@pavelegorkin Предположим, что у нас появилась большая цель: «Стать членом аквариумного содружества». Мы не знаем, как её достичь, и когда это случится, знаем только то, что нужно забраться на вершину горы Отыкотыкомутотуго, а там уже принять участие в ритуале. pic.twitter.com/QxbRLylAgD
Вот здесь кратко описано использование неточных целей. twitter.com/terbiyarchitec…
@itunderhood Список других занятий огласите, пожлуйста. А то у меня совсем нет идей. Обычная инжерная специальность.
Вопрос к людям с опытом в других инженерных специальностях. Как там устроена разработка нового устройства? twitter.com/leonidmesnik/s…
Ещё немножко о продуктивности, но уже с точки зрения именно разработки. Есть одна практика, которая меня ужасно раздражает, но которая даёт отличные результаты — прочитать весь написанный код перед коммитом.
Вторая неплохая практика — писать сообщения коммитов до написания кода. Так вы получите лёгкую броню от разъезжания во все стороны.
Идея практики — книга Git Essentials от Ferdinando Santacroce. twitter.com/itunderhood/st…
@itunderhood Я обычно делаю пр черновик, прохожу весь код вдоль и поперёк и если все норм, то публикую пр. Если не норм, то правлю пр. Просто у гитового диффа сложный для восприятия формат, чтоб так код смотреть, а тулзы для диффа мне не нравятся никакие. Самое норм-в гитхабе/гитлабе
Да, хорошее замечание. Я обычно использую diff в WebStorm. twitter.com/litleleprikon/…
Рабочий день разработчика
Приходите вы в офис или переползаете с кровати на компьютерный стул. Что дальше?
Ответ известен и большим, и детям: нужно максимизировать собственную производительность. Желательно купить себе эргономичный стул, сесть в него, словить Чиксентмихайи и начать перерабатывать Jira в код.
Спустя 4 часа необходимо сделать перерыв на восполнение утерянных калорий. Они необходимы для работы станка для обработки информации. Хотя, знаете ли, перерывы губительны для производительности, перенастройка занимает много часов.
В лучших традициях научного менеджмента, под знамёнами Тейлора и Форда мы ускорим конвейер и увеличим выработку. Даже молодое большевистское государство признало наши достижения, хотя и поначалу называло это эксплуатацией рабочего класса.
По заветам системы 5S рабочее пространство организовано и рационализировано. Клавиатура и мышь сортированы, находятся на местах. Окружение находится в чистоте. Ко всему этому применяются корпоративные стандарты и постоянное совершенствование операций ввода информации.
Думаю, что с таким в своей практике сталкивался примерно никто. Но вновь окунёмся в первые дни профессиональной разработки, когда всё в новинку. Понятно, что нужно делать таски, укладываться в срок. А что будет, если не уложусь? Грозит ли мне это проблемами?
А можно ли вставать из-за рабочего места? А как часто можно? А можно ли работать не на рабочем месте? А вон ребята пошли в кикер играть, а мне можно? А разве я не должен как можно скорее выполнить одну задачу и взять следующую и кикер сюда как-то не вписывается?
Как и многое в нашей индустрии, эти вопросы оказываются без ответа. Все принимают обыкновенный порядок вещей, когда всё происходит обыкновенно, не отсвечивая. Но вопросы от этого никуда не исчезают. Сегодня мы рассмотрим ситуация с точки зрения работника, игнорируя компанию.
Вообще, я планировал размышление на эту тему как свою следующую статью на Hackernoon, но пока до неё не добрался. Так что это репетиция.🙂
Обыкновенный порядок вещей практически не даёт никакой информации для вдумчивого рассмотрения этих вопросов, мы посмотрим извне.
Рассмотрим рабочий день с трёх сторон: здоровья конкретного разработчика, его умения решать поставленные задачи и карьерных перспектив. Продолжать не отсвечивать, меняя свой рабочий день, всё так же полезно, поэтому менять свои привычки рекомендую постепенно.
При рассмотрении заявленой темы я планирую руководствоваться двумя книгами: Pragmatic Thinking and Learning от Andy Hunt (прагматик-Энди) и The Healthy Programmer от Joe Kutner, а также некоторыми другими. Сильно углубляться не будем, там гораздо больше всего.
Задачки обычно не имеют свойства кончаться. Часто есть разработка новых функций, устранение не особенно приоритетных багов, технический долг. Что есть у нас в арсенале, так это темп работы. Если он не вызывает нареканий, то небольшое его замедление вряд ли кого расстроит.
После предыдущего шага начинает освобождаться некоторое время. Предлагаю сразу рассмотреть технику Pomodoro. Но не по той причине, что вам нужна концентрация, а потому, что помидоры полезны для здоровья. В следующем твите я поясню подробнее.
Идея состоит в том, что в пятиминутный перерыв, когда вы резко встаёте из-за стола и моментально забываете о задаче вас волновавшей, осуществляется небольшое физическое упражнение. Это может быть простая прогулка, упражнение для спины или профилактика туннельного синдрома.
Если вы думаете, что в течение этих пяти минут ваш тимлид рвёт на себе волосы и горестно рыдает, то знайте, что делает он это совершенно зря. В этот момент наконец-то дорывается до памяти та часть вашего мозга, которая отвечает за синтез решений.
Её нельзя контролировать напрямую, она придёт к вам, когда не ждёте, и предложит решение. То есть вполне можно поймать озарение, раскорячившись в планке. К слову, эта же часть отвечает за восприятие музыки, так что с большой вероятностью музыкальность сделает вас нерешительным.
Если вы тимлид, то вы уже немного сам себе хозяин. Что это значит? Это значит, что вы можете потратить двадцать минут каждый день на сокращение риска преждевременной смерти на 20%. Если вы ещё и заботливый тимлид, предлагайте прогулки во время 1-на-1 вместо посиделок.
Мы без конца проклинаем стендапы, и, разумеется, за дело. Формат «Что сделал?», «Что сделаю?», «Что меня блокирует?» фокусируется на ложных вещах, но такой формат очень подходит для проверки здоровья.
Ежедневный стендап здоровья:
• Что я делал вчера для поддержания и улучшения здоровья?
• Что я сделаю сегодня для поддержания и улучшения здоровья?
• Что мешает мне быть здоровым?
А что насчёт карьеры? Предлагаю вам задуматься над тем, чтобы тратить час в день на самообразование. Рухнул ли я с дубу такое предлагать? Не совсем. Сейчас мы проанализируем, стоит ли так сильно хвататься за час малопродуктивного работника.
Чем вдохновлялся создатель производственной системы «Тойоты» Тайити Оно? В далёком 1937-м году он узнал, что производительность японского рабочего в 9 раз меньше американского. То есть покранчить не вариант, просто не найдётся 72-х часов в сутках.
К чему привели действия Тайити? К тому, что в 1970-х Япония с ноги вошла на американский рынок и показала доминатора. А если вы любитель Кента Бека и его «Экстремального программирования», то знайте, что в конце своей книги он очень мечтательно отзывается о ПСТ.
Упор в действиях по улучшению производительности японских рабочих шёл на устранение ненужных операций и многопрофильное образование. Вместо одного станка рабочий мог обращаться с несколькими. Настало время волчьей мотивационной математики.
Представим, что час образования в рабочий день даёт вам улучшение ваших навыков на 1%. В 2022-м году 247 рабочих дней. Кручу, верчу, сложный процент мучу 1,01^247 ≈ 11,68. То есть за следующий год вы можете стать в 11,5 раз круче, вуф!
А легально ли общаться с коллегами для решения совместных вопросов? А если не хочется? Так же приятно посидеть в тишине, поработать. Вот об этом мы поговорим завтра.
Тред (Герман Тебиев)
@itunderhood Я тута. Есть проблема у меня: любые инструменты устранения влияния собственной рассеянности требуют собранности для их использования.
Е, рок! Приятно вовлекать в дискуссию уважаемых ведущих предыдущих недель. Отвечать буду уже завтра.🙂 twitter.com/softskillpump/…
@itunderhood Программирование - работа с абстракциями, но также и большинство других родов деятельности - работа с абстракциями. Приведу пример из своего опыта: я получила образование в медицинской сфере и успела побыть практиком, и познала так называемое врачебное мышление
Друзья, ёмкий и познавательный тред, рассказывающий об абстракциях в медицине. Очень рад, что он случился, спасибо большое @enemorrian. twitter.com/enemorrian/sta…
P.S. После плотного знакомства на уровне пациента с доказательной медициной я понял, что «до свадьбы заживёт» — важный её принцип.
Вопрос к людям с опытом в других инженерных специальностях. Как там устроена разработка нового устройства? twitter.com/leonidmesnik/s…
Вот и где все умники и умницы, когда они так нужны?! Мы с вами как в пятницу производственную систему строить будем без знаний о схожих занятостях в других областях? twitter.com/itunderhood/st…
Четверг
@itunderhood Для начала нужно поплакать.
Рабочий день разработчика Приходите вы в офис или переползаете с кровати на компьютерный стул. Что дальше?
Знали бы вы, как я был бы рад, если бы мне рассказали об этом, когда я был джуном. Вёлся бы на этой неделе @jnrUnderhood, попросил бы ретвитнуть. twitter.com/itunderhood/st…
А если вы в начальствующих должностях и вам хочется, чтобы люди пользовались полезными советами из этого треда, то одних слов недостаточно. Эти действия должны логически следовать из рабочей среды. То есть если прогуливаться попросту негде, то никто и не станет.
@itunderhood Кстати, чотам по высокоэргономичным кресла? Кто какие выбирает? Самурай мне не очень зашёл.
Я не специалист, помогайте! twitter.com/denisemenov/st…
Не могу удержаться и не спросить, как вы поняли выражение «словить Чиксентмихайи» из последнего треда?
🤔
6.3% Словить инсайт🤔
47.7% Войти в поток🤔
2.9% Быть в ресурсе🤔
43.1% Что-то из «Ведьмака»@itunderhood Сначала заводишь таску и под неё коммитишь. Название таски и есть сообщение для коммита с префиксом fix или solved. А коммитить без таски низзя
Вот, точно, хорошая практика.👍 Я уже настолько к ней привык, что и забыл. twitter.com/ivankunitsin/s…
@itunderhood Я тута. Есть проблема у меня: любые инструменты устранения влияния собственной рассеянности требуют собранности для их использования.
Итак, углубимся в парадокс, при котором есть только рассеянность и нет собранности, хочется избавиться от рассеянности, но для этого нужна собранность. Если бы мы рассуждали в мире логики, то эта задачка была бы неразрешима, но мы сейчас не в таком идеализированном мире. twitter.com/softskillpump/…
Мне неизвестны многие вводные, так что все мои рекомендации могут пойти мимо кассы, но идеи у меня есть. Одна из ключевых характеристик моей ежедневной работы заключается в том, что собранность используется очень избирательно. Я использую её для того, чтобы помнить о системе.
То есть открывать свой Todoist каждый день, приводить его к состоянию, когда выполнимость задач обеспечена временем, местом и обстоятельствами и затем руководствоваться им в течение дня. Понятно, что что-то может прилететь, это не очень страшно, обработаем.
В остальном собранность я стараюсь не использовать. Всё уже в достаточной степени собрано в одном месте. В качестве бонуса идёт то, что для выработки привычки уже требуется не 21 день, а грамотно сформулированная периодическая задача.
Как хотя бы привить эту одну мета-привычку? Вот здесь предлагаю обратиться к книге Atomic Habits авторства James Clear. Я прочитал эту книгу относительно поздно, она могла принести больше пользы, прочитай я её ранее.
Джеймс Клир предлагает 4 типа действий для заведения привычки:
Сделайте старт очевидным,
Сделайте продолжение привлекательным,
Сделайте выполнение облегчённым,
Сделайте завершение удовлетворяющим.
В предыдущем твите была такая концентрация успешного успеха, что сахарная патока могла потечь с экрана. Голова же начнёт болеть на том моменте, когда начнёте прикладывать её к реальной жизни. «А как сделать старт очевиднее?» «А как облегчить выполнение?»
Тред (Герман Тебиев)
@itunderhood Chics [👯♀️] and machine AI?
Хороший вариант! twitter.com/angelaZvdvsk/s…
Прохладные отношения с асинхронностью. Команда и взаимодействие внутри её
Многие программисты любят работать одни. Некоторые начальники не любят, когда их работники особенно активно взаимодействуют. По ровной ли мы идём дорожке или по кочкам, по кочкам?🤔
Когда разработчики говорят, что они не любят встречи и предпочли бы всё время проводить с компьютером, то в душе я улыбаюсь. Если наступит тот момент, когда разработчик сможет всё выполнить, ни с кем не общаясь, то тогда ИИ предложит подвинуться, дружески хлопнув рукой по плечу.
Почему это я так радикально завернул? Давайте немного всмотримся, чем мы занимаемся. Мы пишем обширные инструкции, позволяющие компьютеру делать полезную работу и справляться с трудностями на её пути. А откуда мы знаем, какую именно полезную работу должен делать компьютер?
Это хороший вопрос. При разработке для любой неизвестной нам предметной области мы не знаем ответа на него. Но знают другие люди. Ситуация может быть ещё закрученнее, когда другие люди не знают точно, а только предполагают, и им необходимо произвести исследование.
Вопрос ещё осложняется тем, что не все мыслят в подобных терминах. Кто-то может и не знать, что нужно провести исследование жизнеспособности решения и просто предложит: «сделай то-то». Если вам не повезло сильно, то «то-то» — непроверенное решение, первым пришедшее в голову.
То есть мы пришли к тому, что часто разработчик не является решателем проблем в широком смысле. Его задача состоит в том, чтобы воспроизвести описанное на естественном языке решение в терминах искусственного языка. Мы в каком-то смысле переводчики. Но переводим ли мы дословно?
Не совсем, наши переводы содержат дополнительную информацию, которую я уже упомянул — решения для проблем, которые могут появиться в пути. Какие это проблемы? Можно увидеть по крайней мере два вида: проблемы технического характера и проблемы логики решения.
Проблемы технического характера вроде необходимости подстраиваться под не самый удачный API библиотеки мы можем решить и сами. Хотя некоторые технические проблемы всплывают и до уровня пользователя, и не в наших силах это изменить. Например, ожидание ответа на запрос.
Это то, что явно будет заметно, и значит то, что нужно будет как-то обработать аналитику, предлагающему решение. Более того, ему уже нужно будет подумать об обработке исключений в самом процессе решения пользовательской проблемы. Продумать обработку неверных данных, подсказки.
Не каждый человек, предлагающий решение проблемы, занимается её проработкой вширь, не каждый умеет. Умеет ли делать такое разработчик? В какой-то мере да, но умеет ли кто-то делать это лучше него? Да, QA-инженер, это его работа.
Путём этих размышлений мы пришли к тому, что без совместной работы троих людей над одной задачей её решение будет вопиюще неполным. А может ли решение быть полным? Нет, таковым оно быть не может. А может ли быть полным в достаточной степени? Да, такое возможно.
Почему решение не может быть полным? По той причине, что обработка неожиданных ситуаций в его логике не имеет явного конца. Неожиданные ситуации — это проблемы, материализовавшиеся риски. Сколько рисков мы можем придумать для моего завтрашнего утреннего прослушивания аудиокниги?
Да сколько угодно: я просплю, мне захочется посмотреть мультик с дочкой, я решу дописать небольшой тред про работу с книгами, лупоглазый гуманоид мне предложит дружбу века, вознесёт на крыльях ветра в даль, что светит ярко нам.
Там на праздничном конгрессе я поставлю свою подпись, скрепив дружбу меж народов на грядущие века. Представлять я буду Землю, как вы поняли, наверно, а мой друг представит свой удалённый внешний мир.
В какой-то момент обработка неожиданных ситуаций перестаёт иметь видимый смысл, тогда-то решение становится в достаточной степени полным. Новый опыт может нас научить видеть новые риски. Тогда до достаточно полного состояния потребуется сделать новый шаг.
Если же по каким-то причинам взаимодействие в группе, разрабатывающей решение, не произойдёт, то мы окажемся на дороге последовательных работ, и сначала свою работу выполнит аналитик, потом разработчик, а затем QAE. Асинхронность в уродливом виде покажется во всей красе.
Через пару недель QAE вернётся с парой багов, потом разработка пойдёт в бой. Ещё спустя некоторое время счастливые клиенты через удобнейшие механизмы фиксации обратной связи пришлют вам информацию о непокрытых рисках и немножечко денег, чтобы вы всё починили.
Так что же после всего сказанного стоит воспринимать как выполнение разработчиком поставленной задачи? Написанный код на имеющуюся спецификацию или же завершение её проработки в составе группы с последующим доведением до ожиданий заинтересованных лиц?
Ответ на него многослойный, часть его мы рассмотрим завтра, если я не забуду. В своей команде я всё же пытаюсь продвигать именно второй вариант. Но должен ли разработчик заниматься такой деятельностью? Сама постановка вопроса «А почему я должен?..» мешает обзору перспектив.
Если окружающая среда не подсказывает вам ответ, перспективнее задать вопрос: «Будет ли мне полезно делать это?» Если будет, то действуйте, собирайте людей, качайте навыки взаимодействия, организации. Ведь если что-то выглядит и крякает как тимлид, то это, наверное, он и есть.
А если вокруг летят головы, да и вообще не очень-то вам и нравится взаимодействовать с людьми, то полезнее не будет. По возможности, избегайте этого.
Мы лихо проехались по самому базовому взаимодействию, а что ещё бывает?
Бывают стендапы, бывают ретроспективы, демонстрации и прочее. Нужно ли это всё? В своей практике я стараюсь использовать стендапы для того, чтобы фокусировать команду на определённых действиях, а также помогать людям увидеть альтернативные способы решения их задачи.
Ретроспективы — это настолько отдельная песня, что даже погружаться в них не хочется, тред и так затянулся. Единственное, хочу сказать, что очень удивился, когда прочитал в Твиттере, что участники уходят с них в слезах. Это ярчайшее свидетельство их ошибочного проведения.
Про демонстрации ничего не скажу. У меня нет опыта проведения качественных демонстраций.
Я опять ушёл от вопроса, нужно ли это всё. Мне кажется, что да, но с нюансами. Без внутреннего взаимодействия команда перестаёт быть командой и становится группой, суммой частей.
То есть, уходя от общения, мы уходим от взаимного обучения, синхронизации взглядов, выработки более качественных решений и в полном согласии с законом Конвея создаём системы, организованные по принципу «кто в лес, кто по дрова».
Если это всё так важно, то почему слово «встреча» — почти ругательное? Дело в том, что, как и в остальных вопросах, здесь нужно действовать лучше, чем как-нибудь. Мне нравится модель, предложенная книгой Where the Action Is авторства Elise Keith.
В книге предлагается руководствоваться несколькими вещами: воспринимаемым качеством встреч, то есть внутенним ощущением участников и чистым позитивным влиянием, то есть пользой от этих встреч для целей организации.
Также в книге предлагается базовая структура любой встречи, пять этапов зрелости культуры встреч в организации. Кстати, если задуматься, то концерт — это тоже встреча, но лица там обычно не такие кислые.
Тред (Герман Тебиев)
@wrongshell @softskillpump @itunderhood Там тонкость есть... если "каждый день засыпать в пожаре и в обнимку с огнетушителем", то тут два момента: первый - это недостаток дескриптивного описания. Мы же не в прямом смысле берем огнетушитель и спим, спасаясь от опаляющего пламени. Это все метафоры...
Рад, что у меня в тредах дают рекомендации уважаемые профессионалы. Спасибо, @cartmendum! twitter.com/cartmendum/sta…
Пятница
@itunderhood Очень хреново, что ты не знаешь предметную область под которую пишешь код.
Хорошо иметь представление о предметной области, но я не особенно понимаю, как можно получить в ней настолько глубокие знания, чтобы предлагать решения по автоматизации.
Так-то за время работы я должен был бы стать экспертом в педагогике, финансах и нефтянке и прочем. twitter.com/juchkov/status…
А если организация процесса разработки неумелая, и всё развалилось, то и инвестиция в предметные знания была напрасна.
@itunderhood Пример: школьное образование. У тебя 4 участника процесса: государство, учителя, родители, дети. Учителя по заказу государства составляют школьные программы обучения, получают финансирование, собирают статистику по успеваемости, отправляют отчеты государству.
Хороший пример, когда для автоматизации нужно понимание только части предметной области. twitter.com/za_mat_izveny/…
Вопрос, на который я пока не нашёл ответ. Откуда пошла канбан-доска в той форме, в которой мы используем её в разработке? Сама идея идёт из производственной системы «Тойоты», но там это сильно другое.🤔
Прохладные отношения с асинхронностью. Команда и взаимодействие внутри её Многие программисты любят работать одни. Некоторые начальники не любят, когда их работники особенно активно взаимодействуют. По ровной ли мы идём дорожке или по кочкам, по кочкам?🤔
Предлагаю проснуться, улыбнуться и выискать стихи в недрах треда. twitter.com/itunderhood/st…
@itunderhood Официально software kanban (aka kanban method) был описан в kanban от David Anderson в 2010 и являлся карго-культ копией из практик JIT и приоретизированной доски из Lean (heijunka box)
Спасибо огромное! twitter.com/twilightsign/s…
Вопрос, на который я пока не нашёл ответ. Откуда пошла канбан-доска в той форме, в которой мы используем её в разработке? Сама идея идёт из производственной системы «Тойоты», но там это сильно другое.🤔
Ещё один такой вопрос. Когда компьютер полностью занят обработкой запросов и место в очереди запросов закончилось, но новые всё приходят, то куда они деваются на физическом уровне? twitter.com/itunderhood/st…
@itunderhood Хотелось бы дополнит. Если не понимаешь скоуп, не всегда лучшее решение включаться, даже за большие бефы. Деньги получить легко, а вот если логика потеряется, то уже пенсия
Не смотрел под таким углом, спасибо! twitter.com/mihmihwuk/stat…
Сегодня будет последний на этой неделе крупный тред, а в выходные уже разного рода развлечения и небольшие треды.
31-го числа не совсем разумно писать закрученные простыни, но дело пошло, не могу остановиться!
Причины прекращения кодирования
Сейчас я не пишу код. В команде и так 12 FE-разработчиков помимо меня, так что заниматься требуется менеджерскими активностями. Расстраивает ли меня это? Нисколько, и дальше я объясню, почему.
В своё время, желая писать качественный код, я прошёлся по соответствующей литературе. Были там и известные книги вроде «Чистого кода» или «Паттернов проектирования». Были и малоизвестные: Bad Programming Practices 101, Refactoring for Software Design Smells и другие.
Всего на тему качественного написания кода я прочитал около 12 книг. Это не считая того, что относится к конкретным языкам программирования. То есть знаменитые JavaScript: The Good Parts сюда не входят. Казалось бы, Герман, сиди да радуйся, в чём твоя проблема?
Проблема в том, что, несмотря на множество прочитанного и желание его применять, возможности делать это масштабно совершенно нет. Хорошо, наведу я порядок в этих 20 относящихся к задаче файлах, а дальше что? Во-первых, в остальной 1000 и нет этого порядка, а, во-вторых...
...оттого, что порядок случился где-то локально, совсем не следует автоматическое принятие этого порядка командой и системой. То есть дальше никто, кроме меня ничего подобного делать не будет. Если вы на этом моменте уже собрались дать отпор этим двум проблемам, то не спешите.
Есть проблема покрупнее, чем две упомянутых. Значительно крупнее, я бы сказал. Заключается она в том, что, как бы мне и многим из нас того не хотелось, истинно правильного и единственного способа программировать нет. Нет и полностью неправильного.
Если вы не согласны с моим способом программирования, то мне вам и сказать-то нечего. Приходится выходить из мира кода и вести торг в других областях. Однако, это не значит, что ничего поделать совсем нельзя.
Как команда мы можем начать вырабатывать свои подходы. Наше время ещё хорошо и тем, что есть и подходы по умолчанию, выложенные в интернете в виде линтеров и форматтеров. Они не покрывают уж очень существенных вещей, но можно не беспокоиться о всякой мелочи.
А как вырабатывать эти подходы? Тут нам на помощь придут качественные характеристики систем. Помните любимые многими производительность, адаптивность, устойчивость к падениям и прочее? Не только запущенное программное обеспечение может обладать характеристиками.
Система исходного кода может обладать и своими собственными. Сюда относится и почти эзотерическая читаемость, обнаруживаемость, доступность для поиска. Всё это пока пустой звук, но подумайте, как обстоят дела с доступностью для поиска у Git-репозитория ОС Windows?
Эта мономегарепка уже в 2017-м году весила 270 GB, отчего Microsoft потребовалось разработать технологию виртуализации GVFS. Идея в том, что файлы скачиваются только по прямому требованию, а не в момент клонирования. А так они висят как заглушки в десктопном UI облаков.
Сразу оговорюсь, что я пока в начале своего большого исследовательского пути в организации процесса разработки ПО и могу перегибать палку или ошибаться. Поправляйте меня, если знаете предмет лучше.
Итак, как же нам наделить сутью эти качественные характеристики? Ответ мы найдём в рукописях слегка древних людей: статистиков Уолтера Шухарта и Уильяма Деминга. Первого я не читал, но с удовольствием сейчас изучаю труды и наследие второго. Нам нужны операциональные определения.
Это что за чертовщина!? Это определения, выраженные в терминах операций. Что такое мытая картошка? Возьмите картошку, подставьте её под струю тёплой воды и счищайте грязь металлической губкой до тех пор, пока её не останется. Результат этих действий и есть мытая картошка.
А как же мы можем определить в терминах операций читаемость? Мы можем сказать, что файл, пропущенный через форматтер, считается в нашей команде читаемым. Если этого будет мало, то можно добавить дополнительную операцию обработки и учитывать её в определении.
Есть ли у нас какое-нибудь подспорье для операционных определений? Да, автоматизированное тестирование. «Что в нашей компании «работающий продукт»?» «Продукт, успешно проходящий все виды автоматизированного тестирования, запускающиеся в нашем CI, и собирающийся без ошибок».
Как вы уже могли заметить, команде нужно постоянно что-то вырабатывать. Я могу войти традиционно: «тимлид — это самый умный разработчик,» и сказать всем, что нужно делать, но рабочая ли это схема? Мне видится, что нет. Беспрекословное подчинение — не свойство нашей профессии.
Итак, если я не кодирую, то как же я могу повлиять на качество кода? Через изменение окружающей среды. Эдакая командная урбанистика. Часто разработчикам предлагают поднапрячься и превозмочь, но делать это, скорее всего, нужно не вам. Вы и так уже делаете зависящее от вас.
Мы снова послушаем дедушку Деминга, и он скажет нам, что не более 6% всех проблем находятся в поле деятельности рядовых работников. А значит 94% всех проблем должны решаться менеджментом. И эти проблемы связаны с тем, что окружающая среда не поощряет качество.
Стоит ли вообще слушать дедушку Деминга? Это большой вопрос. Практически уже 72 года назад высший менеджмент одной разгромленной в войне страны решил послушать. Затем с 1968-го по 2010-й их страна была второй экономикой мира.
А что это за такая окружающая среда при разработке программного обеспечения? Во-первых, это сами задачки. Помните выражение «мусор на входе — мусор на выходе»? Это справедливо и для нас как для системы, разрабатывающей ПО.
Если хотите посмотреть на забавную иллюстрацию этого, то рекомендую видео с экспериментом с красными и белыми бусинами. В нём работников «мотивируют» как можно лучше вынимать белые бусины и избегать красных. «Нормально делай — нормально будет».
youtube.com/watch?v=ckBfbv…
Путём этих размышлений мы пришли к тому, что без совместной работы троих людей над одной задачей её решение будет вопиюще неполным. А может ли решение быть полным? Нет, таковым оно быть не может. А может ли быть полным в достаточной степени? Да, такое возможно.
Правда, сразу хочется отметить, что здесь не всё так просто, вчера я уже писал об этом.
twitter.com/itunderhood/st…
А прочее — это уже действительно то, что нас окружает. Начиная с рабочего места, продолжая тем, как удобно взаимодействовать с разрабатываемым приложением в принципе. Можно ли запустить его локально? Как много времени занимает сборка? А что насчёт встреч?
Мы без конца проклинаем стендапы, и, разумеется, за дело. Формат «Что сделал?», «Что сделаю?», «Что меня блокирует?» фокусируется на ложных вещах, но такой формат очень подходит для проверки здоровья.
Они тоже являются окружающей средой. Помните я писал, что популярный формат стендапа фокусируется на ложных вещах? Давайте посмотрим подробнее. На чём фокусируются вопросы «Что сделал?», «Что сделаю?», «Что меня блокирует?»?
twitter.com/itunderhood/st…
Они фокусируются на занятости работника, а не на задачах. Что интересно сделать бизнесу при разработке новой функциональности? Выпустить её как можно скорее, выяснить, подходит ли она пользователям. Но тогда и фокусироваться надо на задачах, а не занятости работников.
Формат стендапа, в котором осуществляется проход по всем задачам и используется вопрос «что нам необходимо сделать, чтобы перевести задачу на следующий этап?» мне кажется куда более соответствующим этой цели. То есть даже вопрос — уже окружающая среда.
А что за известный специалист занимался в своё время вопросами балансирования сквозного прохода через всю организацию? Элияху Голдратт со своей теорией ограничений. Но применимы ли его идеи к нам? Да, на его идеях построена идея DevOps, и описано это в книге «Проект Феникс».
Полный хохотач в этом вопросе случается со мной по той причине, что в индустрию из DevOps'а утекла только непрерывная интеграция, которая была описана ещё в 1999-м году в «Экстремальном программировании» Кента Бека. А может, и того раньше в неизвестном мне источнике.
Если подводить итог под тем, что мне кажется необходимой деятельностью лида, то это будет выстраивание среды, способствующей качественной разработке программного обеспечения. И если давать этому более подходящий термин, то вместо «руководителя» я предлагаю «средоустроителя».
Тред (Герман Тебиев)
Фух, ну всё, большие треды написаны, мне было нелегко, но я справился.😄 В оставшиеся два дня всякие потешные дела, отмечание нового года и небольшой тред об обращении с книгами напоследок.
Во сколько завтра выкладывать потешную алгоритмическую задачку?
🤔
37.5% ~ 9:00🤔
15.9% ~ 12:00🤔
16.8% ~ 15:00🤔
29.7% ~ 18:00Суббота
С Новым годом всех читающих! Желаю вам в новом году более наукоёмких методов работы и хороших команд!🥳
Как-то раз в одной книжке наткнулся на фамилию Соловей (Soloway), и подумал, что это клёвая фамилия. Книга была про компьютеры, так что замечание легально в этом аккаунте.🙂
@itunderhood По моим наблюдениям, тимлид это чистилище для дальнейшего развития. С фин. точки зрения разница не велика, в сравнении с помидорами. А вот хотелок от менеджмента сверху гораздо больше. Хорошо, когда ты не пишешь код. Но вопрос дальнейшего развития остается открытым. Что дальше?
Хорошие рассуждения на тему реалий, с которыми приходится сталкиваться. twitter.com/a250188/status…
Потешная алгоритмическая задача
Два года назад я выборочно читал книгу «Грокаем алгоритмы». Тогда я подумал, что понятие алгоритмической сложности оперирует достаточно ограниченным набором O(.): O(1), O(n), O(lg2n), O(n^2), ...
Но есть же и другие математические операции!
Мои ответы следующие: У человека значительная часть головы отвечает за восприятие визуальных образов. Отсутствие таковых из коробки в программировании сильно сокращает наши мощности. twitter.com/itunderhood/st…
Недавно я тут вещал на тему сложностей в программировании из-за отсутствия визуализации. Мне кажется, что алгоритмическая сложность также пала жертвой этого вопроса. Что такое алгоритмическая сложность? Это мерило необходимой работы.
twitter.com/itunderhood/st…
Если вам нужно перетащить 5 больших коробок из одного места в другое, и за раз вы можете перетащить только одну, то сколько походов нужно осуществить? Пять. А если коробок n, то походов в этом упрощённом примере нужно n. Значит, алгоритмическая сложность таскания коробок — O(n).
Итак, задачка. У нас есть квадратный лист бумаги, и мы его расчерчиванием на равные квадраты. Расчерчиваем, проводя прямые линии. Ничего не нарисовали, получили 1 большой квадрат. Нарисовали две линии — получили 4, нарисовали четыре линии — получили 9. Работа — рисование линий.
Какова алгоритмическая сложность расчерчивания листа на n квадратов? Тут стоит отметить, что n в этой задаче не может быть любым целым числом, может быть только квадратом: 1, 4, 9, 16, 25, и так далее.
По мере поступления решений, я буду усложнять задачу.
Тред (Герман Тебиев)
@itunderhood Про гиперболическую сложность все знают? Которая О(1/(L-n))
Я не знаю, расскажите, интересно! twitter.com/amaslyaev/stat…
Баран. Какое отношение это слово имеет к человеку, первым предложившему реализацию интернета?
Воскресенье
@itunderhood @lisyarus @0xfe0d Если совсем на пальцах, О-нотация нужна для оценки скорости роста времени при росте количества значений. Чтобы быть более-менее уверенным, что когда вместо 10 элементов, функция столкнется с 10М, код не взорвется. В математике самый близкий аналог — первая производная.
Алексей привёл хорошее объяснение понятия алгоритмической сложности, которое заставило меня усомниться в собственном понимании. twitter.com/mudasobwa/stat…
@itunderhood @lisyarus В треде происходит подмена понятий асимптотической сложности и числа операций, хотя обычно их в отрыве друг от друга и не рассматривают. Кроме прочего, если говорить о скорости работы с учётом времени, то...
Ещё одно хорошее замечание на тему некорректности постановки вчерашней задачи про расчерчивание листа. twitter.com/0xfe0d/status/…
@itunderhood Не так мерило необходимой работы как мерило скорости прироста работы с ростом обьема задачи
Стоит также упомянуть, что вчера мне об этом писали. twitter.com/kotia/status/1…
@itunderhood @MontlyPayment Ну вообще-то большая О это именно про "асимптотически сходится при N стремящемся к бесконечности". То есть если реальная сложность ≥ O(an) и ≤ O(bn), то это O(n). В Introduction to algorithms Cormen'а очень доходчиво. А также про всякие омега нотации
Также рекомендую прочитать эту ветку с замечаниями про алгоритмическую сложность от @simonovvasiliy и @dimonb. twitter.com/simonovvasiliy…
Вопрос в зал. Хочу поделиться ссылкой на песню так, чтобы она предлагала выбрать из основных для наших мест музыкальных платформ. Яндекс.Музыку, Spotify, Apple Music, возможно, VK. Есть ли такой сервис? Я пока только для иностранных стримингов нашёл.
Пользуясь тем, что аудитория вопросов большая, хочу спросить такую штуку. Лет 8 назад я читал начальные книги по типографике, и где-то наткнулся на выражение: «Типографика — искусство расстановки пробелов». Было ли такое где-то или у меня ложное воспоминание?
Немного о неизвестной музыке
Мне видится, что мы живём в мире, где предложение хорошей музыки так велико, что спрос едва справляется с ним. Так я себе объясняю отсутствие того ощущения единения, которое музыка раньше давала. Вместо общих песен у нас теперь у каждого свои.
В этом треде я буду размещать песни, которые мне нравятся, но с одним условием: я сконцетрируюсь на малоизвестных артистах. Поехали!
Группа «Дунаевский Orchestra». 63 слушателя Spotify.
С ней я познакомился технично: написал скрипт, который добавляет в мои аудиозаписи VK все песни участников не помню уже какого конкурса для дальнейшего прослушивания. Срели 400 не самых приятных для меня песен нашлись они.
Я тогда очень тосковал по какому-то свежему взгляду в русскоязычной музыке, и с некоторым трением они попали в критерии приёмки. Но от альбома к альбому существенно росли.
Название этой песни хорошо подходит для Твиттера: «Кто такой Олег?».
song.link/s/6rlOsW8cd3A5…
Группа «Шкловский». 556 слушателей Spotify.
Если кто-нибудь спросит у меня, какая у этой группы лучшая песня, то я отвечу: «все». А вам рекомендую песню «Бассейн», у неё просто космический конец, рекомендую слушать в наушниках.
song.link/s/41PAsQJ4pee0…
Группа «Гражданин Топинамбур». 771 слушатель Spotify.
Что сказать?! Талантливые ребята, песня приятная, самое то для зимы.
song.link/s/1zVJiB4tJNlL…
Группа Z Is for Xylophone. 832 слушателя Spotify.
Первая англоязычная песня в подборке. Если нужно песней выразить ярость без криков, то пожалуйста.
song.link/s/0OhwDKIKisjX…
Целых два исполнителя! Псой Короленко и группа «Опа!». 143 слушателя Spotify.
Остаётся только плакать, что последние совместные записи вышли в далёком 2010-м году! Ураганная песня про петуха Петьку. Тренирует выдержку.
song.link/s/7588rtlCNCql…
Исполнительница Charusha. 1916 слушателей Spotify.
Создательница саундтрека к фильму «Хардкор». Если вы не знаете, какую песню петь после «Знаешь ли ты» певицы Макsим, то вот вам подсказка.
song.link/s/02Hm8fOEzUnv…
Великие мастера слова «Есть Есть Есть». 2057 слушателей Spotify.
В один бар заходит утка в строительной каске...
song.link/s/2ErfXzxFOFV6…
Группа BerlinskiBeat. 2730 слушателей Spotify.
Что будет, если взять Corvus Corax и выдать им дудки? А вот это и будет, потому что этим и является.
song.link/s/5sBZ6FJCQx2v…
Группа A Hawk And A Hacksaw. 4989 слушателей Spotify.
Даже не знаю, что и сказать, будто в других местах и временах оказываешься.
song.link/s/0aR65GnQBwGa…
Группа Koza Mostra. 14031 слушатель Spotify.
Если для всего мира последняя интересная группа с «Евровидения» вышла в 1974-м году, то для меня в 2013-м. Правда черти так редко что-то выпускают, что зла на них нет!
song.link/s/5YpBEEbtn8Mn…
На этом всё! Надеюсь, что что-то по душе вам тут найдётся.🙂
Тред (Герман Тебиев)
Наткнулся на тред с разговорами об алгоритмической сложности, O-нотации и задачи. Там много путаницы, поэтому вот ликбез-тред 🧵 twitter.com/itunderhood/st…
Ликбез-тред, подробно объясняющий суть путаницы, которую я вчера внёс своей задачей, а также корректный способ взаимодействия с алгоритмической сложностью. twitter.com/_rbtsv/status/…
Так, у меня ещё один бонусный мини-тред заготовлен про систему работы с книжками.
🤔
80.8% Выкладывай, спесивец🤔
19.2% Себе оставь, гордецТак, у меня ещё один бонусный мини-тред заготовлен про систему работы с книжками.
Как я уже заявлял ранее, я тот ещё читальный шакал. В течение дня у меня зарезервировано 6 временных отрезков под книги. До 2020-го я практически не пользовался аудиокнигами, так что раньше их было меньше. twitter.com/itunderhood/st…
Каждый обучающийся рано или поздно сталкивается с тем, что материалы-то проходятся, а знания и навыки так и остаются лежать в них. Какие есть варианты преодоления этой проблемы? Обычно предлагается конспектирование и повторение.
Я пытался применять SQ3R, flashcards, но всё было не то. До недавнего времени у меня была система работы с книгами средней мощности, не стоило о ней и рассказывать бы, но в последние два месяца она получила значительное усиление, теперь можно.
В 2018-м году я использовал Твиттер @turbobureaucrat для того, чтобы публиковать туда клёвые вещи, о которых я читал. Формат не особенно зашёл, но где-то в то же время я устроил опрос авторов прочитанных мной книг об их литературных рекомендациях.
Одной из рекомендаций была занятная книга On Trails. Она рассказывает о тропах и том, как они рождались. К чему я это говорю? К тому, что часть свой системы я представляю как поляну, от которой в разные стороны расходятся тропы в книги.
Если уйти от метафоры, то это папка в облаке, в которой хранятся прочитанные книги. На компьютере стоит мощная программа по поиску в PDF. В случае необходимости моя голова даёт смутные подсказки, и я по ним ищу.
Эта часть достаточно результативна, но иногда нужно потратить время. Плюс, она больше подходит для вальяжной демонстрации эрудиции, чем для реальной работы. Вторая часть — это недавнее надстроение. Она позволяет ковать железо, не отходя от ликбеза.
Структура её нехитрая: в органайзере под применение книги заводится проект с разделами. Каждый раздел — это важная мысль книги. Также создаётся повторяющаяся задачка, указывающая пройтись по важным мыслям.
Если в момент перепрочтения заголовков разделов в голову приходит идея, то я её записываю. В следующий проход я наткнусь на неё снова и смогу перевести в уже конкретные действия.
Вот такой двухслойный пирог для более вероятного применения знаний.
Тред (Герман Тебиев)
@itunderhood Что думаешь по поводу zettelkasten, smart notes, evergreen notes и подобного?
Есть ли кто-нибудь, кто смог раскатать у себя одну из этих систем на полную катушку? Интересно послушать о вашем опыте. twitter.com/wrongshell/sta…
На этом всё, спасибо, что были со мной в двух годах! Спасибо тем, кто оставлял комментарии, лайкал и распространял. И даже тем, кто насовал мне в панаму, я желаю отличного 2022-го года!
С вами был Герман Тебиев: @terbiyarchitect и @turbobureaucrat.
song.link/s/2xXviSO2h7ju…
Отдельно хочу передать привет моей жене @Elizavetaveta, я тебя очень люблю!
Ещё раз спасибо @GlafiraZhur за рекомендацию меня сюда и @igrekde за такую прекрасную площадку для безраздельного недельного вещания.
А теперь цепи, которые не хочется терять!⛓
Всем привет! На этой неделе с вами Герман Тебиев @terbiyarchitect. Я работаю лидом front-end команды в @devexperts. Мой основной язык разработки — JavaScript & Co, а ещё я около полутора лет программирую на Clojure. За рекомендацию меня сюда большое спасибо @GlafiraZhur!
Описание недели.
twitter.com/itunderhood/st…
Мой путь в разработке ПО. Здесь мне хочется больше рассказать о становлении мышления, чем о конкретных происшествиях. Я люблю размышлять о всяком, так что будут отсылки к популярной культуре, не пугайтесь!
Так вот я какой человек, с флегмцой.
twitter.com/itunderhood/st…
Не постесняюсь и вынесу повыше ссылки на статьи, упомянутые в одной из веток. Дедовский метод дебаггинга. twitter.com/itunderhood/st…
Парочка статей о нехитрых методах.
twitter.com/itunderhood/st…
Небольшое предисловие перед планирующимся тредом о языках программирования и другими. Я не считаю своё мнение по этому вопросу окончательным и с удовольствием познакомлюсь с вашими. Я замечаю, что люди иногда настолько дорожат своим мнением, что соглашаются на одиночество.
О мнениях и ошибках.
twitter.com/itunderhood/st…
О языках программирования вообще и Clojure в частности Я не очень много читал об архитектуре программного обеспечения, всего 3 книги, но послушал про неё много подкастов, пока гулял с новорождённой дочерью.
Языки программирования и Clojure.
twitter.com/itunderhood/st…
Перед тем, как перейти к обещанной теме дня, личной продуктивности, ещё немного поразмышляю о полезности публикаций статей, похвалю HTML и CSS, да и сам немного похвастаюсь.
Статьи, HTML и CSS.
twitter.com/itunderhood/st…
Личная продуктивность Это интересная тема. С одной стороны, я бы порекомендовал каждому что-то изучить по ней. С другой стороны, в приличном обществе говорить о таком не принято. Кому нравится смотреть на этих нервных людей, лихорадочно что-то учитывающих?!
Личная продуктивность.
twitter.com/itunderhood/st…
Мои ответы следующие: У человека значительная часть головы отвечает за восприятие визуальных образов. Отсутствие таковых из коробки в программировании сильно сокращает наши мощности. twitter.com/itunderhood/st…
Принципиальная сложность программирования.
twitter.com/itunderhood/st…
Рабочий день разработчика Приходите вы в офис или переползаете с кровати на компьютерный стул. Что дальше?
Рабочий день разработчика.
twitter.com/itunderhood/st…
Итак, углубимся в парадокс, при котором есть только рассеянность и нет собранности, хочется избавиться от рассеянности, но для этого нужна собранность. Если бы мы рассуждали в мире логики, то эта задачка была бы неразрешима, но мы сейчас не в таком идеализированном мире. twitter.com/softskillpump/…
Про собранность.
twitter.com/itunderhood/st…
Прохладные отношения с асинхронностью. Команда и взаимодействие внутри её Многие программисты любят работать одни. Некоторые начальники не любят, когда их работники особенно активно взаимодействуют. По ровной ли мы идём дорожке или по кочкам, по кочкам?🤔
О социальной составляющей программирования.
twitter.com/itunderhood/st…
Причины прекращения кодирования Сейчас я не пишу код. В команде и так 12 FE-разработчиков помимо меня, так что заниматься требуется менеджерскими активностями. Расстраивает ли меня это? Нисколько, и дальше я объясню, почему.
Причины прекращения кодирования.
twitter.com/itunderhood/st…
Потешная алгоритмическая задача Два года назад я выборочно читал книгу «Грокаем алгоритмы». Тогда я подумал, что понятие алгоритмической сложности оперирует достаточно ограниченным набором O(.): O(1), O(n), O(lg2n), O(n^2), ... Но есть же и другие математические операции!
Ошибочно поставленная потешная алгоритмическая задача.
twitter.com/itunderhood/st…
@itunderhood @lisyarus @0xfe0d Если совсем на пальцах, О-нотация нужна для оценки скорости роста времени при росте количества значений. Чтобы быть более-менее уверенным, что когда вместо 10 элементов, функция столкнется с 10М, код не взорвется. В математике самый близкий аналог — первая производная.
Объяснение O-нотации и других интересных моментов от @mudasobwa.
twitter.com/mudasobwa/stat…
@itunderhood @lisyarus В треде происходит подмена понятий асимптотической сложности и числа операций, хотя обычно их в отрыве друг от друга и не рассматривают. Кроме прочего, если говорить о скорости работы с учётом времени, то...
Объяснение подмены понятий в задачке от @0xfe0d.
twitter.com/0xfe0d/status/…
@itunderhood @MontlyPayment Ну вообще-то большая О это именно про "асимптотически сходится при N стремящемся к бесконечности". То есть если реальная сложность ≥ O(an) и ≤ O(bn), то это O(n). В Introduction to algorithms Cormen'а очень доходчиво. А также про всякие омега нотации
Хорошие замечания на тему O-нотации от @simonovvasiliy, @dimonb и @aovlllo.
twitter.com/simonovvasiliy…
Наткнулся на тред с разговорами об алгоритмической сложности, O-нотации и задачи. Там много путаницы, поэтому вот ликбез-тред 🧵 twitter.com/itunderhood/st…
Подробный тред с математическим описанием тонкостей O-нотации от @_rbtsv. Его ретвитнули многие признанные специалисты.
twitter.com/_rbtsv/status/…
Немного о неизвестной музыке Мне видится, что мы живём в мире, где предложение хорошей музыки так велико, что спрос едва справляется с ним. Так я себе объясняю отсутствие того ощущения единения, которое музыка раньше давала. Вместо общих песен у нас теперь у каждого свои.
Немного о неизвестной музыке.
twitter.com/itunderhood/st…
Как я уже заявлял ранее, я тот ещё читальный шакал. В течение дня у меня зарезервировано 6 временных отрезков под книги. До 2020-го я практически не пользовался аудиокнигами, так что раньше их было меньше. pic.twitter.com/yC9jA4qQP5 twitter.com/itunderhood/st…
Метод практического применения книг.
twitter.com/itunderhood/st…
С наступившим 2022-м годом!
Тред (Герман Тебиев)
