Archive for the ‘Разное’ Category

Три самых больших лажи в моей карьере.

Воскресенье, Июнь 1st, 2008

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

Лажи я меряю по количество зеленных баксов, которые были попалены (хотя точных цифр я и не знаю). Ну и само-собой эти те лажи в которых я принимал прямое и в достаточно главное участие. Слава богу, не все из них происходили за мой счет.

Лажа N1.

Был один проект, который будучи молодым и зеленым программистом я оценил в 2000 часов. Как я сейчас понимаю, 4000-5000 а то и больше было бы более точной цифрой. После чего я на этом проекте еще и был главным программистом. Ну и когда менеджер начал гнать хворостиной, чтобы я все делал быстро, я стал делать быстро, но…. некачественно. В общем как результат, сроки завалены, проект не закончен, меня чуть не уволили, менеджер из фирмы ушел, директор… потерял некоторое количество денег (или по крайней мере хорошего клиента).

Лажа N2.

Меня поставили project manager’ом (на самом деле, для точности, я исполнял роль product manager’ом). Ну и так как это была моя первая подобная должность, естественно проект я залажал по мощному. Не учел технических рисков, слишком занырнул в тактику, опять же я был еще завязан на его оценку, ну и как результат — те же самые вылетевшие сроки, проект устаревший до того, как он был выпущен, отсутствие team lead’а на серверной части, которые сказалась на качестве. Правда в середине всей это свистопляски я ушел сам, так что выгонять было поздно.

Лажа N3.

А вот эту лажу уже успел провернуть на свои деньги.

В самом начале, когда я только стартовал бизнес, то был у меня один заказчик. Опять же, с высоты нынешнего опыта, я понимаю, что заказчик был просто золотой. Хорошая предоплата, хотел наращивать размеры заказов, отсутствие стандартного супер-трепетного (читай скряжного) отношения к деньгам. И вот из-за того, что ему было нужно разрабатывать серверную часть, вместо мобильной (на которой я в основном специализируюсь) я фактически слил заказчика. То есть, просто уделял мало внимания, до тех пор, пока он не решил прекратить давать проекты.

Вот, такие вот дела…

Знаете, сейчас все в блогосфере рассказывают в основном о своих успехах и удачах. Типа, я крутой SEO и срубил 5 штук за три дня или я крутой продавец и продал вчера на 100 штук. Почему-то никто не хочет показать, что на пути к успеху, были и лажи.

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

И в прямую передаю эстафету писания о трех самых больших лажах следующим товарищам 😉

Максу Крайнову.
Сергею Корнилову.
Дмитрию Давыдову
Сергею Жуковскому
Дмитрию Смирнову

Кстати, если у вас нету блога. С удовольствием бы услышал ваши истории или комментарии тут.

P.S. Поступило идея именовать лажи — косяками. Я за 🙂 А, второе, что спросили уже два человека, почему я называют это лажами, ведь это ошибки на которых я набирал опыт. Да, так это и есть, я даже писал статью «Опытный значит ошибавшийся». Просто я назвал их лажами, так как эти ошибки мягко говоря стоили прилично. Хотя безусловно опыта на каждой из этих ошибок я получил тоже гигантское количество.

OpenID vs Brian’s threaded comments.

Суббота, Май 31st, 2008

Ура господа, случилось то о чем так долго говорили большевики.

Разобрался таки с багом, что не дружил openID с комментариями вложенными и частенько слетал. Фикс правда получился топорный, но работает.

Если кому нужно будет для блога, с удовольствием отдам фикс в хорошие руки 🙂

Кстати, если заметите странности вокруг написания комментариев — дайте знать.

Молочные реки и кисельные берега.

Суббота, Апрель 19th, 2008

Есть такой достаточно американский анекдот: «Как узнать, что адвокат лжет?  Очень просто… У него губы шевелятся».

А еще в сериале Friends, была серия в которой они обсуждали, что значат типовые фразы, которые говорят друг другу встречающиеся (в смысле парень и девушка).  Например: «Дело не в тебе» обозначает на самом деле «Дело именно в тебе» и т.п.

Сегодня на меня снизошло озарение, что фактически все CEO (особенно американских фирм) являются помесью адвокатов и встречающихся.

Так что, предлагаю перевод некоторых типовых фраз:

«Мы решили остаться маленькими» значит «Как мы не пытались мы не смогли вырасти».

«Мы сейчас общаемся с большим количеством инвестором» значит «Ни один инвестор не хочет давать нам денег».

«Ну и если мы станем следующим Googl’ом….» значит «Мои эротические сны заменила именно эта идея».

«Следующий год должен быть прорывом» — «Черт. Мы это уже говорим это пять лет. На этот раз нам должно повезти».

«Мы собираемся продать компанию за 100 миллионов» — «Другим удалось. Мы что, хуже? Жаль, пока у нас доход всего 17 центов».

«Мы легко можем прямо сейчас продать компанию за 10 миллионов, но мы хотим ее еще вырастить» — «Я где-то в журнале читал, что кто-то продал похожую компанию за 10 миллионов. Может и мы смогли бы, но нам все еще надо работать над теми 17 центами о которых я тоже соврал в прошлом ответе».

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

И так можно продолжать до бесконечности. В общем, все просто, говоря с CEO

А) Делите все их идеи и слова на десять — не ошибетесь.

Б) Оценивайте успех компании по доходу и расходу (идеально по полному финансовому отчету), а не по словам CEO.

В) Если CEO говорит «точно» читайте «может», если говорит «может» читайте «шансов фактически нет».

Вот такой вот краткий словарь общения с CEO на переговорах.

Расчет, прежде всего.

Пятница, Апрель 4th, 2008

Вы заметили в крутых боевиках, не менее крутые, чем сам боевик герои, не просто мочат все направо и налево , но и просчитывают ситуацию на десять шагов вперед. Именно благодаря этому, ну и быстрой руке (которая как известно лучший друг индейца) они спасаю свою заднюю часть от разнообразных неприятностей.

Шахматисты, они тоже видно в прошлом супергерои, и тоже пытаются считать ситуацию наперед.

Так же наперед пытаются считать ситуацию инвесторы, банкиры.

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

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

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

Просто постоянно вижу картину, когда молодой (и горячий) разработчик бросается в бой с багом, по пути наталкиваясь на новый и бросаясь разбираться с ним и так обнаруживающий себя через неделю в глубине кода работающий неизвестно над чем. Причем, если его спросить, какой был изначальный баг, то где-то секунд десять в отражении его глаз можно расчесываться, после чего человек с напряжением выдает какую-то вразумительный ответ.

Так что, нужно всегда выстраивать дерево (сначала желательно на бумаге), потом можно и в голове. Дерево должно выглядеть так – идея N1 (что сломано) + как проверить, идея N2 + как проверить и т.п.. Почему я говорю дерево, да потому, что иногда в не слишком удачно написанных проекта, проверка теории не удается без того, чтобы, например, пофиксить другой баг (для которого тоже нужны записывать варианты). И чем глубже приходятся «копнуть» тем больше шансов потом забыть какой-то из кусочков этого дерева.

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

Ну и вернусь к тому, что я говорил, что метод проверки теории должен быть наибыстрейший. Как по мне, один из самых эффективных метод – комментировать большие куски кода. Это сразу позволяет выявить внутри этого ли модуля находиться баг. Хотя есть и другие не менее эффективные методы.

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