Одна из самых перегруженных идиотами специальностей — менеджеры, управляющие программистами. Не все, а те, которые сами программистами отродясь не были. Те, которые думают, что можно «повышать» эффективность (или повышать «эффективность»?) методами из книжек. Даже не удосужившись эти самые книжки прочитать — видосик ведь есть цыганский.
Те, которые никогда не писали код. Те, для которых снимают голливудские фильмы про программистов — ну, те, где электронную почту командной строкой смотрят. Те, которым не интересно ничего, кроме показателей, сроков и собственной зарплаты.
Те, которых большинство.
Но идиоты они по другой причине. Они хотят эффективности, или хотя бы результативности (давай, менеджер, гугли, в чем разница), не разбираясь ни в том, ни в другом. Вообще не понимая сути, процесса получения результата, потерь, происходящих в этом процессе, затрат на разработку. Короче, работая с программистом, как с черным ящиком.
Понабежали в управление программистами ровно по одной причине: тут хайп, деньги, рынок и куча таких же идиотов. Есть, где затеряться.
Был бы хайп в механосборочном производстве — побежали бы туда. Универсалы хреновы. Не удивлюсь, что чувак, продающий в декабре ёлки в нашем квартале, это ИТ-менеджер в отпуске.
Короче, если есть возможность, гоните этих парней в шею. Не переживайте, они найдут себе работу. Никто из них, никогда не сделает ничего приличного, пока сам не станет программистом. Потому что не понимает сути, механизма, логики процесса, которым управляет.
Ну всё, хватит про менеджеров. Теперь по делу, для программистов. Как повысить эффективность разработки, научившись писать качественный код.
Чтобы повысить эффективность, надо быстрее решать задачи, не теряя качества. Чтобы быстрее решать задачи, надо уметь сразу писать качественный код. И «качественный», и «писать», и «сразу». Поясню метафорой.
Писать качественный код – это как грамотно говорить на иностранном языке. Когда языка не знаешь, тратишь кучу времени на то, чтобы сформулировать на нем свои мысли.
Если сказать надо срочно, просто налепишь каких-то слов, зачастую не тех, что надо, забудешь про артикли, правильный порядок слов, не говоря уже о временах глаголов и убогом произношении.
Если есть время на формулировку ответа, то придется открывать словарь, или интернет-переводчик, и тратить кучу времени на формулировку своих мыслей. Чувство, правда, всё равно будет неприятное: ответ говоришь, и не знаешь, правильный он или нет. Аналогично с кодом – вроде написал, вроде работает, а качественный он или нет – ХЗ.
Получается двойная потеря времени. На то, чтобы придумать ответ, уходит время. На то, чтобы этот ответ сформулировать, тоже уходит время – причем, не так уж и мало.
Если же навык написания качественного кода присутствует, то ответ можно формулировать сразу, как только он созрел в голове, не тратя дополнительное время на перевод.
Навык написания качественного кода помогает при проектировании архитектуры. Ты просто не будешь рассматривать в голове неправильные, нереализуемые или рукожопые варианты.
Резюмируя: навык написания качественного кода существенно ускоряет решение задач.
Но и это не всё. Благодаря валенкам-менеджерам, есть одна загвоздка – так-то у нас нет повода писать качественный код. Менеджер код не смотрит, клиент код не смотрит. Друг другу мы код показываем редко, только иногда, в некоторых проектах, где есть назначенный «проверятор» кода или периодический рефакторинг.
Получается, в большинстве случаев говнокод уходит в продакшн или клиенту. У человека, написавшего говнокод, формируется устойчивая нейронная связь – говнокод писать не только можно, но и нужно – его принимают, да еще и платят за это.
В итоге, у навыка написания качественного кода вообще нет шансов развиться. Код, написанный условным сотрудником, не проверяет никто и никогда. Единственная причина, по которой он научится нормально программировать – внутренняя мотивация.
Но эта внутренняя мотивация вступает в противоречие с планами и требованиями по эффективности и продуктивности. Разрешается это противоречие явно не в пользу качественного кода, ведь за говнокод даже не ругают. А за невыполнение плана – еще как.
Как быть? Я вижу и предлагаю два пути, которые можно сочетать.
Первый – показывать свой код кому-то внутри компании. Не реактивно (когда просят/заставляют), а проактивно (э, чувак, глянь мой код, пжлста). Тут главное – не развешивать сахарные сопли, не стараться облечь критику кода в вежливую форму. Если код говно, мы так и говорим: код – говно. С пояснениями, разумеется, и рекомендациями, как сделать его лучше.
Но этот путь тоже так себе. Его применимость зависит от точки, в которой произошел контакт. Если работа уже попала в продакшн, и выяснилось, что код – говно, переделывать его уже нет смысла. Точнее, повода — еще и метрики просядут. Набегут менеджеры и задавят требованиями к эффективности. И даже не пробуй им объяснить, что говнокод обязательно вернется в виде багов — тебе же боком выйдет. Можно лишь взять на себя обязательство больше так не делать.
Если же работа еще не сдана, или только начата, то поливание кода (или его проекта, задумки) говном может иметь вполне себе практический смысл – человек сделает нормально.
Второй путь, самый крутой – заняться опенсорс-разработкой в нерабочее время. Цель ведь какая: чтобы куча программистов, именно программистов, увидели твой код и высказались о нем. Внутри компании всем некогда. А программистам всего мира всё равно заняться нечем, и, если ты напишешь полезную с прикладной точки зрения штуку, то они обязательно заглянут внутрь.
Главная фишка, на мой взгляд – это написание кода в нерабочее время, потому что не будет работать противоречие качества кода и скорости выдачи результата. Хоть год пиши свою разработку. На тебя не будут давить ни сроки, ни ТЗ, ни деньги, ни начальник. Полная свобода и творчество.
Только в свободном творчестве ты поймешь и прочувствуешь, что такое классный код, увидишь красоту ЯП и технологий, ощутишь прелесть бизнес-задач. Ну и научишься писать качественный код.
Правда, это потребует от тебя затрат личного времени. Как и, собственно, любое другое развитие. Рассматривай это не как затрату, а как инвестицию – в себя.
Те, которые никогда не писали код. Те, для которых снимают голливудские фильмы про программистов — ну, те, где электронную почту командной строкой смотрят. Те, которым не интересно ничего, кроме показателей, сроков и собственной зарплаты.
Те, которых большинство.
Но идиоты они по другой причине. Они хотят эффективности, или хотя бы результативности (давай, менеджер, гугли, в чем разница), не разбираясь ни в том, ни в другом. Вообще не понимая сути, процесса получения результата, потерь, происходящих в этом процессе, затрат на разработку. Короче, работая с программистом, как с черным ящиком.
Понабежали в управление программистами ровно по одной причине: тут хайп, деньги, рынок и куча таких же идиотов. Есть, где затеряться.
Был бы хайп в механосборочном производстве — побежали бы туда. Универсалы хреновы. Не удивлюсь, что чувак, продающий в декабре ёлки в нашем квартале, это ИТ-менеджер в отпуске.
Короче, если есть возможность, гоните этих парней в шею. Не переживайте, они найдут себе работу. Никто из них, никогда не сделает ничего приличного, пока сам не станет программистом. Потому что не понимает сути, механизма, логики процесса, которым управляет.
Ну всё, хватит про менеджеров. Теперь по делу, для программистов. Как повысить эффективность разработки, научившись писать качественный код.
Чтобы повысить эффективность, надо быстрее решать задачи, не теряя качества. Чтобы быстрее решать задачи, надо уметь сразу писать качественный код. И «качественный», и «писать», и «сразу». Поясню метафорой.
Писать качественный код – это как грамотно говорить на иностранном языке. Когда языка не знаешь, тратишь кучу времени на то, чтобы сформулировать на нем свои мысли.
Если сказать надо срочно, просто налепишь каких-то слов, зачастую не тех, что надо, забудешь про артикли, правильный порядок слов, не говоря уже о временах глаголов и убогом произношении.
Если есть время на формулировку ответа, то придется открывать словарь, или интернет-переводчик, и тратить кучу времени на формулировку своих мыслей. Чувство, правда, всё равно будет неприятное: ответ говоришь, и не знаешь, правильный он или нет. Аналогично с кодом – вроде написал, вроде работает, а качественный он или нет – ХЗ.
Получается двойная потеря времени. На то, чтобы придумать ответ, уходит время. На то, чтобы этот ответ сформулировать, тоже уходит время – причем, не так уж и мало.
Если же навык написания качественного кода присутствует, то ответ можно формулировать сразу, как только он созрел в голове, не тратя дополнительное время на перевод.
Навык написания качественного кода помогает при проектировании архитектуры. Ты просто не будешь рассматривать в голове неправильные, нереализуемые или рукожопые варианты.
Резюмируя: навык написания качественного кода существенно ускоряет решение задач.
Но и это не всё. Благодаря валенкам-менеджерам, есть одна загвоздка – так-то у нас нет повода писать качественный код. Менеджер код не смотрит, клиент код не смотрит. Друг другу мы код показываем редко, только иногда, в некоторых проектах, где есть назначенный «проверятор» кода или периодический рефакторинг.
Получается, в большинстве случаев говнокод уходит в продакшн или клиенту. У человека, написавшего говнокод, формируется устойчивая нейронная связь – говнокод писать не только можно, но и нужно – его принимают, да еще и платят за это.
В итоге, у навыка написания качественного кода вообще нет шансов развиться. Код, написанный условным сотрудником, не проверяет никто и никогда. Единственная причина, по которой он научится нормально программировать – внутренняя мотивация.
Но эта внутренняя мотивация вступает в противоречие с планами и требованиями по эффективности и продуктивности. Разрешается это противоречие явно не в пользу качественного кода, ведь за говнокод даже не ругают. А за невыполнение плана – еще как.
Как быть? Я вижу и предлагаю два пути, которые можно сочетать.
Первый – показывать свой код кому-то внутри компании. Не реактивно (когда просят/заставляют), а проактивно (э, чувак, глянь мой код, пжлста). Тут главное – не развешивать сахарные сопли, не стараться облечь критику кода в вежливую форму. Если код говно, мы так и говорим: код – говно. С пояснениями, разумеется, и рекомендациями, как сделать его лучше.
Но этот путь тоже так себе. Его применимость зависит от точки, в которой произошел контакт. Если работа уже попала в продакшн, и выяснилось, что код – говно, переделывать его уже нет смысла. Точнее, повода — еще и метрики просядут. Набегут менеджеры и задавят требованиями к эффективности. И даже не пробуй им объяснить, что говнокод обязательно вернется в виде багов — тебе же боком выйдет. Можно лишь взять на себя обязательство больше так не делать.
Если же работа еще не сдана, или только начата, то поливание кода (или его проекта, задумки) говном может иметь вполне себе практический смысл – человек сделает нормально.
Второй путь, самый крутой – заняться опенсорс-разработкой в нерабочее время. Цель ведь какая: чтобы куча программистов, именно программистов, увидели твой код и высказались о нем. Внутри компании всем некогда. А программистам всего мира всё равно заняться нечем, и, если ты напишешь полезную с прикладной точки зрения штуку, то они обязательно заглянут внутрь.
Главная фишка, на мой взгляд – это написание кода в нерабочее время, потому что не будет работать противоречие качества кода и скорости выдачи результата. Хоть год пиши свою разработку. На тебя не будут давить ни сроки, ни ТЗ, ни деньги, ни начальник. Полная свобода и творчество.
Только в свободном творчестве ты поймешь и прочувствуешь, что такое классный код, увидишь красоту ЯП и технологий, ощутишь прелесть бизнес-задач. Ну и научишься писать качественный код.
Правда, это потребует от тебя затрат личного времени. Как и, собственно, любое другое развитие. Рассматривай это не как затрату, а как инвестицию – в себя.
