Фёдор Борщёв

Заметки с тегом «Софтскиллы»

Мне сказали — я копаю

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

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

Мне сказали — я копаю

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

Давайте использовать скептицизм программистов — звать их на обсуждения, поощрять новые идеи, а самое главное — писать в задачах поменьше требований и побольше целей. Одно «чтобы что» стоит десяти «что сделать».

Не учитесь технологиям — учитесь решать задачи

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

Фреймворки, паттерны, методики разработки, языки программирования — это хард-скиллы. Навыки, которыми можно овладеть, просто изучив пару книг и немного попрактиковавшись. Если вы имеете за спиной базовые знания о том, как устроены инструменты программиста —  вы легко приобретёте нужный хард-скилл в любом возрасте.

Пример хард-скилла — умение размахивать молотком. Само по себе это умение ничего ничего не стоит. Молоток нужен, чтобы забить гвоздь, а гвозди забивают, чтобы построить дом. Вот это и есть самое главное умение — строить дома. И это — софт-скилл.

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

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

Процесс vs результат у разработчиков

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

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

Процесс vs результат у разработчиков

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

Самый хороший способ — прямо сейчас найти у себя на работе проект с жестким дедлайном и взять на себя ответственность за его завершение. После второго просранного таким образом проекта, вы научитесь вести правильный внутренний диалог с собой: «Действительно ли то, что я делаю необходимо для запуска?»; «Для чего мы запускаем этот проект? Какая у нас цель?»; «Что из того, что я запланировал можно НЕ делать?».

Процесс vs результат у разработчиков

Если не хотите искать проекты на работе — сделайте свой. Только поставьте жесткий дедлайн с осязаемым результатом. Пример хорошей личной задачи — завести блог. Пойдете писать бекенд на гошечке и микросервисах? Возьмете модный генератор статичных сайтов? Или все-таки медиум?

Сдавать с первого раза

И ещё один банальный софтскилл, которого не хватает 80% программистов, которых я встречал — сдавать работу с первого раза. Серьезно, любой менеджер или дизайнер легко вспомнит десяток случаев за последний год, когда программист написал «я сделяль», а на самом деле ничего не работает.

Я говорю не про сложные для программистов случаи, когда действительно нужен сторонний взгляд — вроде форм заказа, которые принимают номера телефонов только в одном, программисту известном формате.

Нихуя не работает

Я говорю о простых случаях, которые может заметить кто угодно, банальном «нажимаю на кнопку — получаю ошибку». Непосредственных причин такой хуйни может быть много — CI упал, код не прошёл валидацию\тесты, программист забыл сделать git push.

А вот фундаментальная причина одна, и ее легко исправить — это непонимание definition of done. В случае бага все просто, сделанная работа — это когда баг не воспроизводится на продакшене. В сложных фичах нужно позадавать себе вопросы — что постановщик ожидал получить? Какой самый частый сценарий использования? В каком виде лучше показывать результат?

Самое лучшее средство от непонимания definition of done — всегда подкреплять свои слова доказательством. Пофиксил баг — приложи скриншот. Выкатил фичу — запиши видосик. Если не понимаешь, что скриншотить/записывать — иди за пониманием задачи к тимлиду или менеджеру.

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

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

Воображение!
Воображение!

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

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

Приходи с решением, а не с проблемой

Люблю, когда в трекере у задачи появляются ответы, а не вопросы: «Федя, я тут сделал не по макету, потому что бек пока не готов, переделаем после запуска» или «У нас была очень сложная вьюха в авторизации и я ее переписал».

Задача не ждёт, пока я проверю почту, а количество дефектов от таких самостоятельных решений, внезапно вовсе не растет.

Задать вопрос и просидеть до конца спринта в ожидании ответа — самый лёгкий способ соблюсти закон Паркинсона.

Не бойтесь принимать решения — в здоровом коллективе ошибки ценят больше, чем безделие.