

One IDE to Rule them All? - thelonecabbage
http://programmers.stackexchange.com/questions/140264/one-ide-to-rule-them-all

======
dasil003
I can accept that there are valid reasons to do this, but I couldn't work in a
shop like that. The bottom line is I invest in my tools, and a big part of my
career development is mastering standard unix tools. I don't expect to be
doing Rails work 10 years from now, but I'll definitely be using vim + bash
for the long haul.

------
dkhenry
This specific question is talking about Eclipse, and depending on the language
they are using it might be they are moving the build system to eclipse, so
they are mandating everyone use the tool. I think in the FOSS world we are a
little spoiled that we have options like what editor / build system / OS we
would like to use to develop on. I know there are a lot of shops that on day
one you are given access to Visual Studios and that's the last tool you will
use at that company for anything. So this isn't anything extraordinary that is
being asked of the employee. I know where I work we develop on remote system's
and while some people prefer to do a lot of upfront work in eclipse, when
testing on the production equipment your left with nothing but a command line.
So knowledge of at least one text line editor and gcc/make is fundamental for
anyone who wants to work with us. I could totally see someone coming in with
the complete opposite question.

"My company is mandating that everyone use vim and make"

And still see it as a valid request of an employer.

~~~
slowpoke
I think there's a very important line to be drawn between "require everyone to
know (the basics of) $tool" and "mandate that everyone use $tool". I think the
former _can_ be reasonable, if it's done both ways, ie everyone is required to
be somewhat familiar with the standard UNIX toolchain, but also with $IDE.
Then, the choice could be left to every member of the team what to use.

I think, however, it's a _huge_ mistake to take the second route. Myself, for
example, I could never be even remotely productive in an IDE. The moment I
open one, it feels _wrong_ , and my productivity as well as motivation drops
significantly. I just prefer vim + $tools for the language I am working with,
and it's highly unlikely that this will ever change. It's like trying to code
in a noisy, public place when I could be coding at my desk listening to my
favorite music.

Yes, this is partially an emotional reason. I _hate_ programs that throw tons
of information, menus and buttons at you, most of which are useless 98% of the
time. Furthermore, I hate programs that try to be a God Object and do
everything by themselves - I'm a stern advocate of modularity/interoperability
and the UNIX philosophy of writing programs that do _one_ thing, and do it
well.

But, to conclude this, I would fiercely disapprove forcing anyone to do it my
way as much as I would object to being forced into a different workflow
myself. I know I could never work for someone that does either.

------
Vitaly
Jungo (<http://jungo.com/>), a company where I first learned the "proper"
development process with code reviews etc, had instituted Vim as the company
wide editor. You _could_ choose something else if you still could work
reasonably in vim and mastered that "other" editor to a high degree, being
able to do x,y,z things with it. There was an actual document describing
required level of mastery ;)

Now, vim being one of the top productive environments (only probably be
contested by emacs), and the fact that we worked in C, so stags vim plugin
provided as much IDE-ness you could get anywhere else at the time (2000), I
think that was a very reasonable requirement. Eclipse? nah, not really, you
can pry VIM from my dead hands, definitely would not work at this place.

------
justncase80
Where I work people do a variety of things. We mostly use VS but I like to hit
F5 and have it do an incremental build and start the debugger but most
everyone else builds through a command line tool they created and have a VS
extension that automatically attaches to certain processes when you fire them
up. It's not uncommon at all for people who are not building via visual studio
to break the build for people who are not. The main checkin gate of course
does it the same as the command line people so it can be very ugly when
everyone is doing a variety of things. They can end up breaking your system
inadvertently.

------
nraynaud
that's what I did in my team, I want people to be able to sit next to each
other, I want shared formatting settings, I don't want them to do the
formatting by hands, and we have shared ownership of the code. You can only
change the formatting style after discussing it with the others. I want people
to remove my personal style after me, and I want to remove other's personal
style in the code. Adding dependencies or libraries has to be debatted and if
possible each new library should delete another one, the same with lines of
code. I call it "trying to control the entropy".

~~~
omarqureshi
So you don't do the formatting by hand, you configure your editor of choice to
do the work for you, assuming it is smart enough. If you have a group of
people that use the same editor they can share this information through a
developer wiki.

Sounds like you just need to have a well defined style guide rather than
trying to micromanage developer habits.

~~~
justncase80
What's also good is to establish a procedure to change the guidelines. It can
be a source of frustration to have some funky guideline that most of the team
doesn't like.

~~~
nraynaud
that's what the wednesday afternoon is for, changing our way of working. But
we sometimes do it before. We've a problem with our python formatting
guidelines, and I'll bring the issue tomorrow I think (we've to decide for
spaces or tabs and camelcase or underscore, since it's not our only language,
we've to arbitrage between a common rule for all our languages, or the usual
rule of each language).

------
user2459
This question lacks a lot of details, what tech is being used, how experienced
the team is, what the build and deploy environments are like, what level of
syntax consistency is needed for various reasons etc..

While many programmers are religious about their tool chain there are very
legitimate reasons for wanting a standardized dev environment especially with
an IDE that does things like syntax homogenization for you. Without more
details it's impossible to tell weather this specific individual case would
really benefit from the mandate in spite of upsetting the comfort of their
devs.

