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

Сначала удивляешься — "ведь будут КРАСТЬ (!)", потом включаешь мозг и понимаешь , что красть больше, чем зарплата продавца, однозначно не будут, так что профит понятен.

-

Подумал, что с техническим долгом у многих то же самое: "неэффективное" решение технарей просто парализует одним своим названием — "да это же ТЕХНИЧЕСКИЙ ДОЛГ". Только при этом вторая фаза просто отказывается включаться, и плюсы более простого решения просто не рассматриваются.

Микросервисы это сложный, хлопотный и социально приемлемый способ сэкономить время на регрессионном тестировании системы

Подытожил, что нашел за выходные о финансировании стартапов

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

Если у кого-то из моих читателей есть желание и план продать свою ИТ-компанию, я готов обсуждать. Рассматриваю варианты от 5 человек, не меньше полугода на рынке, бэкенд и фронтенд (в идеале java и angular), регистрация на территории РФ. Выручка/доходность принципиально не важна

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

Но почему-то про мир программистов так не размышляют.

Юнит-тесты не делают код надёжнее и дешевле вдолгую - они обеспечивают возможность это сделать. Но на практике 90% тестов проверяют "1+1=2" и такое похожее. 9 из 10 разработчиков не открыли НИ ОДНОЙ книги по разработке юнит-тестов.

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

Тысячи таких примеров.

Хочется обо всем забыть и побыть некоторое время ответственным только за какой-нибудь код

Рыночек близок к состоянию "умеет сходить в БД в транзакции -- тимлид и эксперт"

Мне в личку в последнее время кидают большое количество ссылок типа “а вот посмотри, как устроен процесс разработки в […]“, где в качестве […] - Uber, Netflix, Slack, что-то еще такое же.

- Смотри, а в Netflix микросервисы
- Смотри, а в Slack лютейшее количество автотестов
- Смотри, а в Uber 70 команд работают над мобилкой

Наверное, догадываетесь, что их объединяет. Все это SaaS-поставщики. И именно это делает их абсолютно непригодными для рассмотрения как пример.

Поясняю, почему.

Все современные SaaS вендоры 90% своего бюджета тратят не на разработку, а на маркетинг, продвижение и прочие непрограммистские активности. Это космические суммы. На этом фоне никак не важно, жжете ли вы на эксплуатацию вашего поделия $1М или $10M, они все равно составляют проценты в общей сумме трат. Платить ежемесячно $25k за облачное логгирование? Не вопрос.

А я - не Uber, для меня разница между $1M и $10M на инфраструктуру может быть определяющей.

Подозреваю, и для вас тоже

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

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

Только я - не смеялся в этом месте.

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

"Неудачи бессильны против того, кто твердо гнет свою линию. Раз не везет, два, сто, – но не бесконечно. И когда человек обретает умение и мужество держаться вопреки любому невезению – вот тогда он в порядке; и с первой крохой удачи – а эти крохи выпадают всем! – он попрет, как танк."

"Во-первых, [..] невезение – это когда человек хочет больше, чем может. Этим надо быть скромней. Второе: не умеет учитывать все жизненные обстоятельства. Третье: не готов к худшему. Четвертое: принимает мелочи близко к сердцу."

"На удачу надо плевать – тогда она придет сама. И быть к ней готовым: недостойному она не поможет – он не сумеет ею воспользоваться, удержать. Ее надо добиваться, но на нее нельзя рассчитывать: везет тому, кто сам себя везет. Когда человек может и без удачи, своим горбом и разумом добиться цели – при любых обстоятельствах! – вот тогда удача сама идет навстречу."

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

CTO в стартапе - "тот Самый чувак, коTорый пишет кОд"

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

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

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

Ну, что: сделал вывод, что мало нетворкаю, раз такое вокруг.

Внезапно оказалось, мало кто знает, что в Java (и других похожих языках с mark-n-sweep) сборщик мусора НА САМОМ ДЕЛЕ собирает как раз не мусор, а живые объекты. А вот про мусор он ничего (почти ничего) и не знает

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

"Ужасный сайт. Где React или хотя бы Vue? Где куча джаваскрипта? Где скрипты с аналитикой и отслеживанием пользователя? Почему он грузится и отрисовывается настолько быстро? Такие сайты надо запрещать, они бросают тень на современные технологии."

Когда люди говорят вам в ответ “нет”, это не значит, что надо передумать или все бросить  — это значит только то, что в текущей ситуации они вам не будут помогать

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

Скажем, если работал меньше 2х лет на месте — скорее всего, ничего не смог сделать или “попросили вон” за общую дисфункцию управленческих органов и систем.

Если пишет “участвовал” — значит, повторить сам, без и впрямь умеющих людей, не может.

Есть больше 1 опечатки в резюме — пофигист (оно вам надо?).

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

Очень, очень высокая корреляция с последующим опытом.

Слышал, говорят так: «Не учите нанятых специалистов, как им делать их работу».

Все верно, но забывают ещё кое-что: обязательно учите их, как им делать ВАШУ работу.

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