Артём Полтавцев написал о формах записи в салоны красоты

Вопрос: есть команда из трёх человек: сильный разработчик, который делает быстро, но поверхностно; есть слабый разработчик, который делает медленно, но работающий код (и часто переделывает за сильным) и есть тимлид/пм (я), который не сильно разбирается в коде. Сильный буллит слабого, что тот не разбирается и вообще плохой программист. Что делать?

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

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

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

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

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

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

На основе тех же данных можно быстро собрать прототип.

В современном JS для этого есть шаблонизируемые строки, их ещё называют «бэкти́ки» — по типу кавычек, в которые они берутся. Для простых прототипов больше не нужно искать фреймворки и шаблонизаторы. Если вы можете сверстать один элемент — вы можете легко сверстать и список на реальных данных.

Статья на Медиуме: https://medium.com/p/3153e280cfbf

Пример кода: https://codepen.io/detepr/pen/dmxYyX

Скринкаст: https://www.youtube.com/watch?v=gw-EaA2xAgc&t=25s

— Мониторы у вас излишне чёрные и недостаточно эстетичные
— Не хочется делать проекты для behance
— Не хочется ездить в офис на работу
— Ой, чё-то я прям не могу себя заставить за эту задачу взяться

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

Однако, всё познаётся в сравнении и если у вас нет этого «дна», с которым можно сравнивать — ценить то, что есть сейчас, вы полноценно не сможете.

Вы даже не сможете понять, что это нечто иное, нечто классное и уникальное и надо здесь задержаться.


Вспоминаю, как пришла работать в 1C:Битрикс.
По грёбаному дождю еле нашла их офис в какой-то вонючей(буквально) промзоне. Сначала час на вот этот текст на логику с шнусмумриками…

Потом задача на цикл, которая не хотела решаться. А в результате оказалась с ошибкой в условии. Какой-то прыщавый лид-программист, чьё ЧСВ было таким же жирным как и он сам.
Скептический настрой, только потому что ты девочка.
И вообще всё это нахер ему не надо. Эти тупые кандидаты, которые не могут решить придуманную задачу. «Господи, как же вы заебали» — читалось в его уставших красных глазах.


А работа в банке Русский Стандарт.
Более депрессивный, подставляющий друг друга персонал ещё поискать: тёлочки конкурировали друг с другом, рвали бумаги, вырывали клиентов друг у друга. Двухнедельное(с утра до ночи) бесплатное обучение всей системе рассчёта кредитных продуктов, страховок, выявления мошенников и поддельных документов. Страх отчисления, ежедневные чистки, унижения. Отсутствие эмоций и поток людей. Угрозыск, задержания, показания, золотые цепи на груди. Немые младенцы мошенников. Стопки налички из рук в руки под столом.


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


Для 90% компаний, люди — это мясо, средство достижения цели.
На ваши эмоции плевать. Ваши идеи никому не нужны.


Иногда нужно побывать на «дне», чтоб было с чем сравнивать и научиться ценить.


С любовью ❤️ гав-гав

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

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

Вместо результата у непонятных задач лучше фокусироваться на процессе. К примеру, можно пообещать проверять по одной гипотезе раз в два дня. Садимся, и раз в два дня выдвигаем гипотезу, скажем «я считаю, что виноват redis, потому что он иногда падает, а потом долго грузит сохранённые данные с диска».

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

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