The Workplace Stack Exchange is a question and answer site for members of the workforce navigating the professional setting. It only takes a minute to sign up.
Sign up to join this community
I recently joined a new company, and in my previous company, I've been working with my Vim/Tmux workflow. But in new company, they say that I need to follow company standards, and one of the company standards is to use Sublime Text Editor with a few configurations.
Now, I'd really like to continue with my Vim/Tmux workflow, as I'm quite fast at it. So how should I communicate with them to resolve this thing?
Note: Vim can surely be configured like Sublime would have been configured.
One of the worst things you can do for a long term career is to become so wedded to some tool, language, or environment that you cannot change. Then you find your preferred tool is not available for the new hardware at the next job...
I retired early, so my total time in industry was only 32 years. During that time I went from coding in a now-obsolete assembly language on punch cards to Java in an IDE. Human working lives are often longer than software tool lifetimes.
Maybe at the moment you are only at "prefer not to change" rather than "cannot change", but the longer you go on with one tool set the harder it will be to change.
I am currently in a somewhat similiar position. Most everyone in the company uses an IDE called eclipse, but I prefer to use IntelliJ because I develop faster with it. My tips:
We always first like to use "the tool we know" in your case, vim. However, each tool has its advantages and disadvantages. Use their tool for a bit, ask for help doing things you are used to in vim. Through this you either learn "their way" or you build an argument for your tool.
Also take this as an opportunity to grow your skills in more than one tool. As others have mentioned, knowing more than one way to do this is important. Make sure to keep your skills fresh. And even if you don't stick with this tool, there may be aspects of it you can bring to your vim workflow.
As a side story, on a team I heard about but never was on, the team used tool X to develop. A new teammember wanted to use tool Y, but was told: "no, we do it with tool X ONLY!!!" So the teammate used tool X. Later he asked: "How do I diff with tool X?" Their reply: "oh, we use tool Z for that." His: "If we use tool Y, we only pay one licence and it can develop and diff. You currently pay 2 licenses for tool X and Z." That is a clear business reason to allow tool Y in.
If you have done the above, and they still insist on their tooling -- which in your case I strongly see happening with the learning curve of vim -- use your choice but don't call it out. Set it up to have similar code style to theirs. This is what I am doing. Not making anyone else switch IDEs on my team, but my teammates know I use a different one. Occasionally they ask about it, and I am a good ambassador for the IDE. You can become a similar ambassador for vim if you like.
Per a comment on a different answer, If you choose to use a different setup from the standard, as a professional you take your own time to set it up. Which means working nights and weekends if you are fussing with your setup or your setup breaks the normal workflow of others. This also means taking charge of fixing sub-par tooling and infrastructure to allow you to work -- for example allowing a build to happen on the command line instead of in an IDE. Be courteous and remember that you are asking for a favor to not use the standard setup, you are definitely not entitled to it. If you using different tooling causes too many issues be prepared to throw in the towel.
The risk with this from management, is that you are basically asking for forgiveness if they really insist on Sublime. There is value in standardized tools on a team. Depending on the situation, standard environments can mean better collaboration because a teammate can come over to your station and know exactly what they are looking at to help. Respect that if management insists.
Special comment about Sublime: Sublime does require a license in a business environment, though I have seen that ignored. You should make sure that that license is paid for. If it is not, suggest they move to atom which is a GitHub made Sublime clone that is truly free-as-in-beer as well as free-as-in-speech.
I had a long answer typed out about how I dislike the arguments over whether tool X is better than tool Y, because they're just arguments over which type of screwdriver is "better", but I deleted it because it's off-topic, and boring too.
My advice is this: ensure your reasons for using one tool contain more than "I prefer this one", or "I know it better".
Companies who have standard tooling usually have it because someone's put it in place, either because it's the right thing to use and gets the job done right, or because that person prefers it. If it's the former, and you can actually demonstrate your tool will not break the process, you might be able to change things. If the latter, and that person is still in a decision-making position, you're into an argument.
The best way to avoid this is to design processes that are tooling-agnostic, but that's a horse of a different colour.
I have been doing consulting work for over twenty years. I routinely encounter situations like yours because I keep going to new places.
Over time I realized that what I am good at is using features in my tools a certain way - so that the issue is not the tool, but the feature used in a certain way - "how do I do this in tool X".
Therefore, if a company is unwilling to let me download and install the tools I want, then I will ask them to help me to adapt their tools to the features I need to maximize my productivity for them.
And, that has turned out to be very beneficial to me - I learn a new tool AND how to use it MY way. That helps in the long run as a consultant - the more tools I know the better off I am - and the more ways I know of solving the same problem, the better off I am.
Therefore, focus on the benefit to yourself and the company - work toward a win-win by focusing what you actually need, rather than arguing which tool is best.
(Once in a great while though, as I go over the features I need, I'll convert a client to use my preferred tool as they realize it is better, which is still a win-win - just in reverse.)
I note that none of these answers are from the perspective of a Vim power user*
*I define Vim power user as anyone who runs into problems with various plugins because they do not conform to <choose your vim behavior>.
Vim and tmux make for an insanely powerful combination. If you don't yet have the binding setup, adding something like this:
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>
Allows you to hit Enter to run your automated tests in your split pane, and while they're running you can keep editing. Obviously change the commands to suit your preferences/environment. I use this as an example, but there are many, many other extremely powerful things that you can do with vi/vim/tmux that do not require you to take your hands from the typing position. Any other workflow that I have tried has always left me wanting for the good ol' fashioned command line.
In general, if there is a tool that you have available such as vim+tmux you should use it. I do not believe that it's possible for someone in their entire life to learn and take advantage of everything that they can about vim+tmux.
I suspect that if you feel passionately enough about a non-standard tool that you want to use, it's probably something that has this kind of power.
On the other hand, are you so sure that your tool is as good as you think it is? It might not be. The only way you'll know for sure is if you try the other thing. There are some pretty neat features of Sublime/Atom/Brackets/ that can make your life better. Or at least maybe compete with your tool.
Learn the tool that your company provides/requires. Learn to use its shortcuts/hotkeys, learn its features. Is it faster to just use the keyboard? Or can you operate it more quickly with mouse and keyboard? If your initial impression is right, that your tool is better than the standard one, chances are within a week or two you will have explored pretty much everything you can do without extensive customization (e.g. plugins or programming your own extensions). If you aren't continually learning new features that can improve your speed, and especially if you're facing friction in your workflow, now you can put this tool back on the shelf.
Most tools that are designed for mass consumption. (<insert tool that you're balking at here>) is designed to work well for the lowest common denominator. I'm pretty sure that I could plunk any of my children down in front of Sublime and they would be able to start typing things out (sure, it won't be very good, but editors aren't good enough to solve that problem yet).
In a corporate environment, you want that. I should be able to sit down at your workstation, or you at mine, and we should have a common language that we can speak. With a standard editor like Sublime, you can say, "okay, now open your sidebar, and go to this directory and open that file, then scroll down until you're at this function."
There is some power to having that commonality. You don't have to flame me for using emacs, and I don't have to deride you for using "modal editing, whatever that is," every time we get together to edit code. And if I sit down that your keyboard there's a very good chance that we will have the same keybindings, even if it's my very first day as a brand new programmer fresh out of college/bootcamp at your company.
Different Companies , Different culture, tools, standards etc. Either follow them , Try to be routine with them OR convince them to add/modify in standard what you want. They will definitely modify standards if that will be beneficial for company.
Request them to configure and allow you to use Vim/Tmux as you are more flexible with that. Also explain them benefits of Vim/Tmux over Sublime.
If they deny for Vim/Tmux then start to be flexible with Sublime, As by the course of time you will be familiar and flexible to work with it also.
It takes time to accept new things/tool either it is for company or for employee. You are new or may be not flexible to use Sublime Text Editor and Vim/Tmux is new for company. So for both(You and Company) situation is same and not accepting this change immediately. I hope you will convince them for Vim/Tmux.
You're new, so you need to take time and find out why things are they way they are. Then you can determine a strategy on how to change them or possible don't change them at all. During the interview process, you should be asking about how the programming group is managed and get some insight into whether or not you're a good fit. Based on your current situation, there is a chance you don't.
There are some situations where you have no change of changing: pair-programming, heavily restricted use of company equipment, the company purchased/built add-ons that only work on one type of text editor.
If they just feel like everyone being consistent helps with maintenance, setting up workstations and providing support when you have an issue, it may take some time to prove you're not going to have problems and if you do, you can solve them quickly.
Be careful, you don't want to be perceived as someone who is difficult and not flexible. If a company could make a lot of money writing code in COBOL, those that refuse to learn it do so at their own peril.
I find it strange that most answers push you towards accepting the standard and not asking nicely if you can use a different tool (as long as there are no licensing problems, etc.)
First of all, make sure that you have all the standard tools installed on your workstation so if a coworker of yours needs to use your workstation, they can access all the standard tools that they're familiar with.
Then go to your manager and ask if it's ok to install your own tools (and make sure to mention that they're free to use or that you'll supply your own license and will provide proof of the license).
I do this every time I start at a new job (I have a set of my of standard tools that I use - Far Manager, 7-zip, all the SysInternals tools, etc.) and there wasn't a single occasion when I didn't get approval. (I have specific licenses for the tools that require one.)
I usually end up learning the company-standard tools, as well but I'm orders of magnitude more efficient using Far Manager than using Windows Explorer so I prefer my own tools in some areas.
This will clearly not work with some tools (if the company uses MySql, you can't just use SQL Server) but for local development tools, I have a hard time seeing a decent manager care much one way or the other. Over time, some of my tools usually become "standard" because some / many coworkers realize their value and start using them.
At the end, if the manager says no, you'll have to stick to standard tools but it won't hurt to ask.
Different companies have different needs and have made different choices. Some companies allow everyone to choose what tools they use, many do not. Sometimes this is as a result of growth (smaller companies are less likely to be standardized) and sometimes it is as a result of something bad happening when someone used a different tool and then others couldn't adequately support it, so they standardized everything. This is often found after the first person has left and chaos has resulted.
If a company has gone so far as to make a standard, they are going to expect you to learn to live with it. As a new employee, if the first thing you do is go in and try to get them to make an exception for you, then you are likely to be labeled a troublemaker or someone who is a special snowflake, difficult to work with person. This is never in your best interests. It is very hard to undo a bad early impression. It is better to adapt to the new tool even if it temporarily slows you down.
In the future if using a particular tool is important to you, then only accept jobs that use that tool or allow the freedom to choose what you want. Even then you may have to adapt later if things change at that company.
