Comments 154
Это не значит что у него появилась фобия. Это значит, что его профессия более невостребована. А востребована другая, смежная профессия — авиаремонтника.
Из статьи я сделал вывод, что Вам очень везло с коллегами ;)
Фобии у них, можно сказать, конструктивные, и то, что страхи, заставляющие (в конечном итоге) двигаться, делают жизнь немного неуютной — это фича, а не баг.
Если говорить про фобии (раздутые до комплексов, временами), которые делают профессионала, особенно из нашей области, несчастным — чаще всего замечал боязнь быть неправым.
Знание о том, что с ошибкой не запустится часто применяется не только при взаимодествии с компьютером, но и с другими людьми. И чем меньше ресурсов на полноценные "сессии", чем дефицитнее общение с человеком, тем с большой вероятностью время будет потрачено на продавливание своего "кода", попытки успеть доказать, что это не я дурак.
Может и не те люди мне попадались, но очень часто, но описанный в статье типаж — ни разу.
Аркадию, скорее, надо менять окружение, искать равных себе и заниматься каким-то rocket science. Искать работу в организациях, где думают не в масштабах месяцев, а в масштабах лет.
Так что это вряд ли фобия :) Скорее недостаточно подходящее место он себе выбрал.
Вам тут много раз повторяют, что Аркаша не такой, а вот по мне так вылитый он. :) Ещё могу дополнить портрет: возраст за 45, познания ограничиваются например анси си 89-го года разлива, и/или Перлом + CGI, Oracle 8-9, CentOS 5-6 единственная и неповторимая ОС и/или NT4. Любит длинные монологи про «молодёжь (т.е. моложе 35л) работать не хочет» и ковыряться с ламповыми усилителями/программируемыми калькуляторами или на крайний случай ДВК. Что самое грустное, часто занимают руководящие должности в силу солидности :)
Т.е. Вам достаточно одного атрибута, возраста, чтобы убедить собаку в том, что она баран?
Все так и есть, я из тех и могу сказать, что закончил программировать в ~97 (хотя все еще тут).
Но, судя по комменту, многие "молодые" (на самом деле не только) программисты имеют низкую культуру написания кода ;).
Получают на вход функции обсуждения конкретный объект и если у того атрибут age>40 — можно первым делом переопределить все его параметры. Кроме ID, в надежде, что, если объект передавали по ссылке, вызывающая сторона подмены не заметит.
Пусть компонованием и потреблением фреймворков занимаются хипстеры — это их стезя
Такие люди как Аркадий должны решать более глобальные задачи, например разрабатывать операционные системы, писать драйверы, ну или как вариант, прошивку для электроники.
Как насчёт потери зрения, рук или альцгеймер / рак?
Все это, если можно так сказать, общечеловеческие фобии, присущие целым поколениям, странам и континентам. Но есть и чисто профессиональные фобии, которые вряд ли будут понятны представителям других профессий.
А вы это высмеяли
Жаль, если у вас такое впечатление сложилось. Все герои — мои друзья больше 15 лет. Они прочитают эту статью.
Но для правильного руководителя работа с фобиями — это настоящий клад, потому что открывается почти прямой доступ к мотивациям человека.Потому что можно «расширить и углубить»(с)
Идеального еще не придумал.
Обрушение дома в Междуреченске
Нельзя так делать без перерасчета проекта. А это, как мне рассказывали, геммороя до хрена.
П.с. что-то по запросу «обрушение дома» как-то очень до… [много] видео высыпалось… Кажется, я так фобию заработаю :-)
С другой стороны нет знакомых архитекторов, которые бы проектировали что-то серьёзное — там могут быть и бессонные ночи и терзания «всё ли предусмотрел» (мне так кажется).
С другой стороны, у меня отчим — архитектор. И он был в ужасе от последней работы. Потому что строили там, наплевав на все ГОСТы. Слишком маленькие конурки получались при максимально разнесенных несущих.
И ничего, запас по прочности сделали и норм — стоит себе домик со студиями меньше, чем у меня комната…
У строителей, как правило, весь проект рассчитан на бумаге от начала до конца — откуда может появится страх, если ты знаешь все?
А вот программисты редко планируют, чаще «строят» на лету и не придерживаются каких либо принципов проектирования. Такой подход неизбежно приведет к каше в проекте, в котором тяжело отслеживать зависимости и тяжело понимать к чему приведет новое изменение — отсюда и страх — «а не пропустил ли я что-то».
У строителей, как правило, весь проект рассчитан на бумаге от начала до конца
Мы с вами каких-то разных строителей видели. Некоторые из них и писать-то не умеют, как дядя Толя, с которым я работал на стройке. У него не было никакой документации, он просто строил. Сначала из целых кирпичей, потом из битых, когда целые кончились. Потому что оплата за кубометры построенных стен. В итоге сделал окно не в том месте, на метр ниже запланированного. Получил в тыкву от мастера. Мастер всем бил в тыкву, кто не так работает. Например, водителю бетономешалки дал в тыкву, когда показалось, что тот по дороге где-то слил часть бетона.
Я всегда боюсь, что у меня в продакшене что-то внезапно само отвалится.
Как отвалится, так и пофиксим. Ну посидят пользователи немного без одной нужной страницы, это же не конец света. Не медицинское оборудование разрабатываем, никто не умрёт.
Если бояться что-то поменять, то говнокод никуда не денется. А если взять и порефакторить, то хотя бы текущая страница будет работать нормально, а количество плохого кода на проекте уменьшится.
Увы чем моложе разработчики, тем меьше они вообще разбираются в том, что используют, прочитали доки и вперед. К счастью не все, еще много тех кто готов разбираться.
Меня всегда повергает в шок, когда начинаются проблемы, задаешь вопрос, как это работает, в ответ, ну я вот тут написал в конфиг компонента, а здесь вывалилось, а теперь почему то не работает, хотя я все правильно с доки скопировал.
П.С. а вообще я боюсь ядерной войны и это не шутка
Собственно, для того и создают API, чтобы быстро использовать, а не разбираться в нюансах (потому что самому написать выйдет быстрее, чем досконально разобраться).
Пояснение области применимости моих размышлений: есть TCP, многие им пользуются. Очень маловероятно, что всем так уж нужно досконально знать каждый параметр, но неплохо бы знать, что они есть и где почитать, какой подкрутить, в случае возникновения проблем.
Скажу про себя. Эти фобии больше зависят от проекта, чем от человека:
Фобия выкатить в релиз. Каждый раз боюсь выкатывать новую версию кода в релиз. Особенно если правок произошло достаточно много с момента последнего деплоя. Лечится частыми и мелкими релизами, тестированием изменений другим человеком и автоматические тесты жизненно важных частей системы. Хотя, фобия часто остается. Особенно, когда ты единственный кодер и вся ответственность на тебе.
Фобия что-то менять в коде. Обычно прослеживается в монолитных сложных спагетти системах. Тут естественно поможет TDD, что улучшит качество кода в разы, компонентный подход и нормальное наименование переменных/функций/классов/namespace'ов/п.р… Про комментарии не говорю, потому что хорошая архитектура и грамотно написанный код намного лучше любых комментариев.
Страх брать сложные задачи. Не всегда это последствия лени. Пожалуй, это скорее последствия первых двух фобий, когда ты просто боишься сломать все, что уже сделано. Особенно, если можешь получить от этого втык. Лекарства все те же: тесты, хорошая архитектура и чистый код.
Это то, с чем столкнулся я. Сказать честно, думал, что в статье речь пойдет о подобном. Но нет. Тут все намного глубже.
Если говорить о подобных психологических моментах, то сейчас я боюсь работать с другими людьми. Всю свою карьеру работаю один удаленно. Ни разу не работал в команде. Если вдруг начальство решит взять еще одного человека, я даже не представляю, как я ему буду объяснять, что творится в моем коде.
У разработчиков (точнее SRE) Гугла есть так называемый бюджет на ошибки, почитайте вот тут: landing.google.com/sre/book/chapters/embracing-risk.html
Выкатывать хотфиксы сразу в прод — а вы рисковый. С точки зрения SRE, сначала безусловно делается rollback к предыдущему релизу, а уж потом анализ причин поломки, исправления и т.д. Roll forward — только для чего-то не очень критичного.
Неоднократно сталкивался с ситуацией, когда характер изменений таков, что катить назад вариантов нет, только патчить на живую и молиться.
>и автоматические тесты жизненно важных частей системы
>Хотя, фобия часто остается. Особенно, когда ты единственный кодер и вся ответственность на тебе.
Так тестировать надо не только жизненно важные части системы, а побольше. Тогда и зависимости можно без страха обновлять.
Все бы ничего, но если ты один кодер/верстальщик/дизайнер/тестер на весь проект, то времени и сил тестить "побольше" как-то совсем нет.
А бояться время есть? ) А если серьёзно, то наверняка же тестируется хоть как-то, если не мелкий баг-фикс.
А на "бояться" как-то время не уходит. В проект только недавно внедрили автоматическое тестирование, а кодовая база уже немаленькая. Поэтому тестами покрываются сначала самые важные части системы, без которых функционирование сервиса будет совсем невозможным (Unit тестирование, тестирование API и п.р.); тестирование очень хрупких частей, изменение которых может повлечь за собой неадекватную реакцию на действия пользователей (в нашем случае — это тестирование правильного распределения прав доступа); а потом на то, что сломалось, стараюсь написать тест и поправить ошибку. Естественно, при внедрении новых функций стараюсь писать тесты, если это необходимо.
Я про обычное, ручное тестирование.
Недавно наняли одного человека, который тестирует новые функции. Стало намного лучше. Но не может ведь человек тестировать одно и то же каждый раз. Для этого и пишутся автоматические тесты. Естественно, ручное тестирование и раньше было, только очень посредственное. Для этого даже сделали специальный тестовый сервер, на котором все можно безопасно опробовать.
Я больше про локальный запуск разработчиком, чтобы проверить код, который только что написал, перед тем как пушить его в репозиторий или выкатывать на сервер для тестировщиков.
Ну это само собой разумеющееся. У меня на компе работает локальная копия сайта. Благодаря докеру это не вызывает никаких проблем, сделать идентичное окружение, как на проде. Но согласитесь, взгляд со стороны и автоматические тесты дают значительный прирост качества проекту.
Не знаю, как у других, но у меня глаз замыливается, я устаю и порой упускаю очень очевидные вещи и допускаю очень глупые ошибки.
Иногда побаиваюсь сложных задач.
Боюсь языков программирования со слабой типизацией.
Уверенность в том, что его код читают, заставляет Аркадия работать соответствующим образом, тратя массу времени на бессмысленную оптимизацию.
Не уверен, что имееется в виду под бессмысленной оптимизацией, но уверен, что со стороны не видно, или легко забыть, что код обязательно читают. Пусть это будут не другие коллеги, но это будешь другой ты. Ты сам через 3 месяца или через год, но ты обязательно окажешься тем человеком, который видит этот код как в первый раз в жизни.
Лучше все-таки научиться работать в команде. Надо относиться к этому как к возможности узнать новые подходы, улучшить свои навыки. Когда половина компонентов незнакома, и твои тоже кто-то может изменить, это способствует написанию более качественного и независимого кода.
У меня фобия простая и основана на большом и весьма болезненном опыте — боязнь что-либо менять в своём проекте (не добавлять, а именно менять поведение, даже при исправлении багов). Ибо опыт подсказывает, что даже небольшие и, казалось бы, совершенно невинные изменения обязательно что-нибудь ломают, что может (и так часто было) вылиться в потери денег, и очень больших (к счастью, не моих, а фирмы, но всё равно неудобно). Так что очень часто, видя откровенную кривизну (или просто плохо написанный код, часто тобой же N-цать лет назад), усилием воли подавляешь зуд в руках и произносишь классическое: «Солнце точно всходит? Точно заходит? Ну так и не трогай».
Я почти всегда, почти во всех задачах пишу легко отторгаемый код, который можно потом многократно использовать других проектах… если такой код не получается, то это плохой код.
Доктор, все плохо?
Вообще авиаконструкторы нужны не раз в 30 лет, а каждый день. Просто не все умеют или хотят клеить самолетики.
А том то и пичалька.
Я конечно не такой динозавр, как Аокадий, но тоже заметил, шо мало кто желает под капот заглядывать, вместо этого по-быстрому слепить из фреймворков и первых попавшихся библиотек монстра Франкенштейна. Я то лично не против фреймворков всяких, проблема в том, что никакого анализа зачастую не проводят, а самое главное не понимают как это потом работает и зачастую получается оверхеад.
У железячников аналогичная ситуацию: Любят ставить ПЛИС туда, где один транзистор справится :-)
В железячной
Но как-то сохранить инженерную культуру нужно пытаться. Эта важная задача бизнеса, и/или государства. (А то конкуренты-то борют.)
Радует уже то, что руководители стали разбирать эти ситуации, а не делать скорые выводы о «туповатом задроте». Поэтому «неистово плюсую». И рекомендую Аркадия пересадить на участок ответственных (server side / hi load) работ, или отвести роль наставника. Если самооценка не окончательно загублена.
Правда и ожидать, что входной билет в эту область станет дешевле не приходиться.
Хотя … если честно. То какую-то большую часть «нынешнего программирования» действительно можно отобрать у человека. А для кого-то это «и хлеб, и масло»….
Я ожидаю, что в будущем любой сможет легко создавать себе программу, отчего обычные программисты переведутся.
Но получающиеся программы будут громоздки и далеко неоптимальны по скорости, отчего настанет время Аркадиев, которые знают систему от и до, и как её улучшить.
Т.е. программисты всё это время поднимались вверх, создавая всё более лёгкий способ создания программ. Но достигнув предела простоты создания (и пределов производительности процессоров) им придётся спускаться обратно в низкие уровни — сражения будущего будут идти за эффективность.
Мне кажется, что популярные нынче функциональные языки типа F# или Haskell как то уходят от математически четкой декларативности, а без этого, потенциальная мощь подхода сильно снижается. Даже вот первый пример на Wiki — да мало чем отличается от императивной версии.
На мой взгляд, если уж программирование останется в каком то виде (и нас не заменит ИИ), то языки буду становиться всё более предметно-ориентированными (DSL) и абстрактными.
"SELECT" это повелительный глагол, это "сделай это". Декларативность SQL по сути заключается в том, что не нужно вручную формировать план запроса. Емнип, принципиальное отличие между ISAM и MyISAM было в отсутствии необходимости указывать индексы — оптимизатор MyISAM сам смотрел есть ли пригодные для использования и стоит ли их использовать, а ISAM ждал явных указаний.
А с людьми, в Вашей модели, руководитель работает?
Спасибо, т.е. Вы имеете в виду психиатрический термин. В таком случае — согласен.
Тоже уверен, что автор имел в виду "некоторые страхи", а не клинические отклонения. Место и стиль статьи не предполагают.
Хороший руководитель, вероятно, может помочь в каждой из ситуации, если у него есть на это ресурсы и желание. Его главная задача собрать команду и получить от неё результат.
Про первое — не знаю ;). Но не осуждаю автора за художественный прием.
По второму — думаю, что это, как раз, тот случай, когда руководитель, если он претендует на звание хорошего, обязан находить желание и ресурсы на помощь в каждой похожей ситуации.
Собрать команду и получить результат — звучит немного механистически, уверен, что Вы имели в виду именно неохватную деятельность руководителя между двумя этими пунктами командного путешествия.
Аркадий это один из нормальных разработчиков, в отличии от фреймворк девелоперов, которые тащат 100500 зависимостей, для решения какой то простой задачи. А когда проект из начального перерастает в легаси начинается бег на костылях по фреймворкам.
Интересно, насколько может быть востребовано такое обучение?
И я уверен, что позже появились новые пионеры, которые новый код и дизайн назвали говнокодом и предложили новое прогрессивное решение которое решит все проблемы.
Косятся, потому что эффективные менеджеры хотят сэкономить на зарплате.
Здесь, мне кажется, лучше не программистов "лечить", а найти подходящий проект под способности Аркадия и Геннадия. В идеале.
Чего боятся программисты?