Комментарии 42
Лично я смог поднять скорость печати с ~200 до 450-500 символов/мин, что очень ускорило мою работу.
Я не понимаю - вы кем работаете, секретарём-машинисткой на сдельной системе оплаты или программистом разработчиком?
Простите, навеяло
-А с какой скоростью вы можете печатать на машинке?
-Ну... 1000-1200 знаков в минуту....
-Разве можно с такой скоростью печатать?!!
-Печатать-то можно, но такая херня получается!!!!
???
Что-то типа этого хотел тоже написать, что с такой скоростью можно писать только быдло говно код. Ибо пока всё осмыслишь пока тонкости в голове и поворочаешь и только потом в код и скорость будет в среднем несколько знаков в минуту. Даже когда всё расписано и разложено по полочкам, то какая разница что я кода напишу не за минуту, а за 5? Что изменится? Экономия энергии? Или что? Или мы делаем, просто делаем, чтобы что-то делать не придавая значения?
Я уже много лет учусь писать код медленее. А лучше вообще не писать по возможности. И знаете это гораздо эффективнее.
Лично я смог поднять скорость печати с ~200 до 450-500 символов/мин, что очень ускорило мою работу.
А я купил машину которая может ехать не 150 а 300 км/ч, и теперь доезжаю до работы в два раза быстрее!
Можно попросить помощника нажимать каждый чётный символ, а самому жать нечётные. Это же двукратный рост скорости получится!
Нужно в капитал вкладываться
?
Слышал, кстати, как-то занятную штуку. На самом деле общепринятая "QWERTY" она не самая эффективная с т.з. английского языка. А откуда это взялось. Первые машинки были полностью механические и при быстром нажатии подряд двух соседних клавиш их часто заклинивало, поэтому раскладку клавиатуры подгоняли так, чтобы такие комбинации при наборе встречались пореже.
Да как выйти из этого вашего vim?!
Это про меня :) До недавних пор.
Способ 3: использование редактора Vim (или хотя бы vim motions)
Vim — это текстовый редактор, который работает в терминале на UNIX-системах. В отличие от других редакторов, у него собственная логика ввода текста, и его можно удобно кастомизировать под себя, поэтому Vim используют многие разработчики для ускорения написания кода.
Работа с Vim требует привыкания — это не обычный текстовый редактор, где мы используем клавиатуру вместе с мышью, чтобы управлять курсором и набирать текст. В нем есть три режима: режим ввода, командный и визуальный режим. То есть, все команды выполняются при помощи клавиатуры — и ввод текста, и перемещение по нему (в Vim это называется моушнами или движениями). Это здорово экономит время: например, вам не нужно брать мышку и искать начало строки, чтобы поставить туда курсор, а переместиться в начало или конец файла можно парой клавиш.
Но с другой стороны, это и вызывает сложности у новичков, потому что логика работы с текстом абсолютно меняется. При запуске Vim вы сразу попадаете в командный режим, а чтобы выйти из редактора, нужно написать определенную команду во внутренней консоли — привычно свернуть окно или кликнуть куда-то мышкой не получится.
Нет, я конечно всё понимаю, но я всегда думал что Vim пользуются только сисадмины, да счастливые владельцы CLI-only систем.
Но это не vscode конечно, зато в bash работает
Для VS Code есть расширение. Для Visual Studio тоже. Стрелки и мышь, к слову сказать, даже в консольном vim давно уже работают. Стрелки, впрочем, это на любителя - зачем тянуть руку к стрелкам когда "hjkl" всегда прямо под рукой.
здравствуйте, меня зовут Вася и я использую vim
Причём и под Linux и под windows.собственно говоря из-за Linux все и началось. Надо было писать под обе системы и очень не хотелось привыкать к разным редакторам. Под виндой в то далекое время сидел на SlickEditor. Может он жив ещё не знаю :)
Немного ИМХО про слепую печать. Пользуюсь слепой печатью уже больше 20 лет поэтому пишу про собственный опыт. Слепая печать нужна не только для скорости. Слепая печать позволяет добиться эффекта, когда слова автоматически появляются на экране. Примерно как при разговоре. Т.е., набор текста "делегируется" на уровень подсознания, а сознание разгружается для решения настоящих задач.
Другой полезный эффект - это меньше нагрузка на глаза. Когда при зрячей печати приходится иногда смотреть на клавиатуру - это вынуждает глаза постоянно перефокусироваться и главное - сужать и расширять зрачок из-за изменения яркости.
Поддержу это замечание. Ловил пару раз себя на том, что уже отвлёкся от кода на разговор, а пальцы ещё допечатывают слово-другое.
Ну и раз уж трачу свой единственный коммент, поддержу vim тоже. Начал пользоваться лет десять назад, и теперь куча профита прям каждый день. В обеих осях в консоли он теперь "под рукой", в вскоде тоже те же привычки, и что самое главное, мне теперь плевать какой формы стрелочки сделали инженеры ноутбука, и куда запрятали home и end, и поставили ли клавишу power вместо delete, у меня всегда всё на месте.
Разве перефокусировка и сужение/расширение зрачка - это не профилактика спазма аккомодации?
Почитал про спазм аккомодации, оказывается и у меня такое наблюдается. Для себя интуитивно выработал такой режим работы: работаю пока не захочется встать и подойти к окну. Тогда я встаю и похожу к окну. Иногда это может быть через 5-10 минут, иногда через час. Скорее всего, этого недостаточно, поскольку наблюдаются симптомы.
Но насчет "профилактики" в виде постоянной нагрузки, здесь я готов поспорить. Может быть и можно натренировать глазные мышцы, чтобы они стали более выносливыми, но чрезмерная нагрузка на глазные мышцы (а работа она такая, не спрашивает комфортно или нет) на мой взгляд вреднее чем недостаток нагрузки.
Поналетели коршуны, как обычно) автор, спасибо за лайфхацки!
Удивляюсь фанатам ускорения написания кода. Вы там что, каждый день бутстрапите новые приложения? За 4 года даже с уровня джуна уже доходят до уровня, когда сам процесс написания кода занимает 5-10% времени, а остальное - бесконечные синки, согласования спек, дебагинг, работа на сервере или браузере и т.д.
Ничего удивительного. Когда был ребенком, главной характеристикой крутости автомобиля была максимальная цифра скорости на спидометре. У фанатов ускорения написания кода примерно такое же преставление о программировании как у меня об автомобилях в детстве.
Если процесс написания кода занимает 5-10% времени, то вопрос скорости этого написания становится ещё более актуальным, разве нет? Думаю, есть определённая разница между "задача заняла час кодинга, который был размазан на 2-3 дня" и "задача заняла полчаса кодинга, который удалось провести в течение дня".
то вопрос скорости этого написания становится ещё более актуальным, разве нет?
Настолько же актуальный, насколько ускорение бекенд-приложения путем переписывания с питона/руби на плюсы/раст. Аналогия очевидна: само приложение тратит на обратку запроса > 5-10% общего времени, большая часть уходит на ожидание запросов бд, системы кеширования и т.д. Так что эффективнее выходит оптимизировать именно последнее.
Рекомендую на деле померить, на что именно тратится Ваше рабочее время, а не пытаться натянуть реальность на специально подобранную аналогию. Безусловно, в плохо организованной рабочей среде много времени уходит впустую - на согласование деталей с коллегами, на ожидание компиляции или тестов, на какую-нибудь унылую отладку и т.п. Но так живут не все. Если Вы действительно будете интересоваться собственной производительностью, измерять её и пытаться улучшить, то окажется, что советы из статьи действительно полезны.
Навыки работы в IDE или продвинутом редакторе типа Vim не сводятся к простому "быстрее печатать буквы". Это в принципе более быстрое редактирование кода. Например, автоматические рефакторинги в IDEA (выделение метода, изменение сигнатуры, переименование). Хоткеем это можно сделать за секунды и при этом минимизировать риски неверного применения (например, риск потерять переменную при выделении метода). А руками будете плюхаться гораздо дольше, да ещё и риски сильно вырастают. Каждая ошибка приводит к новым задержкам: сначала надо найти причину, потом разобраться, как её поправить, потом снова перепечатать код... В итоге, без инструментальной поддержки мы проводим один простой рефакторинг за то же время, за которое с инструментом можно было бы сделать 10-15 шагов. Это совсем другой уровень работы.
Более того, эти же навыки помогают бороться с задержками, когда мы изучаем код. Не секрет, что много времени тратится не на само написание финальных изменений, а на то, чтобы понять, где надо поправить код, и каким образом. И умение быстро редактировать код здесь тоже может помочь - например, банально через экспериментирование: "так плохо, так не очень, так норм". Пока медленный человек набивает свои буковки в первом решении, более быстрый успеет проверить 2-3 варианта и выбрать из них более подходящий. А это, опять же, даёт положительную обратную связь в виде более надёжного решения, более чистого кода, более качественного понимания системы.
Я тимлид и код пишу только 5-10% времени. Все остальное время я тупо печатаю, спеки, бесконечные чаты с менеджерами, членами команды, ревью кода надо написать. Как хорошо было печатать только код. И очень хорошо, что я научился быстрой слепой печати, я бы и половину работы бы не сделал, если бы прыгал глазами на клавиатуру.
Очень большой плюс за пункты 2 и 3. Люди не ценят их, потому что даже не могут представить, насколько быстро эти инструменты позволяют лепить код на самом деле. Как-то раз я шарил код с коллегами в IDE, на ходу что-то рефакторил и комментировал свои действия. Так один из коллег с удивлением воскликнул "как это у тебя код моментально появляется?". Это именно так и происходит порой. Скорость редактирования становится сравнима практически со скоростью мышления и почти перестаёт быть блокером. Это позволяет буквально на ходу создавать и пробовать разные подходы, выбирать из них самый подходящий и отбрасывать неудачные пробы без сожаления. А сравнение разных подходов - это экспа! Тот самый опыт, который позволяет тренировать чуйку и улучшает процесс принятия решений в дальнейшей работе.
Вообще, я бы ещё порекомендовал обратить внимание на CLI-утилиты. AI-это хорошо, конечно, но пробовали ли Вы всю мощь grep, sed или comby? Забавно (но в то же время и грустно), когда оцениваешь с коллегой какую-то задачу, и ты точно знаешь, что сделаешь её за 5-10 минут с помощью CLI (потому что на самом деле уже сделал её из интереса и даже время специально засёк), а он такой "ну, тут времени как минимум на полдня".
Через время может оказаться так, что прав был ваш коллега, а не вы...
И может даже он знал, что это можно сделать за 3 минуты)
через время может оказаться так, что был прав ваш коллега, а не вы
В том конкретном случае, что был у меня, - нет. В его представлении, время должно было уйти на ручной поиск и перебивание текста в десятках файлов. А по факту вопрос вполне успешно решался несложной однострочной командой на bash (несколько секунд на набор команды, условная секунда или меньше на исполнение, несколько минут на контрольный просмотр изменений). Я же не просто так написал: уже сделал задачу и даже время засёк. Обсуждение изменений было необходимо лишь для "легализации" этих изменений (бюрократия: каждое изменение должно иметь связанный тикет).
В общем случае может быть что угодно, да. Мы делаем 5-минутное изменение в коде, но оно ломает что-то в неожиданном месте, и приходится тратить пол-дня на исправления (хотя чаще лучше и быстрее бывает применить простой советский revert). Но это уже оффтопик, по-моему. Статья про скорость редактирования кода.
Это здорово экономит время: например, вам не нужно брать мышку и искать начало строки, чтобы поставить туда курсор, а переместиться в начало или конец файла можно парой клавиш.
не уверен, что мне нужен vim, что бы в любом редакторе нажать кнопку "home" или "ctrl+home".
В vim очень быстро привыкаешь перемещаться или оперировать не буквами-строками, а какими-либо "логическими" структурами кода. Например, "скопировать /вырезать в буфер текущий блок кода": yi{ / di{ (без фигурных скобок) или ya{ / da{ (с фигурными скобками), "переместиться на начало /конец блока '(...)'": [( / ]) - и куча всего подобного.
Все эти возможности есть в любой ide. Только нажимаются проще. Типа Ctrl+скобка.
А, например, "Вырезать весь строковой литерал на котором стоит курсор"? В vim три клавиши: da" :)
Или "Перейти на первое за курсором двоеточие / точку с запятой / запятую"? f: / f; / f,
"Сделать все текущее слово заглавными / строчными буквами": gUiw / guiw
В "обычном" редакторе потом без таких и еще кучи подобных вещей себя чувствуешь каким-то инвалидом с ограниченными возможностями.
Вот об этом и надо писать. А то пример с переходом в начало файла звучит как: "на автомобиле можно доехать быстрее, чем на автобусе, потому что у автомобиля есть колёса" :D
Кстати, спасибо за ответ, заставил меня сильно задуматься.
В моей жизни никогда не было такого, чтобы надо было писать много кода, хотя, наверное, в мире существует ниша подобных кодеров, где думать не надо, а надо уметь быстро стучать по клаве...
Ну да... Мне, чтобы написать какое-то подобие такой статьи, понадобилось бы истратить, наверное, целый день, если не больше, и часа три ушло бы только на ввод, редактирование и последующую правку текста... Так ведь, черт, нет времени - баги, текущие задачи, переписка с коллегами на двух языках, рефакторинг, ещё всякая муть... Нет времени, да... Не тем я занимаюсь, не тем...
Фух, я со своими пара строк кода в день выдохнул, думал рак совсем, люди то вон по проекту в неделю сдают....
С 200 до 500 знаков в минуту — 4 года учусь писать код быстрее. Рассказываю о самых эффективных методах в статье