Какие качества нужны senior-разработчику, или Как зарабатывать на 1000 долларов больше?

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

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

Не обойдется и без упоминания тех, кто как-то меня вдохновлял. =) Это Денис Цыплаков с семинаром о том, какие качества нужны senior-разработчику, и Сергей Бережной со своими тренингами. Семинар Дениса был очень интересным сам по себе, а для меня вообще попал в яблочко — он проходил как раз когда я задумал написать эту статью, и я несказанно обрадовался возможности поиспользовать чужие мысли в своих целях, чем я сейчас и займусь. По ходу того семинара я делал заметки и сейчас привожу их здесь. Вот мнение Дениса (вернее, то, как я его услышал) на то, какими качествами должен обладать сеньор:

• Очень важно, что он может делиться своими знаниями с коллегами и делает это.
• Знает и видит грабли на этапе проектирования.
• Может уверенно рассказать не о достоинствах, а о недостатках широко используемых технологий (попробуйте Nhibernate).
• Пишет очень простой и понятный код.
• Умеет говорить, а не только сидеть, уставившись в монитор, надежно отгородившись от внешних раздражителей тяжелой музыкой.
• Умеет работать с тем, что есть (не заниматься бесконечным обвинением «индусов», которые писали этот код до него).
• Может взять и решить задачу (заказчик спокоен и не думает об этом).
• Может помочь решить мелкую задачу с другого проекта, т.е. умеет переключаться между задачами и иметь их больше одной в своем списке.

Я согласен с большинством из этих пунктов, но хотел бы сделать акцент на немного других вещах.

Когда ты сказал, что ты крутой, и никто не спорит, то ты крутой

Сеньор «по Цыплакову» получился очень крутым, но мне кажется, ему не хватает одного качества для более быстрого продвижения — умения заявить о своей крутизне. Никто о тебе так не позаботится, как ты сам. Надо заявлять о своих умениях вслух и заниматься «саморекламой».

Ты же не Памела Андерсон, у которой все сильные стороны сразу видны, тебе еще нужно доказать, что они у тебя есть.

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

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

Проявлять инициативу

Прошли те времена, когда инициатива была исключительно наказуема. Сейчас — скорее, наоборот. Твои идеи могут реально помочь заказчику, команде или тебе самому.

Чтобы не перестараться и не делать работу, которая никому не нужна, необходимо постоянно искать компромисс между «не делать, пока не говорят» и «сделать, потому что так будет лучше».

Принимать решения и нести за них ответственность

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

1. Тебе объяснят, почему ты не прав и ты согласишься, но даже в этом случае все отметят то, что ты думаешь широко и ищешь альтернативы.
2. Все согласятся с твоими доводами — явная победа.
3. Спор не приведет к единому мнению. Это тот случай, когда надо проявлять решительность. Надо делать по-своему. Понятно, на кого теперь ложится ответственность и возможно это приведет к тому, что тебе придется задерживаться пару дней на работе до полуночи и исправлять свою ошибку, но я утверждаю, что

   Успешным может быть только тот, кто не боится брать на себя ответственность.

Надо отстаивать свою точку зрения.

Управлять ожиданиями

Что лучше — сделать эстимейт для таска пять дней и уложиться в него или сделать эстимейт три дня, но выполнить работу за четыре? В подавляющем большинстве случаев первый вариант намного лучше. Каждый эстимейт формирует ожидание. Вначале у PM, потом у заказчика, потом у клиентов заказчика. Очень неприятно на каждом уровне общения обосновывать причины задержки, не говоря уже о том, что задержка — это дополнительные деньги, которые выкладывает заказчик (или ваша компания, в зависимости от типа договора). Никому не нравится платить больше, чем было заявлено первоначально. Кроме того, когда мы вылезаем за рамки эстимейта, то спешим, на нас давит время, пишем некачественный код.

Не стоит бояться увеличить эстимейт, если есть опасение, что не успеем. Надо обязательно с кем-то советоваться в случае сомнений! Мысль «я и так в прошлый раз увеличил эстимейт, в этот раз уменьшу» пользы не принесет, в конце концов, есть кто-то, кто должен заметить постоянно завышенные эстимейты с вашей стороны и спросить, почему так происходит. Если никто такого не говорит, значит, это просто обычный страх показаться плохим специалистом («а вдруг кто-то скажет, что на этот таск с головой хватит в два раза меньше времени»).

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

Восприятие вашей работы зависит именно от того, какие ожидания вы сформировали.

Умение расставлять приоритеты!

Это скилл разработчика № 1. Нельзя, ни в коем случае нельзя позволять себе заниматься «чем-то интересным», когда у тебя есть задачи, по которым с тебя спросят и которые хотя бы немного сложнее, чем вывести список всех продуктов на страницу. Мы же все знаем, что всегда найдется что-то, о чем мы не подумали, когда представляли себе решение задачи, и что это обязательно приведет к спешке.

Надо любыми способами заставлять себя соблюдать правило «Сейчас я сделаю это, это самое важное, а уже потом это, если хватит времени», хотя конечно же сразу хочется заняться последним, оно же самое интересное.

Мы не все знаем и не все можем предугадать. Например, кто бы мог предположить, что по запросу «потный мексиканец» в поиске картинок Гугла будет куча фотографий Брюса Уиллиса?

Очень помогает установление дедлайнов типа «На этот ресерч время до 14:00, ни о чем другом в это время не парюсь, но в 14:05 я уже должен заниматься чем-то другим».

Забивать на некоторые вещи!

Это я о том, что надо всегда помнить, кто нам платит деньги, и о том, что есть такая штука, как business needs. Нам может не давать покоя вопрос с прошлого таска который «ну вааще не поняно почему не работал» и который пришлось решить другим способом, но все равно нужно делать именно то, что нужно заказчику в данный момент. Плюс далеко не всегда надо вникать в суть каждой запутанной проблемы, если ее можно решить проще. Если что-то пофиксилось каким-то непонятным способом («ну это чистая магия...»), то не всегда нужно тратить пол дня и весь мозг на то, чтобы понять, почему так произошло. Чтобы понять, стоит ли это делать, надо подумать, носит ли проблема системный характер, повторится ли она еще когда нибудь и окупятся ли те часы, которые сейчас можно потратить на ее глубокое изучение. Если этого не знает даже Чак Норрис, то надо просто взять и забить на это.

Признавать и исправлять ошибки

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

Взять и сделать

Так называется песня моего хорошего знакомого, и это то, что требуется от разработчика, который считает себя сеньором. Я совсем не утверждаю, что обязательно доделывать все, что начал, но все нужно доводить до логического конца. Если ты решил забить на то, что еще недавно казалось таким нужным, то нужно четко понимать, почему ты так делаешь (вот мы видим два предыдущих пункта в работе). Даже если что-то откладывается на потом, хорошо бы понимать, при каких обстоятельствах это «потом» может наступить.

Однако просто объяснять себе каждый раз, почему это больше не актуально — недостаточно. Хотя бы какие-то из своих планов надо реализовывать и получать красивые результаты — иначе нечем будет хвастаться.

Придираться к себе

Свою работу крайне необходимо оценивать с критической стороны. Это гораздо ближе к тому, как ее видят окружающие, чем то, как ваша работа видится вам изначально.

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

Так как все-таки заработать кучу денег?

Можно съездить на море, хорошенько загореть и попробовать получить деньги в банке под именем Уилла Смита. Но это может не сработать. Есть другой гениально простой способ. Надо попросить у себя в компании столько, сколько хочется, и если не дадут, то спросить, что надо делать, чтобы дали. И потом это делать.

Что будет, если все попросят повышения?

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

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

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU