[Перевод] 5 важных и упущенных навыков, необходимых лучшему разработчику
Предисловие
Вы видели эти статьи тысячу раз:
- »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, либо покиньте компанию чтобы найти работу получше или станьте фрилансером. Я не знаю, что из этого, но не стагнируйте.
Спасибо что прочли!
Моё мнение может не совпадать с мнением автора оригинального текста.
Я уважительно отношусь ко всем подходам программистов решать поставленные задачи, и не стал бы называть кого-либо code monkey.
Также я уважительно отношусь к чужим чувствам и не стал бы призывать кого-либо расстраиваться меньше.
И прочее.
Спасибо Вам что прочитали этот текст, я для Вас старался и переводил его и с удовольствием планирую почитать Ваши комментарии за чашечкой чая Strawberry Gourmet (очень вкусный).
Не стесняйтесь :3.