• Начните с самого сложного. Я видел, как это правило нарушали сотни раз разными способами. Программист начинает проект и быстро сообщает, что работа готова на 90 %. Затем он вдруг заходит в тупик, и оказывается, что первые 90 % проекта заняли только 10 % времени. Так всегда случается, если программисты смотрят на проект и хотят начать с той части, которую они умеют делать. Если нужно сделать что-то новое, они сосредоточатся на пользовательском интерфейсе, чтобы показать видимый прогресс. Они убеждают себя, что легко справятся со сложной частью и оставляют ее на потом. Хороший вопрос, который можно задать программистам на начальном этапе: «Что, по-вашему, в этом проекте самое сложное?» Как только вы выясните, с этого и начинайте. Всегда. Никогда не откладывайте сложную часть на потом. Сначала сделайте то, что вас пугает.
• На вашем критическом пути не должен стоять и мешать вам по нему двигаться никто, кроме вас самих. Программисты категории ААА никогда не говорят: «Моя часть кода готова, но я жду, пока группа API напишет свой код, чтобы я мог протестировать». Или: «Подозреваю, что в коде Microsoft есть какая-то ошибка. Жду ответа от их техподдержки». Если у кого-то есть код, с которым вам нужно интегрировать свой собственный, но чужой код не работает, напишите свой собственный код, который притворится чужим. И затем используйте этот новый код как «затычку» для тестирования собственной работы. Не сидите и не ждите. Если какая-то функция Microsoft (или чья-то еще) не работает так, как указано в документации, найдите альтернативное решение. Продолжайте двигаться и доводите дело до конца. С самого начала вы должны думать о том, как устранить зависимость от других. Если у вас не получается, пусть это будет из-за вас, а не потому, что с задачей не справился кто-то другой.
Приходит человек к врачу, отставляет руку в сторону и выворачивает ее под прямым углом.
– Доктор, доктор, – говорит он, – мне больно, когда я так делаю. Вы можете мне помочь?
– Да, – отвечает врач. – Не делайте так!
• Берите на себя ответственность. Если ваш код не работает, скажите: «У меня ошибка. Я ею занимаюсь». Не пытайтесь заметать баги под ковер. Примите вашу ошибку, признайте, что ее сделали именно вы, и сосредоточьтесь на том, чтобы как можно скорее это исправить. Если вас уволят за ошибку, извлеките уроки и двигайтесь дальше. Но не прячьтесь. Промахи случаются даже с лучшими из лучших. По-настоящему сильные программисты берут на себя ответственность за ошибки и не успокаиваются, пока все не исправят. Если вы тимлид, а программист постоянно придумывает отговорки, почему кто-то другой тормозит его работу или почему в багах всегда «виноват другой», гоните его вон – пусть идет работать к конкурентам. Туда ему и дорога.
• Не отвлекайтесь. В рабочее время тупить в Интернете или болтать с коллегами – это для неудачников. Если надо кому-то позвонить, это можно сделать и за обедом, если дело не слишком срочное. Если вы хотите побеждать, то и вести себя надо как победитель.
• Чтобы найти ошибку в коде, нужно начать с уменьшения объема кода до того уровня, на котором все работает. А затем постепенно добавлять код, пока не случится сбой. Допустим, у вас есть приложение с несколькими тысячами строк кода. Вы пишете метод, который вызывает некий API от Twitter. Почему-то на вызове этого метода все вылетает. Если я ваш тимлид и вы придете ко мне и скажете: «Из-за Twitter у меня код вылетает», то я отвечу: «А покажите мне ваш тестовый пример». Если в нем больше 20 строк кода, я отправлю вас обратно на рабочее место. Почти всегда лучший способ найти ошибку – уменьшить объем кода. Обычно это означает написание нового кода, который будет окружать и «нагружать» код с ошибкой. Программисты вечно сопротивляются этому подходу – не хотят отклоняться от основного дела и потратить четыре часа на написание какого-то фреймворка-подпорки для неработающего метода. Практически во всех случаях, когда я давлю на программиста, заставляя его вытащить неработающий код из полного приложения и запустить отдельно, оказывается, что код-таки работает или в нем быстро обнаруживается баг. Ошибку, затерянную среди тысяч строк кода, найти практически невозможно. Но если сократить область поисков до 50–100 строк кода, проблема будет найдена за считаные минуты. Не бойтесь отвлечься на несколько часов, чтобы создать «испытательный стенд» (фреймворк) для поиска неуловимой ошибки. Это решение работает в 99 % случаев.