Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
Не лыбдыр пост это.)
Да, я знаю о метриках. Заметка была попыткой показать, что программисту можно искать изящество и в донесении на языке менеджера тех технических моментов, которые он сделал. И я знаю, что и PM-ы, обычно, достаточно хорошо понимают технические моменты.
Если вы для прототипа, призванного протестировать гипотезу и умереть, пытаетесь выстроить архитектуру на 10 лет жизни и написать идеальный код, то у меня для вас плохие новости.
Overdesign — так же?
Overdesign — это же тоже не красиво?
Есть разные стратегии завоевания и удержания рынка для продукта:
1) Пишем Гкод, но быстро завоевываем рынок.
2) Ищем нишу и работаем в более спокойном рынке, конкурируем качеством или иновациями или тем и другим.
(и другие)
И первый и второй подход в определённых условиях выгоден. И одного и второго подхода есть преимущества и недастатки и для HR отдела и для репутации и т.д.
Программисты, в некоторых случаях, это технари, которые очень интересуются техническими проблемами, но далеки от задач, которые стоят перед PM-ами. Программисты относятся к техническим проблемам, как к проблемам стоящим внимания, а управленческие подходы (теже корреляции метрик по проекту) оценивают, как мешающие (_творчеству_) основной задаче программиста — создания хорошего кода.
Отмечаю:
Лучше сотрудничество между PM-ами, другим руководством и программистами.
Предлагаю:
Рассматривать задачи диалога как вызов. Как вызов перевода технических моментов в понятные формулировки пользователю, заказчику, бизнесу. При этом, лучше уделять внимание уникальным знаниям разработчика, например, техническим характеристикам решения.
Считают бюджет. Используют метрики. В том числе, метрики количества строк, которые были отредактированы в репозитории. Метрики, конечно, только коррелируют
Преимуществами (по сравнению с группой softmax) можно назвать, что у нас есть что-то вроде encoding-ов для каждого из действий из входных данных. Т.е. расширяются возможности для transfer learning. (Это упоминается в конце статьи.)
Тетрис сам по себе применяется как задача для тестирования алгоритмов RL. (Т.к. тетрис достаточно сложная задача.) Но оптимизировать ни сеть ни параметры обучения не было вычислительных ресурсов. Плюс CNN архитектура сети можно было сделать более совершенной. Но опять же в демонстрации архитектуры сети не стал это делать.
Долго обучается. Плюс применялось transfer learning для того, чтобы в начале обучить CNN часть. Иначе процесс и длительный и сходимость намного хуже. Уже есть обученные модели (они в каталоге tetris/models). Нужно было мне писать изначально очень хорошо оптимизированный код на C++ и подключать вмешними модулями к питону.
Также отмечу, что модели не оптимально обученные (как CNN часть так и основная модель). У меня тоже не хватило терпения на то, чтобы дождаться нужного результата. Да и задумывались проекты не как улучшение результатов RL алгоритмов, а только как демонстрация подхода архитектуры нейронной сети.
Не лыбдыр пост это.)
Да, я знаю о метриках. Заметка была попыткой показать, что программисту можно искать изящество и в донесении на языке менеджера тех технических моментов, которые он сделал. И я знаю, что и PM-ы, обычно, достаточно хорошо понимают технические моменты.
И что лучше диалог.
Как Вы будете вести диалог?
Вопрос: Создание хорошего кода для чего?
Возможный ответ: Для создания удобной, полезной программы для пользователя…
Overdesign — так же?
Overdesign — это же тоже не красиво?
1) Пишем Гкод, но быстро завоевываем рынок.
2) Ищем нишу и работаем в более спокойном рынке, конкурируем качеством или иновациями или тем и другим.
(и другие)
И первый и второй подход в определённых условиях выгоден. И одного и второго подхода есть преимущества и недастатки и для HR отдела и для репутации и т.д.
Это не лыбдыр пост, а скорее предложение для «художников».
Бывали, и плохие, и хорошие «конторы», бывали, и хорошие, и плохие менеджеры, и разработчики.
Разработчик корпит над деталями, но это оказывается не нужно.
Не нужно в одном проекте, в другом, в третьем.
Уходит на другую работу и те наработки (то корпение) выстреливает.
Давайте вместе проанализируем «беличью кисть».
Руководитель отметил по метрикам, что:
1) провал;
2) провал;
3) провал.
Руководитель (другой) отметил:
1) выигрыш.
Пожалуйста, Ваш анализ…
Или нет?
И нужно «опускаться» до уровня маркетолога?)
Попробую переформулировать.
Есть проблема:
Программисты, в некоторых случаях, это технари, которые очень интересуются техническими проблемами, но далеки от задач, которые стоят перед PM-ами. Программисты относятся к техническим проблемам, как к проблемам стоящим внимания, а управленческие подходы (теже корреляции метрик по проекту) оценивают, как мешающие (_творчеству_) основной задаче программиста — создания хорошего кода.
Отмечаю:
Лучше сотрудничество между PM-ами, другим руководством и программистами.
Предлагаю:
Рассматривать задачи диалога как вызов. Как вызов перевода технических моментов в понятные формулировки пользователю, заказчику, бизнесу. При этом, лучше уделять внимание уникальным знаниям разработчика, например, техническим характеристикам решения.
Какие есть вопросы?
Также отмечу, что модели не оптимально обученные (как CNN часть так и основная модель). У меня тоже не хватило терпения на то, чтобы дождаться нужного результата. Да и задумывались проекты не как улучшение результатов RL алгоритмов, а только как демонстрация подхода архитектуры нейронной сети.