Size: a a a

2021 November 17

MS

Max Syabro in ctodailychat
а ни у кого на WSJ нет подписки?
источник

SS

Slava Savitskiy in ctodailychat
неа. хочешь про наушники почитать?
источник

VI

Vladimir Ivanov in ctodailychat
опа, контент про выход из айти https://journal.tinkoff.ru/it-disillusion/
источник

MS

Max Syabro in ctodailychat
не
источник

Y

Yaroslav in ctodailychat
нормально набрасывают,душевно)))))
источник

O

Onlinehead in ctodailychat
- Обратитесь к системному администратору
- Блин, а че делать то, я и есть системный администратор..
источник

O

Onlinehead in ctodailychat
Ох, у меня жир с монитора потек. Предупреждать надо о таком:)
источник

SG

Samat Galimov in ctodailychat
Написал программный пост ака крик души
источник

SG

Samat Galimov in ctodailychat
Буду благодарен за «конструктивную критику»
источник

SG

Samat Galimov in ctodailychat
Telegram
запуск завтра
Закончил на днях технический аудит очередного клиента. Хочу поделиться историей, которую вижу буквально в каждом втором случае.

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

Через 3-6 лет в компании уже 50 разработчиков. Продукт при этом практически не развивается, фичи доставляются разработкой в продакшен со скорость улитки. Добавьте к этому зарплаты разработчиков в 100-400 тысяч в месяц и вы можете представить, что чувствует бизнес. Почему так?

А происходило вот что: все эти годы, каждый раз, когда нужно было выбрать между «сделать фичу побыстрее прямо сейчас» и «сделать так, чтобы это можно было потом поддерживать, пусть и подольше прямо сейчас» — бизнес с разработкой вместе выбирали первый вариант. Логично, что рано или поздно гора неподдерживабельного кода становится слишком высокой и уже никто не может докинуть ещё что-то сверху.…
источник

IV

Igor V in ctodailychat
странно что нет пункта “3. нанять нормального CTO который будет отвечать за баланс системы”
источник

SG

Samat Galimov in ctodailychat
!!!
источник

Y

Yaroslav in ctodailychat
прочитал и вспомнил со слезой два моих последних места работы)
источник

Y

Yaroslav in ctodailychat
на одном из них прокатил подод: сделать так чтобы бизнес и люди с их ценным мнением меня боялись. Каждую неделю я делал демо и рассказывал что именно мы изменили, почему это важно и т.п.

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

Y

Yaroslav in ctodailychat
а потом еще год (когда все смирились и поверили в тот путь который мы делали) приходилось вычищать карму и обелять облик команды в глазах всей остальной компании
источник

SG

Samat Galimov in ctodailychat
Про «нормального CTO» я понимаю, что ответственность CTO это как раз не допустить такой жопы, но я подозреваю, что если переставить двух таких CTO местами — то скорее всего, каждый сделает у соседа нормально. Навести порядок  на новом месте психологически проще, чем вытаскивать себя самого за волосы в месте, где ты уже за годы врос.
источник

IV

Igor V in ctodailychat
я сейчас нахожусь в похожей ситуации и анализирую причины которые привели к этому состоянию. буквально вчера вернулся с воршопа с лид инженерами и лид архитекторами.

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

нужно менять технологии и подходы как мы мыслим о системах.
источник

IV

Igor V in ctodailychat
(не IT-системы, а системы организации работы и управления)
источник

SG

Samat Galimov in ctodailychat
Да, но какие новые подходы?

Реально нарастить авторитет и уверенность в себе, чтобы успешно ограничивать product people и не давать им стрелять бизнесу в ногу
источник

IV

Igor V in ctodailychat
Не нужно ограничивать product people, это их работа. Программистам пора понять что наш new reality состоит в том, что продуктам всегда надо и надо завтра, поэтому нужно строить инженерную организацию  вокруг этого факта
источник