Руководство начинающего девелопера в стиле Григория Остера

Никогда не составляй ТЗ

Техническое задание совершенно не нужный, но даже вредный документ, на составление которого уходит уйма времени, которое надо посвящать программированию. Ну и что, что ты можешь разрабатывать совсем не то, что на самом деле нужно заказчику – это все мелочи. Главное же — это тот шедевральный код, который ты пишешь! Ведь именно в этом в первую очередь измеряется результат программиста.

Используй свою память на сто процентов

Не для того мы наделены памятью, чтобы где-либо еще хранить информацию. Все эти заметки на стикерах очень легко могут потеряться, телефон могут украсть, компьютер сломаться, а интернет отключиться в самый необходимый момент. Но если ты будешь хранить всё в голове – ты никогда ничего не упустишь! Зачем нужны заметки, если все хранится у тебя в голове в моментальной доступности?

Никогда не оговаривай конкретные сроки и бюджеты

Мир – очень изменчивая штука. Поэтому как можно гарантировать, что проект будет готов к определенному сроку и разработка уложится в отведенный бюджет? Разработка не терпит спешки. Ни в коем случае разработчиков нельзя торопить, ведь тогда идеальный продукт без единого бага просто не получится. Поэтому тянуть нужно как можно дольше. И конечную смету выставлять побольше. Ну и что, что стоимость его выйдет в три раза выше рыночной, главное – качество!

Заказчик – твой лучший друг

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

Это фича, а не баг

Если вдруг, каким-то чудом в твоем идеальном продукте возникает непредвиденное поведение, он внезапно крашится или заказчик говорит, что делает он не то, что надо – ни в коем случае не признавай свою ошибку! Это самое страшное, что может случиться с тобой. Ведь тогда, может поползти слух, что ты не идеален, и ни один заказчик не захочет с тобой работать. Упирайся как хочешь, с пеной у рта объясняй, что так и было задумано. Напиши подробное руководство, в котором пошагово будет описано руководство к действию, как это можно сделать по-другому. Но исправлять и признавать свои ошибки – никогда. У программистов – не бывает багов!