Posts

TLDR: Я считаю, что на проекте за качество ответственны только разработчики, значит они должны думать больше о качестве, чем о бизнес-ценности. Но есть нюанс. Disclaimer: под термином “разработчики” в посте я имею в виду и программистов, и тестировщиков. Code quality Разработчики должны понимать, что деньги для них берутся не из тумбочки, но и проект вряд ли будет приносить деньги, если стабильность оставляет желать лучшего. В интернете масса статей, где пишут, что нужно соблюдать баланс между качеством и скоростью доставки на продакшн, но такой совет звучит как “варить суп до готовности” - непонятно, как искать этот баланс. ...

Disclaimer: Советы ниже - вредные, доверять им не стоит. Антипаттерны придуманы не мной. В статье я стараюсь дать примеры, на которых будет видно, почему такие подходы и назвали антипаттернами Код юнит-тестов - это не second-class код, его тоже нужно писать поддерживаемым, читаемым и понятным для остальных ребят в команде. Курсивом - вредный совет, обычным шрифтов - пояснение. 0. Кукушка (Cuckoo, aka Stranger) Твой класс делает запросы к внешним системам? Отлично, проверь и вызовы тоже вместе с выходными данными. Кому хуже будет? ...

Картинка взята отсюда Очевидные вещи нужно проговаривать Так говорил мой тимлид, закончивший юрфак, но ушедший в айти. Говорил он так о процессах разработки: свод правил, по которым работает команда. Этакий кодекс программиста отдела N. Этот свод правил должен быть публичным и каждый должен знать, где его прочесть. Но зачем нужно описывать то, что и так всем известно? Давайте обсудим. Правила работы в команде есть всегда, даже если они нигде не описаны и никем не проговорены. Так складывается исторически, что Ваня лучше знает платежи, Петя - как настроить тестовое окружение, а Юля - что делать, если нашел баг. И тот, кто уходит в отпуск, начинает получать сообщения в мессенджеры: “сорри что пишу, но …..”. В такой среде легко допустить ошибку, особенно новичкам. Еще хуже, когда даже не знаешь, кого можно спросить в критичный момент. ...

Этот текст - шпаргалка по книге “Говори красиво. Выступай легко” от Нины Зверевой и Светланы Иконниковой. Я считаю, что книга очень полезная, но в ней много информации, которую легко забыть. Поэтому я решил сделать шпаргалку, чтобы в будущем можно было быстро вспомнить основные моменты. Часть 1. Сторителинг В любой истории есть герой. Во время истории с ним что-то случается, причем неожиданно. Плохое, хорошее, веселое, трагическое - любое. Нельзя Можно Рассказывать истории долго Уложить историю в 1-2 минуты Ничего не сообщить о герое - какой он, чего хочет, как выглядит В начале истории презентовать главного героя В самом начале рассказать концовку Держать интригу 10 инструментов рассказчика: Внятная речь Интонация Ваши глаза. Поглядывай по 2 сек на зрителей в разных частях ацдитории. Слова в начале истории. Как-то нужно зацепить слушателя. Тайминг. История - не более трех минут. Сдержанные эмоции. Рассказываешь анекдто - будь невозмутим. Паузы. Не будь монотонным. Картинки и фотографии. Юмор. Шути над собой, люди сильнее уважают тех, кто над собой смеется, чем тех, кого распирает от чсв. Метафоры. Части истории: Вступление. Описываем героя. Описываем быт героя, чем он живет. Что-то происходит, что влияет на жизнь героя. Возникла проблема или опасность. Подробно рассказываем, что чувствует герой. Как весь мир рухнул, как стало плохо жить. Герой собирается с духом, делает нечто для исправления ситуации. Итог. Герой пожинает лавры, возвращается к привычному. Быстро проходимся по пунктам 1-3, затем долго рассказываем о переживаниях в пункте 4, затем быстро идем по пунктам 5 и 6. ...

Why do you need to increase the version of the nuget package? When you push a new nuget package to nuget.org, you need to increase the version of the package. Otherwise, you will get an error. I will show you how to do it automatically with Github Actions. As an example, I will use my nuget package MaximGorbatyuk.DatabaseSqlEndpoints. TL;DR You need github.run_number variable to increase the version, The release.yml file as example for you, Code example - MaximGorbatyuk.DatabaseSqlEndpoints. Workflow Usually, I use the following workflow: ...

Disclaimer У меня есть опыт руководства командой, которая находилась в одной локации. Советы актуальны и для распределенных команд, однако для них стоит учесть разные таймзоны. Когда я пишу “разработчики”, я имею в виду не только программистов, но и тестировщиков, аналитиков, дизайнеров и всех, кто выполняет задачи бизнеса и помогает строить продукт. 1. Ты - не разработчик Время, когда можно было несколько часов подряд кодить, закончилось. Теперь твоя личка в распоряжении ПМа, продакта, бизнес-аналитика, тестировщиков и разработчиков. У тимлида всегда хотят что-то узнать, посоветоваться с ним, согласовать решение, пожаловаться на товарища. Молодому тимлиду нужно быть готовым к этому и расставлять приоритет. ...

Тайм менеджмент Тайм-менеджмент - дело одновременно сложное и простое: с одной стороны - делай все вовремя, но с другой - почему же с тайм-менеджментом у многих беда? Вроде занимаешься какими-то делами в течение дня, под вечер устаешь, а перед сном вдруг понимаешь, что не успел сделать еще кучу дел. Решаешь завтра обязательно сделать все, что нужно, но и следующим вечером понимаешь, что снова ничего не успел. Давайте разбираться в чем причины и как с этим быть. ...

Как часто стоит менять проекты? Какой период времени смены работы можно считать некой нормой? На эти рассуждения меня натолкнуло обуждение в одном из чатов разработчиков. Вопрос действительно интересный. Disclaimer Все данные в статье являются моими личными оценками и не являются истиной в последней инстанции. Смена проетка - не всегда смена работодателя. А иногда даже и новая роль на том же проекте. TL;DR: Адекватные сроки: Грейд/роль Срок Джун 0.5 - 1 год Миддл 1 - 2 года Сеньор / лид 2 - 3 года Тимлид 2+ лет ПМ 2+ лет Но это не точно. ...

Открытые зарплатные вилки – это когда каждый миддл знает, сколько зарабатывают миддлы и другие грейды в той компании, где он работает. Условно говоря, получает специалист 1500$, но он знает, что вилка его уровня составляет от 1200$ до 2000$. Но просто взять и рассказать всем про деньги, которые они могут получать, нельзя. Мало знать возможности, нужно еще и понимать, как достигнуть ее. Для того, чтобы работники знали путь достижения нового грейда, компании нужно привести в порядок бизнес-процессы. ...

Каждый из нас так или иначе сталкивается с техническими собеседованиями: кто-то их проходит, а кто-то - проводит. И каждый вспомнит удачные и неудачные примеры из своего опыта. Чтобы интервью прошло с пользой для всех его участников, стоит придерживаться набора шаблонов и паттернов. Тогда разговор не пойдет на самотек и собеседование будет успешным. В статье я расскажу о том, что стоит делать интервьюеру и чего делать не стоит ни в коем случае. ...