Комментарии 109
Отличные примеры когнитивного искажения, называемого "Ошибка невозвратных затрат".
Вообще люди к сожалению очень мало внимания и времени уделяют принципам по которым работет их мозг, из-за чего мы частенько страдаем от подобных когнитивных искажений.
У этого явления много названий. Я называю его длинно "Отсутвие силы воли зафиксировать убытки".
Оно встречается по всюду. Пример из личной жизни. Машина попала в ДТП, родственник давайте отремонтируем, закажем детали. Начинает ремонт, он не идет. И вот надо бы бросить и продать как есть, закрыв ситуацию (блого по сути средства позволяли), но нет мы же деньги вложили как теперь потеряем.
Вообще очень тяжело закрыть вопрос, и зафиксировать потери (деньги, время, нервы чувства....). Это кстати одна зи причин почему люди продолжают жить друг с другом.
Или бездумная последовательность:
Как сказал великий английский физик Майкл Фарадей, последовательность порой одобряется в большей степени, чем правота. Когда Фарадея как-то после лекции спросили, не считает ли он, что ненавидимый им ученый-соперник всегда неправ, Фарадей сердито посмотрел на спрашивающего и ответил: «Он не до такой степени последователен».
Давным давно был одесский тост про умение вовремя остановиться
Почему я нажал в голосовании на третий вариант?
Вы нажали, потому что уже прочитали статью и потратили время... Ваш Кэп.
И я тоже нажал на третий, потому что последний вариант -последний, а два первых как правило неверные, хотя выглядят так же.
Число хорошее. Всегда есть три богатыря, три девицы под окном, три попытки...
В конце концов двоим скучно, а четверо неизбежно бьются на пары.
Да, из статьи прочитал только вводку. Остальное и так понятно. А вот результаты голосовалки захотелось посмотреть. И ради этого даже кликнул. На троечку, естественно.
Я не стал воздерживаться и выбрал сразу четыре варианта
Я был огорчён, когда выбрал все варианты, кроме третьего. А он был в два раза больше остальных. (голоса 29, 31, 61 и 29, то есть 23%, 25%, 49% и 23%)
По сути статьи – регулярно сталкиваюсь с подобными вещами, и умение вовремя отступить сильно помогает. Правда, для этого надо иметь более простой "план Б", на который можно быстро переключиться и быстро сделать, если крутой и навороченный "план А" занял больше отмеренного на него времени.
И это действует не только в программировании, но и в куче других сфер, что радует. Правда, силы воли не всегда хватает что-то быстро прекратить... :D
Тоже хотел выбрать третий, потом включил самоконтроль, осознал, что я не Бэтмэн, и решил воздержаться.
Я нажал на 3 просто потому что люблю это число и, если для меня нет видимой разницы, почти всегда выбираю этот вариант
Я нажал на третий вариант по очень простой причине. Из многих вариантов при прочих равных я отбрасываю первый и последний. Остаются второй и третий. Из двух вариантов при прочих равных я выбираю второй. Все, алгоритм в два прохода при n = 4
Потому что там три слова?
Я прочитал пару абзацев по диагонали, занёс мышь над 3-м вариантом, потом подумал, что это слишком банально и наверняка 3-й победит, а меньше всего голосов будет за 2-й, щёлкнул на 2-м. Мне больше интересно, какой всё-таки вариант в итоге проиграет.
Потому что там машина уже разогналась вовсю, а тупичка пока не видно!
Имхо надо иметь одно важное понимание: если ты наемный работник, то продукт ТЕБЕ не принадлежит. И код тоже НЕ ТВОЙ. Поэтому решение надо принимать, руководствуясь тем, готов ли ВЛАДЕЛЕЦ оплатить время и затраты на рефакторинг, а не бросаться с головой в омут. Для этого надо САМОМУ понять глубину кроличьей норы, прежде чем лезть за ЧУЖИМ кроликом. А потом обсудить с хозяином время и бюджет. И только потом копать.
Рефакторинг такая же работа для тебя, как и добавление новой фичи. Для хозяина - нет. Он должен понять, что это необходимо ему и ЕГО продукту.
Со своим личным проектом, конечно, всё проще - ты сам себе хозяин кролика. А кролика надо любить и ухаживать за ним, чтобы не умер с голоду или от ожирения :)
Делать красиво или копипастить говно вызывает разные чувства. Но конечно дядя, который платит должен быть в курсе, за что он платит.
Хотя иногда рефакторинг + задача стоит столько же по времени, сколько задача. Тогда можно просто оценить задачу и не вдаваться в подробности, если этого не требуют.
Все таки код принадлежит команде разработчиков, владелец обычно не имеет знаний про то как качество текущего кода влияет на скорость и надежность разработки, поэтому команде разработчиков придётся платить технический долг. Да конечно есть разные подходы как делать рефакторинг - как часть фичи или потом отдельно, но как бы то ни было это делать придется и иногда придётся даже лукавить владельцу если вам не все равно какое качество кода вы выдаете
Если продукт опенсорсный (и код доступен через vcs) - это инвестиция в собственную репутацию. Для этого пишутся вменяемые коммит-месседжи, для этого вообще всё затевается. Чтобы даже (если) всё не взлетит - на будущих собеседованиях ты мог показывать свой реальный ход мысли в этом реальном проекте.
А если взлетит - это инвестиция самому себе. Потому что когда-то придётся разбирать старое легаси, и описания решений, где бы они не были, очень помогут!
Я бы добавил, что опыт работы с опенсорными проеками дает и хороший буст в коммуникациях, особенно если вы вносите довольно крупные изменения и вам нужно обосновывать их значимость. Мне несколько раз приходилось повторять одно и то же, приводить разные аргументы, формулировать мысли по-другому, чтобы в итоге мои изменения посчитали полезными и приняли.
Живу в геймдев сообществе последние 20 лет. И знаете, вижу обратную ситуацию:
люди вкладывают огромные ресурсы, пишут движки, делают готовые демки игр... А потом бросают и начинаю заново новый проект.
"Алё! У тебя почти готовая игра! Допили и выкинь на рынок! Хоть какая-то отдача будет!"
Но нет. Проект задвигается и цикл повторяется.
Это что за когнитивное искажение?
Видимо больше нравится сам процесс, чем любой результат
Я бы предположил, что люди просто не видят желаемого "вау-эффекта" от того, что они наваяли.
Я пишу электронную музыку и пока начинаешь только работу над идееей трека тебя захватывает каждый такт, а когда доходит до мастеринга (слушаешь один и тот же трек 100500 раз) то тебе кажется что трек твой скучная фигня. Делаешь мастеринг и забываешь про трек на пару месяцев, а потом возвращаешься к нему и вот сразу чувствуешь то что было в начале и конечно же косяки мастеринга которые замылились в процессе мастеринга.
"Почти готовая игра" - это игра, готовая на 90%. А вторые 90% кто делать будет?
Так и получается. Если разработчик или команда считают, что вытянуть вторые 90% у них не выйдет, то первые 90% - мёртвый груз.
Правило 80/20. Это только кажется, что почти готовая игра почти готова. Как правило, от готовности её отделяет в разы больше работы, причём рутинной и ресурсоёмкой, а также просто непонятной для компетенции разработчиков (релиз игры тоже работа, требующая совсем других талантов). Самое интересное на момент почти готовности уже сделано, а если ещё и демка показана, то основной выхлоп уже достигнут, награда получена, и перспективы более не видны. А вот вагон трудностей впереди становится уже хорошо виден.
Ну а готовность движка в контексте игр - это вообще крайне малый процент от готовности проекта. В играх начиная с 90-х годов контент преобладает над кодом в огромном непропорциональном соотношении, весь код - это пара процентов от объёма работ. И остальные работы требуют совершенно других талантов, причём очень высокого уровня, то есть это вообще не решаемо для автора движка, а получение даже высокооплачиваемой помощи через привлечение других талантов - это ещё один очень специальный скилл, совершенно не похожий на написание кода.
Нет. Я говорю о реальных 80% проделанной работы. Собственно те, у кого такой проблемы нет - наводняют рынок и зарабатывают на нём. Те кто не могут сделать шаг - получают кучу почти готовых проектов.
Я предполагаю что причина в боязни релиза. Что игра провалится, что игра не принесет ожидаемого результата. Ведь если не релизить - этого точно не случится.
Меня эти рассуждения заставили откопать один старый проект, который мы с другом почти сделали. Там действительно игра в состоянии "неделя работы и можно релизить". Но основной довод друга на моё предложение проект доделать сегодня: "я хочу чтобы проект был хорош, а на это у меня сейчас нет времени"
Правило 80/20 - 80 (реальных) процентов работы занимают 20 процентов времени, оставшиеся 20 (реальных) процентов работы занимают 80 процентов времени.
Те, кто наводняет рынок - едва ли зарабатывают, разве что чисто формально, больше нуля. Наводнение - это индикация низкого порога вхождения, по тем или иным причинам. Если смог наводнить один, наводнит и другой и ещё тысяча человек, а ёмкость рынка конечна, и в итоге и без того невысокий профит размазывается по множеству разработчиков. Даже очень успешные независимые разработчики не сильно-то зарабатывают, и множество студий закрывается после первого внешне успешного релиза.
Вы ошибаетесь. Те кто наводняет рынок получают стабильно свой кусок пирога. Те кто наводняет конкурируют друг с другом, но вполне себе живут. 50К долларов в месяц на одиночку вполне реальная цифра.
Вот тем кто делает хорошие игры, на этом рынке сложнее. Потому что ты всё равно вынужден плавать в море мусора и тебя в нём не видно.
Но это лирика, я не про рынок писал, а про людей.
Я не ошибаюсь, а транслирую свой опыт в той же области, и он значительно отличается от вашего. Я не знаю никого, кто получал бы 50K в месяц на одиночном инди проекте, включая тех, кто занимается этим десяток лет в качестве своего основного занятия. В моей реальности у большинства инди игр даже общая сумма продаж за всё время не достигает таких значений.
Я ничего не понял. Какие одиночные проекты?
Речь про "наводняют рынок". Массово заливают рынок простыми играми.
Тогда это называется длинный хвост продаж - есть условная сотня плохих игр, но какие-то продажи идут, и в сумме на долгом периоде получается какая-то прибыль. С разработкой это имеет мало общего, под такие цели обычно скупают чужие проекты за копейки. Есть конечно и такие уникумы, которые могут выпускать по две игры в месяц, но это совершенно определённо не норма.
Посмотрите на график ретеншена и сразу станет понятно (они не только к игрокам относятся).
На первый день проект кажется "вау бомба!", на второй "классная идея", на 7-й "прикольно". Через пол года разработки "ща блевану", "всё что угодно только не это", "я вам сам заплачу только чтобы это больше никогда не видеть".
При этом объективно игра может быть очень крутой. Для игр обладать нулевым долгосрочным ретеншеном это вообще скорее правило.
А разработка всё только усугубляет. Ты на протяжении долгого времени играешь (тестишь) недоделанную, недобаланшенную забагованную штуку. Под конец ещё и тоннельное зрение начинает добавлятся и ты вообще перестаешь понимать что круто а что нет.
Возможно это невротическое проявление перфекционизма, когда основная преграда для личности (точнее для деятельности) заключается в попытке защититься от болезненной, невыносимой критики, через бесконечные итерации переделывания.
Имхо это что-то вроде погони за журавлем в небе вместо синицы в руках.
Т.е. люди хотят сделать идеальную игру, а выходит нормальная игра. Но хочется идеальную. И нормальную выкидывают в мусорку даже не доделав. Потому что нужна идеальная.
А вся фишка в том, что идеальный результат недостижим.
Много всего вспомнилось, читая истории и ситуации из статьи.. Самый ранний опыт из двухтысячных, когда на, долгое время, успешной дружной фирме начались задержки по зарплате (сменилось законодательство, а направление деятельности фирмы не имело никакого другого даже подстраховочного продукта) и весь офис приходил просто потому что жалко потерять начисленную, но неполученную зарплату. Выплачивали мааленькими частями, при этом общий долг накапливался лавинообразно. И по сейчас, то там, то там, встречаю различные вариации добровольного якоря надежд на обещания.
Очень сильно держит хобби, особенно когда находишься в его потоке.
P.S. Выбор голосовалки напомнил ситуацию выбора ключа на антивирус).
Я бы не стал писать регулярку на проверку маску IP, потому что явно это легче проверить иным способом.
Может, на то и вопрос был? Ну типа если поставит минимальную разумную проверку (такую, чтобы регэксп читался) и скажет "а дальше проверяем при парсинге в бэкэнде" – значит, разумный человек.
Да там ничего сложного (PCRE2):
^([1-9]|([1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$
127.0.0.1 не распарсится - надо поддерживать одиночный ноль в 2-4 октетах
Да, спасибо, очепятался в первой подгруппе, вот так правильно:
^(\d|([1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$не совсем - в первом октете, мне кажется, одиночного нуля быть не может. Хотя надо RFC читать
был неправ - вполне может быть 0 в любом октете
Да, может, просто 0.0.0.0/8 зарезервирована.
Бонус: при исследовании поведения этого самого контрола в окне свойств подключения обнаружил баг: через копипаст в октет можно вставить число гораздо длиннее ожидаемого.
01.01.01.01 является валидным адресом, но не матчится.
А ещё мало кто знает, что IP адрес можно записать одним 32-битныим числом. Попробуйте ping 2130706433
01.01.01.01 является валидным адресом, но не матчится.
Согласен, бывает, что нужно валидировать адреса, введённые людьми. Тогда так:
^(0?0?\d|(0?[1-9]\d)|(1\d\d)|(2([0-4]\d|5[0-5])))\.(?1)\.(?1)\.(?1)$А ещё мало кто знает, что IP адрес можно записать одним 32-битныим числом.
А вот тут мои полномочия всё :)
127.1 тоже валидный адрес ;)
Нули в середине можно опускать. (Кстати, в ipv6 тоже так).
В линуксе ping работает именно так. Под windows 7 было так же, кажется в 10 переделали.
docs.microsoft.com/en-us/windows/win32/api/winsock/nf-winsock-inet_addr
0..255 кто будет проверять?
Думаю, за 10 секунд можно сделать что-то типа \d{1,3}\.\d{1,3}\.\d{1,3}\.\d{1,3} , в большинстве случаях этого достаточно. Я бы сделал так, сказал бы, что оно пропустит и невалидные IP, и надо ли проверять на [0-255] ?
Пример с 2-мя месяцами - эталонный вариант успеха.
Сдалали MVP из копролитов и целлюлозы, потом поняли, что нужно, и переделали как надо.
А если бы бы сразу реализовывали как надо - все равно вышла бы ерунда под выброс. Потому что требования поменялись.
2 месяца - это не потеря. Это наработка экспртизы, это исследования, это рабочий прототип для быстрого старта, решающий сиюминутные потребности заказчика.
Это что угодно - но не потеря.
такому даже название есть - PoC
Monolith first - хорошая практика. Если с правильной архитектурой изначально зайти, не нужно будет потом с нуля все заново писать.
Спасибо за статью, хорошие примеры! Ничто иное не далет проблему существенной, как подтверждение о её важности от другого лица.
Но хочется отметить некотрую недосказанность, наверное вам стоило бы рассмотреть факторы, и побольше написать о "звоночках", и например, сравнить со случаями, когда из-за медленной реализации проекта кажется, что дорога ведет в тупик, хотя на самом деле дорога идёт в гору возле локального максимума.
Так же не могу не отметить, что в конце статьи вы вмешались в ход эксперимента вашим заголовком "Мне реально интересно, какой вариант ответа выиграет в этот раз и почему". Прочитав эти строки самостоятельно и непринужденно задаешь этот вопрос себе, и поскольку он развлекательный, то первые мысли будут связаны с областью развлечений. В качестве ответа фраза "Бог любит Троицу" всплыла раньше, чем были осмотрены пункты опроса. На данный момент, не могу сказать, благодаря какому шоу или шутке эта фраза закрепилась в голове. Но перед голосованием я предположил, что третий пункт вырвется вперёд, и считаю, что именно отсутствие каких-либо распространенных шуток, связанных с числами, приведи в равномерному распределению в остальных вариантах.
В RPG за победу над бесполезным мобом дают экспу. Это вполне разумная метафора для потраченного времени. Если время было приложено по делу, но результата нет (или он ни о чём), остаётся опыт. Чем больше одного и того же моба фармишь, тем меньше опыта. Но первые мобы - это самое нажористое, от них левелы так и прут.
Хорошее сравнение)
Ну так вообще можно договоириться до Дзен-будизма и философских материй. В принципе нет ничего полезного или бесполезного, важно лишь Ваше отношение к этому.
Всё ведь на самом деле в голове. Любую ситуацию автора можно развернуть на 180° и сказать, что я получил супер важный опыт который потом в жилзни мне сэкономил 1000 часов.
По сути это отношение к жизни, например:
"не опоздал на самолет, а значит мне нужно в другое место"
"не потерял 100500$ на бирже, а уберёг себя от не нужной мне траты"
"не просрал собеседование, а одна дверь заркылась 10 открылось"....
Ну так вообще можно договоириться до Дзен-будизма и философских материй.
Всего лишь до обычного рационализма, иногда в виде защитной реакции. И, иногда, болезненного рационализма, как одного из синдромов какого-либо психического заболевания.
Для Дзен-буддизма все же более характерна отстраненность и принятие случившегося как есть, а не рационализация:
Опоздал на самолет? Ну и что в этом такого.
Потерял 100500$? Это не трагедия.
Просрал собеседование? Жизнь продолжается.
PS. Но если вы видите, что рациональный флегматик бегает в истерике, и вы не в дурдоме, значит пора вырывать первую страницу паспорта и скручивать в трубочку.
На каждое правило находятся исключения.
Джефф Хинтон упорно занимался нейронными сетями лет 30. За это время появилась куча куда более перспективных конкурентов - HMM, SVM, первые рекуррентные сети... Не то что нейронки Хинтону ничего не приносили - всё же он был полным профессоров в уважаемом универе, но он бы так и остался малоизвестным учёным из периферии, если бы не настойчивость.
Эдисон сделал несколько тысяч бесплодных экспериментов в поисках материала для нити накаливания. Годы, потраченные впустую, с точки зрения окружающих.
Десятки операционных систем, сотни человеко-лет. Выстрелили две или три. Стартапы, где выживает каждый двадцатый. Некоторым просто повезло, а некоторые просто сдались слишком рано. Умение вовремя остановиться и упорный труд с верой в себя, когда целый мир против - кто подскажет что важнее?
Знал бы прикуп, жил бы в Сочи.
Еще как следствие этого искажения (а может, не сделствие, а новое искажение) - это то, что некоторые считают, что чем больше фактов приведено ради подтверждения высказывания (или чем больше "а если" приведено против высказывания), тем это высказывание становится правдоподобнее. Но нет, на то, правдой является высказывание или нет, количество фактов никак не влияет
А ведь Антонио Страдивари говорил своему брату: "Карло, завязывай с этой ерундой. Делай скрипки!". А тот всё твердил: "За шарманками будущее, за шарманками будущее..."
про "сожги" - хорошо. я сам стараюсь использовать две поговорки "лошадь сдохла - слезь" и "чем ярче горят мосты за спиной тем лучше видно куда идти". они как "якоря", которые помогают бороться с конгинтивным искажением о невозвратных затратах.
Помню, давно уже, работал в одном проекте на С, проект довольно прикольный был, с упором на производительность. Писалось все на скорую руку, и там частенько бывали проблемы с утечкой памяти и сигфолтами. В общем, я решил раз и навсегда положить этому конец, и начал ваять такую библиотеку, которая упрощала бы работу с памятью. Накатал какое-то неимоверное количество кода, прикрутил это все к проекту, начал отлаживать. В проекте появилась масса проблем, связанных уже не с выделением и освобождением памяти, а с моей этой библиотекой, проблемы росли снежным комом, и в какой-то момент я понял что я пытаюсь соорудить какой-то кривой сборщик мусора, похожий на то что есть в JVM, только намного более глючный. И вот тут мне хватило ума и здравомыслия, наступить на горло своей песне и выпилить эту хрень из проекта, вернувшись на исходные позиции. Вычистить код от утечек оказалось намного легче и быстрее чем пытаться прикрутить мою убер библиотеку.
Решение выбросить все к черту, было верным, но очень тяжелым. Рад что все-же на это решился, это мне дало ценный опыт - не надо упорствовать в продвижении по неправильному пути. Как только приходит осознание его ошибочности, лучше вернуться назад и попробовать другой маршрут, чем зайти в такие дебри, что уже назад вернуться не получится..
Никогда не сдавайся! vs Если лошадь сдохла - слезь!
ИМХО тут задачка как предсказать будущее. Кто умнее или удачливее - тот предсказывает правильней.
Я как-то пилил некий сложный продукт - куча математики + связь с программами написанными другими людьми. В какой-то момент я уже перестал понимать как и что у меня работает (там была куча обратных связей) я был близок к тому, чтобы сделать то, что предлагал автор статьи и друзья советовали то же самое. Но... было жалко и лениво всё переделывать. Я как-то разделил всё на блоки, расписал комментарии и... оказалось, что оно вполне неплохо работает. Народ получил продукт и остался доволен.
Он развивает идею и 40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра.
Не знаю насчёт 40 лет, но судя по статье и комментариям, у автора либо шиза либо маразм.
Знакомо, на прошлой неделе столкнулся со сложным функционалом, если вкратце - отправление пуша по определенным условиям. 3 дня писал код, уже покрыл все тестами, и уже когда залил код на ревью, вспомнил - лучший код это тот, которого нет. Написал аналитику и мы решили сделать намного проще (массовая рассылка), поэтому я снес все что делал и написал решение в 100 строк. Да, не идеально, но бизнес задача решена и почти никто не заметит разницы.
Да, часто такое бывает, что неделю ломаешь голову над чем то, все получается криво и медленно. Тогда бросишь все это, работаешь неделю над другими задачами. А потом начнешь писать с нуля и за день получается красиво и быстро, как в учебниках. Часто мозгу чтобы придумать что то хорошее нужно сперва сделать неудачную попытку, а после нее еще и отдохнуть, переключиться на какое то время.
Завел себе правило: когда начинаешь какой-то проект, в незнакомой тебе предметной области, то первая версия считается черновиком.
В черновике разрешается г-нокодить по полной, на эффективность, обработку ошибок, утечки и пр. сознательно забивается. Основной упор делается на простоту и ясность кода.
После достижения понимания о том, что и как должно работать, черновик безжалостно выкидывается и код пишется с нуля (однако, разрешается копипастить удачные фрагменты).
Если с самого начала настроится на то что код будет выкинут, то потом намного легче с ним расстаться.
Это же великое правило, облегчающее жизнь перфекциониста и прокрастинатора, достойное быть выбитым в граните:
«Зачем тянуть до последнего и делать все плохо, когда можно сразу сделать плохо и останется время переделать».
Лишь бы не получилось так, что в момент когда пришло время выкидывать черновик и переписывать с нуля, на вас не начинают давить в плане - дедлайн (о котором вас никто на берегу даже не предупреждал, или предупреждал, но он внезапно переместился на ранние сроки) был уже позавчера, поэтому не страдай фигней - лей в прод то что есть!
В итоге черновая версия "отливается в гранит" (Ц) и остается с нами навечно. А следующий поколения разработчиков смотрят на все это с недоумением - ну как-же можно было так наговнокодить! :)
А это не прототип называется? =) Тут правда бывает так, что накидаешь черновую версию, добиваешься того, чтобы дышало, а руководство:
И так сойдёт.png
Бывает, что кто-то изобретает вещь, как ему кажется, революционную, и вкладывает в неё душу - этакий крестраж. Он развивает идею и 40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра. Потом он постит её на Хабр и ему все говорят, что это просто провал. Будь это вы, стали бы вы сомневаться в какой-то концепции, если живёте с ней 40 лет и даже применяете её в жизни? Да хрена с два!
я подумал, что ссылка будет на язык ДРАКОН :-)
И оно получилось. Да, мне пришлось всё переписывать, но я уже знал, что нужно бизнесу, и писал именно под новые требования. Мы потеряли время на этот "откат", но зато стали двигаться вперёд быстрее.
все правильно, так и должно было быть. В смысле - на старте вы и клиент не видели всей картины и забахали минимально работающий прототип. В процессе - требования поменялись и на вторую итерацию уже надо все сжечь и сделать с нуля. Все ок. Это лучше, чем начать строить уберсамолет, а потом выяснить, что он сделан не так.
В целом - статья очень хорошая. Видел на хабре аналоги про тему "когда нужно фиксировать убытки" и эту самую психологическую ловушку, что "осталось еще чуть-чуть, давайте поднажмем", но, к сожалению, найти не смог
А я сенунд 30 выбирал в голосовалке вариант ответа, но потом вспомнил суть статьи и выбрал №3.
А ведь говорят, что, в действительности, мозг уже принял решение, а мы колеблимся и наивно полагая, что у нас есть выбор и пытаемся сами принять решение. Хотя это иллюзия и решение уже принято где-то в подкорках головного мозга. Об этом, кстати, рассказывал Андрей Курпатов.
Тут главное чтобы антирефакторинг не вошел в привычку
Один раз сделали по-быстрому - только добавив колонки,
второй раз, ну потому что фичу надо было сроко, потом, третий ...
И вот вы уже в конторе второй года только и делаете что копи-пастите разрастающее ся легаси.
Когда то надо стукнуть по столу кулаком.
40 лет примеряет её то здесь, то там, и даже обучает ей других по воскресеньям в 10 утра.
40 лет насыщенной, полноценной, возможно, счастливой жизни, не та ли цель, который достигает соискатель?
Структурирование времени по Берну, форма игры, одно. Способно дать хороший выход, но он не главное. Конкретный результат, полученный в течение n времени, а если не получен, то бросаем, совсем другое.
Тогда уж надо перестать складывать мили и градусы.
Человек занимался 40 лет стартапом и вдруг все бросить - это значит выкинуть 40 лет своей жизни, признать, что все что ты делал - бесполезная хрень. Решиться на такое и сделать - это нужно иметь железную силу воли, на такое способен один и тысячи.
Я много повидал в командировках на заводах изобретателей, которые много лет пилят какую-то рационализацию или "революционный прорыв", но по факту он оказывается никому не нужным. и они продолжают его пилить, плачут, жалуются что их "гений" не понимают, денег не выделяют , изобретение не внедряют. Грустно...
По кейсу "6 часов" - абстрагировать не вариант? Просто спросил.
Иногда просто не получится бросить и сжечь. Нужно сначала дойти до того момента, когда приходит понимание, что вот уже сейчас нужно бросать.
Я это понял, когда на предыдущей работе вёл один внутренний проект. Нужна была связка 1С с одной системой: своя база данных, особая структура этой базы, неинтуитивная внутреная логика этой системы, которая не ложилась на логику 1С. Опыт был занятный. Все с кем я общался по поводу такой связки говорили одно и тоже - бесполезно. Типа, будет потрачено больше времени, чем результата получится в итоге. Оказалось это почти правда. Реализовать связку возможно, но понятно это стало только после того, как первую версию связки через два года реалиации я выкинул на мороз, и начал переписывать всё с нуля, учитывая все нетривиальные решения, которые я открыл для себя в процессе написания первой версии. В тот момент меня спасало то, что работодатель вообще не интересовался процессом разработки этой связки. Это давало мне свободу реализации, и практически безграничное время на реализацию. В другой ситуации, возможно, первая версия так и осталась бы единственным вариантом реализации.
Возможно более правильно указать, что хорошо, что приходит понимание, что пара бросать и делать с нуля. И есть желание это сделать. И плохо, когда понимание не приходит, или приходит, но желания начинать с начала нет.
Я тоже проголосовал за третий номер. Но почему?
"Если лошадь сдохла, слезь с нее" старая, но актуальная пословица
Как здорово, что мы не на уроке литературы, и автор может сказать именно то, что хотел сказать автор.
Спасибо. Читал на уроке литературы.
Несколько секунд выбирал между 1м и 3м - и в итоге тыкнул 2й.
Когда несколько лет назад увольнялся с одной из предыдущих работ, шеф на прощание подарил книгу "Искусство отступать". До сих пор не прочёл, но в начале книги мысли похожие.
Когда пешком идти полчаса, а ты уже простоял 30 минут на остановке в ожидании автобуса...
Когда голосуешь зв третий вариант, чтобы проверить, что большинство проголосовало за него.😁
А статья хорошая и посыл в ней правильный.
У меня есть гипотеза, что человеческое время — единственное, что имеет ценность, так как жизнь человека конечна. Тот же биткойн ценен потому, что его долго майнить. Золото сложно (а значит и долго) добывать. Картины долго рисовать. Именно поэтому они и ценны. Деньги чаще всего мы платим кому-то для того, чтобы этот человек уделил нам своё время.
Отсюда следует, что нельзя просто так взять и, например, прожить жизнь, занимаясь фигнёй. Это уже и не фигня получается, а что-то ценное, пусть даже и для ограниченного круга лиц.
Вот тут, я думаю, и разгадка — нужно оценивать широту того круга лиц, для которого потраченное время имеет ценность. Это даст нам понятие о ликвидности потраченного времени, что означает лёгкость монетизации этого времени (читай — лёгкость обмена этого времени на время других людей).
С другой стороны, если отказаться от ценности человеческого времени, можно прийти к абсурдной ситуации, когда вообще всё имеет нулевую ценность. Художник рисует бессмысленные картины, которые у него покупают бессмысленные люди за бессмысленные деньги, и вообще на Земле (бессмысленной планете) живёт бессмысленное человечество, бессмысленно сменяя поколения за поколениями. Мы тогда ничем не отличаемся от плесени.
Сожги и начни заново