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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Вот те, люди/сайт которые на меня больше всего ссылаются и принесли больше всего посетителей. Загляните к ним, если хотите.

А если кто-то из нижеперечисленных - это вы, то огромное вам спасибо, что обо мне пишите.

Корпоративные благодарности:

itblogs.ru
developers.org.ua
it4business.ru, он же Слава Панкратов
netvibes.com
bloglines.com
live.cnews.ru
psylive.ru

Персонально/блоговые благодарности:
Крайнов
Фриц, он же Морген
У Wada
Сергей Корнилов
vgarnick.livejournal.com
dz.livejournal.com
rssh.livejournal.com
100blogov.blogspot.com
Тюшков Николай
gem-tmp.livejournal.com

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

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

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

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

P.S. Кстати, это непосредственно связано со статьями:

Не позволяйте планке падать

Ремонт нельзя остановить, его можно только закончить.