Iyfjky

Question

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.

What do they really care about? Presumably it's the code format. If you don't break that I don't think they will even know what you use. — Jan 8 '16 at 6:54
A real vim power user is arguably much faster than a Sublime power user. — Jan 8 '16 at 14:24
If you're allowed to install sublime plugins, you can apparently add vi style editing. sublimetext.com/docs/2/vintage.html (Not an endorsement since I've never used it, but something I quickly found via Google.) — Jan 8 '16 at 15:05
Having everyone use the same tools - ESPECIALLY editors - means that it's easy to help each other by leaning over someone's shoulder, or passing the keyboard back and forth. This can be a very valuable in some situations, and is seriously hindered if one developer uses a different toolset. — Jan 8 '16 at 15:42
I don't quite get why this is on hold. In software there are disagreements about tooling quite a bit, from new guy wanting to use the newest and shiniest to with someone wanting to use "what they know" etc. Knowing when to push for tooling changes to increase developer productivity vs when to back off is important. — Jan 9 '16 at 20:57

Patricia Shanahan 16.2k53256 · Answer 1 · 2016-01-08 09:59:50Z

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.

Comments are not for extended discussion; this conversation has been moved to chat. — Jan 8 '16 at 21:35
+1 for pointing out that this is one of the fastest changing industries in the World, my first was 'Basic' on a Commodore 64, not a lot of use these days. — Jan 9 '16 at 8:14

score 25 · Answer 2 · 2016-01-08 18:54:26Z

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:

Give their tool a chance

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.

Use your tool anyway

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.

TrueDub 3,8181731 · Answer 3 · 2016-01-08 10:03:01Z

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.

++ for tooling agnostic processes & builds.
â€“Â ThatGuy
Jan 9 '16 at 12:03 — Jan 9 '16 at 12:03

user45269 · Answer 4 · 2016-01-08 15:33:52Z

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.)

Wayne Werner 64059 · Answer 5 · 2016-01-08 15:59:14Z

TL;DR

Learn to use the tool(s) they provide

When you learn all there is to know, chances are you will find significant friction, so use your old workflow

Be ready to bring out the "standard" workflow when getting/giving assistance.

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>.}}

On behalf of power (Vim/Tmux)

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 behalf of standards

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.

It's nothing personal

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.

Lilienthalâ™¦ 53.9k36183218 · Answer 6 · 2016-01-08 08:52:01Z

Short Answer

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.

Long Answer

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.

I've edited your post to drop the incorrect use of the blockquote syntax and instead add titles for the Short and Long answer. Your phrasing is a bit confusing though so it would benefit from some copyediting. — Jan 8 '16 at 8:53
@Lilienthal - Thanks for formatting answer. I will take care next time :) — Jan 8 '16 at 8:54

user8365 · Answer 7 · 2016-01-08 14:38:54Z

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.

score 1 · Answer 8 · 2016-01-08 20:52:07Z

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.

Then you are very lucky as there are plenty of companies out there that will only allow approved software (for security and regulation issues) and they will only allow a company license (there can be issues using a personal license in a business environment). When it comes right down to it where you work has the final say in what software and hardware you use. — Jan 8 '16 at 19:31
@JoeW Yes, it does depend on company culture but even now, when I'm working under very strict security policy, I was still allowed to use all my tools. The company even bought me an Office license when I offered to buy my own to avoid having to use Google Docs. (I use both Office & Docs now, depending on situation.) — Jan 8 '16 at 20:42
It all depends on the policies and the reasons for them. I have been at places where they will say no if it is not on the approved software list because there are legal/contractual restrictions on what software can be approved for use. — Jan 8 '16 at 20:50
You're right, at the end it all depends on the specific company - this is why I recommended asking nicely. — Jan 8 '16 at 20:51

HLGEM 133k25226489 · Answer 9 · 2016-01-08 15:18:38Z

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.

score -1 · Answer 10 · 2016-01-08 14:47:05Z

Downvotes or not, it's not a good investment for your employer or yourself.

So you're asking your employer to invest in tuning vi to match Sublime, and dealing with any ongoing maintenance from the change? And to take risk that some unknown side-effect will cause a problem that's hard to find (or at least annoying)? What do they get for the investment? And to support a different workflow than Sublime's integrated git, and is that identical to the command line git you'd need? And what are you using for linting? And are you more productive a month from now if you switch to a far more modern tool, even if you take a short-term hit?

You have a chance to get paid to learn how to use a newer, modern tool with many advantages. Even if you end up not liking it, it's an opportunity. Make the switch, it's the job.

BTW, suggest they switch to atom. :-)

I am no vim expert, but many vim/emacs experts are very good at integrating different tool chains into their IDEs. I have seen an emacs terminal as fully featured as a true IDE, with test integration, linting, source control ect. Don't immediately dismiss that which you do not understand. The OP could be able to mimic all the Sublime features his team uses. — Jan 8 '16 at 14:26
@adeady Even if he can, the point still stands. And as I stated, he's asking the company to take the risk that his integration won't cause any headaches. Eclipse uses a different git than command line, and that has caused massive headaches. Why run the science experiment? Why is that a good investment for the company or the OP? Not all the plugins have command-line versions that are tunable identically. The go language even addresses this by asserting a single correct format regardless of tools. — Jan 8 '16 at 14:46
@adeady - but the company already has a standard suite in Sublime and selection of plugins - and that company would not consider the time needed to configure vim to do what their current standard suite worth the effort. — Jan 8 '16 at 14:48
@HorusKol when I have wanted a different setup I take the time myself, on an evening or a weekend, to do it because I respect that the company is not paying me to setup my special snowflake configuration. — Jan 8 '16 at 17:42

Patricia Shanahan 16.2k53256 · Answer 11 · 2016-01-08 09:59:50Z

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.

Comments are not for extended discussion; this conversation has been moved to chat. — Jan 8 '16 at 21:35
+1 for pointing out that this is one of the fastest changing industries in the World, my first was 'Basic' on a Commodore 64, not a lot of use these days. — Jan 9 '16 at 8:14

score 25 · Answer 12 · 2016-01-08 18:54:26Z

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:

Give their tool a chance

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.

Use your tool anyway

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.

TrueDub 3,8181731 · Answer 13 · 2016-01-08 10:03:01Z

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.

++ for tooling agnostic processes & builds.
â€“Â ThatGuy
Jan 9 '16 at 12:03 — Jan 9 '16 at 12:03

user45269 · Answer 14 · 2016-01-08 15:33:52Z

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.)

Wayne Werner 64059 · Answer 15 · 2016-01-08 15:59:14Z

TL;DR

Learn to use the tool(s) they provide

When you learn all there is to know, chances are you will find significant friction, so use your old workflow

Be ready to bring out the "standard" workflow when getting/giving assistance.

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>.}}

On behalf of power (Vim/Tmux)

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 behalf of standards

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.

It's nothing personal

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.

Lilienthalâ™¦ 53.9k36183218 · Answer 16 · 2016-01-08 08:52:01Z

Short Answer

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.

Long Answer

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.

I've edited your post to drop the incorrect use of the blockquote syntax and instead add titles for the Short and Long answer. Your phrasing is a bit confusing though so it would benefit from some copyediting. — Jan 8 '16 at 8:53
@Lilienthal - Thanks for formatting answer. I will take care next time :) — Jan 8 '16 at 8:54

user8365 · Answer 17 · 2016-01-08 14:38:54Z

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.

score 1 · Answer 18 · 2016-01-08 20:52:07Z

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.

Then you are very lucky as there are plenty of companies out there that will only allow approved software (for security and regulation issues) and they will only allow a company license (there can be issues using a personal license in a business environment). When it comes right down to it where you work has the final say in what software and hardware you use. — Jan 8 '16 at 19:31
@JoeW Yes, it does depend on company culture but even now, when I'm working under very strict security policy, I was still allowed to use all my tools. The company even bought me an Office license when I offered to buy my own to avoid having to use Google Docs. (I use both Office & Docs now, depending on situation.) — Jan 8 '16 at 20:42
It all depends on the policies and the reasons for them. I have been at places where they will say no if it is not on the approved software list because there are legal/contractual restrictions on what software can be approved for use. — Jan 8 '16 at 20:50
You're right, at the end it all depends on the specific company - this is why I recommended asking nicely. — Jan 8 '16 at 20:51

HLGEM 133k25226489 · Answer 19 · 2016-01-08 15:18:38Z

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.

score -1 · Answer 20 · 2016-01-08 14:47:05Z

Downvotes or not, it's not a good investment for your employer or yourself.

So you're asking your employer to invest in tuning vi to match Sublime, and dealing with any ongoing maintenance from the change? And to take risk that some unknown side-effect will cause a problem that's hard to find (or at least annoying)? What do they get for the investment? And to support a different workflow than Sublime's integrated git, and is that identical to the command line git you'd need? And what are you using for linting? And are you more productive a month from now if you switch to a far more modern tool, even if you take a short-term hit?

You have a chance to get paid to learn how to use a newer, modern tool with many advantages. Even if you end up not liking it, it's an opportunity. Make the switch, it's the job.

BTW, suggest they switch to atom. :-)

I am no vim expert, but many vim/emacs experts are very good at integrating different tool chains into their IDEs. I have seen an emacs terminal as fully featured as a true IDE, with test integration, linting, source control ect. Don't immediately dismiss that which you do not understand. The OP could be able to mimic all the Sublime features his team uses. — Jan 8 '16 at 14:26
@adeady Even if he can, the point still stands. And as I stated, he's asking the company to take the risk that his integration won't cause any headaches. Eclipse uses a different git than command line, and that has caused massive headaches. Why run the science experiment? Why is that a good investment for the company or the OP? Not all the plugins have command-line versions that are tunable identically. The go language even addresses this by asserting a single correct format regardless of tools. — Jan 8 '16 at 14:46
@adeady - but the company already has a standard suite in Sublime and selection of plugins - and that company would not consider the time needed to configure vim to do what their current standard suite worth the effort. — Jan 8 '16 at 14:48
@HorusKol when I have wanted a different setup I take the time myself, on an evening or a weekend, to do it because I respect that the company is not paying me to setup my special snowflake configuration. — Jan 8 '16 at 17:42

Category

Random preview

Arguing the use of a program that's not the company standard [closed]

closed as off-topic by gnat, The Wandering Dev Manager, Philipp, user9158, Joe Strazzere Jan 9 '16 at 18:03

closed as off-topic by gnat, The Wandering Dev Manager, Philipp, user9158, Joe Strazzere Jan 9 '16 at 18:03

closed as off-topic by gnat, The Wandering Dev Manager, Philipp, user9158, Joe Strazzere Jan 9 '16 at 18:03

closed as off-topic by gnat, The Wandering Dev Manager, Philipp, user9158, Joe Strazzere Jan 9 '16 at 18:03

10 Answers 10

Give their tool a chance

Use your tool anyway

TL;DR

On behalf of power (Vim/Tmux)

On behalf of standards

It's nothing personal

Short Answer

Long Answer

protected by Jane Sâ™¦ Jan 9 '16 at 3:32

10 Answers 10

10 Answers 10

Give their tool a chance

Use your tool anyway

Give their tool a chance

Use your tool anyway

Give their tool a chance

Use your tool anyway

Give their tool a chance

Use your tool anyway

TL;DR

On behalf of power (Vim/Tmux)

On behalf of standards

It's nothing personal

TL;DR

On behalf of power (Vim/Tmux)

On behalf of standards

It's nothing personal

TL;DR

On behalf of power (Vim/Tmux)

On behalf of standards

It's nothing personal

TL;DR

On behalf of power (Vim/Tmux)

On behalf of standards

It's nothing personal

Short Answer

Long Answer

Short Answer

Long Answer

Short Answer

Long Answer

Short Answer

Long Answer

protected by Jane Sâ™¦ Jan 9 '16 at 3:32

Comments

Post a Comment

Popular posts from this blog

What does second last employer means? [closed]

List of Gilmore Girls characters

Confectionery

10 Answers
10

10 Answers
10

10 Answers
10