Одна из худших вещей, которые вы можете сделать для своей долговременной карьеры, — это настолько привязаться к какому-то инструменту, языку или среде, которые вы не сможете изменить. Затем вы обнаружите, что предпочитаемый вами инструмент недоступен для нового оборудования при следующем задании...

Я рано вышел на пенсию, поэтому мой общий стаж работы в отрасли составил всего 32 года. За это время я перешел от программирования на уже устаревшем языке ассемблера на перфокартах к Java в IDE. Срок службы человека часто превышает срок службы программного инструмента.

Возможно, в данный момент вы находитесь только в состоянии «предпочитаю не меняться», а не «не могу измениться», но чем дольше вы работаете с одним набором инструментов, тем труднее будет измениться.

Я сейчас нахожусь в несколько похожем положении. Почти все в компании используют IDE под названием eclipse, но я предпочитаю использовать IntelliJ, потому что с ним я разрабатываю быстрее. Мои советы:

Дайте их инструменту шанс

В вашем случае мы всегда сначала предпочитаем использовать «известный нам инструмент», vim. Однако у каждого инструмента есть свои преимущества и недостатки. Используйте их инструмент немного, попросите помощи, делая то, к чему вы привыкли в vim. Благодаря этому вы либо учитесь «их пути», либо создаете аргументы в пользу своего инструмента.

Также используйте это как возможность улучшить свои навыки в более чем одном инструменте. Как уже упоминалось, важно знать более одного способа сделать это. Обязательно обновляйте свои навыки. И даже если вы не будете пользоваться этим инструментом, некоторые его аспекты вы можете использовать в своем рабочем процессе vim.

В качестве побочной истории, в команде, о которой я слышал, но никогда не был, команда использовала инструмент X для разработки. Новый член команды хотел использовать инструмент Y, но ему сказали: «Нет, мы делаем это ТОЛЬКО инструментом X!!!» Итак, товарищ по команде использовал инструмент X. Позже он спросил: «Как мне отличить инструмент X?» Их ответ: «О, для этого мы используем инструмент Z». Его: «Если мы используем инструмент Y, мы платим только за одну лицензию, и он может развиваться и изменяться. В настоящее время вы платите 2 лицензии за инструмент X и Z». Это четкая деловая причина для использования инструмента Y.

В любом случае используйте свой инструмент

Если вы сделали все вышеперечисленное, а они все еще настаивают на своих инструментах — что в вашем случае, как я четко вижу, происходит с кривой обучения vim — используйте свой выбор, но не называйте его. Настройте его так, чтобы стиль кода был похож на их собственный. Это то, что я делаю. Не заставляю никого менять IDE в моей команде, но мои товарищи по команде знают, что я использую другую. Иногда они спрашивают об этом, и я хороший представитель IDE. Вы можете стать подобным послом для vim, если хотите.

Согласно комментарию к другому ответу, если вы решите использовать настройку, отличную от стандартной, как профессионал, вы тратите свое время на ее настройку. Это означает работу по ночам и выходным, если вы возитесь со своей настройкой или ваша установка нарушает нормальный рабочий процесс других. Это также означает, что вы должны взять на себя ответственность за исправление некачественных инструментов и инфраструктуры, чтобы вы могли работать — например, разрешить сборку в командной строке, а не в IDE. Будьте вежливы и помните, что вы просите об одолжении не использовать стандартную настройку, вы точно не имеете на это права. Если использование других инструментов вызывает слишком много проблем, будьте готовы сдаться.

Риск, связанный с этим со стороны руководства, заключается в том, что вы в основном просите прощения, если они действительно настаивают на Sublime. В команде есть ценность в стандартизированных инструментах. В зависимости от ситуации, стандартная среда может означать лучшее сотрудничество, потому что товарищ по команде может прийти к вам на станцию ​​и точно знать, что ему нужно, чтобы помочь. Уважайте это, если руководство настаивает.

Специальный комментарий о Sublime : Sublime требует лицензии в бизнес-среде, хотя я видел, что это игнорировалось. Вы должны убедиться, что эта лицензия оплачена. Если это не так, предложите им перейти на атом , который является клоном Sublime, сделанным GitHub, который действительно свободен как в пиве, а также свободен в речи.

У меня был напечатан длинный ответ о том, как мне не нравятся споры о том, лучше ли инструмент X, чем инструмент Y, потому что это просто аргументы о том, какой тип отвертки «лучше», но я удалил его, потому что он не по теме, и тоже скучно.

Мой совет таков: убедитесь, что ваши причины использования одного инструмента содержат нечто большее, чем «Я предпочитаю этот» или «Я знаю его лучше».

Компании, у которых есть стандартный инструментарий, обычно имеют его, потому что кто-то его установил, либо потому, что он подходит для использования и выполняет работу правильно, либо потому, что этот человек предпочитает его. Если это первое, и вы действительно можете продемонстрировать, что ваш инструмент не нарушит процесс, вы можете что-то изменить. Если последнее и этот человек все еще находится в состоянии принятия решений, вы вступаете в спор.

Лучший способ избежать этого — разработать процессы, которые не зависят от инструментов, но это лошадь другого цвета.

Я занимаюсь консалтингом более двадцати лет. Я регулярно сталкиваюсь с ситуациями, подобными вашей, потому что постоянно бываю в новых местах.

Со временем я понял, что то, в чем я хорош, — это использование функций в моих инструментах определенным образом — так что проблема не в инструменте, а в функции, используемой определенным образом — «как мне сделать это в инструменте X».

Поэтому, если компания не хочет разрешать мне загружать и устанавливать инструменты, которые я хочу, я попрошу их помочь мне адаптировать их инструменты к функциям, которые мне нужны, чтобы максимизировать мою производительность для них.

И это оказалось очень полезным для меня - я изучаю новый инструмент И как использовать его МОИМ способом. Это помогает в долгосрочной перспективе как консультанту — чем больше инструментов я знаю, тем лучше я работаю — и чем больше способов решения одной и той же проблемы я знаю, тем лучше я себя чувствую.

Поэтому сосредоточьтесь на пользе для себя и компании — работайте на взаимовыгодный результат, сосредоточившись на том, что вам действительно нужно, а не споря, какой инструмент лучше.

(Однако время от времени, когда я перебираю функции, которые мне нужны, я обращаю клиента на использование моего предпочтительного инструмента, поскольку он понимает, что он лучше, что по-прежнему является беспроигрышным - только наоборот.)

TL;DR

• Научитесь использовать инструменты, которые они предоставляют
• Когда вы узнаете все, что нужно знать, скорее всего, вы столкнетесь со значительными трениями, поэтому используйте свой старый рабочий процесс.
• Будьте готовы использовать «стандартный» рабочий процесс при получении/оказании помощи.

Я отмечаю, что ни один из этих ответов не с точки зрения опытного пользователя Vim *

* _{^{Я определяю опытного пользователя Vim как любого, кто сталкивается с проблемами с различными плагинами, потому что они не соответствуют <выберите поведение вашего vim>.}}

От имени силы (Vim/Tmux)

Vim и tmux создают невероятно мощную комбинацию. Если у вас еще нет настройки привязки, добавьте что-то вроде этого:

func! BindTest()
    call inputsave()
    let session = input('tmux target session:pane> ', ':1.1')
    let command = input('test command> ', 'py.test --cov')
    "let global = input('bind for all windows? ', 'y')
    call inputrestore()

    execute "nnoremap <cr> :w!<cr>:!tmux send-keys -t " . session . " \"" . command . "\" C-m<cr><cr>"
endfunc

nnoremap <leader>st :call BindTest()<cr>

Позволяет запускать Enterавтоматические тесты на разделенной панели, и пока они выполняются, вы можете продолжать редактирование. Очевидно, измените команды в соответствии с вашими предпочтениями/средой. Я использую это в качестве примера, но есть много, много других чрезвычайно мощных вещей, которые вы можете делать с помощью vi/vim/tmux, которые не требуют, чтобы вы отрывали руки от печатающего положения. Любой другой рабочий процесс, который я пробовал, всегда оставлял меня без старой доброй командной строки.

В общем, если у вас есть доступный инструмент, такой как vim+tmux, вы должны использовать его . Я не верю, что кто-то за всю свою жизнь может узнать и использовать все, что можно, о vim+tmux.

Я подозреваю, что если вы достаточно страстно относитесь к нестандартному инструменту, который хотите использовать, вероятно, он имеет такую ​​же силу.

От имени стандартов

С другой стороны, так ли вы уверены , что ваш инструмент так хорош, как вы думаете? Это может быть не так. Единственный способ узнать наверняка, если вы попробуете другую вещь. В Sublime/Atom/Brackets есть несколько довольно полезных функций, которые могут сделать вашу жизнь лучше. Или хотя бы конкурировать с вашим инструментом.

Изучите инструмент, который ваша компания предоставляет/требует. Научитесь использовать его сочетания клавиш/горячие клавиши, изучите его функции. Быстрее ли просто использовать клавиатуру? Или вы можете управлять им быстрее с помощью мыши и клавиатуры? Если ваше первоначальное впечатление верно, что ваш инструмент лучше стандартного, есть вероятность, что в течение недели или двух вы изучите почти все, что можно сделать без обширной настройки (например, плагинов или программирования ваших собственных расширений). Если вы не изучаете постоянно новые функции, которые могут повысить вашу скорость, и особенно если вы сталкиваетесь с трудностями в рабочем процессе, теперь вы можете положить этот инструмент обратно на полку.

ничего личного

Большинство средств, которые рассчитаны на массовое потребление. (<инструмент, от которого вы отказываетесь>) предназначен для работы с наименьшим общим знаменателем. Я почти уверен, что могу посадить любого из своих детей перед Sublime, и они смогут начать что-то печатать (конечно, это будет не очень хорошо, но редакторы недостаточно хороши, чтобы решить эту проблему ) . пока что).

В корпоративной среде вы этого хотите . Я должен иметь возможность сесть за ваше рабочее место, или вы за мое, и у нас должен быть общий язык, на котором мы можем говорить. В стандартном редакторе, таком как Sublime, вы можете сказать: «Хорошо, теперь откройте боковую панель, перейдите в этот каталог и откройте этот файл, затем прокрутите вниз, пока не дойдете до этой функции».

Есть некоторая сила в том, чтобы иметь эту общность. Вам не нужно ругать меня за использование emacs, а мне не нужно высмеивать вас за использование «модального редактирования, что бы это ни было» каждый раз, когда мы собираемся вместе для редактирования кода. И если я сяду за вашу клавиатуру, есть очень хороший шанс, что у нас будут одинаковые сочетания клавиш, даже если это мой самый первый день в качестве совершенно нового программиста, только что закончившего колледж/учебный лагерь в вашей компании.

Короткий ответ

Разные компании, разная культура, инструменты, стандарты и т. д. Либо следуйте им, либо старайтесь быть с ними рутинными, либо убедите их добавить/изменить в стандарте то, что вы хотите. Они обязательно изменят стандарты, если это будет выгодно для компании.

Длинный ответ

Попросите их настроить и разрешить вам использовать Vim/Tmux , так как вы более гибки в этом. Также объясните им преимущества Vim/Tmux над Sublime .

Если они отказываются от Vim/Tmux , тогда начните быть гибким с Sublime , так как со временем вы будете знакомы и гибки, чтобы работать с ним.

Требуется время, чтобы принять новые вещи/инструменты, будь то для компании или для сотрудника. Вы новичок или не можете использовать Sublime Text Editor , а Vim/Tmux является новым для компании. Таким образом, для обоих (вас и компании) ситуация одинакова, и они не принимают это изменение немедленно. Надеюсь, вы убедите их в пользу Vim/Tmux .

Вы новичок, поэтому вам нужно найти время и выяснить, почему все так, а не иначе. Затем вы можете определить стратегию их изменения или, возможно, не менять их вообще. В процессе собеседования вы должны спросить о том, как управляется группа программистов, и получить некоторое представление о том, подходите ли вы. Исходя из вашей текущей ситуации, есть вероятность, что вы этого не сделаете.

Есть некоторые ситуации, когда у вас нет возможности изменить изменения: парное программирование, строго ограниченное использование оборудования компании, компания приобрела/создала надстройки, которые работают только с одним типом текстового редактора.

Если они просто чувствуют, что все, будучи последовательными, помогают с обслуживанием, настройкой рабочих станций и оказанием поддержки, когда у вас есть проблема, может потребоваться некоторое время, чтобы доказать, что у вас не будет проблем, а если они есть, вы можете быстро их решить.

Будьте осторожны, вы не хотите, чтобы вас воспринимали как человека сложного и негибкого. Если компания может заработать много денег, написав код на COBOL, те, кто отказывается его изучать, делают это на свой страх и риск.

Мне кажется странным, что большинство ответов подталкивают вас к принятию стандарта и не спрашивают, можете ли вы использовать другой инструмент (если нет проблем с лицензированием и т. д.).

Прежде всего, убедитесь, что на вашей рабочей станции установлены все стандартные инструменты, чтобы, если вашему коллеге понадобится использовать вашу рабочую станцию, он сможет получить доступ ко всем стандартным инструментам, с которыми они знакомы.

Затем обратитесь к своему менеджеру и спросите, можно ли установить ваши собственные инструменты (и обязательно упомяните, что они бесплатны для использования или что вы предоставите свою собственную лицензию и предоставите подтверждение лицензии).

Я делаю это каждый раз, когда приступаю к новой работе (у меня есть набор своих стандартных инструментов, которыми я пользуюсь - Far Manager, 7-zip, все инструменты SysInternals и т.д.) и не было ни одного случая, чтобы я не получил одобрения. (У меня есть специальные лицензии на инструменты, для которых они требуются.)

Обычно я также изучаю стандартные инструменты компании, но я на порядок эффективнее использую Far Manager, чем Windows Explorer, поэтому в некоторых областях я предпочитаю свои собственные инструменты.

Это явно не будет работать с некоторыми инструментами (если компания использует MySql, вы не можете просто использовать SQL Server), но для локальных инструментов разработки мне трудно увидеть, что порядочный менеджер так или иначе заботится о них. Со временем некоторые из моих инструментов обычно становятся «стандартными», потому что некоторые/многие коллеги осознают их ценность и начинают их использовать.

В конце концов, если менеджер откажет, вам придется придерживаться стандартных инструментов, но спросить не помешает.

Разные компании имеют разные потребности и сделали разный выбор. Некоторые компании позволяют каждому выбирать, какие инструменты использовать, многие — нет. Иногда это происходит в результате роста (более мелкие компании с меньшей вероятностью будут стандартизированы), а иногда это происходит в результате чего-то плохого, когда кто-то использовал другой инструмент, а другие не могли должным образом поддерживать его, поэтому они стандартизировали все. Это часто обнаруживается после ухода первого человека и возникновения хаоса.

Если компания зашла так далеко, что создала стандарт, она будет ожидать, что вы научитесь с ним жить. Как новый сотрудник, если первое, что вы сделаете, это войдете и попытаетесь заставить их сделать для вас исключение, то вас, скорее всего, назовут нарушителем спокойствия или кем-то особенным снежинкой, с которым трудно работать. Это никогда не в ваших интересах. Плохое первое впечатление очень трудно исправить. Лучше адаптироваться к новому инструменту, даже если он вас временно тормозит.

В будущем, если для вас важно использовать определенный инструмент, принимайте только те задания, которые используют этот инструмент, или дайте свободу выбора того, что вы хотите. Даже в этом случае вам, возможно, придется адаптироваться позже, если в этой компании что-то изменится.