Предисловие
Вы видели эти статьи тысячу раз:
- «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.
Комментарии (12)
Suvitruf
29.07.2019 10:16+4Как разработчик, Вы должны осуществить функцию
Осуществить как мечту? «implement » — это «реализовать».
кто получает выгоду от данных
«has to make sense of the data» — это не про выгоду, а про человека, который, даже если переводить буквально, извлекает «смысл» из данных, т.е, речь о человеке, который «понимает» данные.
Я видел это все время, от Junior до Senior Developer. Вы получаете задачу, и Вы выполняете ее. Я называю этих людей «Code Monkeys».
Т.е, ситуация, когда разработчику ставят нормальные таски и дают нормальное ТЗ, которое не вызывает вопросов, даже не рассматривается?
Вместо этого Вы должны попробовать найти хорошую аналогию в сфере, где все всё понимают.
В данный момент большая картина Вашей сложной программы их не волнует, и они ее не понимают.
Какие-то двойные стандарты. «Менеджеров это не волнует», «сюсюкайтесь с менеджерами, общайтесь и разжевывайте им как младенцам».
Я парень с сильным синдромом opinionated
«I'm a strongly opinionated guy» — это, если по-русски, «человек, у которого на всё есть своё мнение».
Если сюда ещё добавить все эти «Вы» и «Вас» с большой буквы, то читать становится совсем тяжело.
P.S. хватит вместо «ё» использовать «е».Normal_Mur Автор
29.07.2019 10:34Спасибо большое Вам за отзыв. Я сейчас напишу Вам в личку чтобы попросить поделиться Вашим опытом в переводе.
VolCh
29.07.2019 10:39+1Какие-то двойные стандарты. «Менеджеров это не волнует», «сюсюкайтесь с менеджерами, общайтесь и разжевывайте им как младенцам».
Тут зависит от вашей цели. Решить проблему дискоммуникации между нетехническим менеджментом и вами, как разработчиком можно несколькими основніми способами:
- "опуститься" на их уровень
- "поднять" их самому на свой (ликбезы всякие)
- настоять на том, чтобы с вами общались только те, кто понимает ваш язык (неважно сами менеджеры подтянутся без вас или введут позицию "переводчика" типа анлитика
- уйти и искать там, где проблема уже решена (по сути предыдущий вариант)
Как думаете, какой ваш подход к решению этой проблеме будет больше всего цениться в ощем случае?
Suvitruf
29.07.2019 10:44Этот вопрос должен решаться с обеих стороны. Если изначально постановка такая, что все попытки наладить коммуникацию должны идти от технаря, а не с двух сторон, то да, лучше уйти.
VolCh
29.07.2019 10:54Или таки наладить со своей стороны, чем повысить свою ценность для бизнеса.
Suvitruf
29.07.2019 10:57Это всё вопрос интереса. Если компания интересна и хочется сделать её (или процессы в ней) лучше, то да, можно и попробовать наладить со своей стороны. Если же текущее место работы просто перевалочный пункт, то, возможно, оно того не стоит.
VolCh
29.07.2019 11:33+1Даже во втором случае строчка в резюме "наладил процессы комуникации между бизнесом и разработкой" может быть очень полезной :)
swetlanaspb
30.07.2019 12:54В дополнении к комментариям выше:
уйдут – потому что не смогут выносить это больше.
Хотела бы порекомендовать переводить так: «потому что не смогут это больше выносить». Так более привычно звучит с точки зрения русского языка.
VolCh
Я бы добавил: не бояться говорить "пока не знаю, мне нужно время, чтобы разобраться с вопросом"