Сроки
Краткая памятка о сроках по работе с [неразборчиво].
«Сегодня» — завтра.
«Завтра» — напомнить завтра, что уже сегодня (см. «сегодня»).
«В течение недели» — в следующую среду.
«В течение недели, но до выходных, пожалуйста» — в понедельник.
«Через две недели» — месяц.*
«Месяц» — неопределенная, очень большая величина времени.
«Три месяца» — три неопределенные, очень большие величины времени.
«К осени» — когда выпадет снег. Снег выпадает каждый год, поэтому «к осени» является наиболее благоприятным сроком, пропустить который практически невозможно.
«Через год» — не используется, ибо есть «к осени».
* — Популярно заблуждение, что две недели — это 14 дней. Это не так. Две недели — это 14 дней + «в течение недели» (ибо вторая неделя еще не кончилась) + завтра («один день погоды не сделает»). В особых случаях отсчет «двух недель» начинается со следующего понедельника, так выигрывается еще несколько дней.
Если повезет, то в результате выходит месяц срока и опоздание всего на один день («завтра»).
Гениальные идеи
Вот, бывает, придумаю гениальную идею и спрашиваю у хакира Болка — хорошая ли идея, будет ли работать?
Оказывается, что идея хорошая и более того — хакир Болк уже эту идею пару раз использовал.
Сразу возникают противоречивые чувства:
1. Досада. Почему про такие вещи нельзя прочитать почти нигде? Нет, я серьезно: куда ни глянь — всюду обсуждения уровня «как передеть переменную выше. например, то где она должна определится на 20 строке, а то где она включается в код на 30 строке, как ее можно передать выше?». На самом деле понятно, почему: 90% людей — идиоты. Всегда и везде. Оставшиеся 10% заняты тем, что молча работают. Если они начнут что-то объяснять людям, то в 90% случаев это будет метание бисера перед свиньями. КПД = 10% — это как-то грустно.
2. Радость. Как хорошо быть умным, придумывать умные вещи и узнавать, что они работают.
Вот, такие дела.
В конце не будет никакой морали.
Производительное кодирование
Но что просто выводит меня из себя, так это то, что ещё на первой моей работе я понял — производительное кодирование отнимает у меня, как разработчика, в среднем по два-три часа в день.
Joel On Software
А я думал, что я один такой.
Я не программист
Дальше я пишу о себе всякие хвалебные вещи, читать не обязательно. Как написано в качестве эпиграфа здесь. detail.phpclub.net/
Я на самом деле не программист. Я, конечно, умею программировать, но... не люблю это делать. Я просто люблю решать проблемы (ну и создавать заодно). Я скорее разработчик или дизайнер (дизайнер — это не «оформитель», а, опять таки, «разработчик»). Я умею писать такие ТЗ, что самому читать приятно. Дело в том, что я умею программировать, поэтому мои ТЗ основаны не только на «а вот хочу того и того», а еще и на знании «почему хоть то-то и то-то правильно, а то-то и то-то — нет, и как это все в конце концов реализовать».
Лирическое отступление:
На прошлом месте работы начальник как-то сказал что-то вроде (за точность не ручаюсь, но по духу примерно так) «Вот ты написал два ТЗ, а кому оно нужно? Наш программист сам знает, что нужно». Потом, увидив Spesta, он сказал (дословно): «Блин, классная статистика. Гораздо лучше Киселевской — ты ему ее показывал?». (Диме Кисилеву привет!). При этом я, с присущей мне скромностью, не считаю, что оно лучше запрограммировано. Оно лучше придумано. Именно для этого и нужно ТЗ — не смотря на то, что программист знает, «что нужно», главное — это «как нужно», потому что конечному пользователю все равно общаться с уровнем «как нужно», а «что нужно» его не интересует.
То есть пользователю совершенно не важно, что «нужно собирать такую-то статистику». Ему важно, как потом работать с этой статистикой. Ну, это мы уже залезли, опять же, в интерфейс...
Я тут пару дней думал на тему «Идеальная CMS». Здесь, опять же, проходит грань между программистом и разработчиком. Я придумал пару архитектурных решений и свежих идей, которые «программист» не придумал бы — только потому, что программисту не доводилось так плотно общаться с контентом, как мне.
Основная проблема в том, что я знаю, как ее сделать, но делать не хочу: очень уж лениво так много программировать. Есть, конечно, хороший принцип «If you want something to be done — do it yourself», но...
I actually hate programming,
but I love solving problems.
Rasmus Lerdorf