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.

Комментарии (12)


  1. VolCh
    29.07.2019 10:06
    +4

    Я бы добавил: не бояться говорить "пока не знаю, мне нужно время, чтобы разобраться с вопросом"


  1. 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. хватит вместо «ё» использовать «е».


    1. Normal_Mur Автор
      29.07.2019 10:34

      Спасибо большое Вам за отзыв. Я сейчас напишу Вам в личку чтобы попросить поделиться Вашим опытом в переводе.


    1. VolCh
      29.07.2019 10:40
      +3

      «человек, у которого на всё есть своё мнение» = "каждой бочке затычка"? :)


      1. Suvitruf
        29.07.2019 10:42

        Я именно так и воспринял оригинал. Как противоположность «молчуну», который не задаёт вопросов, есть вот такие «затычки» (:


        1. VolCh
          29.07.2019 10:53

          Я больше про уместность именно такого перевода в данном посте. Воспринял я тоже так.


  1. VolCh
    29.07.2019 10:39
    +1

    Какие-то двойные стандарты. «Менеджеров это не волнует», «сюсюкайтесь с менеджерами, общайтесь и разжевывайте им как младенцам».

    Тут зависит от вашей цели. Решить проблему дискоммуникации между нетехническим менеджментом и вами, как разработчиком можно несколькими основніми способами:


    • "опуститься" на их уровень
    • "поднять" их самому на свой (ликбезы всякие)
    • настоять на том, чтобы с вами общались только те, кто понимает ваш язык (неважно сами менеджеры подтянутся без вас или введут позицию "переводчика" типа анлитика
    • уйти и искать там, где проблема уже решена (по сути предыдущий вариант)

    Как думаете, какой ваш подход к решению этой проблеме будет больше всего цениться в ощем случае?


    1. Suvitruf
      29.07.2019 10:44

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


      1. VolCh
        29.07.2019 10:54

        Или таки наладить со своей стороны, чем повысить свою ценность для бизнеса.


        1. Suvitruf
          29.07.2019 10:57

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


          1. VolCh
            29.07.2019 11:33
            +1

            Даже во втором случае строчка в резюме "наладил процессы комуникации между бизнесом и разработкой" может быть очень полезной :)


  1. swetlanaspb
    30.07.2019 12:54

    В дополнении к комментариям выше:

    уйдут – потому что не смогут выносить это больше.

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