Comments 67
Где вы таких находите, что строки считают?
Считают бюджет. Используют метрики. В том числе, метрики количества строк, которые были отредактированы в репозитории. Метрики, конечно, только коррелируют
Считают многие менеджеры.
Это не лыбдыр пост, а скорее предложение для «художников».
Это не лыбдыр пост, а скорее предложение для «художников».
Попробуйте найти нормальную компанию, а не рабскую аутсорс-галеру
Ищу нормальную компанию уже 4 год, в трудовой место заканчивается )
в трудовой место заканчивается
В таком случае не приходила в голову мысль, что проблема, возможно, не в компаниях?
Я об этом думал) Как сказали разработчики Амиго… Было принято несколько неправильных решений, только в моем случае при выборе компании, а с рваным опытом работы одно веселье искать работу. Да и счета рано или поздно догонят. Печально только то что опыт работы в таких компаниях можно игнорировать.
Уверен вам всем сильно повезло не слышать от коллег фраз "збей, на наш век зватит", "я возьмусь делать в соло проект ( одной из компаний большой тройки операторов ) на GO но я на нем никогда не писал", от руководства "все люди тупые и их надо пинать, но я не знаю как сделать push" и т.д. Цените это и не выпендривайтесь.
А я оставлю лучше место в хорошей компании тому у кого еще блестят глаза при слове программирование )
В принципе, смысл понятен, но стиль изложения...
Всегда нужно согласовывать, на что ты собираешься тратить кучу времени. Плох тот руководитель, который не поймёт. Плох тот разработчик, который тратит месяц на то, что в данный момент нафиг не нужно для развития продукта.
В принципе, смысл понятен, но стиль изложения...
Попробую переформулировать.
Есть проблема:
Программисты, в некоторых случаях, это технари, которые очень интересуются техническими проблемами, но далеки от задач, которые стоят перед PM-ами. Программисты относятся к техническим проблемам, как к проблемам стоящим внимания, а управленческие подходы (теже корреляции метрик по проекту) оценивают, как мешающие (_творчеству_) основной задаче программиста — создания хорошего кода.
Отмечаю:
Лучше сотрудничество между PM-ами, другим руководством и программистами.
Предлагаю:
Рассматривать задачи диалога как вызов. Как вызов перевода технических моментов в понятные формулировки пользователю, заказчику, бизнесу. При этом, лучше уделять внимание уникальным знаниям разработчика, например, техническим характеристикам решения.
Какие есть вопросы?
UFO just landed and posted this here
Да, софт скилы, во-первых, должны быть развиты у PM-а. Но почему их не может быть у разработчика?
Почему ПМ не может транслировать задачу разрабам?
Если технический специалист разработчик? Может ли PM до деталей понимать задачу?
Почему ПМ не защищает разрабов?
Извините, на какой фрагмент комментария habr.com/en/post/535114/#comment_22468212 вы задаете вопрос? Я не понимаю цепочку диалога. Поясните, пожалуйста, на какой фрагмент вы задаете данный вопрос и почему.
Почему разрабы должны вести диалог?
Поясните, пожалуйста, вашу позицию.
Какие ещё есть вопросы?
основной задаче программиста — создания хорошего кода
Основная задача программиста — создание работающей, удобной и полезной для пользователя/заказчика системы с прогнозируемым временем жизни. На красоту кода всем, кроме программистов, начхать, если честно. Если вы для прототипа, призванного протестировать гипотезу и умереть, пытаетесь выстроить архитектуру на 10 лет жизни и написать идеальный код, то у меня для вас плохие новости.
Качества кода не коррелирует с «работающей, удобной и полезной для пользователя/заказчика системы с прогнозируемым временем жизни»?
Сколь-нибудь существенно не коррелирует (кроме совсем уж маргинальных случаев, когда код настолько некачественный, что просто не работает). Качество кода существенно коррелирует со стоимостью сопровождения системы (что есть головная боль разработчика, а не пользователя/заказчика), и то, начиная с какого-то уровня сложности, т.к. пока она достаточно простая, любой говнокод будет читабелен, а стоимость рефакторинга, при необходимости, невелика.
Сколь-нибудь существенно не коррелирует (...) Качество кода существенно коррелирует со стоимостью сопровождения системы
А через такие параметры, как скорость внедрения новых фич/период выпуска обновлений/возможностью пользователям получать тех поддержку? Если рассматривать весь жизненный цикл. В том числе, «любимый» legacy.
А через такие параметры, как скорость внедрения новых фич/период выпуска обновлений/возможностью пользователям получать тех поддержку?
Это всё вторично. Обновления и техподдержка в подавляющем большинстве случаев не продают ваш продукт. А скорость внедрения новых фич в режиме говнокода зачастую превышает оную в режиме «чистой» разработки. По крайней мере, пока продукт не разросся в нечто монстроидальное. Но в последнем случае у вас, как правило, время/ресурсы на рефакторинг уже есть.
Для части софта вторично. Да.
Существует достаточно большое количество нишь продуктов, которые основной доход получают за счёт техподдержки и развития фич. Например, работающие на гос структуры, софт, который постоянно используется долгое время отдельными компаниями. Такой продукт может жить по десятку лет, порой меняя, во время своей жизни, ряд технологий. Очень важно, не потерять за весь этот период клиентов.
Существует достаточно большое количество нишь продуктов, которые основной доход получают за счёт техподдержки и развития фич. Например, работающие на гос структуры, софт, который постоянно используется долгое время отдельными компаниями. Такой продукт может жить по десятку лет, порой меняя, во время своей жизни, ряд технологий. Очень важно, не потерять за весь этот период клиентов.
Сколько-то лет назад я бы с вами согласился. Сейчас — нет, в свете того, что практически 100% такого софта, который мне попадался, имеет код разной степени паршивости, от «сойдёт, хоть и содержит нагромождение из нескольких слоёв легаси» до «полнейшее нечитабельное дерьмо, написанное джунами под руководством пофигиста». И он прекрасно живёт и продаётся, а за исправление килотонн косяков, костылей и грабель заказчики смиренно платят деньги.
Я согласен, что во вногих случаях диалог налажен, проблемы кода учитываются и они не оказывают существенного влияния на конечный продукт.
Но работал и с legacy, например.
Но работал и с legacy, например.
Если вы для прототипа, призванного протестировать гипотезу и умереть, пытаетесь выстроить архитектуру на 10 лет жизни и написать идеальный код, то у меня для вас плохие новости.
Overdesign — так же?
Overdesign — это же тоже не красиво?
Overdesign — это не профессионально, т.е. результат недостатка квалификации или понимания задач бизнеса.
Одна из граней красоты/изящества — это профессионализм?
С моей точки зрения, при решении бизнес задач, основной критерием изящества является оптимальность решения по сложности и трудоемкости поставленной задаче.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
В книге про тестирование в гугле про это хорошо написано.
Когда изначально проект развивается как старт-ап, с минимальными требованиями к процессу разработки. И если в нем видят потенциал, начинают инвестировать в качество.
Это и есть управление качеством.
основной задаче программиста — создания хорошего кода
Вопрос: Создание хорошего кода для чего?
Возможный ответ: Для создания удобной, полезной программы для пользователя…
Фраза «Опуститься до уровня руководителя?» — мысленный конструкт восприятия ситуации диалога с руководством некоторого технаря
13 лет работал программистом и последние лет 5 руководителем (менеджером продукта), вот прочитал и ничего не понял что хотел сказать автор…
Да ничего, заслуживающего внимания, если честно. Просто он попал в какую-то паршивую контору с паршивым менеджментом (бывает-с), и спроецировал свои личные переживания на всех.
Автор до сих пор считает коммерческую разработку ПО полигоном для поиска изящных решений и недоумевает, почему индустрия его в этом не поддерживает.
Есть разные стратегии завоевания и удержания рынка для продукта:
1) Пишем Гкод, но быстро завоевываем рынок.
2) Ищем нишу и работаем в более спокойном рынке, конкурируем качеством или иновациями или тем и другим.
(и другие)
И первый и второй подход в определённых условиях выгоден. И одного и второго подхода есть преимущества и недастатки и для HR отдела и для репутации и т.д.
1) Пишем Гкод, но быстро завоевываем рынок.
2) Ищем нишу и работаем в более спокойном рынке, конкурируем качеством или иновациями или тем и другим.
(и другие)
И первый и второй подход в определённых условиях выгоден. И одного и второго подхода есть преимущества и недастатки и для HR отдела и для репутации и т.д.
Все верно, стратегии есть разные.
И обычно об этом договариваются на берегу — при приеме на работу.
Скажем, если Вы пришли в стартап с ограниченным бюджетом, то долгосрочные инвестиции в совершенство кода приведут к банкротству — деньги закончатся раньше, чем продукт выйдет на рынок.
Если же Вас наняли в R&D отдел компании для инноваций, то там и постановка задач другая.
И обычно об этом договариваются на берегу — при приеме на работу.
Скажем, если Вы пришли в стартап с ограниченным бюджетом, то долгосрочные инвестиции в совершенство кода приведут к банкротству — деньги закончатся раньше, чем продукт выйдет на рынок.
Если же Вас наняли в R&D отдел компании для инноваций, то там и постановка задач другая.
И тот и другой подход — это грань красоты/изящества кодирования?
1) Реализовать функциональность в рамках минимального бюджета. Определить минимальный функционал. Здесь, как выше упомянули в комментарии, профессионализм это, например, возможность обзора архитектур и знание многих библиотек, чтобы знать что можно использовать с минимальными затратами и где не возникнет большого технического долга на малом интервале разработки.
2) Найти эффективное/иновационное решений?
1) Реализовать функциональность в рамках минимального бюджета. Определить минимальный функционал. Здесь, как выше упомянули в комментарии, профессионализм это, например, возможность обзора архитектур и знание многих библиотек, чтобы знать что можно использовать с минимальными затратами и где не возникнет большого технического долга на малом интервале разработки.
2) Найти эффективное/иновационное решений?
Я не слишком ошибусь, если скажу, что для 99% проектов успех — это «быстрее махать лопатой». Их инженерная сложность находится на таком уровне, что нет необходимости выбирать что-то из архитектур, а достаточно брать первое, с чем знакомы разработчики. Их творческая составляющая заканчивается на выборе первичного и вторичного цвета в дизайне. И да, из метрик там подойдёт даже такая тупость, как измерение количества строк в день. Потому что над кодом для CRUD-операций думать особо нечего.
А какие предположения?
Раз уж ты спрашиваешь, я сперва подумал, что это написал какой-то джун, высокомерный такой, которому еще и нормальные компетентные менеджеры еще пока не попадались, которые в программировании шарят, но потом, посмотрел профиль и подвис.
Да, сложно писать полемичные замечания.
Точные минусы статьи:
1) Подход только с точки зрения одной стороны конфликта. Что при отсутствии точного таргетинга сильно влияет.
2) На сайтах подобных Хабру в каждой новой статье нужно знакомиться с читателем заново.
3) Приемы художественного текста должны быть дозированными. Все же это техническое чтение.
1) Подход только с точки зрения одной стороны конфликта. Что при отсутствии точного таргетинга сильно влияет.
2) На сайтах подобных Хабру в каждой новой статье нужно знакомиться с читателем заново.
3) Приемы художественного текста должны быть дозированными. Все же это техническое чтение.
О том, что и мы программисты, и менеджеры, и маркетологи решают одну задачу – создание успешного продукта/услуги.
Не смешите. Уже лет 15 наверное более правильно говорить — маркетологи решают задачу пропихивания всего того гуано, которое сотворили менеджеры с программистами.
А есть ли критерии изящества?
И в какой момент нужно остановиться?
«Работа над произведением искусства никогда не может быть закончена, а может быть только заброшена.»
Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
Дурацкая притянутая за уши аналогия: я пригласил маляра покрасить стену, а он вместо краскопульта или валика расписал ее беличьей кистью №4. В один цвет, в лучшем случае дотянул по качеству до валика. «Художника может обидеть каждый»?
Бывают ситуации, когда компании выгодно иметь такого специалиста, если, простите за пошлость, «монетизация» идет через PR (статьи, конференции, олимпиады), обучение коллег, создание атмосферы «избранности» в команде или поддержание ЧСВ у учредителей. Но это какая-то отдельная история.
И в какой момент нужно остановиться?
«Работа над произведением искусства никогда не может быть закончена, а может быть только заброшена.»
Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
Бывают ситуации, когда компании выгодно иметь такого специалиста, если, простите за пошлость, «монетизация» идет через PR (статьи, конференции, олимпиады), обучение коллег, создание атмосферы «избранности» в команде или поддержание ЧСВ у учредителей. Но это какая-то отдельная история.
А давайте, другую притянутую за уши аналогию.
Разработчик корпит над деталями, но это оказывается не нужно.
Не нужно в одном проекте, в другом, в третьем.
Уходит на другую работу и те наработки (то корпение) выстреливает.
Давайте вместе проанализируем «беличью кисть».
Руководитель отметил по метрикам, что:
1) провал;
2) провал;
3) провал.
Руководитель (другой) отметил:
1) выигрыш.
Пожалуйста, Ваш анализ…
Разработчик корпит над деталями, но это оказывается не нужно.
Не нужно в одном проекте, в другом, в третьем.
Уходит на другую работу и те наработки (то корпение) выстреливает.
Давайте вместе проанализируем «беличью кисть».
Руководитель отметил по метрикам, что:
1) провал;
2) провал;
3) провал.
Руководитель (другой) отметил:
1) выигрыш.
Пожалуйста, Ваш анализ…
Я расцениваю это так, что 3 работодателя оплатили навязанную и бесполезную для них работу. 4-й выиграл в лотерею, но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
Критерии изящного решения Вы так и не привели. Поэтому не очень понятно, в чем заключался выигрыш.
Критерии изящного решения Вы так и не привели. Поэтому не очень понятно, в чем заключался выигрыш.
Критерии изящного решения Вы так и не привели.
habr.com/en/post/535114/#comment_22469272
Ваши слова ошибочны?
Я расцениваю это так, что 3 работодателя оплатили навязанную и бесполезную для них работу. 4-й выиграл в лотерею, но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
На основании каких наблюдений/фактов вы делаете такие выводы?
но в долгосрочной перспективе может потерять больше, т.к. будет оплачивать другую навязанную и бесполезную для него работу.
Вы считаете, что наказания менеджеров за неуспех, (но старания — в habr.com/en/post/535114/#comment_22469234 использовалось слово корпел) разработчика оказались неэффективны и он все также будет стремиться использовать «машинное время работадателя» для своих целей?
Менеджмент не эффективен?
Вы не верите в успешность работников, которые старательно работают?
Вы не верите в успешность работников, которые старательно работают?
В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
Уж извините.
Выводы делаются на основании личного опыта.
В успешность работников, которые не могут объяснить, над чем и зачем они работают, я не верю.
Вы формулируете «не могут». Но может ли это быть «не умеют», «не требовался ранее навык объяснения», «не наработан (слаб) навык».
Тогда алгоритм по «не могут»:
1) Учим объяснять;
2) Укрепляем навык объяснения;
3) И вуаля «разработчик может».
И работник может сам анализировать свои ошибки и научится навыку «объяснять».
И если в первом случае, когда разработчика нужно научить навыку ваше «не верю» — это блок для дальнейшего развития коммуникации, то во втором случае, когда сотрудник «может анализировать свои ошибки», то ваша вера — это только повод для ваших собственных разочарования — разработчик с навыком анализа своих ошибок рано или поздно научится объяснять, возможно не у вас на работе, а у другого PM.
Выводы делаются на основании личного опыта.
Можете ли вы поделиться кейсами из личного опыта?
Вы формулируете «не могут». Но может ли это быть «не умеют», «не требовался ранее навык объяснения», «не наработан (слаб) навык»
Мой опыт говорит о том, что в подавляющем большинстве случаев это «не хотят». Разработчик обычно ковыряется в каких-то вторичных мелких деталях не потому, что ошибочно считает, что это важно для бизнеса, а потому, что это намного интереснее, чем тупо формочки клепать.
Кроме сроков менеджеры используют и другие показатели или метрики: качество (удобство пользования, эстетическое восприятие, надёжность), стоимость эксплуатации или владения (производительность, потребление ресурсов масштабируемость), стоимость сопровождения (скорость исправления дефектов, сложность внесения изменений, «хрупкость») и т.п.
Если изящность не ложится ни на один из них, то в чем его ценность для того, кто оплачивает эту работу?
Не лыбдыр пост это.)
Да, я знаю о метриках. Заметка была попыткой показать, что программисту можно искать изящество и в донесении на языке менеджера тех технических моментов, которые он сделал. И я знаю, что и PM-ы, обычно, достаточно хорошо понимают технические моменты.
И что лучше диалог.
Как Вы будете вести диалог?
Я предпочитаю, когда диалог ведется при постановке или оценке задачи, т.е. на стадии планирования/проектирования.
А вот если сначала тратиться 2 недели на работу, а только потом думаем, как это обосновать, то я считаю это чем-то сродни навязанным услугам.
Если работающее решение требует 2 часа, а изящное 2 недели, то выбор должен быть за владельцем бюджета, а не исполнителем.
А вот если сначала тратиться 2 недели на работу, а только потом думаем, как это обосновать, то я считаю это чем-то сродни навязанным услугам.
Если работающее решение требует 2 часа, а изящное 2 недели, то выбор должен быть за владельцем бюджета, а не исполнителем.
Если игнорировать факт накопления технического долга, вы правы.
Однако, 5-6 «работающих» решений, приляпанных с разных сторон продукта превращают его в лоскутное одеяло из кода/стиля/решений разных эпох программирования, сделанных разными командами без рефакторинга.
А самое страшное, что с ростом техдолга растет и время, необходимое на новые фичи. По экспоненте растет — первую фичу добавляли два часа, пятую будем к плохой архитектуре прилаживать месяц, при этом будет этап (двухнедельный, по классике) «исследование возможностей для внедрения».
Это можно сравнить с мастерской, или с кухней, кому что ближе — «зачем делать уборку, если завтра опять готовить / точить детали». Спустя полгода, сидя на горе мусора «А, вот зачем».
Однако, 5-6 «работающих» решений, приляпанных с разных сторон продукта превращают его в лоскутное одеяло из кода/стиля/решений разных эпох программирования, сделанных разными командами без рефакторинга.
А самое страшное, что с ростом техдолга растет и время, необходимое на новые фичи. По экспоненте растет — первую фичу добавляли два часа, пятую будем к плохой архитектуре прилаживать месяц, при этом будет этап (двухнедельный, по классике) «исследование возможностей для внедрения».
Это можно сравнить с мастерской, или с кухней, кому что ближе — «зачем делать уборку, если завтра опять готовить / точить детали». Спустя полгода, сидя на горе мусора «А, вот зачем».
Очень часто техническим долгом становятся как раз изящные решения, т.к. кроме автора их поддерживать никто не может.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
Опять же, к техническому долгу надо относиться как к долгу или кредитам — занимаем сейчас, отдаем в будущем. Все сводится к контролю на этим самым долгом.
Ой, я знаю, на что это похоже. Это же вылитые тезисы Хрущева с какого-то там партсъезда. Помнится, он еще художников обзывал, не стесняясь в выборе формулировок.
Это называлось "Об устранении излишеств в проектировании и строительстве".
Как бы это не было прискорбно для вас, а также для начальников, видящих в этом ущерб бизнесу — человек не является рациональным существом — плохо себя чувствует среди бетонных коробок, на станции метро-сороконожке, отделанной кафелем, а также среди типовых задач, для решения которых, по хорошему, талант программиста и не нужен.
Это называлось "Об устранении излишеств в проектировании и строительстве".
Как бы это не было прискорбно для вас, а также для начальников, видящих в этом ущерб бизнесу — человек не является рациональным существом — плохо себя чувствует среди бетонных коробок, на станции метро-сороконожке, отделанной кафелем, а также среди типовых задач, для решения которых, по хорошему, талант программиста и не нужен.
Я предпочитаю, когда диалог ведется при постановке или оценке задачи, т.е. на стадии планирования/проектирования.
Как вы будете вести диалог в рамках agile процесса?
Если 2 недели поиска изящного решения не улучшили качество продукта для пользователя или не принесло ничего для бизнеса, то ROI = 0.
Не принесло для бизнеса сейчас? Не принесло в эти 2 недели?
Пример: фундоментальные исследования.
А фактор целеустремленная работа сотрудника? Небезразличие? ROI?
«Целеустремленная» предполагает наличие цели. Если сотрудник фокусируется на только понятных ему целях (посте он не смог объяснить, на что было потрачено время), то это идет в разрез с интересами работодателя.
Вы вызвали такси, чтобы доехать до аэропорта.
Где-то в глухом месте таксист вышел и вернулся спустя 2 недели. Сказал, что занимался фундаментальными исследования, но чем они заключались, объяснить не захотел.
И да, оплачивать эти исследования Вам.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
Вы вызвали такси, чтобы доехать до аэропорта.
Где-то в глухом месте таксист вышел и вернулся спустя 2 недели. Сказал, что занимался фундаментальными исследования, но чем они заключались, объяснить не захотел.
И да, оплачивать эти исследования Вам.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
Есть такое понятие «подпольная разработка», но обычно это небольшая доля времени от проекта.
Спасибо
«Целеустремленная» предполагает наличие цели.
Можно ли это рассматривать с другой стороны также и как:
1) Недостаточное понимание разработчиков целей на данном этапе разработки проекта.
2) Не сформулированность целей работодателя?
3) «Микроскопом забивают гвозди» — разработчик тяготеет к другому стилю разработки и может быть полезен на другом проекте, на этом же он не столь эффективен?
Неправда. Не надо вам «опускаться» до уровня руководителя, ни к чему это.
Sign up to leave a comment.
Опуститься до уровня руководителя?