Back to blog

9 вещей, которые каждый разработчик должен делать


Быть упорным

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

Хочется сдаться? Именно в этот момент нужно проявить большее упорство и сделать это.

Решение проблемы, которая еще недавно казалось тебе нерешаемой, вызывает неимоверный кайф и состояние эйфории. Даже если причиной этой проблемы стал ты сам 😉


Никогда не прекращать обучаться

Если ты хочешь расти как профессионал и чтобы зарплата тоже росла, нужно все время быть в процессе обучения, изучения нового.

Если не хочешь и счастлив быть разработчикам php5/JQuery, хорошо, каждый сам волен распоряжаться своей жизнью.

Но если у тебя есть хоть малейшая склонность двигаться вверх, ты должен быть готов учиться новым вещам. “Новыми вещами” могут быть новые языки программирования, технологии, подходы, методики и т п. Но лучше всего, чтобы эти новые вещи были каким-то образом связаны с твоим текущим стеком. К примеру, если программируешь на php/js/jquery изучи современный фреймворк react/angular/vue или посмотри в сторону reactphp

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



Оспаривать устоявшиеся вещи и задавать “Тупые” вопросы

Я не имею ввиду, что надо всегда пытаться быть против того, что уже есть в проекте. Просто любимым вопросом должен стать ”Почему?”.

Нужно ставить под вопрос текущие решения. Это может быть очень сложно и коллеги не будут тебя за это сильно любить, но инновации требуют остановиться и спросить “Почему?”.

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


Лучший путь для этого - это “тупые вопросы”. Не надо приходить и говорить “почему мы делаем так?”. Это может показаться грубым и, что хуже, непонятным.

Вместо этого лучше спросить “А есть какая-то особая причина, почему мы используем X для этой части программы?”. Смысл тот же, но это звучит понятнее показывает верное направление. 


Читать эти долбанные Логи/Мануалы/Документацию

Тебе нужно читать то, что тебе дают! 

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

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


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


Отвлекаться от работы.

Нет такого правила всё время сидеть за столом(фирмы, использующие трекеры, горите в аду). Если у тебя что-то не получается, ты в чем-то запутался или просто устал, если ты в буквальном смысле не прикован цепями к столу, то встань и прогуляйся. Сходи за кофе, придумай планы на выходные или напиши что-нибудь другу. Сделай что-то, что отвлечет тебя от работы. Человеческий мозг - странный орган, даже если в данный момент ты не думаешь о проблеме, мозг всё равно пытается решить её в фоновом режиме.

Часто потрясающие идеи приходят вовсе не на рабочем месте, а например в душе или в … кхм… в туалете, в общем, вне рабочего стола.

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


Быть на связи

Я не говорю о том, чтобы быть онлайн 24/7 и по каждому чиху отвлекаться и отвечать. У команды должна быть возможность связаться с тобой. Не нужно следить за всеми менеджерами и соцсетями и отвлекать на каждое обновление. Оставь включенными только личные сообщения и упоминания в корпоративном мессенджере, я думаю, этого достаточно. Некоторые коллеги, могут этим злоупотреблять, беспокоя по “экстренному каналу“ по пустякам. Что ж, таким коллегам придется объяснить, что для таких вещей, есть, например таск-менджер. 


Выигрывать в команде, проигрывать одному

Взаимоотношения с коллегами - это очень важно. Так же важно как и взаимоотношения с начальством. Нужно выстроить и поддерживать хорошие рабочие отношения с коллегами. Особенно, если ты senior или выше. Тебе необходимо признавать успехи своих коллег, когда они делают что-то невероятное. И ты должен брать ответственность за ошибки, потому что ошибки будут. Никакой менеджер не будет винить тебя в то, что ты совершил ошибку (хороший менеджер не будет), все мы люди, очень плохо не учиться на этой ошибке. Если ты совершил промах, возьми на себя ответственность за это, запомни это и больше никогда не повторяй эту ошибку. Худшая вещь, которую ты можешь сделать, это винить в своих ошибках других членов своей команды. 


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


Избегать токсичных рабочих мест

В работе разработчика нет ничего важнее собственного благополучия. Да, именно так:


В работе разработчика нет ничего важнее собственного благополучия


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

У меня была работа, при устройстве на которую мне обещали новейший стэк, полный карт-бланш в выборе технологий и проектировании структуры, адекватное руководство и т. п. На самом деле, было сложно согласовать установку последней версии языка, когда повсеместно а фирме использовался язык версии семилетней давности. Быстрые костыли были основным методом решения задач и приветствовались в отличие от мыслей о хотя бы легком рефакторинге. Задачи и “хотелки” летели от всех подряд: руководства, директоров, руководителей и просто работников других отделов. Несколько часов можно было провести за бессмысленным разговором в скайпе с парой тройкой людей, которые сами не понимают, что от тебя хотят. Указы начальства касательно будущих фич не обсуждались, даже некоторые предложения по корректировками отметаюсь на самом первом уровне.

Я проработал там 4 месяца. И это, наверное, даже долго. Без угрызений совести сменил работу.

Мораль проста - не надо себя мучать, не нравится - уходи.


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

Это частая ошибка которую я допускаю и, скорее всего, допущу снова.

Когда ты ищешь работу, очевидно, что ты хочешь сделать свое резюме как можно привлекательнее. Как? Включаешь туда все-все вещи, с которыми когда-то имел дело. Каждую технологию, каждый язык, на котором написал хотя бы ‘’hello world”. А потом всегда удивляешься, когда тебя назначают “главным” по технологии, которая тебе не нравится. 

Обычно это происходит по следующему сценарию:


“Ты указал в резюме, что имеешь большой опыт в jquery. Теперь ты будешь поддерживать весь наш jquery легаси код”.


Вот ты и застрял на позиции jquery-мэна.


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



Я что-то упустил? Есть еще какие-то вещи, которые каждый разработчик должен обязательно делать? Делитесь в https://teleg.run/progersclub

© 2020 shogenov.com