Программизмы

Когда-то давно баловался я с самописной игрушкой, создавал мир, выкручивался костылями там, где не мог.

В один солнечный и ясный день (не всегда погода попадается удачная) у меня случился монстр. Все сущности в мире имели два показателя: «здоровье» и «опыт». Трава сеялась (level 0), росла (level 1–2), цвела (level 3), плодилась (level 4) и жухла (level 5). С каждым уровнем она росла хуже, а вот умирала — лучше. Внезапно умирая, она превращалась в некротраву, и её нельзя было убить, только вылечить до смерти, а она продолжала прокачивать уровни. Вчера это были приятные красные цветочки, сегодня — жухлая зелень, а с завтра — всё сильнее крепнущие стволы Сада Смерти.

Косяк прост: умирала трава не с шестым уровнем, а от нехватки здоровья, когда оно падало до нуля. Если же здоровье проскакивало ноль и уходило в минус, «смерть» не вызывалась. Починил, добавив к знаку равенства лишь один символ: <.

Если заказчик хочет условие «с …» реализовать знаком ≥, а «по …» — знаком ≤ (или наоборот, смотря по коду), то есть «включительно», то это тоже вполне логично.

Гардероб. Светящаяся табличка:

Внимание! Согласно публичной оферте на пользование нашими услугами, гардеробщик ИМЕЕТ ПРАВО брать себе всё находящееся в карманах и рукавах сдаваемой одежды. Клиент, не желающий этого, обязан перед сдачей одежды вынуть всё из её карманов и рукавов.

Под табличкой — кнопка от кассовой клавиатуры, с прозрачным колпачком которая. За колпачком — бумажка с надписью «Согласен». При нажатии на неё звенит звонок и выходит гардеробщик.

Кто-то эту бумажку вытащил, провёл над «Согласен» горизонтальную черту (булева алгебра!) и поместил обратно. Лайфхакинг в действии!

Все-таки айтишник — это не профессия, а образ мыслей.

Смотрел я вчера последнюю серию «Интернов». Там доктор Быков пытался научить интерна думать своей головой. Он предложил пареньку угадать из трёх процедур одну, которую нужно назначить пациенту. Интерн, чтобы уж наверняка, проделал пациенту все три, чем довёл беднягу чуть ли не до нервного срыва. За это Быков наорал на интерна и велел дать пациенту успокоительного, но не удержался от шпильки:

— Ну, или горчичники ему поставь!

Потом, правда, спохватился — вспомнил, с каким дуболомом говорит, и добавил:

— И заметь, ключевое слово здесь — «или»!

Но интерн всё равно и успокоительное дал, и горчичники поставил.

А ведь я сразу, как Быков про «или» сказал, подумал: вот если бы был он не доктором, а программистом, то он бы такую ошибку не допустил, он бы воспользовался исключающим «ИЛИ».

Сегодня узнал, что значит «руки из жопы»: в jQuery случайно вместо addClass написал assClass. «Классно!» — заметил бы дядюшка Фрейд.

Преподаватель рассказывает о «программировании» на Flash. Можно взаимодействовать с объектом из корня — root — или из другой сцены. На слайде презентации показаны примеры такого взаимодействия.

Сначала послышалась пара смешков. Постепенно засмеялись все, вместе с преподавателем. Виновником смеха стала фраза препода:

— Здесь не с root.

Автор статьи «Вымышленный мир менеджера» осудил автора статьи «Moron-driven development» в преувеличении роли менеджера, при этом очевидно преувеличивая и свою роль.

Работу выполняют только разработчики и инженеры? Хорошо, выполнил ты свою работу — теперь попробуй её продать. Никто не покупает? Странно…

Прежде всего нужно понимать роль каждого сотрудника в компании и кто за что получает деньги: если ты разработчик — разрабатывай, если ты менеджер — продавай. Если ты считаешь, что можешь сам разработать продукт и впарить его заказчику, сообщи об этом руководству компании — шеф с радостью уволит менеджера и будет платить тебе половину его зарплаты. И вообще, зачем тебе шеф, если ты сам можешь добиться успеха на мировом рынке?

Почему у буржуев разработчик себя лучше чувствует? Потому что ты не работал в буржуйской компании и наслышан об их райских условиях из рассказов бабушек у подъезда. У них тоже есть свои проблемы, просто не такие, как у тебя. А тебя буржуи к себе не берут не потому, что ты не хочешь, а потому, что ты им не нужен.

Почему менеджер хочет прикрутить свистелку? Потому что твой проект с двумя кнопками заказчику скучен и непонятен. Он задаст два вопроса: «Что я получу?» и «Сколько это стоит?», а после ответит: «Окей, я подумаю» — и навсегда ускользнёт. Свистелка даёт возможность менеджеру впарить продукт, представив её модной фичей, которой нет у конкурентов. В результате своей работы менеджер зарабатывает деньги не только на свою зарплату, но и на твою.

Не успеешь сделать до среды и не хочешь читать книгу по тайм-менеджменту? А стоило бы, потому что из этой книги ты узнаешь о том, как не делать сотню дел до среды. Есть простые способы всё успевать:

• не обещай, если не уверен;

• предупреди, если не успеваешь;

• предупреди, если остались недоработки;

• если задач несколько, выясни их приоритетность.

Соблюдая всего несколько правил, ты научишься не рвать попу там, где это никому не нужно.

Задача разработчика — твоя задача — оценить срок выполнения работы с запасом и озвучить его, потому что никто не сможет оценить срок лучше тебя. Если тебя не услышали — это не твоя проблема, потому что ты имеешь ценный аргумент: «Я же предупреждал». Если с твоими сроками не согласны, есть другой аргумент: «Найдите того, кто сделает быстрее». Если ты умеешь обосновывать свои сроки, никто не заставит тебя укладываться в меньшие.

Менеджер хочет свистелку? Ты получаешь деньги за прикручивание свистелок. Такая у тебя работа — сидеть с утра до вечера и крутить свистелки. Предупреди, что свистелка затянет проект на два дня, и менеджер сам начнёт думать, так ли она ему нужна. Считаешь, что твоё божественное происхождение не позволяет крутить свистелки — сообщи начальнику, пусть повысит тебе зарплату или уволит на фиг.

Программист отвечает за успех продукта? Значит, ты не там работаешь — найди нормальную компанию, в которой каждый занимается своим делом. Ты же специалист, найти работу для тебя не проблема — тебя везде хотят и ждут. Никогда программист отвечать за успех продукта не должен — это технический специалист, который должен получать фиксированную ставку и премии, если успевает крутить свистелки быстро и качественно. Если компания работает в убыток — это не проблема программиста, это недоработка менеджера, который неправильно избрал стратегию продажи.

В современном мире уровень конкуренции настолько высок, что заказчик не радуется, как дитя, получив новую деревянную игрушку, которую ты создаёшь — он хочет игрушку мягкую и блестящую, и чтоб пуговки из перламутра были. Нужны ли заказчику пуговки? Да на фиг не нужны, если хорошо подумать, но купит он игрушку у того, кто пуговки не поленится пришить.

Для кого ты работаешь, разработчик — для себя или для заказчика? Если для заказчика, тогда изволь выполнить все его капризы и дать ему ощущение важности его роли. Если для себя, тогда работай молча, получай зарплату и не суй нос в работу других. Менеджер как раз и выполняет роль прослойки между тобой и заказчиком — даёт возможность заказчику почувствовать, что он не в советской столовке, а в шикарном ресторане, вызывает желание обращаться снова и платить бабло, а затем бежит к унылому тебе, чтобы дождаться, пока твоя кислая рожа обратит на него свой взор и выслушает новую порцию требований заказчика.

Я занимаюсь веб-разработкой восемь лет и когда-то тоже недооценивал роль менеджера — до тех пор, пока сам не попытался продавать свои услуги. Я осознал, что программированием занимаюсь намного успешнее, чем продажами, и потому КПД выше, если каждый занимается своим делом.

Давайте уважать коллег независимо от того, какова их роль.

Почему ЭВМщику необходимо быть чуть-чуть гуманитарием, рассказывает случай 1989 года. Неопытный пользователь подзывает опытного и просит объяснить, почему не работает кнопка сброса. Тот сразу нажимает кнопку с надписью «СБР» — и машина сбрасывается. Неопытный очень удивлён: в силу отсутствия у себя элементарного знания из области гуманитарщины он искал кнопку с названием, начинающимся не на «С», а на «З». А на эту букву была только «ЗБ» — забой, backspace по-нонешнему. Бегло программировать же на бумаге он был обучен по ершовскому методу до первой встречи с машиной. Сложные и остроумные штуки писал, и когда их потом запустили на машине, они заработали сразу без правки.

Другой случай посвежее, это уже девяностые. Человек обучался одному ЯВУ. Всё быстро схватывал, от графика обучения не отставал, даже опережал, пока не подошла очередь оператора while. Лекцию он записывал под диктовку, не поднимая глаз на доску. А как слово пишется, не знал — записал как «wile». На практическом занятии правильно составил программу, до этого не пользуясь этим оператором ни разу, вот только сам оператор набрал неправильно. Ой, не компилируется! Потом ему, конечно, показали, как правильно, но если бы помимо программирования интересовался бы ещё чуть-чуть гуманитарщиной, эта ошибка бы не возникла вообще.

А может, и вы приведёте подобные примеры из собственной практики, а также практики знакомых?

Вечеринка по поводу выхода новой версии продукта. Вся толпа коллег подтянулась в холл и под шампусик с красным винцом и салатиками, блаженно улыбаясь, пропускает мимо ушей соловьиные трели начальства, вещающего, какой глобальный рывок совершила компания вопреки всем нашим усилиям. Начальство, которому эта вечеринка тоже до лампочки, должно откатать обязательную программу, поэтому со скорбной миной на лице продолжает лениво рассказывать нам, какие же мы замечательные, как мы здо́рово работаем и насколько огромны и всеобъемлющи наши успехи, когда начальство нам не мешает.

Попутно начальство останавливается на статистических данных:

— С момента выхода предыдущей версии продукта объем репозитория вырос с 32 до 34 миллионов строк кода! Мы починили — вы починили — двадцать тысяч багов!

Я, наворачивая салатик:

— Хм. В статистике пропущен важный нюанс. Мы починили двадцать тысяч багов. А сколько внесли?

Коллега, наворачивая шампусик:

— Ну, это просто. По статистике, в программе объёмом больше десяти миллионов строк кода есть один баг на каждые четыре строчки. Мы добавили два миллиона строк, это значит — внесли пятьсот тысяч багов. Даже если при этом починили двадцать тысяч.

И, бросив взгляд на моё ошарашенное лицо, хлопает меня по плечу:

— Учись, малец. Это называется job security.

Каждый раз читаю в сети (как здесь, так и на других IT-ресурсах) про негодование разработчиков от менеджеров — чего стоят все эти истории про создание бритвы! — и каждый раз задумываюсь: уж не в параллельной вселенной ли я живу? Или, может, всё куда проще, и людям, как обычно, свойственно валить свои косяки и проблемы на кого-то другого, а также делиться по принципу «мы vs они» и «свой vs чужой»?

По моему личному опыту разработки, в котором были самые разные проекты как по тематикам, так и по размерам, менеджеры — это как раз тот элемент работы, благодаря которому проекты в итоге успешно сдаются и получаются нормальными. А вот проблемы начинаются как раз тогда, когда за руководство проектом садятся разработчики, любящие гнуть пальцы на тему того, какие они крутые специалисты по всему, или, что ещё хуже, когда проектом руководит сам заказчик (или его представитель), в большинстве которых сразу просыпается «творческая личность», начинающая выдумывать такой бред, который многим даже и не снился.

О проектах, ведомых разработчиками, можно долго рассказывать, но чаще всего там всё довольно-таки прозаично и упирается в неадекватные шапкозакидательские оценки сроков исполнения, абсолютно ублюдочную проработку интерфейсов, логики работы и юзабилити (ведь это всё «не нужно», «тут всё ясно и дебилу» и т. д.), посредственную поддержку и производительность на устройствах конечных клиентов (когда каждый раз «внезапно» оказывается, что средний домашний и офисный компьютер — это не десктоп с i7, 32 ГБ ОЗУ, 27-дюймовым монитором и последними версиями всего ПО). Впрочем, это всё банальные проблемы, которые так или иначе потом можно решить, хотя они и бесят, когда одни и те же люди умудряются регулярно попадать в них раз за разом и не делать выводов.

Куда опаснее ситуации, когда проектом руководит заказчик. Да-да, в этой ситуации все ещё хуже. Нет, заказчик не знает, чего он хочет. Нет, заказчик не «лучше знает», что ему нужно. Заказчик может потенциально знать цель проекта, его потенциальную аудиторию и особенности своего бизнеса, но он гарантированно не знает, как именно для этого должен быть сделан проект, чтобы он был хорошим, удобным, успешным и работающим. Честь и хвала тем людям, которые честно себе признаются, что они не являются специалистами в разработке, и доверяются специалистам, лишь общаясь с ними и обговаривая различные варианты реализации и всякие мелкие детали, однако это, к сожалению, очень редкое исключение. Почти всегда, когда проектом так или иначе рулит заказчик, всё происходит совсем иначе, и разработка превращается в ад.

Свистелки и перделки? Господи, да ведь именно заказчики в первую очередь и просят весь этот бред! Дурной вкус, желание выделиться, понты — объясняйте как хотите, но именно заказчики в первую очередь тянут подобное в проект. Нестандартные, выдуманные ими сами и абсолютно неинтуитивные/нелогичные элементы управления, меню, схемы поведения — шедевры креатива заказчиков. Рахитичные дизайны, кривые схемы вёрстки, цветовые схемы для инопланетян, несочетаемые шрифты, дикие пиктограммы, переусложнённые формы, бессмысленные анимации и прочее «добро» — это как раз результаты прямого доступа заказчика к руководству проектом. Про постоянные смены настроений, идей и многократные переделки уже сделанного я вообще молчу — да, кому-то такое нравится, вот только сроки сдачи проекта таким образом могут сдвигаться почти вечность. В итоге то, что можно было сделать, протестировать и сдать за три-шесть месяцев, делается более двух лет. Я не знаю, каким надо быть мазохистом, чтобы разработчику нравилось участвовать в этом балагане, даже получая за это приличные деньги.

А разгадка проста: менеджер, как руководитель проекта, играет роль фильтра между процессом разработки и заказчиком. Заказчиком, которому менеджер объясняет и рассказывает, что хорошо, а что плохо, что стоит делать, а чего делать не стоит, объясняет последствия для проекта в случае реализации тех или иных идей и фич — в общем, при общении с заказчиком менеджер как раз таки старается, чтобы проект получился нормальный, удобный, современный, актуальный, а главное, его можно было сделать в адекватные сроки и побыстрее успешно сдать. Преуменьшать этот труд можно либо по глупости, либо по наивности или максимализму.