All too often a manager recruiting new designers assesses them subconsciously on the criteria for the manager’s own job—“Could he do well the job I’m doing?” This favors the articulate, the leader, the person who will be effective in meetings. It tends to overlook the introvert, the slow-spoken, and especially the unconventional. But brilliant designers come in these packages, too! (I do not assert that brilliant designers are more likely to come in such packages. I don’t know.) We managers overlook these gifted ones to our great loss, theirs, and society’s. How can we select better? First, by reminding ourselves what we seek. Second, by looking at portfolios of the design work itself, not just oral presentations about the work.
The Design of Design. Frederick Brooks
С тех пор прошло почти 15 лет, и все стало только хуже.
Это также к вопросу о том, почему софт жрет все больше и работает все хуже.
Здравствуйте, Codealot, Вы писали:
C>С тех пор прошло почти 15 лет, и все стало только хуже. C>Это также к вопросу о том, почему софт жрет все больше и работает все хуже.
Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт. Команды бывают разные. Где-то интроверт-молчун будет ОК, а где-то просто не зайдёт. Есть команды с уебанскплохим менеджментом, где решения часто принимаются за 2 дня до ожидаемого результата — и там надо быть болтливым и соображать быстро. ГовнПлохи ли такие команды? Да конечно плохи. Но есть такие? Да конечно. И зарплату там вполне платят. Надо понимать, что любой бизнес — это баланс между зарплатой и прибылью. Если на мудастранных работниках получается поймать баланс, то бизнес — хороший. Что не всем заходит быть внутри такого — это понятно, и тут спорить не о чем.
Здравствуйте, rosencrantz, Вы писали:
R>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.
Прототип они быстро запилят, а не продукт. Потом будут долго и упорно пытаться сделать из этого говна пулю, не смогут, и хренак-хренак в продакшен что получилось. Быстро поменяют место работы. И все с начала.
Много раз уже такое видел.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rosencrantz, Вы писали:
R>>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.
C>Прототип они быстро запилят, а не продукт. Потом будут долго и упорно пытаться сделать из этого говна пулю, не смогут, и хренак-хренак в продакшен что получилось. Быстро поменяют место работы. И все с начала. C>Много раз уже такое видел.
Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
Я понимаю про что вы говорите, но ценность работника определяется не знанием и опытом, а попаданием в темперамент команды. Распиздяям будет комфортнее работать с распиздяем, чем с педантом, пытающимся разложить по полочкам. *Комфорт* важен. *Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра. Если комфорта нет, оно неделю отработает, а дальше будет рушиться. *Охренненно* важен баланс.
Здравствуйте, rosencrantz, Вы писали:
R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
Главное — варить пользователей лягушек медленно, чтобы привыкли.
Если весь софт говно, то новый кусок гов софта и выделяться не будет. Ну чуть вонючее чем остальное, и к этому тоже привыкнут.
R>*Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра.
Зачем послезавтра, если после очередного релиза они разбегутся?
Еще никому не удавалось избавиться от необходимости выплачивать техдолг. Ну, кроме очевидного варианта свалить. Я уже не один раз видел, как с проекта разом сваливало 3/4 старожилов, оставив подарочек тем, кто не понял, откуда ветер дует, и тем кому потом наймут.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rosencrantz, Вы писали:
R>>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
C>Главное — варить пользователей лягушек медленно, чтобы привыкли. C>Если весь софт говно, то новый кусок гов софта и выделяться не будет. Ну чуть вонючее чем остальное, и к этому тоже привыкнут.
Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.
R>>*Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра.
C>Зачем послезавтра, если после очередного релиза они разбегутся?
Ваще вы полностью неправы. Не разбегутся если с комфортом всё ок. Просто на задачу "добавить кнопку" скажут, что займёт неделю, месяц, 3 месяца, полгода, и т.д. И проблемы тут нет. Это может звучать нелепо, но проблемы тут нет
C>и тем кому потом наймут.
Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.
Здравствуйте, rosencrantz, Вы писали:
R>Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.
Зачем экзотику? Достаточно просто не срезать слишком много углов, не пытаться экономить на рефакторинге и так далее.
Да просто тошно. Как участвовать в написании, так и пользоваться. Мы ведь здесь не совещание о стратегии проводим, а просто говорим за жизнь?
R>Ваще вы полностью неправы. Не разбегутся если с комфортом всё ок. Просто на задачу "добавить кнопку" скажут, что займёт неделю, месяц, 3 месяца, полгода, и т.д. И проблемы тут нет. Это может звучать нелепо, но проблемы тут нет
Полностью прав, потому что разбегаются. Раздолбаи — в первую очередь.
R>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.
Ты явно говоришь не о том же, о чем я. Видимо, до твоих краев эта чума еще не докатилась, так что ты с этим просто не сталкивался.
Здравствуйте, Codealot, Вы писали:
C>Здравствуйте, rosencrantz, Вы писали:
R>>Ну а вы не берите на себя ответственность за стратегию развития всего софтвер инжиниринга. При всём уважении, вы *лично* ничего не решаете. Ищите самореализации в чём-то другом. Катайтесь на велике, ходите в походы, учитесь играть на барабане. Если платят 1000 баксов за хелло ворлд на пхп, то и пишите хелло ворлд на пхп. Даже если вы примете все решения исходя из абстрактного "как надо", толку от этого не будет, а вас просто нахрен уволят, потому что притащили в проект экзотику, для которой не найдёшь дешевых девелоперов, чтобы сопровождать.
C>Зачем экзотику? Достаточно просто не срезать слишком много углов, не пытаться экономить на рефакторинге и так далее.
Углы и рефакторинг — это либо такая штука, что делаешь её молча, либо, если говоришь вслух, это ругательное слово. Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий. "Делать лучше" можно до бесконечности. И самое печальное всегда, что это "лучше" — это обычно мнение программиста Васи ("теперь я понимаю как это работает"), а не какой-то явный критерий ("выкинули нахер все instanceof"). Адекватный рефакторинг делается "заодно" — и критерием успешности выступает не чувство прекрасного, а какая-то очередная фича, которая сделана не "через жопу", а "органично".
C>Да просто тошно. Как участвовать в написании, так и пользоваться. Мы ведь здесь не совещание о стратегии проводим, а просто говорим за жизнь?
Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить. А неправ — я, потому что дал первому свободу, а второго — заапрувил.
R>>Все проблемы от того, что технология не может договориться с менеджерами.
C>Ты явно говоришь не о том же, о чем я. Видимо, до твоих краев эта чума еще не докатилась, так что ты с этим просто не сталкивался.
Вы на флажок смотрите чтоли? Я по 8 лет отработал тимлидом в России и в Америке. Примерно один хрен. В Америке сильнее держутся за место, потому что тут работа кроме зарплаты даёт ещё плюшки. Например, страховку (это без работы *минимум* ~$500 в месяц из кармана), и proof of income (приходишь снимать квартиру, тебе говорят: не нужны нам твои поганые $36,000 наличными из кармана — ты там покажи что тебе зарплату в следующем месяце заплатят)
Здравствуйте, rosencrantz, Вы писали:
R>Я никогда не дам аппрув на рефакторинг, потому мало кто может внятно определить критерий.
Говнокодеры — независимо от уровня в иерархии — не понимают, что такое "объективно лучше".
R>Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить.
Все трое. Делать решения "чтобы было по книжке" и тащить в проект ненужные паттерны и фреймворки — признак программиста, который в развитии добрался только до уровня продвинутого ламера. Те, кто книжки не читают — еще хуже. А так же тимлиды, которые не понимают зачем нужна документация и нанимают тех, кого нанимать не надо.
R>Вы на флажок смотрите чтоли? Я по 8 лет отработал тимлидом в России и в Америке. Примерно один хрен.
Значит, недостаточно отработал. В разных компаниях тараканы разных пород. Куда-то тараканы новых пород уже добрались, куда-то нет.
Но на самом деле ты споришь вообще не с тем, о чем я написал.
R>*Комфорт* важен. *Комфорт* — это что позволяет работать и сегодня, и завтра, и послезавтра. Если комфорта нет, оно неделю отработает, а дальше будет рушиться. *Охренненно* важен баланс.
Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).
Здравствуйте, rosencrantz, Вы писали:
R>Технологии позволяют всё легче собрать на коленке команду, которая возьмёт и запилит продукт.
Не продукт, а кусок говна. Инвесторы пару лет поплатят, а после то, что они запилят умрет.
А продукты в ИТ — это то что делали в 80-90-х и начале 2000-х. Всё. Всё что позже умирает сразу после родов.
Здравствуйте, rosencrantz, Вы писали:
R>Мы тут можем до усрачки спорить где граница между прототипом и продуктом Если пользуются и платят бабки, это уже бизнес пошёл. Прототип там или продукт — не так важно.
Вопрос только в том, кто платит.
Здравствуйте, Codealot, Вы писали:
C>Еще никому не удавалось избавиться от необходимости выплачивать техдолг. Ну, кроме очевидного варианта свалить. Я уже не один раз видел, как с проекта разом сваливало 3/4 старожилов, оставив подарочек тем, кто не понял, откуда ветер дует, и тем кому потом наймут.
Техдолг, он не как бомба, которая однажды взорвется и все снесет. Техдолг, он как грузы на ногах. Чем его больше, тем тяжелее идти. Но можно удвоить команду и жить с техдолгом (кому-то от этого будет очень противно, и он сметит работу).
Здравствуйте, rosencrantz, Вы писали:
R>Все проблемы от того, что технология не может договориться с менеджерами. Менеджеры не могут сказать: "что вы мне гоните, эта кнопка не может занимать месяца" — они на то и менеджеры. Это у программистов вечно шило в заднице, чтобы любая кнопка добавлялась за 2 часа. Но на самом деле это нахрен никому не нужна. В большинстве случаев за то, что вы добавите кнопку за 2 часа, а не за 2 недели вы нихрена не получите премию. Иногда вы получите премию, которая на фоне зарплаты программиста теряется. Оно всё того не стоит.
Ряд 1 + 1/2 + 1/4 + ... сходится, у него есть предел, равный двум.
У меня есть подозрение, что разработка продукта, который обрастает техдолгом, с которым никто не собирается бороться, а просто смиряются, что добавление кнопки занимает 2 месяца, а не два часа, тоже сходится. Т.е., такой продукт можно разрабатывать годами, будут какие-то новые версии, новые фичи. Но глядя трезвым глазом, у него есть потолок, которого ему никогда не преодолеть.
Хорошо ли от этого бизнесу? Ну в принципе, может быть хорошо. Мы видели много загнивающих и в конце концов ушедших технологий, которые, тем не менее, за время своей жизни приносили доход. Бизнес такое может пережить, если он способен прожить дольше, чем те продукты, которые его кормят, создавая новые продукты. И не способен, если он зависит от имеющегося набора продуктов, и новые создавать не способен.
Здравствуйте, rosencrantz, Вы писали:
R>Адекватный рефакторинг делается "заодно" — и критерием успешности выступает не чувство прекрасного, а какая-то очередная фича, которая сделана не "через жопу", а "органично".
А как в адекватных командах проводят это "заодно"? Его хоть можно отдельным коммитом провести с честным комментарием, что это именно рефакторинг? Или делаем новую фичу/затыкаем багу, а к коммиту тихой сапой кусочек рефакторинга прикрепляем?
R>Вам стратегия, а у меня просто трудовыебудни Кто-то там написал красивое решение, потом кто-то ещё пришёл и нихрена не понял. Кто в этой ситуации неправ? Один прочитал книжку и сделал "красиво". Второй книжку не читал, но свою задачу хочет выполнить. А неправ — я, потому что дал первому свободу, а второго — заапрувил.
По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).
C>Слишком часто менеджер, набирающий новых дизайнеров, подсознательно оценивает их по критериям собственной работы: «Сможет ли он хорошо выполнять ту работу, которую я выполняю?» Это благоприятствует красноречивому, лидеру, человеку, который будет эффективен на собраниях. Он имеет тенденцию упускать из виду интровертов, медлительных людей и особенно нетрадиционных людей. Но в этих упаковках есть и блестящие дизайнеры! (Я не утверждаю, что блестящие дизайнеры чаще приходят в таких пакетах. Не знаю.) Мы, менеджеры, упускаем из виду этих одаренных людей, к своей большой утрате, их и общества. Как мы можем выбрать лучше? Во-первых, напоминая себе, чего мы ищем. Во-вторых, просматривая портфолио самих дизайнерских работ, а не только устные презентации о работе.
Чтобы просмотреть работы других людей нужно самому что-то соображать. То есть дизайнер оценивает дизайнера, программист оценивает программиста и так далее. Причём люди должны иметь одинаковую специализацию.
Может ли специалист по векторной графике оценить специалиста по растровой графике и наоборот. Может ли питонист оценить сишника и наоборот. Но ситуация может быть и хуже, оценивать может менеджер потребитель.
Собствено ничего нового здесь нет. Две разные команды и даже два разных человека по одному заданию напишут две разные программы. Ещё говорят 90% стартапов проваливаются. Это уже к вопросу о том почему мегакорпорации предпочитают покупать проекты, а не пилить их самостоятельно с нуля.
А в самом начале своего пути практически все являются плохими программистами. Некоторым удаётся стать лучше с годами и десятилетиями, а некоторым нет. Но даже хорошему специалисту на создание качественного продукта понадобится много времени.
По большому счёту никого работодатели не упускают. Просто они не имеют никакого отношения к становлению специалистов и следовательно не умеют их определять.
Чтобы человек стал специалистом ему или кто-то должен платить за работу годами и десятилетиями, или он должен столько же самообучаться, но уже за свой счёт.
Работодатель же не вложив в этого специалиста ни копейки, а напротив тратя его время вдруг начинает жаловаться, что упустил "нетрадиционного слоупока". Вместо него он нанимает хитрого болтуна.
После найма нескольких болтунов до работодателя вдруг доходит, что хорошо бы посмотреть предыдущие работы людей, да и в принципе оценить их технические, а не разговорные навыки.
Но всё сводится к тому, что работодатель всё равно не сможет действовать лучше, чем самый его компетентный сотрудник. Зато он запросто может действовать как его самый некомпетентный сотрудник.
Менеджерам из таких же ничего не соображающих болтунов проще навесить на других какой-то ярлык вроде "медленный нетрадиционый интроверт". Честно признаться, что они сами нубло проникшее в компанию за счёт болтовни они естественно не могут.
Как говорится "..ть не мешки ворочить". Нет у людей элементарного понимания, что на создание качественных продуктов нужно очень много времени. И дело здесь не в интровертности и слоупочности.
Не нужно воспринимать состоявшихся специалистов с 10-20 летним опытом как данность. То что к кому-то в первый же день заглянуло несколько сотен скилбоксовых стажёров не значит, что придёт хотя бы один "слоупочный интроверт".
И если раньше говорят учили врать людей на аутсорсинге, то теперь этому учат на платных курсах. А многие работодатели как известно не ценят сотрудников. У них за забором, то есть на сайте поиска работы стоит очередь.
Здравствуйте, Pzz, Вы писали:
Pzz>Техдолг, он не как бомба, которая однажды взорвется и все снесет. Техдолг, он как грузы на ногах. Чем его больше, тем тяжелее идти. Но можно удвоить команду и жить с техдолгом (кому-то от этого будет очень противно, и он сметит работу).
Скорее не взорвется, а потянет всех ко дну. Увеличение команды тоже помогает только в определенных пределах, особенно если организовано все через жопу.
Здравствуйте, SkyDance, Вы писали:
SD>Это определение болота. Причем в силиконовке это болото обычно хорошо поет и танцует. Для амбициозных людей не подходит. Им нужен драйв. Хороший пример — всякие стартапы, ну и некоторые стили разработки (говорят, что Джобс, что Маск свой успех построили именно на этом драйве — и, признаться, я в это верю).
Pzz>По-настоящему красивое решение должно быть понятно студенту-третьекурснику. Но такие решения очень трудно придумывать (что совершенно неочевидно из самик решений, потому что уже придуманные, они понятны студенту-третьекурснику).
Истинно так. Знаю как по другим решениям, так и по своим. Когда с пятого переписывания вместо 2 тысяч строк и сотни патчей появляется файл из 400 строк и лишь с парой фиксов, — оказывается, что решение было слишком простым, чтобы его можно было увидеть с самого начала.
В том, что тебя лично прет от решения реально интересной загадки. Это может быть что угодно, от поисков этого несчастного байта (был где-то юмористический рассказ эмбеддед-девелопера про размеры программы), до выяснения, куда течет память в .NET сервисе. И до создания по-настоящему лаконичного UI. В этом смысле мне ну очень импонирует стиль Tesla, очень лаконичный снаружи.
Но вот что у них внутри, это жжжесть. Причем понятно, почему — снаружи все тот же Маск может рявкнуть "ну-ка, немедленно спрятать лючок зарядника". А внутри, в программном коде, так сразу и не заметить все переплетения спагетти.