Оглядываясь назад, понимаю – отбор действительно работал шикарно. Все, кого я тогда отобрал, стали уважаемыми в нашей деревне специалистами. Больше половины из них давно открыли собственный it-бизнес, в самых разных сферах – от 1С до разработки CRM-систем.
Вот этот опыт и замутил моё сознание. Настолько, что я решил поменять методику – подумал, что дело не в ней, а во мне. Я есть великий специалист по техническим собеседованиям.
Изменения
Изменения я внёс очень простые – теперь люди писали код не на бумаге, а на компьютере. Чего, подумал я, они будут, как в древнем монастыре, сидеть каракули выписывать. Я и сам давно отучился обходиться без IDE, контекстных подсказок, отладки и прочих красотулек современной разработки.
Давал чуваку задачи, сажал за комп и оставлял на полчаса-час. Когда приходил – видел готовое решение. И не просто готовое, а весьма такое охрененное – и код красивый, и оптимальность на достаточном уровне. Сам офигевал – неужели современное поколение настолько прониклось технологиями, что пишут код, как дышат?
Ну и набрал себе таких чуваков.
Первые месяцы
Поначалу всё шло просто прекрасно. Я отслеживал все показатели их продуктивности и эффективности, и не переставал поражаться быстрому росту этих чуваков. В старые времена люди в первые месяцы вникали достаточно тяжело – они могли написать код учебной задачи, но с трудом справлялись с задачами рабочими. Тут же такой проблемы не было.
Понятно, что простые задачи они решали легко. Я стал давать более сложные задачи – те, что раньше выдавались после года службы. Эти чуваки справлялись, без посторонней помощи, и с такими! Я был в шоке. Радовался – какое замечательное поколение растёт!
Думал, что так будет всегда. В смысле рост продолжится линейно. Ага, щас.
Плато
Через 3-6 месяцев все чуваки до единого вышли на плато по продуктивности. К сожалению, в это же время все они перешли на удалёнку, в связи с коронавирусом. А я сидел дома и бесился.
Время идет, месяц за месяцем, а продуктивность застыла на уровне стажера. Иногда бывали локальные экстремумы, но они легко объяснялись большим количеством простых, монотонных, однотипных задач. Я продолжал беситься и орать в чатах.
Думал, дело в удаленке – там ведь не включишь харизму на полную мощность. Ну, наверное, мотивации людям не хватает, живого общения, а иногда – пинка под зад. Тут еще начальство медвежью услугу оказало – спрашивало типа «продуктивность из-за удалёнки не растёт?». Конечно да, отвечал я. Вот выйдем в офис, и попрёт!
Офис
Ну вышли мы в офис, в августе. Сидим, работаем, задач много – успевай делай (во время удалёнки случался дефицит задач). Смотрю на показатели – не растут, сволочи. Пришлось, блин, погружаться.
Сначала погрузился тупо в помощь людям. Не получается решить задачу? Зови меня. Я подойду, сгоню тебя с компа, сяду и доделаю. А ты, бездарь, сиди рядом и запоминай, как работать надо.
Но вас много, а я – один. Так не пойдёт. Надо понять глубинные проблемы. Решил вернуться к исходной стадии – техническому собеседованию.
Повторное собеседование
Писать код на бумаге я уже не заставлял – просто сел рядом, говорил задание, и программист пытался его реализовать. Думал провести серию таких проверочных работ, начиная с азов, постепенно поднимая уровень сложности. Но всё закончилось на азах.
Оказалось, что только один программист из десятка умеет работать с базовыми сущностями, типами, знает их свойства и методы. Еще хуже – только 2-3 человека сносно работают со встроенной справкой и контекстной подсказкой. Они тупо не могут найти свойства и методы. Не говоря уже о том, чтобы их применить, даже на элементарной задаче.
Один только осмелел и спросил – «а можно я в гугле посмотрю?». Тут до меня, идиота, и дошло.
Гугл-программисты
Меня как будто мешком с мукой по башке ударили. Дня два отходил. Неужели такое возможно? Тот красивый, оптимальный код, который они выдавали на первом собеседовании, был найден в интернете. Те решения, которые обеспечили им взрывной рост продуктивности в первые месяцы работы, были найдены в интернете. Те вопросы пользователей, на которые чуваки отвечали после волшебного «я вам перезвоню», были найдены в интернете.
Они пишут код, не понимая базовых конструкций. Нет, они не пишут код – они его скачивают. Нет, опять не то… Скачать код – это типа «npm i», это нормально. Они списывают код. Не умея его писать.
Начал возмущаться – блин, да как так! Ладно там новую технологию раскурить с помощью интернета, или научиться пользоваться какой-нибудь редко встречающейся хренью, чтобы голову не забивать. Но базовые-то вещи! Как вы можете их из интернета списывать?!
Знаете, что они ответили? «А что такого?». Я чуть в монастырь не ушел с горя. Взял паузу, перестал с ними разговаривать, закрылся и думал. Естественно, понял, что проблема не в них, а во мне.
Они лишь следуют законам своего мира. А я, идиот, эти законы не увидел, не понял, не осознал их серьёзность. Серьёзность поверхностности.
Поверхностность
В первый день учёбы в институте нас собрали в аудитории на кафедре, и старый прокуренный дядька, зам. декана и доцент, сказал: «Институт не даёт знаний. Он учит добывать знания самостоятельно».
Мне повезло – я учился в начале нулевых, когда интернет был только на картинках. Хочешь разобраться в C++ — садись и разбирайся, вот тебе C++. Хочешь написать курсовую по измерению шероховатости – иди в библиотеку, читай книжки, пиши курсач. Хочешь сделать доклад по истории – иди читай журналы. Ага, все подряд, пока не найдёшь нужные статьи.
А гугл-программистам не повезло. Им доступна любая информация, всегда и везде. Они научились быстро находить эту информацию – будь то адрес магазина с печеньками, штаны со скидкой или порождающий запрос.
В книжках пишут, что в мозге образуются и, главное, укрепляются те нейронные связи, которыми человек пользуется. Если постоянно пишешь код, то делаешь это всё лучше и лучше. Если постоянно ищешь информацию в интернете, то прокачиваешь этот скилл. Если списываешь код из интернета, то становишься в этом большим мастером.
Правда, не весь код есть в открытом доступе в интернете. Поэтому возникает плато. Продуктивность гугл-программиста – это не мера написания кода, это мера его списывания из интернета. Это примерно как скорость скачивания. Лет 15 назад, чтобы посмотреть фильм, его надо было сначала скачать, теперь так делают только староверы.
Когда-то, наверное, гугл-программисты обгонят обычных. По крайней мере, в решении стандартных задач. А пока – будем мучительно формировать новые нейронные связи по использованию базовых объектов, типов и конструкций ЯП.
Надо ж мне было так облажаться, блин. Стыдно.
P.S. И это… Своих перепроверьте.
Iqorek
1. Времязатраты увеличиваются с ростом проекта. Могу сказать про себя, когда начинаю новый проект, скорость разработки космическая, у меня ничем не связаны руки. Но со временем, вносить изменения и новые фичи, становится все трудней, нужно учитывать много факторов, связи и так далее. Иногда для новых фичей приходится рефакторить или даже менять архитектуру, но так чтобы ничего не поломать. Это все берет время.
2. Орать, пинка под зад, плохая мотивация особенно для творческих видов работ.
vmoskalev
объём трудозатрат на сопровождение и развитие проекта растёт, а местами аж по экспоненте, если в проекте набран приличный объём архитектурного долга помимо технического (ваш кэп). связи? да, необходимо внимательно следить за разграничением ответственности между областями кода и не допускать укрепления связанности. если интересно подробнее почитать про архитектурные подходы, которые хоть и не такие шустрые на старте, но, если строго их придерживаться, то через 2-3 года добавить в проект пару экранов, или добавить что-то на существующие будет так-же просто как и в первые 2-3 месяца, то можно начать с Lotus MVC (https://matteomanferdini.com/ios-architecture-lotus-mvc-pattern/) а потом уже под свою платформу/язык скорректировать.
з.ы. и нет, конечно, это не истина в последней инстанции и сейчас можно дальше в комментах накидать кучу других ссылок и обхаять эту. но эта, как реально рабочий один из вариантов построения архитектуры приложения, покатит.
archimed7592
Вы хотели сказать так-же сложно, как и в первые 2-3 месяца? :)
amofon
Все правильно. Только вот статья не о трудозатратах.
А о плато.
Авто статьи говорит не о каком-то сложном проекте. А о ситуации, когда в Гугле заканчиваются готовые рецепты.
Готовые рецепты заканчиваются, когда речь начинает идти об нюансах проекта. Так как ваш проект априори уникальный (иначе зачем бы вы его делали, если есть уже полностью готовое решение) — то вот эти сами нюансы проекта вы нагуглить никак не сможете.
Причем на этой стадии вы еще можете гуглить какие-то мелочи. Как и на более поздней стадии. Но это будут только мелочи универсального общего свойства.
Уникальную составляющую вашего проекта нагуглить нельзя.
Автор пишет, что гуглопрограммисты прекращают быть полезными, когда от универсальных общих присутствующих во всех проектах вещах — они переходят собственно к тому что составляет суть проекта.
unsignedchar
Опять нет кнопки «Сделать всё хорошо».
wladyspb
Помню свою боль, когда на определённые ошибки не мог найти объсяснения ни на SO, ни в документации, ни в телеграмм канале у автора инструмента)
DrPass
Нельзя, но например мой опыт говорит о том, что в подавляющем большинстве проектов технической уникальной составляющей нет от слова «вообще». Бывает бизнесовая, но её понимание для программистов — приятный бонус, а не профессиональная обязанность. Поэтому StackOverflow-Driven Development, это вполне жизнеспособный подход, который в большинстве случаев позволяет реализовать проект «от и до». А тем, кому надо иметь в команде знающего гуру, те и наймут знающего гуру.
amofon
Разумеется, конечный продукт — это сочетание обычных обще-универсальных способов решения.
Никаких супер-оригинальных алгоритмов от программистов не требуется, как правило. Исключения редки.
Однако тем удивительнее факт выхода программиста на плато «ничего не могу», когда готовые рецепты в Гугле закончились.
Да, нужно всего лишь составить новый рецепт на базе готовых, выбрав именно то, что нужно для вашего случая. Но не все это могут сделать, потому что готового рецепта об том, как сделать под конкретную задачу нет. Об этом и статья.
delhi_heir
ХРюши потому и любят «софтскиллс», потому что навешать всем лапши на уши «это в принципе невозможно» звучит лучше, чем «я лично ничего не могу».
VolCh
Встречал "программистов", которые ошибки гуглили без малейших попыток абстрагировать их, вот прямо со своими личными путями и неймингами проектов типа /home/vasya/work5/super-project/src/Api/RogaAndKopytaApiClient
PendalFF
Приятно, чёрт возьми, что сисадмин-автомеханик уже чуть-чуть обогнал «программистов» (хотя бы некоторых), так как я все-таки стараюсь разобраться в причинах ошибки а не нагуглить решение. Кстати крайне бесит ситуация когда единственный ответ — это магия, сынок (плавающая ошибка)
Jecky
Ron Jeffries: «Code never lies, comments sometimes do.»
bogdanic2056
Значит это «Как слышим так и пишем». Нет творческого подхода вовсе.
usrsse2
Так гуглится же! Быстрее вставить и нажать Enter, чем редактировать запрос, ну а если уж не нагуглилось так, то тогда уже абстрагировать
Sergunka
Обычно вся уникальность проекта заключается в банальном отсутствии документации на проект.
vics001
Самодокументируемый код.
P.S. документация по методам математического моделирования есть, занимает 3 семестра обучения.
chapai22
… что плавно приводит нас к мысли, что пора не строить все с нуля, растить зерно, молоть муку, вырастить дрожжи-закваску и лишь потом выпекать хлеб — а просто брать с полки в упаковке. И пока кто то растит пшеницу другой кушает бутерброд.
Все придумано до нас (с)
Да он будет не уникален — но годен и быстро и удообно.
С программированием пора строить задачу из типовых гугло-кусков. Как опенсорсные блочные дома.
То есть надо менять подход — коий новое поколение мудро указало и выявило.
так что две цитаты:
Человек, который почувствовал ветер перемен, должен строить не щит от ветра, а ветряную мельницу. © китайская народная мудрость
Надежные машины из ненадежных элементов! © Джон фон Нейман
PowerMetall
Ну так тут выше и написали, что StackOverflow-Driven Development, это вполне жизнеспособный подход ))
Но речь то не об этом, а о том что уникальные вещи (которые, пусть и в минимальных количествах, но всегда присутствуют в любом коммерческом проекте сложнее условного калькулятора) — так просто не скопипастить, даже путем склейки нескольких кусков.
И это я не говорю о
внешнемтехническим долге такому копипаст-проекту после хотя бы годика добавления в него фич такими же способами.Когда-то да придется рефакторить, а то и вовсе, о ужас, менять архитектуру/структуру, под новые фичи. И сможет ли во всё это копипастокодер — вопрос
chapai22
Для этого нужно два, максимум три обученных программиста на всю компанию. Остальные должны быть индусами. И вообще чем меньше уникальностей, если вы не ракету на марс делаете — тем лучше. Весь прикладной софт этого не требует совсем. Уникальность должна быть в полезности и удобстве.
Опять же, надо (нонче) проектировать софт, чтоб кодо-уникальностей не было, и вообще все было искллючительно блочно, дабы менять (и выкидывать) без страха и упрека, и первый залетевший с улицы дятел мало того чтоб не рушил, так мог еще и кусок дописать.
Надо верить в лучшее — появятся копипасто рефакторы. В среднем квалификация публики растет — но некий возвышенный уровень падает. Что данность, и даже понятно почему — так эффективнее, жизнь заставляет давать ответ раньше чем успел подумать и обсосать.
amofon
А если их всего три?
chapai22
Это не компания а кружок. Но в русской культурной традиции для троих предусмотрены особые варианты.
Посидят, подумают, что нибудь придумают © Чистяков
amofon
Ну а если их 300 разработчиков всего?
Настоящих программеров все равно должно быть 3?
А остальные 297 — тупые просто приложения к клавиатуре?
P.S.:
Индустрия разработки ПО существует вот уже более полусотни лет, всё уже рассчитано до нас.
Например, один из классических трудов по организации разработки ПО «Мифический человеко-месяц» Ф. Брукса опубликован еще в 1975 году.
И старших разработчиков нужно довольно много. Типично, на каждые 2-5 человек обычных разработчиков — 1 старший.
А вовсе не:
chapai22
В компании обасучивающей прачечные, в общем то — да. С некой долей условности. И это 99% рынка. Наверно обидно звучит.
Не, там где искусственный интеллект, квантовые компьютеры — все иначе.
То, что было полсотни лет назад — не годится. Настолько все меняется — на моей памяти по два раза в год, минимум. Это я про штаты.
Важным становится скорей быстрая обучаемость и слаженность, а не алгоритмичность. Поэтому, ясен пень, и гуглят активно.
Дык все поделено на группы, а не все 300 скопом над одним проектом. Что нам и дает изолированные блоки внутри компании. И в таком, из нескольких команд над проектом — как раз единицы. Остальные пилят нишу.
Все равно при поставленной разработке за пределы ниши выходить не приходится.
Так кстати не только в китах рынка — но и в стартапах.
amofon
А можно конкретику?
sophist