Как работают хорошие разработчики: 5 важных принципов

Принцип №1

Работать прозрачно

Допустим, вы получили большую задачу, ушли в свой угол и, ни с кем не общаясь, решаете её весь месяц. В итоге ваши коллеги всё это время будут ломать голову и задаваться вопросами: «А всё ли у вас хорошо? Вы всё ещё выполняете эту задачу или переключились на что-то другое? А точно ли все поняли друг друга и на выходе будет именно то, что нужно?» Часто кажется, что ответы на эти вопросы очевидны для всех и все понимают, что вы заняты делом — однако в реальности для людей вокруг вовсе не очевидно то, что очевидно для вас.

Если вдруг вы раздражаетесь от регулярных вопросов менеджера: «Ну чё там? Когда будет готово?» — значит, вам пора научиться вести свою работу прозрачно. Если вы начнёте регулярно делиться, с какими проблемами столкнулись, и показывать результаты своей работы (проактивно, а не по запросу), то у менеджеров просто не будут возникать подобные вопросы.

В чём польза?

• Люди перестанут в самый неподходящий момент лезть к вам с вопросами в стиле «Ну как успехи?».
• Команде проще планировать работу, понимая, что и когда будет готово.
• Вы сможете проще делить и координировать работу с другими членами команды.

Принцип №2

Двигаться по чуть-чуть

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

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

В чём польза?

• Вы сможете быстрее получать фидбэк и корректировать свои планы.
• Вам будет не так обидно что-то переделывать или откатывать — то есть вы не будете подвержены эффекту IKEA.
• Команда будет регулярно видеть осязаемые результаты вашей работы и понимать её ценность.

Принцип №3

Говорить просто

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

Но делают они это не потому, что для них не важна стабильность или скорость разработки. Скорее всего, они просто не понимают ваших доводов. Так что надо развить в себе суперсилу: научиться простым языком объяснять сложные вещи нетехнарям (помните про метод Фейнмана?).

В чём польза?

• Ваши идеи чаще будут слышать, понимать и принимать.
• Люди быстрее будут делать то, что вы у них просите (ведь теперь для них станет понятно, что же вы хотите).
• Вы будете лучше разбираться в том, о чём говорите (иначе невозможно простым языком объяснить сложные вещи).

Принцип №4

Делать скучно

Некоторые программисты считают, что их работа — писать код. Но это не так. Их работа — создавать системы. А у систем есть два требования: они должны решать поставленные задачи и быть простыми в поддержке и эксплуатации. И если задачу можно решить так, чтобы не тратиться потом на поддержку: с помощью no-code, serverless, готового сервиса, фреймворка или библиотеки — используйте такой вариант. В итоге в глазах новых участников команды разработки ваш проект должен выглядеть скучным и однообразным.

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

В чём польза?

• Вы намного проще и быстрее будете ориентироваться в проекте.
• Вы сможете делегировать простые задачи менее опытным разработчикам, а своё время тратить на упрощение проекта и систематизацию.
• Вы без проблем сможете передать проект другому разработчику и начать что-то новое.

Принцип №5

Соблюдать баланс

Большинство разработчиков — перфекционисты. Они пытаются довести свою работу до идеала. Но в работе на реальных проектах всегда есть ограничения по времени и ресурсам. Поэтому опытному разработчику нужно ориентироваться в текущих требованиях и быть способным сделать правильный выбор.

Что важнее прямо сейчас — качество или скорость? Лучше написать тесты или сделать быстро? Разобраться в новой модной библиотеке, которая вроде бы решает проблему, или сделать так, как умеем?

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