До сине-зелёных водорослей (которые своими "отходами жизнедеятельности" полностью и навсегда уничтожили существовавший до них климат, вытравили атмосферу, литосферу и океаны, а также спровоцировали чудовищные стомиллионнолетние оледенения) нам пока что и правда далеко.
Люди вообще не запариваются в наши дни. Пишут в мессенджер "можно я тебе сейчас позвоню?", и затем уже на созвоне задают голосом простейший 3-минутный вопрос. А мы тут правила квотирования обсуждаем, эх...
Выглядит чудесно: copilot отвечает на письма, о чём-то общается с коллегой, договаривается... а потом оказывается, что включивший копилота сотрудник ни о каких договорённостях не знает, ничего не сделал и по факту всё продолбал!
Рекомендую на деле померить, на что именно тратится Ваше рабочее время, а не пытаться натянуть реальность на специально подобранную аналогию. Безусловно, в плохо организованной рабочей среде много времени уходит впустую - на согласование деталей с коллегами, на ожидание компиляции или тестов, на какую-нибудь унылую отладку и т.п. Но так живут не все. Если Вы действительно будете интересоваться собственной производительностью, измерять её и пытаться улучшить, то окажется, что советы из статьи действительно полезны.
Навыки работы в IDE или продвинутом редакторе типа Vim не сводятся к простому "быстрее печатать буквы". Это в принципе более быстрое редактирование кода. Например, автоматические рефакторинги в IDEA (выделение метода, изменение сигнатуры, переименование). Хоткеем это можно сделать за секунды и при этом минимизировать риски неверного применения (например, риск потерять переменную при выделении метода). А руками будете плюхаться гораздо дольше, да ещё и риски сильно вырастают. Каждая ошибка приводит к новым задержкам: сначала надо найти причину, потом разобраться, как её поправить, потом снова перепечатать код... В итоге, без инструментальной поддержки мы проводим один простой рефакторинг за то же время, за которое с инструментом можно было бы сделать 10-15 шагов. Это совсем другой уровень работы.
Более того, эти же навыки помогают бороться с задержками, когда мы изучаем код. Не секрет, что много времени тратится не на само написание финальных изменений, а на то, чтобы понять, где надо поправить код, и каким образом. И умение быстро редактировать код здесь тоже может помочь - например, банально через экспериментирование: "так плохо, так не очень, так норм". Пока медленный человек набивает свои буковки в первом решении, более быстрый успеет проверить 2-3 варианта и выбрать из них более подходящий. А это, опять же, даёт положительную обратную связь в виде более надёжного решения, более чистого кода, более качественного понимания системы.
через время может оказаться так, что был прав ваш коллега, а не вы
В том конкретном случае, что был у меня, - нет. В его представлении, время должно было уйти на ручной поиск и перебивание текста в десятках файлов. А по факту вопрос вполне успешно решался несложной однострочной командой на bash (несколько секунд на набор команды, условная секунда или меньше на исполнение, несколько минут на контрольный просмотр изменений). Я же не просто так написал: уже сделал задачу и даже время засёк. Обсуждение изменений было необходимо лишь для "легализации" этих изменений (бюрократия: каждое изменение должно иметь связанный тикет).
В общем случае может быть что угодно, да. Мы делаем 5-минутное изменение в коде, но оно ломает что-то в неожиданном месте, и приходится тратить пол-дня на исправления (хотя чаще лучше и быстрее бывает применить простой советский revert). Но это уже оффтопик, по-моему. Статья про скорость редактирования кода.
Шаблон - это не хорошо и не плохо. Это способ экономии мысленных усилий. Каждый из нас применяет кучу шаблонов в ежедневной деятельности, на работе, дома и просто по жизни. Не всегда можно угадать, где шаблон надо отключать. Если отключать его слишком часто, легко свалиться в аналитический паралич. Если отключать слишком редко, легко упустить уникальные шансы. Это игра (в математическом смысле слова).
Мне кажется, что отрефлексировать этот момент полезно, но не стоит принимать его слишком близко к сердцу.
Очень большой плюс за пункты 2 и 3. Люди не ценят их, потому что даже не могут представить, насколько быстро эти инструменты позволяют лепить код на самом деле. Как-то раз я шарил код с коллегами в IDE, на ходу что-то рефакторил и комментировал свои действия. Так один из коллег с удивлением воскликнул "как это у тебя код моментально появляется?". Это именно так и происходит порой. Скорость редактирования становится сравнима практически со скоростью мышления и почти перестаёт быть блокером. Это позволяет буквально на ходу создавать и пробовать разные подходы, выбирать из них самый подходящий и отбрасывать неудачные пробы без сожаления. А сравнение разных подходов - это экспа! Тот самый опыт, который позволяет тренировать чуйку и улучшает процесс принятия решений в дальнейшей работе.
Вообще, я бы ещё порекомендовал обратить внимание на CLI-утилиты. AI-это хорошо, конечно, но пробовали ли Вы всю мощь grep, sed или comby? Забавно (но в то же время и грустно), когда оцениваешь с коллегой какую-то задачу, и ты точно знаешь, что сделаешь её за 5-10 минут с помощью CLI (потому что на самом деле уже сделал её из интереса и даже время специально засёк), а он такой "ну, тут времени как минимум на полдня".
Если процесс написания кода занимает 5-10% времени, то вопрос скорости этого написания становится ещё более актуальным, разве нет? Думаю, есть определённая разница между "задача заняла час кодинга, который был размазан на 2-3 дня" и "задача заняла полчаса кодинга, который удалось провести в течение дня".
Иногда практикую. Диктофон - это лучше, чем ничего, но всё ещё далеко от идеала. Если записывать только голос, то утомляет необходимость потом сидеть и заниматься переводом в текст. Если использовать STT (типа гугл-клавиатуры), то надо постоянно следить за знаками препинания, правильностью трансляции и т.п.
Хотя кажется, что и диктовка "прямо из мозга" будет страдать от схожих проблем. Самое сложное порой - это именно формулировать мысль таким образом, чтобы она была понятна потом, когда контекст уже выветрился. Иначе получается "надо взять ту штуку и провернуть с ней этот приём, как я делал в той задаче не помню про что, и тогда можно будет обойти неприятности с теми шнягами".
Процитировали же учёного: изоэнтропу строят. Т.е., график конкретных характеристик газа в разных условиях. А этот график уже потом можно для любых других целей использовать: технику проектировать, недра планет обсчитывать, и тд и тп.
До сине-зелёных водорослей (которые своими "отходами жизнедеятельности" полностью и навсегда уничтожили существовавший до них климат, вытравили атмосферу, литосферу и океаны, а также спровоцировали чудовищные стомиллионнолетние оледенения) нам пока что и правда далеко.
Зато до чего же это будет эпично!
Шесть нобелевок человекам, и ни одной премии мухе! А ведь она жизнь на это дело положила...
Люди вообще не запариваются в наши дни. Пишут в мессенджер "можно я тебе сейчас позвоню?", и затем уже на созвоне задают голосом простейший 3-минутный вопрос. А мы тут правила квотирования обсуждаем, эх...
С Качествами или без? (ирония)
Здесь не телеграм, никаких "оставайтесь на связи". Если конкретных решений не предлагается, за подобную "статью" сразу незачёт.
Священная шестерёнка! Надеюсь, они не забывали использовать в процессе освящённые ароматические масла и вовремя произносить молитвы во имя Омниссии?
Выглядит чудесно: copilot отвечает на письма, о чём-то общается с коллегой, договаривается... а потом оказывается, что включивший копилота сотрудник ни о каких договорённостях не знает, ничего не сделал и по факту всё продолбал!
Рекомендую на деле померить, на что именно тратится Ваше рабочее время, а не пытаться натянуть реальность на специально подобранную аналогию. Безусловно, в плохо организованной рабочей среде много времени уходит впустую - на согласование деталей с коллегами, на ожидание компиляции или тестов, на какую-нибудь унылую отладку и т.п. Но так живут не все. Если Вы действительно будете интересоваться собственной производительностью, измерять её и пытаться улучшить, то окажется, что советы из статьи действительно полезны.
Навыки работы в IDE или продвинутом редакторе типа Vim не сводятся к простому "быстрее печатать буквы". Это в принципе более быстрое редактирование кода. Например, автоматические рефакторинги в IDEA (выделение метода, изменение сигнатуры, переименование). Хоткеем это можно сделать за секунды и при этом минимизировать риски неверного применения (например, риск потерять переменную при выделении метода). А руками будете плюхаться гораздо дольше, да ещё и риски сильно вырастают. Каждая ошибка приводит к новым задержкам: сначала надо найти причину, потом разобраться, как её поправить, потом снова перепечатать код... В итоге, без инструментальной поддержки мы проводим один простой рефакторинг за то же время, за которое с инструментом можно было бы сделать 10-15 шагов. Это совсем другой уровень работы.
Более того, эти же навыки помогают бороться с задержками, когда мы изучаем код. Не секрет, что много времени тратится не на само написание финальных изменений, а на то, чтобы понять, где надо поправить код, и каким образом. И умение быстро редактировать код здесь тоже может помочь - например, банально через экспериментирование: "так плохо, так не очень, так норм". Пока медленный человек набивает свои буковки в первом решении, более быстрый успеет проверить 2-3 варианта и выбрать из них более подходящий. А это, опять же, даёт положительную обратную связь в виде более надёжного решения, более чистого кода, более качественного понимания системы.
В том конкретном случае, что был у меня, - нет. В его представлении, время должно было уйти на ручной поиск и перебивание текста в десятках файлов. А по факту вопрос вполне успешно решался несложной однострочной командой на
bash(несколько секунд на набор команды, условная секунда или меньше на исполнение, несколько минут на контрольный просмотр изменений). Я же не просто так написал: уже сделал задачу и даже время засёк. Обсуждение изменений было необходимо лишь для "легализации" этих изменений (бюрократия: каждое изменение должно иметь связанный тикет).В общем случае может быть что угодно, да. Мы делаем 5-минутное изменение в коде, но оно ломает что-то в неожиданном месте, и приходится тратить пол-дня на исправления (хотя чаще лучше и быстрее бывает применить простой советский
revert). Но это уже оффтопик, по-моему. Статья про скорость редактирования кода.Главное - не забыть через 5 лет поглядеть в нужное время на небо!
Шаблон - это не хорошо и не плохо. Это способ экономии мысленных усилий. Каждый из нас применяет кучу шаблонов в ежедневной деятельности, на работе, дома и просто по жизни. Не всегда можно угадать, где шаблон надо отключать. Если отключать его слишком часто, легко свалиться в аналитический паралич. Если отключать слишком редко, легко упустить уникальные шансы. Это игра (в математическом смысле слова).
Мне кажется, что отрефлексировать этот момент полезно, но не стоит принимать его слишком близко к сердцу.
Очень большой плюс за пункты 2 и 3. Люди не ценят их, потому что даже не могут представить, насколько быстро эти инструменты позволяют лепить код на самом деле. Как-то раз я шарил код с коллегами в IDE, на ходу что-то рефакторил и комментировал свои действия. Так один из коллег с удивлением воскликнул "как это у тебя код моментально появляется?". Это именно так и происходит порой. Скорость редактирования становится сравнима практически со скоростью мышления и почти перестаёт быть блокером. Это позволяет буквально на ходу создавать и пробовать разные подходы, выбирать из них самый подходящий и отбрасывать неудачные пробы без сожаления. А сравнение разных подходов - это экспа! Тот самый опыт, который позволяет тренировать чуйку и улучшает процесс принятия решений в дальнейшей работе.
Вообще, я бы ещё порекомендовал обратить внимание на CLI-утилиты. AI-это хорошо, конечно, но пробовали ли Вы всю мощь
grep,sedилиcomby? Забавно (но в то же время и грустно), когда оцениваешь с коллегой какую-то задачу, и ты точно знаешь, что сделаешь её за 5-10 минут с помощью CLI (потому что на самом деле уже сделал её из интереса и даже время специально засёк), а он такой "ну, тут времени как минимум на полдня".Если процесс написания кода занимает 5-10% времени, то вопрос скорости этого написания становится ещё более актуальным, разве нет? Думаю, есть определённая разница между "задача заняла час кодинга, который был размазан на 2-3 дня" и "задача заняла полчаса кодинга, который удалось провести в течение дня".
По крайней мере, на Земле.
Вспоминается эпический фейл с пенетратором InSight, который тоже хорошо показал себя в испытаниях, но на Марсе толком не смог ничего пробурить.
Лучший комментарий, спасибо!
Боюсь, это очень старая проблема - см "охлократия".
Иногда практикую. Диктофон - это лучше, чем ничего, но всё ещё далеко от идеала. Если записывать только голос, то утомляет необходимость потом сидеть и заниматься переводом в текст. Если использовать STT (типа гугл-клавиатуры), то надо постоянно следить за знаками препинания, правильностью трансляции и т.п.
Хотя кажется, что и диктовка "прямо из мозга" будет страдать от схожих проблем. Самое сложное порой - это именно формулировать мысль таким образом, чтобы она была понятна потом, когда контекст уже выветрился. Иначе получается "надо взять ту штуку и провернуть с ней этот приём, как я делал в той задаче не помню про что, и тогда можно будет обойти неприятности с теми шнягами".
Простите, не сдержался
Процитировали же учёного: изоэнтропу строят. Т.е., график конкретных характеристик газа в разных условиях. А этот график уже потом можно для любых других целей использовать: технику проектировать, недра планет обсчитывать, и тд и тп.