Хабрахабр

[Перевод] 5 важных и упущенных навыков, необходимых лучшему разработчику

image

Предисловие

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

  • «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.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть