По такой логике — а если продукт провалился и принёс убытки, депремировать всю команду? Даже если они все заранее знали, что он рискованный и имеет лишь 10% шанса «выстрелить» — и в итоге, закономерно, «не выстрелил», хотя и был технически выполнен на отлично и в срок — просто рынок был уже занят. Это ж было не их решение, начинать проект — такие решения принимаются куда выше по цепи.
Так все просто будут идти только в многообещающие проекты, раз уж там премируют даже за срыв сроков и бюджетов. И избегать всего остального.
Конечно, с точки зрения программиста я бы сказал, что команду программистов следует премировать и за работу, и за результат, и за энтузиазм, и просто за позитивное отношение к работе. Вообще нельзя не премировать (разве что совсем невезучих лентяев-злодеев, не попавших ни в одну категорию). Лично мне было бы только лучше, если бы так было, но я понимаю, почему может быть и не так.
Заметьте, я не говорю, что премировать ни в коем случае нельзя. Для мотивации можно и уборщице премию выписать по случаю продажи миллионной лицензии на продукт (даже плохо работающей). Просто это вряд ли сильно повлияет на продажи следующего миллиона лицензий.
А фрилансер встречно будет мне уделять 8 часов рабочего времени в день, не отвлекаясь на стопицот других заказчиков? Если так — то я готов платить ему как постоянщику
Отвлекаются на другие заказы потому, что заранее предполагается, что вы этого фрилансера по окончани проекта «уволите». Причём не постепенно, как постоянщика по КЗОТ, а сразу.
Никто не хочет по 20 раз в год превращаться в безработного с туманной перспективой, потому и ведут параллельно несколько проектов. К очень долгим проектам это, естественно, не относится.
Или как Factory Idle, которая отсекает все возможности выбора и размещения зданий строительных игр, оставляя только дерево апгрейдов и развивающийся город:
Абсолютная неправда. В Factory Idle нужно именно строить фабрику и оптимизировать размещение строений и конвейерные линии. Если кто-то из читателей хоть раз испытывал удовольствие, пытаясь красиво развести печатную плату или оптимизировать низкоуровневый код — не упустите шанс попробовать, она браузерная всё равно.
А вообще, лично мне такие игры, как ни странно, помогают оставаться продуктивным. Вместо ожидания очередного апгрейда, можно просто поработать, на время забыв про игру и вернуться, когда уже снова начнётся интересная часть.
Плюс, там и для любителей подумать есть где применить мозги. Помимо строительных Reactor Idle, Reactor Incremental и Factory Idle, почти в любой игре прогресс полностью зависит от решений игрока. У вас есть 100к денег, стоит ли купить несколько дешёвых апгрейдов или один дорогой? Или «перезапустить» игру сейчас с бонусом к скорости, потому что так через 8 часов получится больше прогресса?
Ну и просто приятно наблюдать за прогрессом чего-то, к чему приложил руку. Кто-то для этого заводит комнатные растения, кто-то — дачу, кого-то радует количество перепостов его картинки-мема, а кого-то — успехи сына-первокласника. Каждому своё.
Почему лишним? Почему человек вообще должен работать? Я считаю, что человек должен творчески и интеллектуально самореализовываться.
Я так тоже считал, лет 12 назад, когда учился в школе, жил с родителями и играл в ММО-шки весь день. А когда начал «жить на свои» и кормить не только себя, само пришло понимание «почему человек должен работать». Тут даже не то, чтобы должен, а просто почему так происходит.
Но вообще, «лишнее», это то, что человек сам определяет таковым.
Ну, чтобы не умереть с голоду можно и унылые задачи иногда поделать вполсилы. Но при этом ты понимаешь ради чего ты их делаешь, сделал по-быстрому, что требуется, чтобы получить зарплату, а всё остальное время тратишь на интересное.
Зарплата зарплате рознь. Кому-то и 10к — зарплата, а кому-то и 50к — нет.
Подумать о том, чем ты действительно хотел бы заняться. Очень сомневаюсь, что это будет просмотр сериалов. Наверняка хочется заняться изучением чего-то, созданием какого-то своего проекта.
Если бы изучение и свои проекты были интереснее сериалов и компьютерных игр, то сериалов и игр бы не существовало. Практика показывает, что это не так, и большинству людей свои проекты не интересны (особенно если пару раз уже на этом обожглись).
Видимо, недостаточно явно описал в статье, попробую пояснить ещё раз.
Если введя новую фичу в проект, программист не поломал всё подряд, а фича работает — значит, это уже достаточно качественный код.
Иногда к коду также есть дополнительные требования — переиспользуемость, понятность, соблюдение стайл-гайдов. Чаще всего этих требований нет.
Но дело в том, что даже «чтобы ничего не поломать» и «чтобы скомпилилось, не тормозило и в целом работало» — уже требует сосредоточенности. Представлять себе это «минное поле» проекта, вспоминать, где и что может пойти не так.
Зависит от проекта и задачи, конечно. Ту же валидацию е-мейла можно допилить к полю ввода и не просыпаясь, а вот, например, «добавить новый тип пользователей с ограниченными правами» уже так просто не получится, даже если говнокодить.
Нужно вспоминать, где в проекте уже есть проверки на тип пользователя; как они себя поведут, если он новый; где вообще есть список типов пользователей, или оно всё в хардкоде; а если в хардкоде, то может пора переписать по-нормальному, ведь на неделе ещё 5 типов добавлять собираются; а может и так оставить, вдруг быстрее будет. Вот с такими задачами и бывает, что человек просто не может заставить себя начать неделями.
Короче, если вы не используете формальные методы для доказательства корректности кода, то о какой безошибочности вообще можно говорить.
«Безошибочный код» в данном случае — код, который работает и, в общем, выполняет требования заказчика, а не в смысле идеальный. Если у вас функция выдаёт фигню, когда пользователь указал нулевое или отрицательное значение физической величины (вес, длина) — это не так страшно, по крайней мере для большинства проектов. Но если у вас 20 + 20 = 2020 (привет, JS), то это уже ошибка, которая перечёркивает собой всю остальную работу.
А насчет прокрастинации — может её вообще не существует? Если вам не хочется заниматься какими-то задачами, ну, значит они не достаточно важные и интересные? Значит, то чем вы занимаетесь в данный момент более важно?
Работа «в данный момент» никогда не бывает важна, потому что положительный результат от неё приходит намного позже — после того, как выплатят зарплату и после того, как эти деньги на что-то понадобятся.
А прокрастинация существует, если человек занимается чем-то явно лишним вместо работы. Если этот конкретный час он всё равно не смог бы работать, это уже не прокрастинация, даже если дело с виду бесполезное. Статья о том, что некоторые «бесполезные дела» важнее других.
В случае непонятных багов — это другая ситуация, тут не возникает такого состояния, когда «точно известно, что делать дальше». А вот, например, когда баг найден и исправлен, и следующее действие — просто скопировать то же самое исправление ещё в 3 похожих участка кода, то тут я бы как раз и остановился (если, конечно, это не критичный баг в продакшене и подождёт до завтра).
На мой взгляд, в этом отношении программирование ни на йоту не отличается от многих других областей деятельности. Вот менеджеры в ходе почтовой переписки какое-то решение выработали, потом в протоколе его зафиксировали, и оно стало обязательным к исполнению. Сколько будет стоить их ошибка? Вот технический писатель готовит комплект документации и допускает ошибку. Сколько она будет стоить, учитывая тысячи возможных пользователей?
Примеры, которые вы приводите, тоже относятся к системному решению задач (для решения задачи создаётся и продумывается система) и, да, в них отчасти справедливы те же принципы.
Разница тут, на мой взгляд, не в цене ошибки, а в «дискретности» результата. Т.е. например менеджеры решили, что для замены сломанного компьютера работники должны писать заявку, а соответствующий отдел должен её регистрировать и высылать ответ. Если они не оговорили точный формат заявки и ответа, то люди на месте разберутся, «что-нибудь придумают». Программа же без чёткого формата просто не отработает.
И если менеджерам просто укажут на недоработку, то программисту ещё нужно будет доказать, что он вообще что-то делал, а не просто так сидел. И это не всегда возможно.
Поэтому, с точки зрения прокрастинации, менеджер и может себе позволить ответить на email-переписку невыспавшимся и прочитавшим по-диагонали, он не будет перед этим часами сидеть и приходить в нужное состояние.
Было бы также интересно почитать, как вы справляетесь с частой проблемой low-cost разработки — капризными клиентами, которые выбирают малобюджетные варианты, а потом пытаются «выжать все соки» из заказа, потому что денег на доработку не предвидится.
Меня всегда в таких задачках напрягает их оторванность от реальности. Они, конечно, неплохо подойдут как «тема для разговора» на собеседовании, но делать прямое соответствие «кол-во правильных ответов — шанс на приём» я бы крайне не рекомендовал. Потому что в реальности многие эти «решения» неприменимы и ущербны.
Поясню мысль.
Первая задачка (с последовательностью без числа) в реальности может встретиться, например, при работе с БД. Есть список каких-то записей (юзеры, товары, транзакции — не важно), у них есть ID от 1 до N (autoincrement), есть некая функция, которая их удаляет, нам нужно узнать, что было удалено.
Тут стоит заметить, что во-первых, обычно используется не удаление, а установка какого-нибудь status: disabled (или установка null в поле, если прямо так необходимо избавится от информации). Удаление может вызвать кучу проблем и головной боли в последствии, не надо так.
Во-вторых, обычно всё-таки не должно возникать ситуации «у нас в БД что-то пропало, неизвестно что». ID удалённого объекта должен записываться в момент удаления и обрабатываться сразу же.
Но ок, допустим, какое-то вероисповедание нам не позволяет исключить возникновение такой ситуации. Тогда в-третьих: даже если мы делаем проверку суммы сразу после удаления чего-то, никогда нет гарантии, что в самом деле что-то было удалено, или что была удалена только одна запись. Даже если сегодня это так, завтра функцию могут переписать.
В итоге, человек, который считает, что ответ с суммой — окончательный и достаточный для продакшена будет просто не прав. Тут либо переделка структуры, либо полный перебор ID'ов.
Вторая задачка (кувшины) — ну ок, лёгкая, математическая, чтобы решающий почувствовал себя увереннее. К IT отношения не имеет от слова «совсем».
Но вообще в реальных задачах такого типа (когда есть возможность что-то решить, нестандартно используя существующие объекты), нужно в первую очередь начать задавать вопросы.
Почему такая задача вообще возникла и к ней не готовы? Может, в ТЗ опечатка и нужно всё-таки 3 литра?
Почему у нас нет кувшина на 4 литра? Может, он всё-таки есть и стоит его поискать? Чтобы не занимать те два кувшина, которые явно уже предназначены для других целей и могут понадобиться остальным.
А если скоро опять возникнет такая задача? А если в следующий раз — 1/4 литра? Может, стоит озаботиться покупкой кувшина с литровыми отметками, а не тратить своё время на «костыльные» переливания?
Третья задачка (поменять переменные местами) — да, задачка интересная. В реальности встречается, но крайне редко. Тут только нужно пояснить, в этой самой реальности для решения используют встроенную функцию (обычно называется Swap), либо (на худой конец) третью переменную. А за неожиданный уход в побитовые операции пускают лучи неневисти (те, кому потом придётся поддерживать такой код).
А стоило оно того? Такие деньги можно и на обычной IT-работе заработать (возможно, не за такое же время, но всё же).
Зато теперь достоверно известно, что есть люди, которые финансово заинтересованы вас вычислить, найти и привести в РОВД. Как минимум, они точно смогут в суде оспорить сделку (сложно будет доказать, что вы выполнили «свою часть» сделки) и обязать вернуть деньги. Как максимум (как уже указали выше), тут может быть достаточно на статью. Да и налоговой тоже будет интересно.
Тратить значительную часть денег на комиссии, переводы и мини-аккаунты для вывода? Постоянно ограничивать себя в тратах, чтобы не светиться? Ворочаться, вспоминая, не забыл ли включить тор, когда в последний раз заходил на аккаунт? Вздрагивать от каждого стука в дверь?
Так себе, честно говоря.
Вычислить можно по тому, куда идут деньги, кто владеет сайтом/доменом, кто оплачивает его рекламу и хостинг. «Можно» тут в смысле «теоретически возможно», а не что каждый это может сам.
У кого в итоге оседают деньги? У рекламщиков. Такие сайты не выходят по поисковым запросам, поэтому существуют по принципу, грубо «вкинул 1к в рекламу, повезёт — вернётся 2к, не повезёт — 500». Рекламой могут быть баннеры, всплывающие окна, спам. Можете сами провести аналогию с казино и кто в этом случае является его «владельцем».
Мне уже страшно от того, что через пару лет придётся разгребать код людей, вдохновившихся этой статьёй. Особенно при доведении этих принципов до абсолюта.
function getMapValues(map) {
return [...map.values()];
}
Вот это вообще гениально. На ровном месте создаётся обёртка для синтаксиса языка, которая не несёт вообще никакой пользы.
Просто представьте, что через пару лет после написания этого кода у вас возникла ошибка — вы захотели вывести несколько коллекций в порядке возрастания суммы, но результат вас удивил — порядок явно не тот. В чём проблема — неправильные исходные данные ('null' вместо null), ошибка в сортировке или в функции определения веса?
Вы начинаете копать функцию определения веса и видите этот спагетти-код из микро-функций, которые разбросаны по разным местам разных файлов вашего проекта (код-то «переиспользуемый»). И каждый раз, встретив функцию, вам нужно её индивидуально искать, разбираться, что она делает, и потом возвращаться к тому месту, где остановились.
Не забывайте, мы лишь рассматривали простую функцию подсчёта веса коллекций. Примитив. А теперь представьте, что у нас что-то сложнее и ближе к реальному миру — например, функция, которая определяет, сколько нужно коробок, чтобы переслать N предметов разных габаритов (с учётом всех нюансов — габаритов, ограничений по весу, требований не класть в одну коробку тяжёлое с хрупким, таможенных особенностей). Сколько там можно написать микро-функций? Сколько времени у вас займёт найти среди них ошибку округления?
От статьи как-то веет маркетологической «игрой в слова», без всякой чёткой теории.
Если блок со скидкой 90% и таймером повысил продажи — так естественно, это же M — мотивация.
Если тот же самый блок понизил продажи — так чего ж вы хотели, это же T — доверие, кто же в здравом уме будет доверять скидке в 90%?
Если нужно повысить продажи, как определить, чего именно из S T M не хватает на сайте? Есть ли примеры «golden ratio»? Кейсы «было-стало» с цифрами повышения конверсии? «На глаз»-то и без всякой теории можно что-нибудь придумать.
Просто если брать изначальные вопросы как «стоит ли вносить правку Х? повысит ли она конверсию? насколько? это оправдает затрату человеко-часов?», то теория вообще не может дать уверенного ответа, даже в примере с «игрой со шрифтами».
Если задав себе вопрос: повлияет ли эта правка на удовлетворенность пользователя, его доверие к нам или мотивацию к покупке? — не получается дать определенного ответа, её вносить не следует. Это относится к игре со шрифтами, цветами, «сделать красным жирным телефоном в шапке» и прочему. Только конверсия и максимальная эффективность.
Привлекательность — приятное графическое оформление, соответствующее идеи бренда, вызывает у пользователя доверие и желание изучить сайт более глубоко. [+ S, + T]
Сроки. Это важный критерий для заказчика, особенно для малого бизнеса. Клиент может говорить, что это для него не важно, но это не правда. Чем быстрее вы сдадите ему рабочий сайт, тем с большей вероятностью он вам заплатит и порекомендует знакомым. Определите адекватные сроки, чуть меньше чем по рынку. В последствии я расскажу, как их выполнять.
От сроков напрямую зависит себестоимость выполнения работы для вас. Больше сроки — больше уходит на з/п.
Цена. Начинать советую с минимальной среди конкурентов цены, но не ниже рентабельности. Минимальная цена даст вам возможность создать профицит заказов, который очень потребуется что бы внедрять все последующие советы. Понятно, что только лишь благодаря низкой цене – заказы не появятся, но пока у вас ничего больше то и нет (если есть, то отлично!).
А вот тут я бы поспорил. Конечно, казалось бы, снизив цены мы увеличиваем поток заказчиков и снижаем их ожидания (никто не будет от простого сайтика за 20 т.р. требовать чего-то сверхъестественного), ведь так? На деле всё куда хуже.
Проблема в том, что обычно те заказчики, которые гонятся за низкой ценой — самые проблемные и дотошные на приёмке. У них ведь нет денег заплатить потом за доработку сайта кому-то ещё — вот они и будут пробовать выжать из вас все соки за свою оплату. Обычно это начинается с того, что просят дополнительную скидку. Откажешь — и ты уже психологически «подписался» под то, что приёмка будет идти «до последней запятой» — раз уж такая премиум услуга, что дешевле нельзя. Это как по тому, что было чётко прописано в ТЗ, так и по тому, что не было — «поиграйтесь со шрифтами», «чего-то скучно выглядит, переделайте».
И, да, попробуйте только предложить таким заказчикам платное составление подробного ТЗ — много узнаете о том, сколько должна стоить «какая-то бумажка».
Поверьте, сейчас есть достаточно людей, готовых платить нормальные деньги за нормальную работу. Таких, с которыми и в будущем приятно будет работать. А занижение цен, это просто путь в никуда.
Ну почему же «нет шансов». Могут ввести рейтинг ВУЗов (кто больше правок внёс), те в свою очередь поручат преподавателям, а те — студентам.
Не так уж и плохо, в конце концов — куда больше стимула неделями писать/править статью «за зачёт», чем «за просто так», а потом ещё и получать «удалено за отсутствие значимости».
Но это если не окажется просто очередным распилом, конечно.
«Печально, что менеджмент превалирует над техническим процессом.»
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Всё бы хорошо, вот только такой проект требует публичной поддержки, а с таким названием ему это вряд ли светит (никого не научил горький опыт ГМО?).
Обывателю достаточно показать по первому каналу кадр, где автор заявляет о своём проекте «Атака на СОРМ», а затем объяснить, что СОРМ расшифровывается как «Система (технических средств для обеспечения функций) оперативно-розыскных мероприятий». То есть человек покушается (атакует!) на систему, которая ловит «плохих парней». Вот и всё, у обывателя уже сложилось мнение, а дальше читать по теме он и не станет.
Тут смысл не столько в попрошайничестве, сколько в механике такого заработка. Могут потом возникать неудобные вопросы к себе. Не буду полностью расписывать свою точку зрения, просто перечислю примеры:
«Люди заплатили мне за книгу (качество и писательский талант) или за известность? Если Алла Пугачёва (или Тёма Лебедев) решит закраудфандить свою книгу и получит больше, что это будет значить?»
«Если человек оплатил четверть книги, а потом озвучил своё небольшое пожелание — как быть? Как ни решишь, сам факт просьбы уже повлияет на то, как ты будешь писать книгу — пусть даже подсознательно. С какой суммы начинать прислушиваться к просьбам? А если они будут противоречить?»
«Люди не отдают свои деньги за всё подряд — есть те, кто делает это, чтобы успокоить совесть на время. Значит ли это, что я потенциально отобрал деньги у тех сирот, которым они помогли бы вместо меня?»
«Блин, нужно новую машину покупать, родственник приболел, заказчик сценария кинул. Денег не хватает. А ведь я бы мог просто написать пост в своём блоге, ни о чём даже специально не просить, просто описать ситуацию. Незаметная кнопка „помочь деньгами“ в углу сайта за несколько лет принесла бы меньше, чем один такой пост. А если не писать, то что теперь, совсем про свою личную жизнь не упоминать?»
Именно поэтому, вероятно, Леонид так и оформил свой запрос, чтобы избежать части из них.
Зависит от клиента. Если клиент — технически подкованный и может сам потом его снять — отлично. Если нет, то он может очень резко отреагировать на фразу:
«Я тут у вас поработал, все файлы закрыл от изменений. Теперь чтобы что-нибудь поменять, вам нужно будет сначала связаться со мной, чтобы я поставил права.»
Но статья там была скорее про то, как решить проблему, а не как можно было ранее подстелить соломы в нужную яму.
Так все просто будут идти только в многообещающие проекты, раз уж там премируют даже за срыв сроков и бюджетов. И избегать всего остального.
Конечно, с точки зрения программиста я бы сказал, что команду программистов следует премировать и за работу, и за результат, и за энтузиазм, и просто за позитивное отношение к работе. Вообще нельзя не премировать (разве что совсем невезучих лентяев-злодеев, не попавших ни в одну категорию). Лично мне было бы только лучше, если бы так было, но я понимаю, почему может быть и не так.
Заметьте, я не говорю, что премировать ни в коем случае нельзя. Для мотивации можно и уборщице премию выписать по случаю продажи миллионной лицензии на продукт (даже плохо работающей). Просто это вряд ли сильно повлияет на продажи следующего миллиона лицензий.
Отвлекаются на другие заказы потому, что заранее предполагается, что вы этого фрилансера по окончани проекта «уволите». Причём не постепенно, как постоянщика по КЗОТ, а сразу.
Никто не хочет по 20 раз в год превращаться в безработного с туманной перспективой, потому и ведут параллельно несколько проектов. К очень долгим проектам это, естественно, не относится.
Абсолютная неправда. В Factory Idle нужно именно строить фабрику и оптимизировать размещение строений и конвейерные линии. Если кто-то из читателей хоть раз испытывал удовольствие, пытаясь красиво развести печатную плату или оптимизировать низкоуровневый код — не упустите шанс попробовать, она браузерная всё равно.
А вообще, лично мне такие игры, как ни странно, помогают оставаться продуктивным. Вместо ожидания очередного апгрейда, можно просто поработать, на время забыв про игру и вернуться, когда уже снова начнётся интересная часть.
Плюс, там и для любителей подумать есть где применить мозги. Помимо строительных Reactor Idle, Reactor Incremental и Factory Idle, почти в любой игре прогресс полностью зависит от решений игрока. У вас есть 100к денег, стоит ли купить несколько дешёвых апгрейдов или один дорогой? Или «перезапустить» игру сейчас с бонусом к скорости, потому что так через 8 часов получится больше прогресса?
Ну и просто приятно наблюдать за прогрессом чего-то, к чему приложил руку. Кто-то для этого заводит комнатные растения, кто-то — дачу, кого-то радует количество перепостов его картинки-мема, а кого-то — успехи сына-первокласника. Каждому своё.
Я так тоже считал, лет 12 назад, когда учился в школе, жил с родителями и играл в ММО-шки весь день. А когда начал «жить на свои» и кормить не только себя, само пришло понимание «почему человек должен работать». Тут даже не то, чтобы должен, а просто почему так происходит.
Но вообще, «лишнее», это то, что человек сам определяет таковым.
Зарплата зарплате рознь. Кому-то и 10к — зарплата, а кому-то и 50к — нет.
Если бы изучение и свои проекты были интереснее сериалов и компьютерных игр, то сериалов и игр бы не существовало. Практика показывает, что это не так, и большинству людей свои проекты не интересны (особенно если пару раз уже на этом обожглись).
Если введя новую фичу в проект, программист не поломал всё подряд, а фича работает — значит, это уже достаточно качественный код.
Иногда к коду также есть дополнительные требования — переиспользуемость, понятность, соблюдение стайл-гайдов. Чаще всего этих требований нет.
Но дело в том, что даже «чтобы ничего не поломать» и «чтобы скомпилилось, не тормозило и в целом работало» — уже требует сосредоточенности. Представлять себе это «минное поле» проекта, вспоминать, где и что может пойти не так.
Зависит от проекта и задачи, конечно. Ту же валидацию е-мейла можно допилить к полю ввода и не просыпаясь, а вот, например, «добавить новый тип пользователей с ограниченными правами» уже так просто не получится, даже если говнокодить.
Нужно вспоминать, где в проекте уже есть проверки на тип пользователя; как они себя поведут, если он новый; где вообще есть список типов пользователей, или оно всё в хардкоде; а если в хардкоде, то может пора переписать по-нормальному, ведь на неделе ещё 5 типов добавлять собираются; а может и так оставить, вдруг быстрее будет. Вот с такими задачами и бывает, что человек просто не может заставить себя начать неделями.
«Безошибочный код» в данном случае — код, который работает и, в общем, выполняет требования заказчика, а не в смысле идеальный. Если у вас функция выдаёт фигню, когда пользователь указал нулевое или отрицательное значение физической величины (вес, длина) — это не так страшно, по крайней мере для большинства проектов. Но если у вас 20 + 20 = 2020 (привет, JS), то это уже ошибка, которая перечёркивает собой всю остальную работу.
Работа «в данный момент» никогда не бывает важна, потому что положительный результат от неё приходит намного позже — после того, как выплатят зарплату и после того, как эти деньги на что-то понадобятся.
А прокрастинация существует, если человек занимается чем-то явно лишним вместо работы. Если этот конкретный час он всё равно не смог бы работать, это уже не прокрастинация, даже если дело с виду бесполезное. Статья о том, что некоторые «бесполезные дела» важнее других.
Примеры, которые вы приводите, тоже относятся к системному решению задач (для решения задачи создаётся и продумывается система) и, да, в них отчасти справедливы те же принципы.
Разница тут, на мой взгляд, не в цене ошибки, а в «дискретности» результата. Т.е. например менеджеры решили, что для замены сломанного компьютера работники должны писать заявку, а соответствующий отдел должен её регистрировать и высылать ответ. Если они не оговорили точный формат заявки и ответа, то люди на месте разберутся, «что-нибудь придумают». Программа же без чёткого формата просто не отработает.
И если менеджерам просто укажут на недоработку, то программисту ещё нужно будет доказать, что он вообще что-то делал, а не просто так сидел. И это не всегда возможно.
Поэтому, с точки зрения прокрастинации, менеджер и может себе позволить ответить на email-переписку невыспавшимся и прочитавшим по-диагонали, он не будет перед этим часами сидеть и приходить в нужное состояние.
Было бы также интересно почитать, как вы справляетесь с частой проблемой low-cost разработки — капризными клиентами, которые выбирают малобюджетные варианты, а потом пытаются «выжать все соки» из заказа, потому что денег на доработку не предвидится.
Поясню мысль.
Первая задачка (с последовательностью без числа) в реальности может встретиться, например, при работе с БД. Есть список каких-то записей (юзеры, товары, транзакции — не важно), у них есть ID от 1 до N (autoincrement), есть некая функция, которая их удаляет, нам нужно узнать, что было удалено.
Тут стоит заметить, что во-первых, обычно используется не удаление, а установка какого-нибудь status: disabled (или установка null в поле, если прямо так необходимо избавится от информации). Удаление может вызвать кучу проблем и головной боли в последствии, не надо так.
Во-вторых, обычно всё-таки не должно возникать ситуации «у нас в БД что-то пропало, неизвестно что». ID удалённого объекта должен записываться в момент удаления и обрабатываться сразу же.
Но ок, допустим, какое-то вероисповедание нам не позволяет исключить возникновение такой ситуации. Тогда в-третьих: даже если мы делаем проверку суммы сразу после удаления чего-то, никогда нет гарантии, что в самом деле что-то было удалено, или что была удалена только одна запись. Даже если сегодня это так, завтра функцию могут переписать.
В итоге, человек, который считает, что ответ с суммой — окончательный и достаточный для продакшена будет просто не прав. Тут либо переделка структуры, либо полный перебор ID'ов.
Вторая задачка (кувшины) — ну ок, лёгкая, математическая, чтобы решающий почувствовал себя увереннее. К IT отношения не имеет от слова «совсем».
Но вообще в реальных задачах такого типа (когда есть возможность что-то решить, нестандартно используя существующие объекты), нужно в первую очередь начать задавать вопросы.
Почему такая задача вообще возникла и к ней не готовы? Может, в ТЗ опечатка и нужно всё-таки 3 литра?
Почему у нас нет кувшина на 4 литра? Может, он всё-таки есть и стоит его поискать? Чтобы не занимать те два кувшина, которые явно уже предназначены для других целей и могут понадобиться остальным.
А если скоро опять возникнет такая задача? А если в следующий раз — 1/4 литра? Может, стоит озаботиться покупкой кувшина с литровыми отметками, а не тратить своё время на «костыльные» переливания?
Третья задачка (поменять переменные местами) — да, задачка интересная. В реальности встречается, но крайне редко. Тут только нужно пояснить, в этой самой реальности для решения используют встроенную функцию (обычно называется Swap), либо (на худой конец) третью переменную. А за неожиданный уход в побитовые операции пускают лучи неневисти (те, кому потом придётся поддерживать такой код).
Зато теперь достоверно известно, что есть люди, которые финансово заинтересованы вас вычислить, найти и привести в РОВД. Как минимум, они точно смогут в суде оспорить сделку (сложно будет доказать, что вы выполнили «свою часть» сделки) и обязать вернуть деньги. Как максимум (как уже указали выше), тут может быть достаточно на статью. Да и налоговой тоже будет интересно.
Тратить значительную часть денег на комиссии, переводы и мини-аккаунты для вывода? Постоянно ограничивать себя в тратах, чтобы не светиться? Ворочаться, вспоминая, не забыл ли включить тор, когда в последний раз заходил на аккаунт? Вздрагивать от каждого стука в дверь?
Так себе, честно говоря.
Вычислить можно по тому, куда идут деньги, кто владеет сайтом/доменом, кто оплачивает его рекламу и хостинг. «Можно» тут в смысле «теоретически возможно», а не что каждый это может сам.
У кого в итоге оседают деньги? У рекламщиков. Такие сайты не выходят по поисковым запросам, поэтому существуют по принципу, грубо «вкинул 1к в рекламу, повезёт — вернётся 2к, не повезёт — 500». Рекламой могут быть баннеры, всплывающие окна, спам. Можете сами провести аналогию с казино и кто в этом случае является его «владельцем».
Вот это вообще гениально. На ровном месте создаётся обёртка для синтаксиса языка, которая не несёт вообще никакой пользы.
Просто представьте, что через пару лет после написания этого кода у вас возникла ошибка — вы захотели вывести несколько коллекций в порядке возрастания суммы, но результат вас удивил — порядок явно не тот. В чём проблема — неправильные исходные данные ('null' вместо null), ошибка в сортировке или в функции определения веса?
Вы начинаете копать функцию определения веса и видите этот спагетти-код из микро-функций, которые разбросаны по разным местам разных файлов вашего проекта (код-то «переиспользуемый»). И каждый раз, встретив функцию, вам нужно её индивидуально искать, разбираться, что она делает, и потом возвращаться к тому месту, где остановились.
Не забывайте, мы лишь рассматривали простую функцию подсчёта веса коллекций. Примитив. А теперь представьте, что у нас что-то сложнее и ближе к реальному миру — например, функция, которая определяет, сколько нужно коробок, чтобы переслать N предметов разных габаритов (с учётом всех нюансов — габаритов, ограничений по весу, требований не класть в одну коробку тяжёлое с хрупким, таможенных особенностей). Сколько там можно написать микро-функций? Сколько времени у вас займёт найти среди них ошибку округления?
Если блок со скидкой 90% и таймером повысил продажи — так естественно, это же M — мотивация.
Если тот же самый блок понизил продажи — так чего ж вы хотели, это же T — доверие, кто же в здравом уме будет доверять скидке в 90%?
Если нужно повысить продажи, как определить, чего именно из S T M не хватает на сайте? Есть ли примеры «golden ratio»? Кейсы «было-стало» с цифрами повышения конверсии? «На глаз»-то и без всякой теории можно что-нибудь придумать.
Просто если брать изначальные вопросы как «стоит ли вносить правку Х? повысит ли она конверсию? насколько? это оправдает затрату человеко-часов?», то теория вообще не может дать уверенного ответа, даже в примере с «игрой со шрифтами».
От сроков напрямую зависит себестоимость выполнения работы для вас. Больше сроки — больше уходит на з/п.
А вот тут я бы поспорил. Конечно, казалось бы, снизив цены мы увеличиваем поток заказчиков и снижаем их ожидания (никто не будет от простого сайтика за 20 т.р. требовать чего-то сверхъестественного), ведь так? На деле всё куда хуже.
Проблема в том, что обычно те заказчики, которые гонятся за низкой ценой — самые проблемные и дотошные на приёмке. У них ведь нет денег заплатить потом за доработку сайта кому-то ещё — вот они и будут пробовать выжать из вас все соки за свою оплату. Обычно это начинается с того, что просят дополнительную скидку. Откажешь — и ты уже психологически «подписался» под то, что приёмка будет идти «до последней запятой» — раз уж такая премиум услуга, что дешевле нельзя. Это как по тому, что было чётко прописано в ТЗ, так и по тому, что не было — «поиграйтесь со шрифтами», «чего-то скучно выглядит, переделайте».
И, да, попробуйте только предложить таким заказчикам платное составление подробного ТЗ — много узнаете о том, сколько должна стоить «какая-то бумажка».
Поверьте, сейчас есть достаточно людей, готовых платить нормальные деньги за нормальную работу. Таких, с которыми и в будущем приятно будет работать. А занижение цен, это просто путь в никуда.
Не так уж и плохо, в конце концов — куда больше стимула неделями писать/править статью «за зачёт», чем «за просто так», а потом ещё и получать «удалено за отсутствие значимости».
Но это если не окажется просто очередным распилом, конечно.
Единственный способ превалирования технического процесса — работать на себя. Бесплатно. Либо проинвестировать компанию из своего кошелька.
Не получится вот так просто придти в компанию, и сказать «платите мне среднюю месячную зарплату по стране каждую неделю, а я буду сам решать, будет релиз продукта в этом году или нет».
«Вопреки мнению автора, производство – это написание и отладка программного кода. Именно это и является продуктом, а остальное – не более чем схема его реализации.»
Зависит от бизнеса. В большинстве стартапов, даже чисто технологических это совсем не так. Часто продуктом являются просмотры пользователей, которые продаются рекламодателям. А пользователей ведёт маркетинг, а не качество реализации (см. фейсбук, ранние дни твиттера (картинка с китом)).
Но даже в тех компаниях, где качество продукта чего-то стоит, менеджмент и маркетинг не являются лишь «обслуживающим персоналом единственных работающих людей — программистов». Они выполняют работы и принимают решения, в основном стремясь к тому, чтобы компания выжила, а не ради соблюдения «ритуала техпроцесса».
«А что до рисков… Ну вы же сами хотели капитализм? Получите, распишитесь!»
Предположим, вам предложили работать в компании за процент от прибыли. Компания получила большую прибыль — вы получаете миллионы. Компания понесла убытки — вам нужно продать квартиру и взять кредит, чтобы их покрыть. Вышла в ноль — все остаются при своих. Вы бы хотели такой капитализм?
Это естественно, что люди, берущие на себя риск, стараются его минимизировать. И инвесторы тут не исключение — потому им и нужно сначала убедиться, что «криво, быстро и на коленке» — хоть немного работает.
«Уже давно пора наплевать на весь мир и жить своими реалиями, которые требуют весьма жёсткого и принципиального планирования, не считающегося с рыночными «реалиями» никак.»
Вся статья выше как раз о том, реалии не требуют жёсткого и принципиального планирования. Реалии требуют гибкости и скорости.
Не поймите меня неправильно, я бы тоже был рад если бы все эти «жадные» инвесторы перестали уже трястись над своими деньгами, перестраховываясь и ожидая возврата, а просто раздавали бы их стартапам для развлечения.
«А давайте три года делать сервис с геолокацией, вот миллион, как закончится — просите ещё.»
«Надоела геолокация? Проект ещё не успели в третий раз переписать перед запуском, а конкуренты уже заняли весь рынок? Ну ладно, зато как хорошо посидели. Вот ещё миллион, давайте теперь big data поковыряем.»
Но так уж лучше было бы помечтать, что мне просто в карман деньги сразу положат, без всей этой имитации бурной деятельности.
Обывателю достаточно показать по первому каналу кадр, где автор заявляет о своём проекте «Атака на СОРМ», а затем объяснить, что СОРМ расшифровывается как «Система (технических средств для обеспечения функций) оперативно-розыскных мероприятий». То есть человек покушается (атакует!) на систему, которая ловит «плохих парней». Вот и всё, у обывателя уже сложилось мнение, а дальше читать по теме он и не станет.
«Люди заплатили мне за книгу (качество и писательский талант) или за известность? Если Алла Пугачёва (или Тёма Лебедев) решит закраудфандить свою книгу и получит больше, что это будет значить?»
«Если человек оплатил четверть книги, а потом озвучил своё небольшое пожелание — как быть? Как ни решишь, сам факт просьбы уже повлияет на то, как ты будешь писать книгу — пусть даже подсознательно. С какой суммы начинать прислушиваться к просьбам? А если они будут противоречить?»
«Люди не отдают свои деньги за всё подряд — есть те, кто делает это, чтобы успокоить совесть на время. Значит ли это, что я потенциально отобрал деньги у тех сирот, которым они помогли бы вместо меня?»
«Блин, нужно новую машину покупать, родственник приболел, заказчик сценария кинул. Денег не хватает. А ведь я бы мог просто написать пост в своём блоге, ни о чём даже специально не просить, просто описать ситуацию. Незаметная кнопка „помочь деньгами“ в углу сайта за несколько лет принесла бы меньше, чем один такой пост. А если не писать, то что теперь, совсем про свою личную жизнь не упоминать?»
Именно поэтому, вероятно, Леонид так и оформил свой запрос, чтобы избежать части из них.
«Я тут у вас поработал, все файлы закрыл от изменений. Теперь чтобы что-нибудь поменять, вам нужно будет сначала связаться со мной, чтобы я поставил права.»
Но статья там была скорее про то, как решить проблему, а не как можно было ранее подстелить соломы в нужную яму.