Comments 52
На мой взгляд, мы сильно недооцениваем влияние окружения программиста на его продуктивность. С этой точки зрения, один и тот же человек в может проявлять себя как 10х в одном окружении и как 1х в другом (по сравнению с остальными членами соответствующих команд). Следовательно, писать подобный список нет особого смысла.
Но поднимать вопросы производительности — это вполне правильно. За это спасибо!
На мой взгляд, мы сильно недооцениваем влияние окружения программиста на его продуктивность.
Знаете, что самое смешное? Те люди, благодаря исследованиям которых сделали вывод о существовании 10x программистов, писали, что 10х получается не из-за программиста, а из-за инструментов, языка и команды. Такие дела.
А вот тут один товарисч пишет, что "деятикратники" получаются том числе потому, что пишут себе скрипты, автоматизирующие повторяющиеся операции, и, соответственно, значительно ускоряющие их работу.
как скрипт ускорит написание нового кода в современной IDE мне не очень понятно
Вот именно поэтому я — десятикратник, а Вы, похоже, — нет ;)
Абсолютно уверен.
Та часть нашей системы, которой занимаюсь я, поддерживает взаимодействие с системами примерно 50 наших партнёров, каждый из которых предоставляет данные своим, зачастую весьма извращённым способом. Примерно раз в неделю кто-нибудь из партнёров (а иногда — несколько сразу запускает свои шаловливые ручонки что-то подправляет в своей системе (иногда — слегонца, иногда — на уровне толстого полярного лиса). Моя задача — как в той истории про конвейер, "делай что хочешь, крутись как хочешь, но похороны завтра в полдень загрузка данных должна работать". При этом партнёры зачастую совершенно не горят желанием что-то делать в своих системах.
Партнёр предоставляет данные в файле, который можно воспринимать как 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! Но данные-то на месте, и файл должен загрузиться. Соответственно, открываю написанную мною библиотеку и дописываю обработчик такой ситуации (а заодно, раз уж открыл, и десятка аналогичных).
Файл — обычный 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Причём данные все корректные, но с форматом опять пришёл полярный лис!
В общем, у меня наработана уже весьма обширная библиотека "как ЕЩЁ человек может испоганить данные", причём я уже давно исправляю не только конкретно имеющуюся в данный момент проблему, но и делаю новый код гибким — чтобы, когда (не "если"!) опять возникнет нечто подобное, исправить проблему можно изменением одного-двух параметров, а не написанием новой функции. Вот это и будет примером тех "скриптов/библиотек", о которых шла речь.
Интеграции — зачастую не самая скиловая команда на проекте. Толковым ребятам быстро надоедает по недописанным спекам мапить поля в парсере. Вы скорее 10х json/csv parser
В плюсах:
1 не нужен программист для импорта данных и постоянной коррекции.
2 прекратится вакханалия форматов, данные будут поступать валидированными на стороне партнёров.
Я вообще удивляюсь, почему до сих порт существует обмен данными между автоматическими системами в виде файлов.
Банки, платёжные системы, телко операторы. Все гоняют друг-другу эскцельчики и csv файлы.
Создают друг-другу sftp и перекидывают фалы, которые потом другие системы выбырают и парсят.
Ну бред ведь. В чём профит подобного обмена в 21-м веке?
Если существует десяток партнёров, которые данные, каждый в своём формате в виде файлов передают, почему не предоставить им API вместо загрузки файла, что-бы они данные ч-з API заливали?
Потому что данные нужны не партнерам, данные нужны нам. А, как известно, тот, кому что-то нужно, прогибается под того, у кого это что-то нужное есть, а не наоборот. Я бы с преогромнейшим удовольствием API предоставил — но им это не надо, это ж нужен компетентный программист (на их стороне), чтобы ответную часть к этому API писать — а есть только говнокодер, способный "псевдо-CSV" из десятка print без валидации накорябать.
Ну бред ведь. В чём профит подобного обмена в 21-м веке?
Откуда Вы знаете, какие слова я сказал в первый день на работе? :) Но — см. предыдущий абзац: ответ партнёров один — "не нравится — не скачивайте, никто не заставлет".
Так в том-то и весь цимес ситуации. Отец-основатель компании как-то проходил мимо одного такого партнёра, увидел, что они в своей работе пользуются технологиями хорошо если 1980-х, выматерился (про себя) и сказал (про себя), что сможет сделать лучше. Вот, уже седьмой год делаем всё лучше и лучше, обороты нашей конторы растут на неколько миллионов баксов каждый год, а работы по-прежнему всё ещё непочатый край.
Кстати, несколько замечаний по теме.
- Сразу предупреждаю: компания из США. Так что не нервничайте, что некоторые вещи кажутся неправдоподобными: Россия пропустила некоторые вехи развития технологий, которых Америка хлебнула по полной (см. например "проблема 2000" — большинство российских программистов думает, что это про писюки, но нет, нет, в первую очередь — это про мейнфреймы, хоть и имевшие относительно много памяти, но и оперирующие многими сотнями тысяч записей, так что в этом контексте экономия двух байт на запись для 1980-х была далеко не копеечной..).
- Судя по некоторым неочевидным особенностям некоторых файлов, получаемых нами от некоторых партнёров (первый признак — fixed-width файл, второй — представление десятичных чиcел, для понимающих людей —
PIC 9(8)V99.), они генерятся при помощи ПО, написанного на COBOL. Мне кажется, можно больше ничего не говорить — этим всё сказано...
Послушайте, Вы вообще тред-то читали? Вопросы ко мне были —
как скрипт ускорит написание нового кода
и
За последние два года у меня не было ни одного раза, что бы повторились, или были хоть как-то похожи задачи на работе
Я привёл конкретный пример, где "скрипт (библиотека) ускоряет написание нового кода", в котором "задачи повторяются в среднем раз в неделю". И эта библиотека позволяет мне приводить регулярно ломаемую партнёрами систему обратно в работоспособное состояние за весьма небольшое время. Я где-то хоть раз написал, что это — ВСЁ, что я делал/делаю?
Ваш пример — это шикарная и поучительная история, большое спасибо за неё!
А до того, что не все поняли её scope, так это жизнь. Ещё древние римляне писали: sapienti sat. Не стоит переживать по этому поводу
Не стоит переживать по этому поводу
Если бы просто "не все поняли её scope" и пошли своей дорогой, я бы не переживал, но проблема в том, что эти "не разобравшиеся" вместо этого идут и ср испражняются в карму, в результате чего страдает моя возможность рассказывать поучительные истории и/или отвечать на комментарии с вопросами. А что карма — дорога с односторонним движением, я пишу уже давно.
За ответ спасибо, чем Вы занимаетесь я примерно понял.
Что интересно — мы в банке занимаемся примерно тем же — получаем данные из десятка разных систем, каждая из которых ломается на свой, особый, лад, пережевываем их и отдаём в каком-то виде дальше. При этом, как я и писал, постоянно ломается что-то новое, за всё мое время работы поломки ни разу не повторились. Исправляем, работаем дальше. Есть коллега, сертифицированный разработчик БД, умудряется на PL/SQL работать за троих джавистов, например, недавно сделала возможным загрузку очень многих миллионов строк данных, путём исправления очень и очень многих косяков в этих самых данных. При этом — решая инциденты и переругиваясь с командами, которые эти самые данные испоганили. Как ни странно, даже она не мнит себя 10х инженером. Это просто работа, которую от нас ожидают, вот и всё.
даже она не мнит себя 10х инженером.
Не нашла способа использовать свою редкость как (конкурентное) преимущество?
Ничего, это пройдёт. Я тоже лет десять считал "да во мне нет ничего особенного, я такой же, как и тысячи других и т.п.", несмотря на победы во всероссийских олимпиадах и проч. Эффект Даннинга — Крюгера, во всей красе.
Взгляд на эти вещи сильно зависит от того, что подразумевать под словом "скрипт". Если не трактовать его в узком смысле, то возможности найдутся. Например:
- Использование шаблонов для более быстрого создания типовых файлов. Использование сниппетов для быстрого создания типовых конструкций внутри них (
forи иже с ними). - Более быстрое и надёжное редактирование текста с использованием макросов vim. Vim-режим есть во многих современных IDE
- Если надо внести очень похожие правки в очень большом количестве файлов (типа замены по регулярке), то бывает гораздо быстрее и эффективнее провернуть их вне IDE, используя
sedили условный codemod.
Список не исчерпывающий, можно дополнять. Я уж не говорю о том, что для многих "экосистем" (C/C++, Python, JS, ...) подход с автоматизацией типовых задач именно через скрипты является абсолютно естественным, и IDE в принципе не может их все заменить. Максимум, чем она может помочь, — так это обернуть скрипт в свою же запускалку, чтобы облегчить жизнь мышевозникам (вот радость то: не надо открывать консоль, чтобы напечатать make something, а можно выбрать сохранённую конфигурацию запуска в выпадашке и нажать зелёный треугольничек!).
— Есть области где каждый мелкий результат на виду. Микросервисы, фронтенд. Видимого результата больше.
— Есть сферы где выигрывает многозадачность и умение быстро переключаться. Если находить решение проблемы теми средствами что есть и в те сроки что есть, то решение проблемы — это уже видимый результат, но до готового продукта все равно остается год.
Для меня разница между 10x и 1x — умение быстро переключаться между контекстами и проектами.
С точки зрения бизнеса 10x — это хорошо, т.к. решает насущные проблемы, с точки зрения продукта — не очень, т.к. конкретный продукт может медленнее двигаться к результату из-за постоянных временных решений.
Мое представление (по крайней мере к этому наблюдается тренд):
10x — agile инженер
1x — waterfall инженер
Хорошее наблюдение. А теперь попробуйте мысленно поместить "agile" инженера в "waterfall" окружение. Сможет ли он по-прежнему выдерживать 10x перформанс по сравнению с коллегами?
Ну как по мне контекст тоже влияет.
И 10x это наблюдаемая кем-то со стороны производительность. Тим лид будет видеть все закрываемые задачи, руководитель будет видеть один еще не завершенный проект.
Поясню, что я исхожу из предположения что физически 10x успевает столько же сколько и 1x. Но в силу того что черпает опыт из разных направлений, проектов и задач, то может некоторые вопросы решать более эффективно и быстрее чем 1x.
Это довольно распространенная стратегия в корпоративном сегменте и медиа и в друших сферах
Хорошее наблюдение. А теперь попробуйте мысленно поместить «agile» инженера в «waterfall» окружение. Сможет ли он по-прежнему выдерживать 10x перформанс по сравнению с коллегами?Хорошее наблюдение. А теперь поместите гепарда в океан. Сможет ли он там по-прежнему разгоняться до 110 км/ч?
Отлично, Вы правильно поняли идею! Гепард в океане — это довольно экстремальный пример, но он позволяет понять спектр возможных ситуаций между максимально комфортным и максимально дискомфортным окружениями. А их довольно много.
Чуть более релевантный пример. Пару лет назад я читал интервью легендарного Кента Бека (к сожалению, не сохранил ссылку, а найти повторно пока что не смог). Он рассказывал, что после его перехода на работу в Facebook (в начале 10-х, что ли) на очередном performance review оказалось, что он "является" одним из самых отстойных программистов в своём направлении. Кент Бек, отец agile!
Он, конечно же, перестроился, адаптировался и успешно проработал там ещё несколько лет. Но тем не менее, факт деградации производительности имел место.
Это я к тому, что производительность определяется не только навыками отдельной личности, но ещё и окружением, в котором эта личность работает. И, более того, роль этого окружения систематически нами недооценивается. Может, потому, что мы люди, и нам интереснее смотреть на людей, а не на пейзаж, в котором они находятся.
— не существует.
Предоставляет коллегам конструктивные, полезные и тактичные код-ревью и отзывы, помогая им расти лично и профессионально.и при этом:
Пишет код, который «задыхается», с багами
Смешались в кучу кони, люди (с)
Сначала навели на идею описать обычного инженера, а потом описали многое что присуще и первым, и вторым, как OR, так и XOR.
По опыту, простые правила чтобы отличить хорошего инженера от хренового:
Хороший инженер минимум работает чтобы двигать продукт вперед, и пишет качественные решения. Остальное вытекает из этого – и как он общается, и как решает вопросы, и как пишет решения.
Хреновый инженер просто работает без переживания за проект (кобыла не моя), сидит на окладе, и/или пишет некачественные решения – где можно дать слабину (решения, диалоги, тестирование, что-угодно где можно обойтись простым некачественным решением), это может произойти.
Есть еще группа людей в промежутке – очень хочется но не получается (джуны, мидлы), и очень получается, но не хочется (например, сениор или лид – все могу, решаю задачи хорошо, но за проект не переживаю).
Высказывание выше довольно резкое, но интересно мнение других.
Давайте жить дружно © и писать конструктивно.)
Проблема в том, что оценочные шкалы "хороший vs хреновый инженер" и "10x vs 1x performer" друг другу перпендикулярны. Представим, что у нас в команде работают два абстрактных инженера. Один "болеет душой" за продукт: анализирует (а порой и оспаривает, дабы улучшить) требования, пишет тесты, проводит рефакторинг и т.п. Второй по-быстрому говнякает ровно то, что описано в задании, не утруждая себя глубокими проверками. Кто из них "хороший", кто "хреновый"? А кто из них "лучший перформер" с точки зрения внешнего наблюдателя, который смотрит лишь на время закрытия фичевых тасков?
Не оценивает себя произвольными метриками вклада на любом сайте и не судит других за их метрики и вклад.
Заходим в репозиторий статьи и первое что видим в README.md это картинка с количеством звезд на Github… Как будто бы метрики в правом верхнем углу не достаточно.
А ниже прямым текстом написано для тех кто хочет похвастаться своим 1x статусом:
Want to show off your 1x Engineer status on your own projects/webpages?
Немного противоречиво…
Будучи относительно эффективным software engineer (так получается, что я и мои команды часто выдают больше результата при меньшей численности), начал эскпериментировать с экстраполяцией инженерных навыков в других областях: social engineering, team engineering, self engineering и т.п. Чтобы повлекло наличие многочисленных симптомов из числа описанных. Правильно ли я понимаю, что начинаю деградировать?
Давайте я внесу некоторые коррективы и вы попробуете пересмотреть свой ответ. Первая — я потерял пробел перед частицей "бы", формирующей сослагательное наклонение. С моей точки зрения деградации никакой нет, всё с точностью наоборот.
Вторая — вольно интерпретированные вами social/team/self-engineering. Это то, во что мы и без того вовлечены (если только вы не бездетный, холостой затворник работающий в одиночестве, для такого может отношения с детьми и находятся в категории "bullshit"). Просто инженерные навыки позволяют существенно повысить качество. Вы будете удивлены, но ИТ — это про умение эффективно работать с любой информацией, наша деятельность очень похожа на вычислительные процессы, а принципы вроде SRP/KISS/DRY и т.п. с удовольствием прогуляются с нами и в других сферах. Я ни разу не заметил корреляции что больше времени уделённого семье, друзьям, спорту, экстремальному спорту существенно снижает мою продуктивность. Да, я стал производить меньше LoC в день, но теперь мне надо реже переписывать свой код и в итоге производительность стала намного выше.
Я бы посоветовал вам избегать штамп "нельзя объять необъятное", навязанный неудачниками. Первая причина — он легко бьётся тезисом "успешные люди успешны во всём" и примеров проникновения инженеров в другие области — легион, я уверен вы и сами с ними сталкивались. Вторая — тогда вообще нельзя идти в инженеры, тем более софтверные. Мы постоянно осваиваем новые для себя области. Сегодня это может быть электронная коммерция, завтра рекрутинг, послезавтра мы вдруг окунёмся в био-инжиниринг, крипто-валюты, AR/VR, CV. Хотя, может я просто сторонник холизма и эффективный инженер долбит одну задачу десятилетиями.
Спасибо за комплименты. Намного приятней быть аутистом, чем ординаром. Но мне кажется, эта похвала не заслужена. Ведь engineering — это не "суффикс", а глагол. Я просто соединил существительное с глаголом, что делают… практически все, с первого класса и это уменьшает ценность порождаемого мной "bullshit".
Честно скажу, я даже был не в курсе, чтобы подобные примитивные языковые конструкции "плодят сущности". Я всегда думал, что civil engineering, software development, time management, market research — это применение вполне определённых методов к тем или иным областям. Не намного сложнее в своей конструкции чем "пупок почесать" или "баг починить".
Но в целом вынужден признать, что я на самом деле отношусь к категории тех идиотов, которые убеждены, что дисциплины не существуют в полной изоляции, а тесно между собой пересекаются и это находит реализацию в коде, в буквальном смысле этого слова. Как в моём, так и миллионов безумцев на гитхабе, которые пытаются описать самые разные области знаний на весьма бытовых языках программирования.
Я верю, что данные из самых разных областей можно импортировать в реляционную БД и анализировать используя методы математической статистики и не надо реализовать специализированное хранилище для гидропоники на органических транзисторах. Но… наверняка нет ничего общего между паттернами publish-subscribe в message queues и Почтой России, композицией в приложении, фотографии и музыке. Моя ошибка считать что архитектоника в драматургии пересекается с архитектурой приложений и зданий, мы ведь не воровали "паттерны проектирования" в книге архитектора Кристофера Александра. Такое понятие как dependency применимо исключительно к NPM и никак к рецепту блюда. Много ошибок, но шизоиду вроде меня это простительно.
Вашу аргументацию я понял, спасибо. Как аутист я бы предположил, что вы используете привычный риторический паттерн "резкий как понос", который помогает при нулевой аргументации выглядеть убедительно. Но кто станет всерьёз воспринимать соображения таких, как я. Тем более, что даже я сам не до конца убеждён в своей правоте.
Кто такой одинарный инженер?