Откуда берется эффективность программиста


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


Рассмотрим обычную ситуацию (как это себе представляют некоторые менеджеры):
в одной большой компании работают два программиста - Петя и Вася. Допустим, что Петя и Вася - программисты абсолютно одного уровня, то есть сколько их не тестируй - не выяснишь, кто лучше.
Любой неопытный менеджер вам скажет, что 2 одинаковых программиста приносят фирме одинаковую пользу. Так ли это? Давайте посчитаем.
Пусть Петя и Вася работают по 9 часов в день, включая обед. Но на что и как они тратят эти 8 часов?


Читать дальше Откуда берется эффективность программиста…

Самый простой способ изучить C++ за 21 день




Похожие записи:
Откуда берется эффективность программиста
Один день из жизни Программиста
10 заповедей для программистов
Shu-ha-ri для программистов
Непрограммирующие программисты
Книги + программисты = деньги
25 самых опасных программистских ошибок

Один день из жизни Программиста

Пятница - лучший день для работы, ибо впереди отдых. А в эту пятницу Программисту предстояло начинать изучение нового большого компонента, так что день сулил много интересного.
Утро, как обычно, началось с ежедневного SCRUM собрания минут на 10 и еще с пары совещаний. Потом были письма и ответы на них и быстрый обед.
Зато после этого Программист выгрузил Outlook и Skype и исчез для всех (ибо нет ничего хуже для программиста, чем постоянное отвлечение).
Исчез для всех, кроме второго Программиста, который разработал этот большой компонент, который предстояло изучать. Для ускорения передачи знаний было решено поработать несколько дней в паре за одним компьютером (ибо pair programming офигительно хорош для передачи знаний).
Начали с попыток скачать и сбилдить проект на новом компьютере, для чего надо было установить и прописать в системе кучу нужных SDK и тулзов. К счастью многое уже было установлено и все ограничилось установкой и настройкой QT и Python26. После небольшого колдовства (а QT без колдовства, как известно, не работает), билд заработал. И еще как!
Ребилд на не сильно мощной машине Программиста занял 40 минут!
“Вот оно - приключение”, подумал Программист и сказал второму:
“Я не смогу работать над тем, что билдится 40 минут. Сейчас мы с тобой ускорим билд в несколько раз!”
Второй Программист не очень-то поверил (ибо уже год мучался с таким медленным билдом), но первый настоял, ибо знал, что лучше 1 день потерять, но зато потом за 5 минут долететь. (ибо время билда - один из самых важных факторов в программировании. Сделай долгий билд и никто не сможет вносить легко и просто изменения в компонент, т.к. цикл изменение-проверка будет занимать слишком много времени - тут уже никакие юнит тесты и test automation не помогут. А сделай билд и тестирование мгновенными и получишь легко расширяемый компонент)
И они приступили к ускорению билда.
Читать дальше Один день из жизни Программиста…

10 заповедей для программистов


10 заповедей для программистов от it-епископа:

    1. Программирование - твоя главная страсть. И да не будет у тебя страсти главней.

    2. Не сотвори себе кумира из конкретной технологии. Ибо программирование требует постоянного развития, а технологии-кумиры останавливают развитие.

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

    4. Работай много и хорошо, но не забывай и про отдых. Ибо нет ничего страшнее, чем код усталого, засыпающего программиста.

    5. Уважай учителей и учеников своих. Постоянно учись и учи окружающих, чтобы было тебе всё легче и легче делать всё более и более сложные вещи.

    6. Не убий в себе ребенка. Не забывай эмоции от первого запуска первой написанной тобой программы и воспринимай каждую следующую, как ту - первую.

    7. Не изменяй программированию. Ибо программист может стать кем угодно, но этот кто угодно обратно программистом уже не станет.

    8. Не кради код ближнего своего.

    9. Не программируй то, что может принести вред другим. Ибо встав раз на путь дьявола - на нем и останешься.

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

Непрограммирующие программисты


Джефф Атвуд несколько дней назад написал еще одну статью про непрограммирующих программистов.
В ней он пишет, что 3 года назад он вдруг осознал, что многие люди, приходящие на собеседование на должность программиста, не могут написать даже простейшей программы. Также он пишет о том, как это понимание изменило его подход к интервьюированию программистов - теперь он всегда просит писать код, даже самый простейший, чтобы сразу отсеять тех, кто совсем не может ничего написать. Причем он делает это еще до того, как приглашает людей на личное интервью - по телефону или через интернет.


Интересно, что те же самые мысли у меня были еще лет 5 назад, когда я был главным программистом и руководил отделом программирования в геймдевелоперской компании. Мы тогда начали активно набирать народ. Так активно, что метод рекоммендации уже не срабатывал и пришлось размещать объявления на сайтах поиска работы и проводить интервью - очень много интервью. Работа у программистов в геймдеве очень специфическая, требует постоянного развития и отличного умения программировать, поэтому мало кто на эту должность подходит. К тому же зарплаты в геймдеве были гораздо ниже, чем по отрасли в целом. В итоге, по статистике, я проводил 10-20 личных собеседований, чтобы взять 1 человека. А еще больше отсеивалось на уровне резюме и телефонных звонков или email-ов. Наверняка и кого-то из отличных программистов не взяли, но неважно.
Зато те, кого в итоге брали - это были бриллианты. Готов лично поручиться практически за каждого, кто прошел мое собеседование и испытательный срок, хотя были и те, кто в итоге не выдерживал гонки геймдев-разработки и уходил.
Как же я проводил собеседования?


Читать дальше Непрограммирующие программисты…

25 самых опасных программистских ошибок

Некоммерческая организация MITRE и институт SANS опубликовали список из 25 наиболее распространенных ошибок в программировании, которые могут сыграть на руку хакерам.
На первых трех местах - ‘Cross-site Scripting’, ‘SQL Injection’ и ‘Classic Buffer Overflow’. Первые 2 - чисто интернетные ошибки, а вот переполнение буфера - классическая ошибка, до сих пор встречающаяся повсеместно.
Я здесь привожу переведенный краткий список всех 25 ошибок.

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

Shu-ha-ri для программистов

shuhari

В японских боевых искусствах есть концепция трехэтапного обучения мастерству - Shu-ha-ri.
1. Shu (守:しゅ - “защита”, “подчинение”) — изучение традиционной мудрости — изучение основ, техник, движений.
2. Ha (破:は - “отделение”, “отклонение”) — отступление от традиции — поиск исключений в традиционной мудрости, размышление о правильности традиций, поиск новых путей и техник.
3. Ri (離:り - “покидание”, “отделение”) — превосходство над традицией — нет больше никаких техник или традиционных движений, все движения естественны и рождаются самостоятельно, а не из традиционной мудрости.


Любое обучение начинается с этапа Shu, когда ученик должен преданно следовать всем инструкциям своего учителя. На этом этапе нельзя спрашивать “почему”, нельзя ставить под сомнение правильность движения или слов учителя - только полное подчинение и следование инструкциям. На этом уровне ученик еще не готов к вопросам, а точнее - он не готов задавать правильные вопросы и не готов воспринять ответы на них. Только учитель может решить, что ученик готов перейти на следующий этап - этап Ha.


На этапе Ha ученик начинает изучать границы своей техники и постоянно должен спрашивать “Почему?”. Вопросы позволяют ученику лучше адаптировать под себя фундаментальные знания, которые он получил на этапе Shu. Ученик может даже находить новые техники усиляющие его потенциал.


И вот в определенный момент количество опять переходит в качество и ученик переходит на уровень Ri. На этом уровне больше нет никаких правил, точнее ученик сам создает правила. Ученику больше не надо спрашивать “почему” - он это уже знает или чувствует. Ученик готов к самостоятельному изучению движений, созданию новых движений, и он видит взаимосвязь между ними.

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


А при чем тут IT и программисты, спросите вы?
Читать дальше Shu-ha-ri для программистов…

Why Software Sucks




Недавно прочитал книгу David S. Platt: Why Software Sucks… and What You Can Do about It.. Книга небольшая. Написана очень живо и очень простым языком. Не думал, что в ней найдется что-то, что заденет меня за живое, но пришлось ее прочитать, так как ее очень рекомендовал один умный человек.
И я не пожалел. Фактически, для меня вся эта книга - это всего 3 очень простые и одновременно очень сложные мысли:

  1. Пользователь твоей программы - это не ты. Разработчики часто, очень часто забывают про это. Они пишут программы, ориентируясь на себя и свой уровень знания, а не на уровень знаний клиентов (пользователей). Отсюда проблемы с кривыми интерфейсами, сложными программами или отсутствием юзабилити  у продуктов. Ведь разработчик думает как? Для него следующее - это очень простая и правильная инструкция: “Чтобы сохранить документ - найдите папку, куда установлена программа, запустите файл savedoc.exe с параметром командной строки -s и именем файла для сохранения. Вы можете использовать дополнительные параметры: -m ….. “. Это простая инструкция? Возможно, да,.. для кого-то. Тогда как юзеру надо не инструкцию, а пункт SAVE в меню и всё. Никаких путей и командных строк. Такие “недоразумения” в дизайне случаются всегда, если техническим людям разрешено решать, что для пользователя просто и правильно, а что нет. И дело совсем не в том, что “пользователи все тупые”, а в том, что вы не должны требовать наличие у пользователя того же уровня знаний, какой есть у вас.
  2. Нужно делать простые вещи простыми, а не давать возможность делать сложные вещи. Любовь к созданию сложных вещей - это очень широко распространенная особенность программистов и других технических специалистов. Программисты любят сложности. Они не любят делать простые вещи - они любят делать сложные вещи, которыми можно было бы гордиться. А между тем пользователям не нужны сложности - им нужна возможность очень просто делать простые вещи. Например, вспомните главную страницу гугла - это запатентованный идеал простоты. Невозможно сделать поиск проще. И пользователи это любят. Возьмите любой другой поисковик, где кроме строки поиска еще куча рекламы и другой информации - любят ли пользователи такие поисковики? А ведь казалось бы, что сделать такую поисковую страницу с кучей автоматически генерящейся информации - это в разы сложнее и интереснее для программиста. А страницу гугла может сделать и школьник - никакого удовольствия. Та же проблема пронизывает всю работу программистов - они не любят делать простые удобные дизайны, а лучше сделают что-то супер расширяемое, хоть и неудобное. Они могут заставить пользователя сделать 5 кликов прежде, чем можно нажать кнопку “Сохранить” - и все это только потому, что “зато такой дизайн позволяет до ЛЮБОЙ кнопки добраться всего за 5 кликов” - но ведь пользователю не нужна “любая кнопка” каждые 2 минуты, а только нопка “Сохранить”.
  3. Если вы хотите как-то улучшить ситуацию с ПО, то пишите про каждую найденную неудобность и недоработку разработчику. А если разработчик не реагирует, то на публичные форумы. Например, если на каком-то сайте что-то не работает или работает, но неудобно, то найдите форму обратной связи и напишите там свои впечатления. Если MS Office глючит или новый интерфейс вам не нравится, то найдите там кнопку Send Feedback и напишите про свои впечатления. Это кажется неважным обычно, но на самом деле это единственный канал, по которому разработчики могут узнать, что в программе или сайте что-то не так. Представьте, что Майкрософт поменял интерфейс в MS Word и новый интерфейс никому не нравится, но никто не шлет отрицательные комментарии. Изменится ли что-то? А если каждый из 100 млн. пользователей напишет отрицательный feedback? То же самое относится и к любому сайту, к любой программе - не ленитесь слать фидбек разработчику. А если вы разработчик, то не ленитесь сделать посыл фидбека максимально простым, ведь улучшение продукта - это в ваших интересах



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


P.S.:
А вот она и на русский переведена уже, оказывается: Дэвид Платт. Софт - отстой! И что с этим делать?. Рекомендую.

Общение несовершенно - умей управлять несовершенностью

Любой проект - это море общения.

Общение - это далеко не только разговоры девелоперов на кухне, но и практически любая другая проектная активность:

  • Документация. Написание и чтение оной. Это общение, так как писатель “общается” с читателем посредством документации.
  • Дизайн архитектуры приложения или конкретных фич. Это общение, так как архитектура и фичи не возникают в голове у одного человека. И даже после того, как они возникли - их еще надо донести до окружающих.
  • Митинги, обсуждения, отчеты.
  • Планирование работы, постановка задачи. Бывают ли планирования без общения? Возможно, да, в клинических случаях. Но постановка задачи - это уж точно акт общения.
  • Занесение бага в баг трекер тестером, исправление бага программистом, проверка исправления тестером и т.д.
  • Обучение, тренинги, посещение конференций и т.п.

Можно назвать еще много разных активностей, ведь практически любая активность на проекте связана с общением. Много вы можете перечислить активностей на проекте, в которых “общение” не играет никакой роли? Я не могу назвать ни одной.

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


А как достичь совершенства в общении?
Читать дальше Общение несовершенно - умей управлять несовершенностью…

Масштабы проблемы “нигерийских” писем

Год назад я написал статью про нигерийские (африканские) письма. Для меня это исследование тогда было как развлечение, так как я не представлял себе тогда масштабов проблемы.
За прошедший год я получил сотни комментариев к этой статье и пообщался с несколькими людьми, которые попались на удочку “нигерийцев”. Из положительного - немало людей прекратило общение с “нигерийцами”, прочитав мою статью, хотя уже собирались отправить им деньги.
В комментариях к статье люди помогали друг другу советами и даже обнаружили, что некоторые письма приходят не из африки, а очень даже из России, а значит и найти отправителя возможно (хотя никто этого не пытался пока сделать).


И вот несколько дней назад Ultrascan опубликовал документ, в котором описываются глобальные масштабы этой пробламы в 2009 году.
В 2009 году ущерб от этого вида мошенничества превысил 9,3 млрд. долларов (из них 105 млн. потеряли русские)! В 2008 он составлял “всего” 6,3 млрд.

А теперь шок: если верить википедии, то весь бюджет Нигерии (построенный на продаже нефти) всего раза в 2-3 больше этой суммы! Нафига нигерийцам вообще торговать нефтью, если у них есть такой выгодный источник дохода, как “нигерийские” письма? Легализовать их и писать их всей страной и всё - проблема нефтяной зависимости экономики решена в пользу более современной “зависимости” :)


Правда, уже сейчас рассылкой этих писем занимается больше 250 тыс человек, большинство из которых живет в Нигерии! 250 тыс! В России исследователи нашли 6 действующих «нигерийских» группировок, в состав которых входят более 50 человек (по предположительным оценкам 280).


Еще интересный и ожидаемый при таких масштабах прибылей факт:

Ultrascan отмечает, что международным центром отмывания денег, помимо Греции, теперь является Малайзия, конкретно — ее столичные банки. Зачастую «нигерийцы» оказываются владельцами национальных представительств Western Union или Moneygram. По консервативным оценкам, около 10% таких агентств осознанно пособничают скамерам, получая от них дивиденды.

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



Так что “нигерийские” письма - это глобальная проблема. Этот вид мошеннечества растет на 50-100% в год и уже через пару лет “доход” от такого рода деятельности может обогнать, например, доход всей игровой индустрии или даже киноиндустрии.


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