Мне очень нравится Swan — Practical English Usage. Если конкретно про запятые — там приведено 11 случаев, когда их нужно использовать. И в целом весь учебник — кладезь полезной информации. Его можно использовать и для прояснения конкретных моментов, и для прочтения подряд просто для повышения знания языка (но это может выйти не очень эффективно)
Когда все merge request'ы маленькие (а с помощью feature toggles этого можно достичь), то такой подход действительно интересен. Хотя частые переключения ведут к более частой смене контекста, и такое жонглирование может привести к снижению концентрации в течение рабочего дня и повышению усталости в конце его. Впрочем, это индивидуально и необязательно.
Про парное программирование — как-то взаимодействовал с командой из ThoughtWorks, широко использующей практики XP. У них, кстати, Martin Fowler работает. Сам работал в парном режиме с ними; видел, как они друг с другом работает. И сделал такой вывод: если у людей высокая квалификация и они умеют применять парное программирование правильно, то это прям эффективная техника. Иначе это может свестись к тому, что навигатор тупо сидит в телефоне, а драйвер всё молча делает сам, и тогда только вред от такого применения техники.
А долгое время жизни pull request'ов — это боль, да. Особенно, если потом ещё есть дополнительный шаг в виде manual QA check, который становится боттлнеком, если тестировщиков не хватает.
Я сильно привык писать комментарии на английском, и сначала внутренне не согласился, но поразмышлял — и да, это может быть оправдано во многих случаях. Общение на родном языке эффективнее, а на английский переходят для того, чтобы не было проблем при превращении команды в интернациональную.
Но если комментарии в коде, внутренние вики (confluence, jira) и документация имеют долгосрочную ценность, то комментарии при ревью обычно сиюминутны и к ним (по крайней мере, в моей практике) почти не нужно обращаться в будущем. Конечно, бывают важные обсуждения и решения при ревью, но я предпочитаю сводку таких дискуссий переносить в таск-трекер или комментарий в коде.
Авторский. Это перевод моей же статьи, но изначально опубликованной на английском. Хотел поделиться размышлениями и с хабрасообществом.
Спасибо за тёплый фидбек!
У знакомого мама умерла от общего наркоза. Эффект на организм гораздо сильнее, и выше вероятность, что что-то пойдёт не так.
P.S. извините, если вы теперь ещё и общего наркоза будете бояться.
«Джедайские техники» Максима Дорофеева. Проверил предыдущие подборки, там не было. Показывается, как перестать забывать про разные мелкие задачи, экономить нервы и концентрацию (тем самым меньше уставать), принимать более качественные решения ну и попутно достигать целей, которых всегда хотелось достичь, но как-то недосуг.
Для меня главным принципом стала фраза «что не записано, то продолбано». Запись всех задач в trello разгружает голову и одновременно не позволяет про что-либо забыть. Лично мне ещё хорошо зашла идея делать задачи из того, что нужно поставить на контроль, подсмотренная в постеnmivan.
А, ещё одна из самых классных книг, которые я читал: «Пиши, сокращай» Ильяхова и Сарычевой. Про написание интересных и полезных текстов с заботой о читателе.
Я сначала задумывался о специальном кресле, но в качестве временного решения (которое стремится стать постоянным, к сожалению), остановился на IKEA ÖRFJÄLL, обычное, не особо-то и рабочее по назначению.
Спасибо. Реквестирую очередную статью :)
Выбор индивидуален, но параметры, которые стоит учитывать при выборе, и их важность (или даже существование таких параметров) приходят с опытом использования.
1. Из скольки строк кода состоят внутренности Хабра, какое тестовое покрытие?
2. Битва подушками всем офисом или поход в кино?
3. Обидно ли, что большая часть комментариев в Прямой линии — багрепорты/фичереквесты, хотя есть служба поддержки?
4. Как попадают в команду новые люди (и попадают ли)?
5. Как праздновали релиз англоязычной версии?
6. Делали ли когда-нибудь торт с надписью «Хабр — торт»?
Вы лукавите. Нанимая профессионального ПМа, вы никаким образом не можете получить полную гарантию того, что проект будет сдан в срок. Максимум — увеличить эту вероятность.
Спустя полтора года после Ложной слепоты решил взяться за Rifters того же Уоттса. Потрясающая трилогия! Глубокая проработка мира: после каждой книги целая глава ссылок на научные журналы и публицистические статьи, лёгшие в основу тех или иных деталей. Живой язык, яркие герои, захватывающий сюжет — было жалко дочитывать, хотелось растянуть удовольствие.
Они практически не используются в повседневных текстах, поэтому дополнительно привлекают к себе внимание.
Кроме того, на сайтах в квадратные скобки часто выделяют теги (скорее всего, как раз из-за того, что они редко используются). Поэтому внедрение квадратных скобок внутрь заголовка может действовать как мимикрия под родной интерфейс сервиса.
На мой взгляд, это неуважение к читателям. За три дня можно забыть, о чем была первая часть, особенно детали. Придётся перечитывать, тратить (снова) время.
Про парное программирование — как-то взаимодействовал с командой из ThoughtWorks, широко использующей практики XP. У них, кстати, Martin Fowler работает. Сам работал в парном режиме с ними; видел, как они друг с другом работает. И сделал такой вывод: если у людей высокая квалификация и они умеют применять парное программирование правильно, то это прям эффективная техника. Иначе это может свестись к тому, что навигатор тупо сидит в телефоне, а драйвер всё молча делает сам, и тогда только вред от такого применения техники.
А долгое время жизни pull request'ов — это боль, да. Особенно, если потом ещё есть дополнительный шаг в виде manual QA check, который становится боттлнеком, если тестировщиков не хватает.
Но если комментарии в коде, внутренние вики (confluence, jira) и документация имеют долгосрочную ценность, то комментарии при ревью обычно сиюминутны и к ним (по крайней мере, в моей практике) почти не нужно обращаться в будущем. Конечно, бывают важные обсуждения и решения при ревью, но я предпочитаю сводку таких дискуссий переносить в таск-трекер или комментарий в коде.
Спасибо за тёплый фидбек!
P.S. извините, если вы теперь ещё и общего наркоза будете бояться.
Для меня главным принципом стала фраза «что не записано, то продолбано». Запись всех задач в trello разгружает голову и одновременно не позволяет про что-либо забыть. Лично мне ещё хорошо зашла идея делать задачи из того, что нужно поставить на контроль, подсмотренная в посте nmivan.
А, ещё одна из самых классных книг, которые я читал: «Пиши, сокращай» Ильяхова и Сарычевой. Про написание интересных и полезных текстов с заботой о читателе.
Выбор индивидуален, но параметры, которые стоит учитывать при выборе, и их важность (или даже существование таких параметров) приходят с опытом использования.
А какое у вас рабочее кресло, если не секрет? Уделяли ли специальное внимание вопросу эргономике при работе из дома?
2. Битва подушками всем офисом или поход в кино?
3. Обидно ли, что большая часть комментариев в Прямой линии — багрепорты/фичереквесты, хотя есть служба поддержки?
4. Как попадают в команду новые люди (и попадают ли)?
5. Как праздновали релиз англоязычной версии?
6. Делали ли когда-нибудь торт с надписью «Хабр — торт»?
Вы лукавите. Нанимая профессионального ПМа, вы никаким образом не можете получить полную гарантию того, что проект будет сдан в срок. Максимум — увеличить эту вероятность.
Кроме того, на сайтах в квадратные скобки часто выделяют теги (скорее всего, как раз из-за того, что они редко используются). Поэтому внедрение квадратных скобок внутрь заголовка может действовать как мимикрия под родной интерфейс сервиса.
Вот красиво сделано, и написано живо, но за квадратные скобки в заголовке хотелось минус влепить неимоверно. Но слишком классный макет.
Это безумно интересно! Неожиданное и изящное применение мат.аппарата.