А ребятки тут замутили чятик где координируются офлайн сходки в питере. И уже завтра планируем сходку в севкабеле. Есть шанс высказать тупице что он неправ лично.  https://t.me/joinchat/FbNp8gjbS700Y2Vi Приходите 🙂

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

Что все может быть и правда, но вопрос-то не об этом. Код почему хреновый?

Джунско-Сеньорный разговорник

Я тут подумал, ребятки стараются, учатся и выходят на первую работу и начинают страдать от того что не понимают многих слов. Пилю вам разговорник. Тред.

1. Фоллоуапить - (от англ. follow up)  написать письмо с инфой о решении или статусе. Пример: Я как закончу таск тебе отфолоуаплю в почту/слек.
2. Репа - репозиторий исходного кода, как стандарт сейчас гит, но могут быть вариации; не путать с паттерном репозиторий - он говно и ненужен
3. Пушить в репу - залить свои изменения в репозиторий. Стандартная отмазка на дейлике - я все сделал, сейчас дотестирую и запушу в репу.
4. Дейлик или стендап - ежедневная планерка. Обычно на 10-15 минут, у хуевых менеджеров может быть по часу. У заебатых менеджеров дейликов нет.
5. Митинг (от англ. meeting) - встреча для обсуждения чего-либо. Сейчас обычно в зуме. (тащ майор это не тот митинг)
6. Создать митинг - прислать приглашение в почту. Пример: Нам надо обсудить вопросец - создай митинг на завтра плез.
7. Таск (иногда в женском роде - таска) - задача в багтрекере (обычно джира). Пример - я там взял себе таск, он простой.
8. Деливерить (от англ. delivery) может употребляться в разных контекстах, например - он не деливерит = плохо работает.
9. Шиппить похоже на деливерить, но обычно относится только к доставке кода на стенд.
10. Деплоить - синоним шиппить. Например - задеплой свежую версию на стейджинг.
11. Оппортьюнити - (от англ opportunity) возможность. Часто используется епамскими. Пример - у нас новая оппортьюнити = у нас новый проект
12. Дженкинс (устаревшее) - система автоматизации сборки и доставки кода. Пример - опять дженкинс упал.
13. Репродусить - часто используется тестерами. Значение - воспроизвести, повторить. Пример - как мне зарепродусить тот хитрый баг?
14. Дев энв  (от слова environment) - окружение разработки. Например - можешь взять дев энв для тестов.
15. Стейджинг, прод - популярные энвы - прод обычно охраняется, стейджинг повторяет прод, но его можно ломать.  
16.  Сторипойнт - неведомая хуйня для измерения эстимейтов тасок. У каждого свое понимание как долог сторипойнт.
17. Эстимейт - ожидание, прогноз. Пример - там таск в джире видел? какие у тебя эстимейты? - за неделю сделаю.
18. Погрепать логи - использовать программу grep (поиск паттерна по текстовым файла) для поиска ошибок. Например grep -i error file.log. Устаревшее, иногда используется в контексте логов в Elasticsearch
19. Догфуддинг - использовать продукт который сам разрабатываешь. Не всегда доступно разработчикам с маленькой зарплатой (например разработчикам яндекса)

Сеньорность

Я устал слушать страдания про “нужно выучить X чтоб стать сеньорнее”.

Пост о том что сеньорность не меряется количеством знаний. Лайк, шер, погнали.

1. Бизнесу совершенно похуй сколько и чего вы знаете. Его интересует только одно - сможет ли он с твоей помощью поднять больше бабла.  То есть перефразируя - какую пользу ты можешь принести?
2. У бизнеса есть боль, и ты должен помочь ее убрать. Например: сверстать лендос, сэкономить на амазоне, уменьшить тайм-ту-маркет, запилить фичу.
3. Кстати, именно поэтому в резюме нужно писать про именно что ты сделал. А не то что 8 часов пишешь код. Писать код - это не польза. Решать задачи бизнеса с помощью кода - польза.
4. Так что же такое сеньорность? - спросит пытливый читатель. Сеньорность это не про знания, а про ответственность и способность принимать решения.
5. Сеньор для бизнеса это такой черный ящик. Ты в него кидаешь задачу и получаешь результат. Результат учитывающий кучу моментов и сделанный в лучшем в виде _в текущих условиях_
6. Например - бизнес хочет проверить гипотезу. Дает задачу, а человек начинает патчить компилятор чтоб типы красивее отображались. Время проебано, деньги проебаны.
7. Другой пример - бизнес уже проверил гипотезу и теперь нужно сделать так что клиенты не пиздели в твиторе, а заносили дойчмарки. Обмазываешься тестами и очень аккуратно все проверяешь. Продолбал? - Продолбали бабки.
8. Сеньор должен понимать такие моменты и принимать решения.  
9. Сеньор должен еще немного предвидеть будущее. Где нужно заложить расширяемость, а где похер.
10. Если ты знаешь 5 фреймворков но не можешь решить как лучше делать, долго сомневаешься и ждешь когда тебе скажут как сделать - ты мидл.
11. Как же вырастить из джуна сеньора? Да очень просто - дайте ему проебаться.
12. Если держите джунов в тепличных условиях, то он просто будет джуном со знанием фреймворков.
13. Сеньор еще должен уметь разговаривать с бизнесом - мы можем сделать так, но это дороже, а так будет дешевле но может взорваться. Чо у нас по приоритетам тут? Быстрее?, ну если что я предупредил, письмо отфолоуаплю.
14. Ну и с людьми разговаривать тоже уметь надо. Если джун задает вопросы, не надо свысока и через зубы отвечать или говорить - я лучше знаю. У джунов бывает свежий взгляд и вообще разговаривать полезно.
15. Ну и сеньор может решить задачу. Не важно знает он фреймворк или нет. Умеет ли он конкретно этот яп. Есть задача, есть решение, может не всегда идеальное. Но работающее в данных условиях.
16. Сеньор = профессионал. Не надо тащить эмоции, не надо выебываться., не надо самоутверждаться. Мы делаем работу за деньги.

Что там произошло на неделе? Да кому это важно, ведь Влад и Фил уверенно мчат к цели — прорешать всю тысячу алгоритмических задач на Leetcode. Заходите и смотрите, чего и на чем они там понавертели в этот раз https://www.youtube.com/watch?v=w0B0S2ZpWHM

Приходи

5 лет назад я жил в небольшом городе и работал удалённо. Мне настолько было одиноко и не с кем поговорить, что я выплескивал таксистам о своих переживаниях.

Год назад я жил в питере и работал удаленно. Мне настолько было одиноко и не с кем поговорить, что я бухал и грустил.

Сегодня - крутые люди зовут меня попить пива и им интересно моё мнение. И когда-то я даже не мог такого представить.

Я не знаю в чем секрет, я не замечаю особенно изменений в себе, но что я точно знаю - общаться с людьми которые близки тебе по духу и мыслям это бесконечно круто. И бесконечно важно найти таких людей.

Я зову тебя к бесконечно крутым людям - Фил и Артём делают офлайн сходку в Москве. И я уверен это точно не будет скучно. А ещё будет много разговоров и пива.

А да, я уже отправил заявку. Приходи тоже. https://raif-it.ru/open-bar

Я тут сходил на собес, даже видос записал.

Тестовые задания

Ненавижу тестовые задания.

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

Ты всегда страдаешь от недостатка внимания, недостатка времени, недостатка понимания - что же они ожидают на самом деле. У тебя нет попытки исправить ошибки в следующем спринте. У тебя нет попытки улучшить. Ты сделал - тебя оценили. "Спасибо за потраченное время"

Возможно звёзды не сложились, возможно ты сделал неправильный выбор, возможно ты просто плохо оценил сроки или может твоя собака заболела. Всё бросай и делай наше тестовое. У тебя одна попытка. Ты нам не подходишь.

Мне всегда тяжело слушать оценку моей работы, я слишком много вкладываю себя. Я тяжело воспринимаю критику своей работы. Моя работа это часть меня. Дать подробный фидбек? - Нет, спасибо, мне и без этого уже плохо. Спасибо что дали шанс попробовать.

В следующий раз я сделаю лучше, в следующий раз я буду лучше стараться, в следующий раз. Следующего раза не будет.

Ненавижу тестовые задания.

Просто наблюдение. Почти все коллеги, которые когда-либо говорили "каждый обязан знать X" в итоге оказывались в ситуации, когда они не знали чей-то другой обязательный X. Но делали вывод, что чужой Х - хуйня собачья. А их Х - необходимый, самый критически важный на земле.

Можешь сколько угодно объяснять им, что обязательных, необходимых базовых знаний в разработке больше, чем может знать один человек. Они просто будут отрицать важность того, что они не знают, и поощрять важность того, что они знают.

Из моих твитов может сложиться впечатление, что я транслирую позицию - да похуй на скилл, ничего знать не нужно.

Это не так. Ещё как нужно. Огромное количество вещей. Просто я считаю, что человек вправе комплектовать свою сферу интересов в программировании сам.

Понятно, что столкнулся с проблемой - будь добр, разберись и реши.

Но не столкнулся - и слава богу. У нас огромное пространство для изучения. Правильно учить то, что интересно плюс то, что прямо потребовалось в работе.

Человек, который глубоко изучил в программировании одну вещь, разберется и с другой. Это блядский постулат. Не надо думать, что знания работы вебпака - святой грааль. Есть куча других скилов, знание которых ГАРАНТИРУЕТ, что ты сможешь разобраться с вебпаком.

Это очень важно понимать, когда проводишь собес. Тебе не нужно брать чувака, который отлично знает то же, что и ты. Это и так уже знаешь ты, покажешь если надо. Надо брать чувака, который отлично знает ЧТО-ТО в разработке. Чем оно ближе к вашему проекту и стеку - тем лучше, да.

Но думать, что человек хуйня, потому что он не знает одну из вещей, которую считаешь обязательной именно ты, и отказываться при этом узнать, что хорошо знает он - полная хуета. Если только ты в пожарном режиме не нанимаешь супер эксперта на конкретный узкий кейс.

Вот не знает чувак, прикиньте, как работает сборщик мусора в js. Пиздец же. ПИЗДЕЕЕЦ!!! А что если я скажу, что при этом этот же чувак - очень глубоко разбирается в принципах работы баз данных? А у нас бекенды на ноде? Чё, не берем? Нахуй нужен, да?

Самое главное правило в оценке технического уровня людей: твоя задача тут не говорить, а слушать. Похуй что тебе важно. Похуй, какой у тебя уровень. Похуй на тебя вообще. Послушай, что умеет и знает человек, как он к этому пришёл и зачем - и только потом уже делай выводы.

Меня ещё в школе это бесило. Учитель хотела, чтобы я читал Гоголя, а я не мог себя заставить его читать. Я читал Джека Лондона. Но в мире учителя есть список - книги, которые надо прочитать, чтобы иметь хорошую оценку по литре. Какого хуя? Почему именно эти?

И вот мне кажется, что все проблемы отсюда. Люди выросшие и воспитанные на списках вещей, которые составил какой-то хуй с горы, которые "должны" знать все. Простите, мне это не интересно. Есть куча людей, которым интересно - идите к ним. Мне интересно другое.

С разработкой всё не так просто. Если надо срочно чинить конфиг сборки, у тебя нет опции сказать - я это не умею. Но я настаиваю - если ты этого не умеешь, и при этом отлично умеешь что-то другое в программировании - ты с этим справишься.

Рассказал тут как нанимать ребяток. https://skillbox.ru/media/code/vrednye-sovety-kak-zavalit-intervyu/

Так, гайз, кто живет в Питере:
13-14 августа я (Фил) пригоняю в Питер, и собираюсь там хорошенько посидеть (побухать) со знакомыми и не очень разрабами. Кто хочет вписаться - залетайте в чатик:

https://t.co/FhzoshSgie?amp=1

NEZAVISIMOST’

Очень сложно найти своё дело, своё призвание, своё место. Ещё сложнее принять это. Мы в детстве мечтали стать космонавтами, пожарными, строителями. В результате сейчас мы перекладываем бумажки на столе, мобильники на полке, если повезло - перекладываем джейсоны.

Найти своё место - сложно, получить признание - ещё сложнее. Мы можем смириться с тем что есть. А можем продолжать бить стены головой и пытаться чего-то достичь.  Пытаться кому-то что-то доказать.

Люди жестоки, повсюду конкуренция и каждый пытается урвать свой кусок. Но чаще - люди наиболее жестоки сами к себе. Общество нас пытается загнать в рамки, а люди и сами рады построить границы в голове.

Я ещё недостаточно знаю, недостаточно умею, я слишком плох для этого. Дайте мне время и вы все увидите. Я вам докажу.

Люди проживают целую жизнь в процессе подготовки. Сидя в своей собственной  тюрьме в своей собственной голове. В своей голове люди выстраивают воздушные замки. Людям комфортно. И кто я такой что бы их осуждать.

Кто-то ассоциирует себя с работой. Кто-то ассоциирует себя с делом. Кто-то ассоциирует себя с городом или страной. Я хочу ассоциировать себя с тем что я создаю.

Меня никогда нигде не принимали, я всегда везде чувствовал себя лишним. Я всегда один. И неважно сколько людей вокруг меня. И я устал. Устал подчиняться правилам, слушать толпу и пытаться быть таким как все. Я больше не хочу играть в игры, где все правила против меня.

И мне остаётся надеяться что я не один такой. Такой кому нигде нет места. Мне остаётся надеяться что у меня получится построить место, где каждому будут рады, где каждый будет своим и где не нужно будет играть по дурацким правилам и кому-то что-то доказывать. Где каждого поддержат и примут таким какой есть.

Давайте создавать - площади, города, миры, вселенные. Создавать своё место. Без ненависти, без правил, без грейдов, без священных войн, без кумиров и божеств.

Давайте, а?

https://github.com/nezavisimost

Ребят, тут Влад вышел из депрессии и запустил новое шоу Leetcode Patterns. Давайте поддержим братана. https://www.youtube.com/watch?v=92_ZmKjtfxA

Вашему внимаю представляется список сложнейших, практически неразрешимых задач в IT:

- Инвалидация кэша
- Придумывание названий
- Off-by-one ошибки
- Кнопка «Назад»
- Плавный скролл
- Запомнить позицию скролла
- Плавные веб-анимации
- Звук на видеоконференциях
- Верстка имейлов
- Выравнивание текста и иконки
- Файловые пути с пробелами
- Запоминание «Запомнить меня»
- Не писать еще один пакетный менеджер (ой, написал)
- Логгирование в Джаве
- Юнит тесты в Джаве
- Сборка проекта в Джаве
- Выделение текста в PDF
- Оценка оставшегося времени в прогресс-барах
- Кража фокуса
- Запись в файл (надежная)
- Парсинг XML (надежный)
- Переключение режимов монитора в Windows
- Поиск пути, куда установлена Visual Studio
- Запоминание, на каком мониторе открывать окно
- Плавное изменение размера окна
- Цветовые пространства
- Ввод текста
- Вывод текста
- Часовые пояса

ТЕСТОВЫЕ ЗАДАНИЯ

Никто не любит тестовые задания. Я научился делать тестовые так чтоб их приняли. Пилю тред про мелочи которые повысят вероятность прохождения тестового задания.

1. Помни о том, что тот кто будет проверять тестовое будет это делать на бегу и вряд ли сможет сделать это хорошо. Дедлайны горят, прод горит, митинги кучами. А тут ещё тестовое проверять. Ни у кого нет времени два дня разбираться с твоим кодом.
2. Проверяющий скорее всего будет смотреть на формальные признаки. Сам код будет прочитан по диагонали и если там нет цепляющих взгляд вещей то он пройдет “ревью”.
3. Сделать тестовое задание, которое примут, сложнее чем делать работу. Нужно очень много сделать всякой мелочевки чтоб показать что ты норм.
4. Первая мелочь - не пиши весь код в одном файле, даже если кода 50 строк. Проверяющий доебется что не умеешь декомпозировать и в прод будешь писать так же в одном файле.
5. Вторая мелочь - обязательно юнит тесты, даже если нечего тестировать. Нужно просто наличие - два-три теста которые проверяют ничего лучше чем их полное отсутствие. (Как писать юниты для фронта я не знаю, поделитесь в комментах)
6. Третья - подробное ридми. Просто код без описания никому не нужен, скорее всего чел забьет его вообще смотреть. Напиши что ты сделал, для чего, как запускать, как запустить тесты, как правильно посмотреть работоспособность. Какими версиями собирать и тд. Представь что делаешь опенсорс проект.
7. Хорошо если ты заморочишься и сделаешь мейкфайл, а еще докерфайл. Делов на 15 минут а сразу бонусных очков заработаешь.
8. Если можешь - лучше пиши на английском - ридми, коммит месседжи, комментарии к коду.
9. Добавь файл с версией, пусть будет вечный 0.1.0-SNAPSHOT но проверяющий заметит что ты подумал о версии. Совсем мелочь на 10 секунд работы, а очень бросается в глаза.
10. Старайся форматировать код читабельно, чтоб он выглядел красиво. Не комментируй каждую строку. Код должен выглядеть прилично если его смотреть по диагонали. Однобуквенные переменные оставь для прода, в тестовом задании их писать нельзя. (Ну счетчики i,j можно)
11. Если просят задание в виде репозитории отформатируй git log. Он должен выглядеть прилично и показывать ход мысли. Даже если ты писал за один присест. Покажи что ты умеешь атомарно вносить изменения а не одним куском. Ну и автора не забудь поправить. Фамилия имя почта вот это все.
12. Вот тут можно посмотреть как делал тестовое я. Кода меньше чем описания и обвязки в виде скриптов и описаний. https://github.com/the2pizza/authorizer
13. Главный принцип - тестовое задание должно выглядеть как настоящий проект, даже если там делов на час. Это все не гарантия стопроцентного прохождения, но сильно сильно улучшит мнение проверяющего.

Тимлид - инструкция по применению

Привет друг, ты устроился на работу, но чувствуешь себя одиноким и брошенным, ты не понимаешь что от тебя хотят и страдаешь от синдрома самозванца? Тогда эта инструкция для тебя.

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

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

Ты пишешь ему в личку - “Привет, помоги плиз” - и получаешь в ответ игнор. Ты пишешь в общий чатик и получаешь игнор. Ты бьешься головой об стену и всех ненавидишь. Просто прекрати так делать.

Представь себя на месте тимлида, у него куча обязанностей, куча созвонов, куча людей которым нужно его внимание. “Да он же ничего не делает!” - скажешь ты и будешь прав, но писать код сильно проще, чем рвать контекст на мелкие кусочки, бегать по созвонам и тушить пожары. Просто поверь.

Твоё счастье в твоих руках. И никто не в силах тебе помочь кроме тебя самого.

Так вот. Поймай тимлида за руку у кофемашины. Или просто закинь ему созвон в календарь - не забудь понятно написать что-то в виде 1-1 teamlead - Masha, feedback session. 1 hour.

Иииии просто поговори. Расскажи что тебя беспокоит, расскажи что ты понимаешь, что ему тоже сложно и ты хочешь всеми силами помочь. Расскажи свои эмоции. Предложи ему свой _вариант_ решения этой проблемки. Расскажи ему как и что ты видишь. Ведь часто тимлид даже не понимает что что-то идет не так и потом недоумевает когда видит заявление на увольнение.  

Какой вариант я могу предложить? - спросишь ты. Да очень простой, попроси ментора из числа сеньоров. Чтоб не дергать тимлида и дать сеньору возможность прокачаться в менторинге. Сплошной вин-вин.

А ещё не забудь спросить фидбек у тимлида по своей работе. Ну не удивляйся если услышишь “Да норм всё не переживай”. Давать фидбеки сложна.

Ну а если вдруг тимлид скипнет, проигнорит или начнет обесценивать твои чувства и переживания - просто обнови резюме.

Помни, твоё счастье в твоих руках. Удачи!

А меня опять позвали на подкаст, только теперь это Фронтенд Юность. Думаю будет интересно. Сегодня в 20:00 по Москве на ютубчике можно будет посмотреть в лайве - https://www.youtube.com/watch?v=Bnmh75p8Ssc Приходи :)

Завтра (в Четверг) в 20:00, продолжим менторить начинающего разработчика Сергея.

В этом выпуске разберем в деталях резюме.

Нам будут помогать: Дарья Иванова (Talent Acquisition Manager в AppFollow) и Тупица

🔥Также будем разбирать резюме зрителей, присылайте резюме в личку @kirjs

📺 Посмотреть: twitch.tv/kirjs | youtube.com/kirjs
📄 Инфа по ведущим, планы и предыдущие выпуски: здесь

Вот тут https://t.me/nikitonsky_pub/155 Никита пишет про блоги и хостинг. И я понимаю его боль и совершенно согласен, что телеграм канал пока самое простое чтоб писать свои мысли, конечно комменты меня немного бесят в своей реализации, но лучше чем ничего.

Но у меня немного другая боль. Моя боль это инструмент в котором тексты создавать. Сейчас я использую стандартный макосный Notes. И он вприципе меня устраивает. Драг-энд-дроп есть, даже шрифты можно форматировать. Опять же очень просто писать - создаешь заметку и пишешь свой поток мыслей. Синхронизация опять же очень удобная, в автобусе можно с мобилки перечитать текст и сделать небольшие правки.

Скажете конечно - используй VSCode или IDEA. Но как по мне для текстов это очень плохо подходит, ещё скажете возьми гит чтоб исходники текстов не потерять, но я как представлю сколько надо сделать движений чтоб написать одну заметку мне сразу перехочевается что-то писать.

Поэтому я все чаще раздумываю сделать свой собственный легковесный клон Notes. Но только чтоб с лейблами, поиском и версионированием. И облваной синхронизацией конечно же.

И опять же, что за программист который не написал свой собственный текстовый редактор. Rust и Skia опять же надо же попробовать наконец-то нормально. Так что ждите.

Почему ФП, а не Rust/Go/etc?

Вчера в чате всплыла тема того, насколько плюсовики вообще приспособлены к переходу на другой язык.
У меня неутешительные новости: если ты несколько лет профессионально писал что-то на C++, то твой мозг уже заражён. Всё. Теперь во всех императивных ЯП ты будешь видеть недостатки и тратить свой мозг на поиск «оптимального» решения, вместо того, чтобы сфокусироваться на решении самой задачи. Потому что вот слова, вроде, похожие, делают что-то похоже, но ведь по-любому они там где-то такты впустую теряют на что-то!
Слишком легко перетащить все свои плюсцовые привычки в этот язык и начать творить дичь.

Переучиться, конечно, можно. но как мне видится, это надо опять вставать в позицию джуна и всё пропускать через жёсткий код ревью. Если вас по финансам такой вариант устраивает, то норм. Мне, к сожалению. не подходит.

(Раст формально подходит как язык, на который можно успешно перекатиться с плюсов, но на его счёт у меня своё мнение, возможно, как-нибудь распишу подробнее. Пока что ограничусь тем, что вакансии на расте в подавляющем большинстве — это крипто-стартапы, что я не приемлю по своим этическим убеждениям.)

А вот с ФП ты оказываешься в совершенно иной ситуации: тут вообще всё по-другому. И плюсовые парадигмы зачастую просто физически не накладываются на такой язык (иммутабельные структуры данных, привет!). В результате мозг «сбрасывается» и начинаешь всё воспринимать как будто с чистого листа. Идеальная почва для обучения идиоматике и принятым подходам языка без таскания за собой багажа «знаний».

Часто можно слышать, как люди, пересевшие на Clojure или Elixir снова открывают для себя радость программирования и начинают просто переводить свои мысли в код. Вот хочу так же.