Предисловие

Вы видели эти статьи тысячу раз:

• «10 вещей, которые нужно создать чтобы стать лучшим разработчиком.»
• «Лучшие фреймворки для изучения в 2019.»
• «Сделайте это чтобы стать разработчиком Rockstar.»
• «Прочитайте эти десять технических книг, и Вы станете успешным разработчиком.»

Что они говорят – так это что Вы должны выучить «reactjs» или «node». Создать 1.000.000.000 приложение ToDo. Прочитать «Ускоренный Курс Python» и – бум, Вы лучший разработчик.

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

Давайте поговорим об, как мне кажется, упущенных из виду навыках.

Абстрактное мышление

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

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

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

Вернемся к задаче «насколько часто кликает пользователь на сайте». Я представляю себя в обоих ролях. В роли пользователя, и того, кто видит данные и пытается разобраться – в чём пользователь нуждался.

Для конечного пользователя всё должно быть прежне. Может, появится дисклеймер, который он нажмет раз. И всё. Эти функции должны быть невидимы для конечного пользователя. Хорошо, это было просто. Всегда думайте о своём конечном пользователе в первую очередь! Всегда!

Теперь, давайте подумаем о том, кто получает выгоду от данных. Так что же он хочет видеть? Просто число. Как 42? Но что это число означает? Может, лучший способ измерений будет не частота кликов, а цель клика? Вы идёте обратно к своей команде разработчиков или к акционерам и говорите им что, может лучше обладать статистикой о том, как часто мы кликаем и какие действия следуют за кликом? Возможно Вы слышали что-то вроде «О, ты можешь сделать это? Да, давай сделаем это». Можно и дальше углубляться в абстракции, но я думаю, Вы уловили.

Формулировка правильного вопроса

Я видел это все время, от Junior до Senior Developer. Вы получаете задачу, и Вы выполняете ее. Я называю этих людей «Code Monkeys».

Часть бытия разработчиком – задавать вопросы и доходить до сути того, чего мы должны достигнуть (это возвращает к вопросу абстракции).
Одно высказывание может быть интерпретировано 1000 путями.
Ты должен понимать почему ты реализуешь эту функцию. Так что лучше тебе увидеть проблемы и будущие риски.

Вопрос «почему» в компании часто рассматривается как проблема доверия.
Вы услышите высказывания вроде:

• Нам нужно доверять команде разработки.
• Давайте доверять им, они знают, что лучше для компании.
• Ты мне не доверяешь?
• Давай сначала попробуем, а потому зададим вопросы.

Постановка вопроса и попытка понять почему – не имеет ничего общего с доверием. Как разработчик, ты знаешь внутреннюю работу системы. Ты можешь увидеть технические проблемы и точки выхода, что может работать и что может не работать. Если Вы когда-либо слышали высказывания выше, повторение следующего работает всегда:

• «Я верю тебе, и я знаю – это важно.»

Общение с людьми без технических знаний

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

Или Вы говорите: «Нет, мы не можем это сделать» и начинаете объяснять, что ReactJS не имеет эту функцию и придется подгружать npm пакет.

Если Ваш менеджер по продукту не из бывших разработчиков, тогда он/она не поймет ни слова из того, о чём Вы говорите.

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

Терпение

Вы видели эти руководства на YouTube, где люди создают что-то в видео за 15 минут, и потом Вы пробуете повторить, и это занимает намного-много-много дольше!

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

Вы знаете – откуда это клише пришло, что разработчики – создания ночи? Потому что нам нравится это? Потому что мы антисоциальные? Это может быть правдой только для малой доли. Основная причина – написание кода отнимает время! Много времени, если Вы пытаетесь освоить что-то новое!

Твердое мнение

Я парень с сильным синдромом opinionated, если это касается веб-разработки, и я говорю людям своё мнение даже если я знаю, что им оно не понравится. Я делаю это не чтобы надоесть людям или сбить их с ног. Как может мое мнение быть настолько эмоционально значительно, что после услышанного Вы засомневаетесь в собственном существовании? Простите, но есть множество более значимых проблем вокруг, и Вам следовало бы сообразить – как справиться с ними, потому что иначе это приводит только к одной вещи: Стагнации. Вы будете тем же в 18, 25 и 50 лет. Я знаю, это легче написать, чем сделать, но Вам важно знать: «То, как Вы себя сейчас ведете – единственное, что завело Вас в такую даль»

Худшая вещь, что может случиться в команде разработки – когда все имеют мнение, но никто не высказывает его! Если это случается, Вы мертвы. Это начало конца. Если Вы не code monkey, то Вы чувствуете себя менее мотивированным и более расстроенным каждый день, и это будет не только с Вами. Однажды неожиданно, люди, что работали несколько лет на компанию, уйдут – потому что не смогут выносить это больше.

Я не говорю, что Вам нужно сказать «мне это не нравится». Вы должны сказать – почему, и предоставить какие-то примеры. Не будьте ж*п*й, но и расстраивайтесь поменьше каждый день. Потому что это никому не помогает. Так что, либо выскажите свое мнение, либо не имейте мнения и будьте code monkey, либо покиньте компанию чтобы найти работу получше или станьте фрилансером. Я не знаю, что из этого правильно, но не стагнируйте.

Спасибо что прочли!