Telegram Web Link
Справедливости ради…

Месяц назад писал про историю не очень адекватного поведения админов. В том посте я написал, что руководство решило замять этот вопрос. Но это не совсем так.

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

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

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

Со всем этими событиями заметил у себя интересное когнитивное искажение. В феврале этого года, я сам лично собеседовался в Яндекс. И даже прошел, дошел до финала и очень радовался этому факту. Но потом в связи со всем известными событиями отказался от перехода, потому что непонятно было вообще ничего.

Когда я узнал о возможной покупке Деливери Яндексом, я сначала тоже обрадовался, хотя тогда было вообще ничего не понятно. Оставят ли Деливери как отдельную компанию, бренд или вообще сольют. Что будет с нами, возьмут ли я Яндекс или всех отправят на биржу труда.

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

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

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

Вообще эту идею, о том, что люди в целом с удовольствием меняются, но нне любят изменения, которые им навязывают, я подчеркнул в одной из книг про бирюзовые компании. Там вообще много говорится о том, что любые изменения должны идти изнутри сотрудника. Тогда cомнений в своем решении меньше, а сил на выполнение больше.
Видос с утра пораньше) Готовился к отпуску, и понял, что нужна всякая мелочевка, решил искать на авито. Чтобы найти дешевле, написал парсер, и решил выложить его тут в виде скринкастов.

Доплнительные ссылки к видео

Репо с проектом

Репо с node.js + typescript boilerplate

Ну и само видео

https://youtu.be/hpPJLZEOo_k
А нужны ли тестировщики?

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

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

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

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

Тестировщики по другому видят проект. В отличие от програмистов, они не делят приложение на модули классы и прочие абстракции, а смотрят на него целиком, так же как смотрит на него пользователь. В идеальном случае тестировщик — это такой придирчевый пользователь, который на каждую неисправность заводит тикет.

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

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

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

Можно ли с этим бороться?

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

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

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

Ну и конечно, нужно ввести практику тестирования кода.

А как у вас в команде организовано тестирование?

@alx_four
Когда я решил стать программистом многие из моего окружения очень скиптически отнеслись к моему выбору. Когда я начал расти по карьерной лестнице, те же люди говорили, ну сколько я еще смогу програмировать, 5, 10 лет? А потом?

Но то, что я вижу говорит, что програмировать можно до самой старости, это не фигурное катание. Осолбенно если программировать нравися.

Еще одно подтверждение этому.

https://habr.com/ru/company/productivity_inside/blog/690406/
Пример хорошего решения…

В отдин из своих микрофронтов затащил Pinia вместо Vuex (для тех кто не вкурсе это стейт менеджеры в экосистеме Vue).

Так вот файлов, бойлерплейта, и кода стало на порядок меньше, а функционал сохранился полностью.

Вообще по выразительности языка можно судить о том насколько зрелый этот язык, кстати с разработчиками работает аналогично…

(На картинке красные - это удаленные файлы, а зеленые добавленные…)
Я могу все, но не долго…

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

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

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

Само по себе состояние говорит об эмоциональном подъеме и желании успеть больше, но нужно себя ограничивать и не брать новую задачу, пока не завершил предыдущую. Это сложно, потому что, например выступление будет через неделю, доклад почти готов, и уже можно брать что-то еще… А потом оказывается, что для выступления надо сильно больше, чем я думал, а тут уже поджимают сроки по другим проекта.

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

Кому такое знакомо?
Проблема всех методов увеличения продуктивности

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

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

Со всеми остальными способами, та же история.

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

При этом если я вдруг сорвался и начал заедать стресс сладким, то работоспособность не пропадает одномоментно. Тут опять же работает кумулятивный эффект. И это вторая опасность.

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

Что с этим можно сделать?

Соглашусь, что держать под контролем множество аспектов своей продуктивности сложно, но у нас у всех есть для этого помощник — это привычка.

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

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

Я состою в чатике Ереван IT, и там переодически скидывают вакансии. И тут на глаза попалась вакансия которая «заинтересовала» меня тем, что помимо всего прочего обещали выдать ноутбук после прохождения испытательного срока.

Естественно, я спросил, а на чем писать код во время испытательного, на листочке?

Мне ответили, мол если я не ищу работу, то «проходите мимо», но я не мог так поступить, с такой многообещающей вакансией, поэтому вписался в собеседование.

Тут должен быть дисклеймер, что все трюки выполнены профессионалами, не стоит это повторять. Я согласился исключительно чтобы потом написать пост, поэтому погнали…

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

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

Одного этого факта достаточно, чтобы не идти к ним, я противник многозадачности, а тут я, видимо, наткнулся на ее адептов.

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

Вопросы были стандартные, про мой опыт, чего делал, какие вопросы решал, и тд. Потом мы плавно перешли к обсуждению проекта. Я выложу переписку ниже, но вот, что меня напрягло:

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

🚫 Если ты не понимаешь, за счет чего проект финансируется, скорее всего это либо что-то незаконное, либо ты в какой-то момент останешься без денег. В совокупности с тем, что ребята даже не готовы показать свои лица перед камерой — должно очень сильно напрягать.

🚫 Я часто видел истории, когда один человек долго пишет проект один, после чего понимает, что не увидел изъян в архитектуре, и бросает проект. Невозможно, полтора года писать код без обратной связи и не сделать херню. Именно поэтому появились гибкие методологии с короткими итерациями.

🚫 Поскольку нет тестов, то о какие-то неочевидных зависимостях в коде ты узнаешь сильно позже. Я работал с таким проектом. Это страшно демотивирует, когда ты фиксишь баг, а потом к тебе с прода прибегают и говорят, что ты что-то поломал. И первое что ты начинаешь делать — это искать комит, который все сломал. В итоге разработка напоминает танец: шаг вперед, два назад.

🚫 Про рефакторинг я только скажу, что код должен жить, он должен меняться, поскольку иногда меняются требования, ты сам как программист растешь и придумываешь более удачные решения

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

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

Всем хорошего дня и удачный интервью.
2025/07/08 08:53:32
Back to Top
HTML Embed Code: