Прочитал экономические откровения противника копирайта, посмеялся, но решил не вмешиваться в великую борьбу Добра™® со Злом (скачать бесплатно без регистрации и СМС новый интернет ускорьте ваш компьютер), а вместо этого рассказать про менеджеров.

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

Увы, в реальности всё совсем иначе. Хороший менеджер — на вес золота. Его найти ещё сложнее, чем найти хорошего лида-разработчика. А искать придётся, потому что, как только людей в команде становится больше пяти, они начинают резко утрачивать возможность договориться и отследить договорённости самостоятельно. Если же взаимодействуют несколько команд или отделов, например, дизайнеры, серверные программисты и клиентские программисты, то без хорошего менеджера проектов работа превратится в взаимное перекладывание ответственности. Вася ждёт Петю. Петя ждёт дизайн. Дизайнеры помнят о заказе Пети, но сейчас заняты большой задачей от Коли, ведь Петя попросил какую-то мелочь — откуда им знать, что это важно? Вася тем временем от безделья занимается рефакторингом и разбирает свою часть проекта до состояния, когда ему потребуется ещё неделя, чтобы её переделать — бросать переделку он не хочет, потому как жалко уже потраченного времени и «всё равно это надо».

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

В этом месте некоторые читатели воскликнут: «Да как же так, мы же все умные люди, неужто мы не сможем договориться без какого-то там посредника?» Увы, как показывает практика, люди зачастую не способны договориться даже сами с собой и распланировать свои собственные деньги и время хотя бы на месяц вперёд.

Всё вышенаписанное умножается на десять, если речь идёт о крупной компании, где взаимодействие между отделами строго формализовано.

Ещё в советское время был такой анекдот.

Что нужно сделать, чтобы вскипятить чайник, стоящий на столе? Взять чайник со стола, налить в него воды, поставить на плиту — ну, и так далее, алгоритм очевиден. А если чайник стоит на окне? Нормальный человек скажет: взять чайник с окна, налить воды… А программист (так тогда называли айтишников) скажет: переставить чайник на стол и выполнить предыдущую подпрограмму.

Когда-то мне это казалось прикольным. Не надо, мол, всё программировать снова, можно свести к уже известному. Но когда, чтобы вскипятить чайник, приходится по 25 раз переставлять его с места на место, хочется материться.

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

Но вот очень давно, когда интернет не был ещё быстрым, а диски — большими, произошёл у меня забавный случай. Писал я какую-то разовую утилю, регулярно нажимая Ctrl+S, а параллельно на этот же раздел диска скачивалось что-то сильно объёмное уже не первые сутки. И вот в определённый момент в ответ на хоткей Билдер выдал мне абсолютно левую ошибку. Ну ладно, перезапустим…

Насколько я был удивлён увидеть после перезапуска абсолютно чистый файл исходника — не передать словами.

Ответ на эту загадку нашёлся быстро. Место на диске заканчивалось. При сохранении файл на долю секунды стал нулевой длины; за это время последние байты на разделе заняло скачиваемое, и Билдер, в котором не было предусмотрено защиты от таких идиотов, как я, выдал эксепшн.

Итог: несколько часов потерянного времени и опыт не хранить даже разовые проекты на разделах с остальным мусором.

Недавно работал в сравнительно небольшом IT-отделе небольшой организации. Кругом одни IT-специалисты, которые высокомерно смеются над пользователем: вот, мол, неуч, не умеет скриншоты присылать!

И вот в очередной раз решил один из программистов посмеяться над незадачливым пользователем, что тот переписал месседж-бокс в текст письма вручную. Не придав этому значения, я продолжил работать. Но когда над этим бедным «неучем» смеялось уже человек шесть, я всё же поинтересовался, что там такого прислал пользователь. Каково же было моё удивление, когда я увидел в тексте письма что-то в стиле:

[Window Title]

SomeTest

[Content]

Не удаётся найти «SomeTest». Проверьте, правильно ли указано имя, и повторите попытку.

[ОК]

Высокомерия у них поубавилось, потому что этот «неуч», оказывается, умел пользоваться Ctrl+C и Ctrl+V, в отличие от программистов, что разрабатывали это самое ПО.

Какая досада: не выучил он урок по информатике, а отвечать надо. В спешке с утра готовит шпору. А вот и «допрос». Мальчик, а мальчик, что такое CLS? Ловкий, незаметный для учительницы взгляд в шпору, а там — clear screen. Он и перевёл: «прозрачный экран».

Учительница не оценила дальновидности ученика. А теперь мы знаем: он оказался прав. Индикаторы на лобовом стекле, ПО для дополненной реальности… А Explay Crystal даже успел изрядно устареть.

Я увольняюсь. Мне надо отработать две недели. Я тимлид. За эти две недели я должен научить нового сотрудника тому, что сам изучал десять лет (22 года программирую, из них десять в вебе).

— Объясни мне всю логику приложения, а ещё лучше — напиши комментарии к каждой строчке кода, — просит сотрудник.

— У меня код документирован во всех критических местах.

— Я по образованию музыкант, мне надо всё по полочкам, ещё и диезы расставить.

— ♯♯♯♯♯♯ — на тебе диезы, ♭♭♭♭♭♭ — на тебе бемоли, но учись разбираться в чужом (говно)коде. Я за десять лет ни у кого не спрашивал, зачем он завёл переменные $nah и var poh = 'ololo'.

В итоге сотрудник обижается, но пытается разобраться в моём коде, иногда названивая в скайп. Я получаю расчёт, устраиваюсь на другую работу. Happy end!

Вот это номер! Вроде бы ресурс для айтишников, на который айтишники и пишут. Программисты в том числе. Но одни теряют результаты работы за день, а другие рекомендуют не сохраняться, а не то несколько действий не отменить. Удивлён. Очень сильно удивлён.

Есть такая штука — система контроля версий. Например, git. Делаете осмысленное, логически завершённое изменение — делаете коммит. Оставляете ещё осмысленный комментарий к коммиту. Отключили электричество, UPS не спас (мало ли, тоже не панацея) — не катастрофа. Включаемся — работа жива. Ну, может, последняя строка ушла в небытие. Всё же не убитый день работы.

Потоп, пожар, ураган, прямое попадание артиллерийского снаряда — и компьютера больше нет. Вы можете быть уверены, что с вами такого не случится? Всякое бывает. Берём другой компьютер, логинимся на Гитхабе — и вот оно, счастье: результаты работы в сохранности, можно продолжать, можно выполнить работу в срок.

Допустил ошибку, и теперь отовсюду выпиливать переменную? Тоже бывает. Кто не ошибается? Можно просто-напросто откатиться к определённому коммиту, в котором ошибки ещё не было. А можно и лучше поступить: экспериментальную фичу, в которой пока до конца не уверен, реализовывать в отдельной ветке, не трогая основную. Сделал, отладил, всё хорошо — объединяй ветки. Сделал, ужаснулся, понял, что получилось плохо — убей ветку, и дело с концом.

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

И вопрос, сохраняться или не сохраняться, вообще неактуален. Хорошего кода, коллеги!

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

— Родная, а зачем ты даже после целых чисел ставишь точки? — спрашиваю я, поглядывая на процесс.

— Ну зачем же нам лишнее приведение типов? — смотрит она на меня большими удивлёнными глазами.

Подкалываю:

— Тогда уж и рекурсию раскрой.

Посмеялись. А вообще, заботливая она у меня. Не только за мной и котом ухаживает, но даже процессор старается лишний раз не нагружать.

Будучи школьницей, зело заинтересовалась литературой. В писательском смысле: рассказики там, сказочки, стишочки… Ну, многие баловались, я думаю. Из девчонок — так, наверно, почти все. Человек я педантичный, если что-то интересно, выясняю о предмете всё до конца. И тут тоже решила полностью изучить вопрос: лазала по сайтам соответствующим, читала учебники по русскому, как приключенческие романы — пачками и от корки до корки, обменивалась опытом с единомышленниками. Не знаю насчёт таланта — не мне судить, но технику написания литературного произведения любого жанра и тематики отточила по максимуму, насколько смогла.

А потом пришла пора выбирать будущую профессию. Но, как известно, «филолог — не профессия» (прошу прощения у всех филологов), да и писать по 8–10 часов в сутки я не могу (пробовала подрабатывать копирайтером, чуть не рехнулась). Долго объяснять почему, но пошла на программиста. И знаете, что я скажу? Оказалось, писать код — то же самое, что писать рассказ. Только языки разные — и всё. Схожий тип мышления. Схожий алгоритм создания «продукта». Тут и там важна точность, а то поймут тебя неправильно — и пиши пропало. На адептов «индусского кода» выливается столько же ругани, как и на тех, кто не различает «-тся» и «-ться», «одеть» и «надеть», но хочет называться писателем. И, конечно, столько же нервов тратится, если вдруг почему-нибудь вырубился комп, а ты не сохранился (упаси нас всех Ктулху от такого горя!).

Так что я уже восемь лет как программист с писательским хобби. Вот, нашла на днях интересную схемку в книжке по лингвистике. Завтра в проге применю, пожалуй…

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

Бухгалтерам, как и другим нормальным людям, такая точность нужна в очень редких случаях. В их учёте квант времени — это день; время внутри одного числа используется, только если с одним и тем же объектом произошло несколько последовательных операций, для отражения их очерёдности. «Жёлтый глюк» это понимает, кстати, и по умолчанию принимает начало периода за DD.MM.YYYY 00:00:00, а конец — за DD.MM.YYYY 23:59:59. Он вообще прямо из коробки понимает много чего — поэтому и задушил в своё время конкурентов, практически монополизировав российский рынок ERP-систем.

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