Кто такой одинарный инженер?

Автор оригинала: cutenode
  • Перевод
Кто такой «1х-инженер»?

Возможно, вы слышали о «десятикратных» инженерах. Они очень производительны, эффективны, работают буквально за десятерых. Если такие существуют, то наверняка должны быть и одинарные инженеры?

Конечно, такие есть. Давайте попробуем составить список качеств, присущих простому одинарному инженеру. Неполный список.

Итак, 1х инженер…

  • Если не уверен в ситуации, ищет ответ в Google, Duckduckgo, Bing и везде, где только может.
  • Копипастит фрагменты кода из Stack Overflow, Glitch, Codepen или других ресурсов, где находит ответы.
  • Отдаёт должное авторам кода, если это необходимо.
  • Создаёт сообщество и делится знаниями.
  • Тратит время на вещи, не связанные с инженерией, такие как хобби, друзья и семья.
  • Поддерживает здоровый баланс между работой и личной жизнью, а также уважает время других.
  • Не оценивает себя произвольными метриками вклада на любом сайте и не судит других за их метрики и вклад.
  • Пишет код, &emdashнаполненный&emdash; багами.
  • Пишет код, который другие могут прочитать.
  • Читает документацию.
  • Обновляет документацию.
  • Не обязательно увлекается кодом, который пишет, или проблемой, которую решает, хотя такое возможно.
  • Не удивляется, когда кто-то чего-то не знает.
  • Готов и способен сотрудничать с другими.
  • Публично прославляет других за их победы.
  • Задаёт вопросы, прежде чем критиковать.
  • Критикует в частном порядке, не публично.
  • Относится к другим так, как они хотят, чтобы к ним относились.
  • Предоставляет коллегам конструктивные, полезные и тактичные код-ревью и отзывы, помогая им расти лично и профессионально.
  • Выражает признательность за конструктивные и полезные код-ревью и отзывы коллег.
  • Иногда чувствует себя уязвлённым критикой, но не реагирует деструктивно.
  • Иногда делает короткие перерывы, чтобы очистить голову.
  • Время от времени совершает ошибки и находит в этом причины для профессионального роста.
  • Готов признать свою неправоту и не боится сказать «Я не знаю».
  • Любит или не любит писать документацию, но всё равно делает это для будущих мейнтейнеров.
  • Любит или не любит писать тесты, но учится их писать, если это нужно команде или проекту.
  • Благодарит других за их время, усилия и энергию.
  • Может установить красочные обои на рабочий стол.
  • Поддерживает код в продакшне, даже если не он его написал.
  • Иногда страдает от синдрома самозванца и понимает, что другие тоже могут.
  • Считает, что все присутствующие одинаково умны и способны.
  • Не отказывается помочь другим повысить их уровень и сам просит о помощи, когда нуждается.
  • Никогда не прекращает учиться, но иногда полностью подавлен тем объёмом материала, который нужно изучить.
  • Старается поддерживать продуктивность дискуссий и позволяет людям высказывать своё мнение до принятия решения.
  • Готов покинуть зону комфорта.
  • Вносит вклад в сообщество по-своему, когда это возможно, и ценит то, как другие вносят свой вклад, когда могут.
  • Может программировать медленно.
  • Имеет продуктивные и непродуктивные дни.
  • Не воспринимает себя слишком серьёзно.
  • Говорит «никогда о таком не слышал» вместо того, чтобы кивать и притворяться.
  • Достоин доверия.
  • Работает, чтобы жить, а не живёт, чтобы работать.
  • Иногда теряет свою работу.
  • Не всегда помнит всю кодовую базу.
  • Уважает и поддерживает общественные кодексы поведения.
  • Может работать дома, в офисе, в кафе или где-то ещё, где лучше всего получается.
  • Не хейтит инструменты, процессы или языки, которые сам предпочёл бы не использовать или которые используют другие.
  • Его личность не определяется компьютером, который он использует.
  • Может украсить свой ноутбук и рабочее место любым способом, который ему нравится, а также уважительно относится к декору других (или его отсутствию).
  • Не заражается хайпами в твиттере от невежественных венчурных инвесторов.

В списке чего-то не хватает? Однократные инженеры часто скромны и готовы принять пул-реквесты на исправление ошибок.

Заходите в репозиторий статьи.

Комментарии 52

  • НЛО прилетело и опубликовало эту надпись здесь
      +7

      На мой взгляд, мы сильно недооцениваем влияние окружения программиста на его продуктивность. С этой точки зрения, один и тот же человек в может проявлять себя как 10х в одном окружении и как 1х в другом (по сравнению с остальными членами соответствующих команд). Следовательно, писать подобный список нет особого смысла.


      Но поднимать вопросы производительности — это вполне правильно. За это спасибо!

        +2
        На мой взгляд, мы сильно недооцениваем влияние окружения программиста на его продуктивность.

        Знаете, что самое смешное? Те люди, благодаря исследованиям которых сделали вывод о существовании 10x программистов, писали, что 10х получается не из-за программиста, а из-за инструментов, языка и команды. Такие дела.

          +1

          А вот тут один товарисч пишет, что "деятикратники" получаются том числе потому, что пишут себе скрипты, автоматизирующие повторяющиеся операции, и, соответственно, значительно ускоряющие их работу.

            +4

            как скрипт ускорит написание нового кода в современной IDE мне не очень понятно

              –2

              Вот именно поэтому я — десятикратник, а Вы, похоже, — нет ;)

                +1
                За последние два года у меня не было ни одного раза, что бы повторились, или были хоть как-то похожи задачи на работе. Вы уверены, что это не у Вас должность — шлёпать КРУДы, автоматизировать тесты, или верстать фронтент?
                  0

                  Абсолютно уверен.


                  Та часть нашей системы, которой занимаюсь я, поддерживает взаимодействие с системами примерно 50 наших партнёров, каждый из которых предоставляет данные своим, зачастую весьма извращённым способом. Примерно раз в неделю кто-нибудь из партнёров (а иногда — несколько сразу запускает свои шаловливые ручонки что-то подправляет в своей системе (иногда — слегонца, иногда — на уровне толстого полярного лиса). Моя задача — как в той истории про конвейер, "делай что хочешь, крутись как хочешь, но похороны завтра в полдень загрузка данных должна работать". При этом партнёры зачастую совершенно не горят желанием что-то делать в своих системах.


                  Пример 1

                  Партнёр предоставляет данные в файле, который можно воспринимать как fixed width, то есть


                  значение 1  ,значение 2    ,значение 3    ,значение 4
                  значение 5  ,значение 6    ,значение 7    ,значение 8

                  (К сожалению, парсить этот файл как CSV нельзя, потому что значения могут сожержать кавычки и запятые.)


                  Так вот, в один прекрасный день у них в данных появилось несколько NULL значений, а поскольку код, который формирует файл, написан примерно как


                  print value1
                  print ","
                  print value2
                  print ","
                  print value3
                  print ","
                  print value4

                  в результате чего получается файл


                  значение 1  ,значение 2    ,значение 3    ,значение 4
                  значение 5  ,значение 6    ,,значение 8
                  значение 11 ,значение 12   ,значение 13   ,значение 14

                  То есть это не CSV, но и не fixed-width! Но данные-то на месте, и файл должен загрузиться. Соответственно, открываю написанную мною библиотеку и дописываю обработчик такой ситуации (а заодно, раз уж открыл, и десятка аналогичных).


                  Пример 2

                  Файл — обычный CSV с заголовками, то есть


                  ЗАГОЛОВОК 1 ,ЗАГОЛОВОК 2   ,ЗАГОЛОВОК 3   ,ЗАГОЛОВОК 4
                  значение 1  ,значение 2    ,значение 3    ,значение 4
                  значение 5  ,значение 6    ,значение 7    ,значение 8

                  НО! В один прекраcсный день тот, кто готовил этот файл, похоже, немного недоперепил, и мы получаем


                  значение 1  ,значение 2    ,значение 3    ,значение 4
                  ЗАГОЛОВОК 1 ,ЗАГОЛОВОК 2   ,ЗАГОЛОВОК 3   ,ЗАГОЛОВОК 4
                  значение 5  ,значение 6    ,значение 7    ,значение 8

                  Причём данные все корректные, но с форматом опять пришёл полярный лис!


                  В общем, у меня наработана уже весьма обширная библиотека "как ЕЩЁ человек может испоганить данные", причём я уже давно исправляю не только конкретно имеющуюся в данный момент проблему, но и делаю новый код гибким — чтобы, когда (не "если"!) опять возникнет нечто подобное, исправить проблему можно изменением одного-двух параметров, а не написанием новой функции. Вот это и будет примером тех "скриптов/библиотек", о которых шла речь.

                    +2
                    Почему вы не валидируете данные на этапе ввода/импорта?
                      +8
                      Но фиксы валидации это же не то что ожидают от 10х. Валидацию обычно скидывают на студента который прогуливает пары чтобы работать.
                        +3

                        Интеграции — зачастую не самая скиловая команда на проекте. Толковым ребятам быстро надоедает по недописанным спекам мапить поля в парсере. Вы скорее 10х json/csv parser

                          0

                          А с чего Вы взяли, что я только валидациями занимаюсь? Мне были заданы конкретные вопросы, я дал на них конкретные ответы, с конкретными примерами.

                          +1
                          Если существует десяток партнёров, которые данные, каждый в своём формате в виде файлов передают, почему не предоставить им API вместо загрузки файла, что-бы они данные ч-з API заливали?
                          В плюсах:
                          1 не нужен программист для импорта данных и постоянной коррекции.
                          2 прекратится вакханалия форматов, данные будут поступать валидированными на стороне партнёров.

                          Я вообще удивляюсь, почему до сих порт существует обмен данными между автоматическими системами в виде файлов.
                          Банки, платёжные системы, телко операторы. Все гоняют друг-другу эскцельчики и csv файлы.
                          Создают друг-другу sftp и перекидывают фалы, которые потом другие системы выбырают и парсят.

                          Ну бред ведь. В чём профит подобного обмена в 21-м веке?
                            +1
                            Если существует десяток партнёров, которые данные, каждый в своём формате в виде файлов передают, почему не предоставить им API вместо загрузки файла, что-бы они данные ч-з API заливали?

                            Потому что данные нужны не партнерам, данные нужны нам. А, как известно, тот, кому что-то нужно, прогибается под того, у кого это что-то нужное есть, а не наоборот. Я бы с преогромнейшим удовольствием API предоставил — но им это не надо, это ж нужен компетентный программист (на их стороне), чтобы ответную часть к этому API писать — а есть только говнокодер, способный "псевдо-CSV" из десятка print без валидации накорябать.


                            Ну бред ведь. В чём профит подобного обмена в 21-м веке?

                            Откуда Вы знаете, какие слова я сказал в первый день на работе? :) Но — см. предыдущий абзац: ответ партнёров один — "не нравится — не скачивайте, никто не заставлет".

                              0
                              Претензия в принципе не к вам. Просто удивительно, что подобной фигнёй из 90-х годов прошлого столетия до сих пор пользуются.
                                +2

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


                                Кстати, несколько замечаний по теме.


                                1. Сразу предупреждаю: компания из США. Так что не нервничайте, что некоторые вещи кажутся неправдоподобными: Россия пропустила некоторые вехи развития технологий, которых Америка хлебнула по полной (см. например "проблема 2000" — большинство российских программистов думает, что это про писюки, но нет, нет, в первую очередь — это про мейнфреймы, хоть и имевшие относительно много памяти, но и оперирующие многими сотнями тысяч записей, так что в этом контексте экономия двух байт на запись для 1980-х была далеко не копеечной..).
                                2. Судя по некоторым неочевидным особенностям некоторых файлов, получаемых нами от некоторых партнёров (первый признак — fixed-width файл, второй — представление десятичных чиcел, для понимающих людей — PIC 9(8)V99.), они генерятся при помощи ПО, написанного на COBOL. Мне кажется, можно больше ничего не говорить — этим всё сказано...
                            –1
                            не так я представлял себе 10х инженера…
                              0

                              Послушайте, Вы вообще тред-то читали? Вопросы ко мне были —


                              как скрипт ускорит написание нового кода

                              и


                              За последние два года у меня не было ни одного раза, что бы повторились, или были хоть как-то похожи задачи на работе

                              Я привёл конкретный пример, где "скрипт (библиотека) ускоряет написание нового кода", в котором "задачи повторяются в среднем раз в неделю". И эта библиотека позволяет мне приводить регулярно ломаемую партнёрами систему обратно в работоспособное состояние за весьма небольшое время. Я где-то хоть раз написал, что это — ВСЁ, что я делал/делаю?

                                0

                                Ваш пример — это шикарная и поучительная история, большое спасибо за неё!


                                А до того, что не все поняли её scope, так это жизнь. Ещё древние римляне писали: sapienti sat. Не стоит переживать по этому поводу

                                  0
                                  Не стоит переживать по этому поводу

                                  Если бы просто "не все поняли её scope" и пошли своей дорогой, я бы не переживал, но проблема в том, что эти "не разобравшиеся" вместо этого идут и ср испражняются в карму, в результате чего страдает моя возможность рассказывать поучительные истории и/или отвечать на комментарии с вопросами. А что карма — дорога с односторонним движением, я пишу уже давно.

                                    0
                                    Я в карму испражняться не могу при всём желании, у меня после 68 оценок она застыла на нуле — фантастический результат, не уверен что так бы получилось, даже если бы я специально старался.

                                    За ответ спасибо, чем Вы занимаетесь я примерно понял.

                                    Что интересно — мы в банке занимаемся примерно тем же — получаем данные из десятка разных систем, каждая из которых ломается на свой, особый, лад, пережевываем их и отдаём в каком-то виде дальше. При этом, как я и писал, постоянно ломается что-то новое, за всё мое время работы поломки ни разу не повторились. Исправляем, работаем дальше. Есть коллега, сертифицированный разработчик БД, умудряется на PL/SQL работать за троих джавистов, например, недавно сделала возможным загрузку очень многих миллионов строк данных, путём исправления очень и очень многих косяков в этих самых данных. При этом — решая инциденты и переругиваясь с командами, которые эти самые данные испоганили. Как ни странно, даже она не мнит себя 10х инженером. Это просто работа, которую от нас ожидают, вот и всё.
                      0
                      Ну например habr.com/ru/post/335388

                        0

                        Взгляд на эти вещи сильно зависит от того, что подразумевать под словом "скрипт". Если не трактовать его в узком смысле, то возможности найдутся. Например:


                        1. Использование шаблонов для более быстрого создания типовых файлов. Использование сниппетов для быстрого создания типовых конструкций внутри них (for и иже с ними).
                        2. Более быстрое и надёжное редактирование текста с использованием макросов vim. Vim-режим есть во многих современных IDE
                        3. Если надо внести очень похожие правки в очень большом количестве файлов (типа замены по регулярке), то бывает гораздо быстрее и эффективнее провернуть их вне IDE, используя sed или условный codemod.

                        Список не исчерпывающий, можно дополнять. Я уж не говорю о том, что для многих "экосистем" (C/C++, Python, JS, ...) подход с автоматизацией типовых задач именно через скрипты является абсолютно естественным, и IDE в принципе не может их все заменить. Максимум, чем она может помочь, — так это обернуть скрипт в свою же запускалку, чтобы облегчить жизнь мышевозникам (вот радость то: не надо открывать консоль, чтобы напечатать make something, а можно выбрать сохранённую конфигурацию запуска в выпадашке и нажать зелёный треугольничек!).

                  +2
                  Описали качества хорошего инженера. К ним можно стремиться. Но 10x и 1x это про производительность, контекст и наблюдателя.

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

                  Для меня разница между 10x и 1x — умение быстро переключаться между контекстами и проектами.

                  С точки зрения бизнеса 10x — это хорошо, т.к. решает насущные проблемы, с точки зрения продукта — не очень, т.к. конкретный продукт может медленнее двигаться к результату из-за постоянных временных решений.

                  Мое представление (по крайней мере к этому наблюдается тренд):
                  10x — agile инженер
                  1x — waterfall инженер
                    +1

                    Хорошее наблюдение. А теперь попробуйте мысленно поместить "agile" инженера в "waterfall" окружение. Сможет ли он по-прежнему выдерживать 10x перформанс по сравнению с коллегами?

                      0
                      А должен?
                      Ну как по мне контекст тоже влияет.
                      И 10x это наблюдаемая кем-то со стороны производительность. Тим лид будет видеть все закрываемые задачи, руководитель будет видеть один еще не завершенный проект.

                      Поясню, что я исхожу из предположения что физически 10x успевает столько же сколько и 1x. Но в силу того что черпает опыт из разных направлений, проектов и задач, то может некоторые вопросы решать более эффективно и быстрее чем 1x.
                        0
                        В некотором роде 10x это маркетинговая стратегия инженера. Засветиться как можно чаще в решении как можно большего числа вопросов и стать значимым для большего числа людей.

                        Это довольно распространенная стратегия в корпоративном сегменте и медиа и в друших сферах
                          +1
                          Хорошее наблюдение. А теперь попробуйте мысленно поместить «agile» инженера в «waterfall» окружение. Сможет ли он по-прежнему выдерживать 10x перформанс по сравнению с коллегами?
                          Хорошее наблюдение. А теперь поместите гепарда в океан. Сможет ли он там по-прежнему разгоняться до 110 км/ч?
                            +1

                            Отлично, Вы правильно поняли идею! Гепард в океане — это довольно экстремальный пример, но он позволяет понять спектр возможных ситуаций между максимально комфортным и максимально дискомфортным окружениями. А их довольно много.


                            Чуть более релевантный пример. Пару лет назад я читал интервью легендарного Кента Бека (к сожалению, не сохранил ссылку, а найти повторно пока что не смог). Он рассказывал, что после его перехода на работу в Facebook (в начале 10-х, что ли) на очередном performance review оказалось, что он "является" одним из самых отстойных программистов в своём направлении. Кент Бек, отец agile!


                            Он, конечно же, перестроился, адаптировался и успешно проработал там ещё несколько лет. Но тем не менее, факт деградации производительности имел место.


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

                        +8
                        Последним пунктом непременно должно стоять:
                        — не существует.
                          +5

                          "Считает, что все присутствующие одинаково умны и способны." — но это же откровенное заблуждение. Все люди разные, у кого-то выходит лучше, у кого-то другое, у кого-то третье. И, по-хорошему, такой весь "внимательный инженер 1х" должен это понимать.

                            0
                            Ну, добавьте мыслно спереди «Априори», а сзади ", пока они не докажут обратное", так лучше станет?
                            он ведь
                            Не удивляется, когда кто-то чего-то не знает.
                              +1
                              С такой добавкой смысл любой фразы очень сильно меняется.
                            +2
                            1х инженеры ставят плюсики если им понравился пост
                              +1
                              О чём этот пост?
                                0
                                о не котиках
                                +1
                                звучит как ответственный тактичный но не очень опытный программист сотрудник.
                                Предоставляет коллегам конструктивные, полезные и тактичные код-ревью и отзывы, помогая им расти лично и профессионально.
                                и при этом:
                                Пишет код, который «задыхается», с багами
                                  0

                                  Мне кажется тут не совсем верный перевод, должно быть что-то вроде
                                  «Пишет код, в котором (о, ужас!) есть баги»

                                  0
                                  Часть этого поста — про меня, остальная часть про то, чего мне не хватает, чтобы быть таким, каким я хочу быть. Ну кроме толерантно-инклюзивного: «Считает, что все присутствующие одинаково умны и способны.» (см. комменты выше).

                                  Но причём тут 1х и 10х — вообще непонятно.
                                    0
                                    Но причём тут 1х и 10х — вообще непонятно.

                                    Речь — про скорость разработки.
                                    0

                                    Смешались в кучу кони, люди (с)


                                    Сначала навели на идею описать обычного инженера, а потом описали многое что присуще и первым, и вторым, как OR, так и XOR.


                                    По опыту, простые правила чтобы отличить хорошего инженера от хренового:


                                    1. Хороший инженер минимум работает чтобы двигать продукт вперед, и пишет качественные решения. Остальное вытекает из этого – и как он общается, и как решает вопросы, и как пишет решения.


                                    2. Хреновый инженер просто работает без переживания за проект (кобыла не моя), сидит на окладе, и/или пишет некачественные решения – где можно дать слабину (решения, диалоги, тестирование, что-угодно где можно обойтись простым некачественным решением), это может произойти.



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


                                    Высказывание выше довольно резкое, но интересно мнение других.
                                    Давайте жить дружно © и писать конструктивно.)

                                      +1
                                      так это ж ирония. Мол, 10х-еры — это такие высокомерные муд чудаки-ноулайферы, с которыми невозможно работать. А персонажи из статьи — обычные такие, приземленные, нормальные люди, хорошо выполняющие свою работу, в том числее ее унылую рутинную часть
                                        +1

                                        Проблема в том, что оценочные шкалы "хороший vs хреновый инженер" и "10x vs 1x performer" друг другу перпендикулярны. Представим, что у нас в команде работают два абстрактных инженера. Один "болеет душой" за продукт: анализирует (а порой и оспаривает, дабы улучшить) требования, пишет тесты, проводит рефакторинг и т.п. Второй по-быстрому говнякает ровно то, что описано в задании, не утруждая себя глубокими проверками. Кто из них "хороший", кто "хреновый"? А кто из них "лучший перформер" с точки зрения внешнего наблюдателя, который смотрит лишь на время закрытия фичевых тасков?

                                        0
                                        мама сказала бы — вылитый папа
                                          +2
                                          Не оценивает себя произвольными метриками вклада на любом сайте и не судит других за их метрики и вклад.

                                          Заходим в репозиторий статьи и первое что видим в README.md это картинка с количеством звезд на Github… Как будто бы метрики в правом верхнем углу не достаточно.

                                          А ниже прямым текстом написано для тех кто хочет похвастаться своим 1x статусом:
                                          Want to show off your 1x Engineer status on your own projects/webpages?


                                          Немного противоречиво…
                                            0

                                            Будучи относительно эффективным software engineer (так получается, что я и мои команды часто выдают больше результата при меньшей численности), начал эскпериментировать с экстраполяцией инженерных навыков в других областях: social engineering, team engineering, self engineering и т.п. Чтобы повлекло наличие многочисленных симптомов из числа описанных. Правильно ли я понимаю, что начинаю деградировать?

                                              +1
                                              Вы просто начали экстраполировать свои навыки в сферы bullshit engineering, autism engineering и немного даже затронули shiza engineering. Из-за широкого поля работ прогресс в вашем развитии замедлился, его-то вы и воспринимаете как деградацию. Нельзя объять необъятное.
                                                +1

                                                Давайте я внесу некоторые коррективы и вы попробуете пересмотреть свой ответ. Первая — я потерял пробел перед частицей "бы", формирующей сослагательное наклонение. С моей точки зрения деградации никакой нет, всё с точностью наоборот.


                                                Вторая — вольно интерпретированные вами social/team/self-engineering. Это то, во что мы и без того вовлечены (если только вы не бездетный, холостой затворник работающий в одиночестве, для такого может отношения с детьми и находятся в категории "bullshit"). Просто инженерные навыки позволяют существенно повысить качество. Вы будете удивлены, но ИТ — это про умение эффективно работать с любой информацией, наша деятельность очень похожа на вычислительные процессы, а принципы вроде SRP/KISS/DRY и т.п. с удовольствием прогуляются с нами и в других сферах. Я ни разу не заметил корреляции что больше времени уделённого семье, друзьям, спорту, экстремальному спорту существенно снижает мою продуктивность. Да, я стал производить меньше LoC в день, но теперь мне надо реже переписывать свой код и в итоге производительность стала намного выше.


                                                Я бы посоветовал вам избегать штамп "нельзя объять необъятное", навязанный неудачниками. Первая причина — он легко бьётся тезисом "успешные люди успешны во всём" и примеров проникновения инженеров в другие области — легион, я уверен вы и сами с ними сталкивались. Вторая — тогда вообще нельзя идти в инженеры, тем более софтверные. Мы постоянно осваиваем новые для себя области. Сегодня это может быть электронная коммерция, завтра рекрутинг, послезавтра мы вдруг окунёмся в био-инжиниринг, крипто-валюты, AR/VR, CV. Хотя, может я просто сторонник холизма и эффективный инженер долбит одну задачу десятилетиями.

                                                  0
                                                  Это было написано к тому, что вы плодите сущности на ровном месте, добавляя суффикс engineering, что есть верный признак bullshit. На другие области вы смотрите исключительно через призму своей, инжениринга, что есть верный признак autism. Все вместе это отлично укладывается в шаблон поведения фрика, что есть та самая shiza.
                                                    +1

                                                    Спасибо за комплименты. Намного приятней быть аутистом, чем ординаром. Но мне кажется, эта похвала не заслужена. Ведь engineering — это не "суффикс", а глагол. Я просто соединил существительное с глаголом, что делают… практически все, с первого класса и это уменьшает ценность порождаемого мной "bullshit".


                                                    Честно скажу, я даже был не в курсе, чтобы подобные примитивные языковые конструкции "плодят сущности". Я всегда думал, что civil engineering, software development, time management, market research — это применение вполне определённых методов к тем или иным областям. Не намного сложнее в своей конструкции чем "пупок почесать" или "баг починить".


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


                                                    Я верю, что данные из самых разных областей можно импортировать в реляционную БД и анализировать используя методы математической статистики и не надо реализовать специализированное хранилище для гидропоники на органических транзисторах. Но… наверняка нет ничего общего между паттернами publish-subscribe в message queues и Почтой России, композицией в приложении, фотографии и музыке. Моя ошибка считать что архитектоника в драматургии пересекается с архитектурой приложений и зданий, мы ведь не воровали "паттерны проектирования" в книге архитектора Кристофера Александра. Такое понятие как dependency применимо исключительно к NPM и никак к рецепту блюда. Много ошибок, но шизоиду вроде меня это простительно.


                                                    Вашу аргументацию я понял, спасибо. Как аутист я бы предположил, что вы используете привычный риторический паттерн "резкий как понос", который помогает при нулевой аргументации выглядеть убедительно. Но кто станет всерьёз воспринимать соображения таких, как я. Тем более, что даже я сам не до конца убеждён в своей правоте.

                                                      0
                                                      Вот вам еще один престарелый риторический паттерн: вы за деревьями не видите леса.

                                            Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                            Самое читаемое