One IDE to Rule them All?(programmers.stackexchange.com)
programmers.stackexchange.com
One IDE to Rule them All?
http://programmers.stackexchange.com/questions/140264/one-ide-to-rule-them-all
6 comments
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.
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.
"My company is mandating that everyone use vim and make"
And still see it as a valid request of an employer.
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.
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.
It's completely and totally within the rights of an employer to demand and mandate the usage of any tool. It's usually not a problem when there's a small, single-digit number of programmers, but once you reach a certain number, mandating procedures, code-conventions, style, tools, even the machine you work on to guarantee as little difference between developers becomes a necessity.
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.
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.
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.
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".
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.
Sounds like you just need to have a well defined style guide rather than trying to micromanage developer habits.
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.
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).
Enforcing formatting is good policy, and pre-installing a common editor on all workstations is certainly advisable; but enforcing the personal use a certain editor is like forcing a writer to use the editor's favorite pen, no matter how uncomfortable or cramped the writer's hands become.
From the answers:
From the answers:
Yes, it's a bit of a red flag that management considers itself a better judge
of which tools you would be more efficient with than you are.It's absolutely different from a writer, I'm asking them to behave like a collaborative engineering team, not like a tortured drunk guy alone in a under lit room.
No 2 IDE can produce the same formatting, can store the dependencies and the running targets the same way, have the same shortcuts, etc. Therefore, you can't collaborate efficiently on the same machine.
Moreover, the only rule is that everybody uses the same, the majority can vote. Our last IDE change was initiated by a team member and multiplied the price per developer by 3
No 2 IDE can produce the same formatting, can store the dependencies and the running targets the same way, have the same shortcuts, etc. Therefore, you can't collaborate efficiently on the same machine.
Moreover, the only rule is that everybody uses the same, the majority can vote. Our last IDE change was initiated by a team member and multiplied the price per developer by 3
But there is a huge difference between enforcing style rules and enforcing which editors people use.
You can have different team members using different editors, but with the same style rules - and with a style checker that runs on commit/post-edit to verify the common rules are adhered to.
Enforcing which editors each team member must use to do his/her development is a form of management deciding it knows which tools each developer will be more efficient with than the developer does. It's pointless.
You can have different team members using different editors, but with the same style rules - and with a style checker that runs on commit/post-edit to verify the common rules are adhered to.
Enforcing which editors each team member must use to do his/her development is a form of management deciding it knows which tools each developer will be more efficient with than the developer does. It's pointless.
no, I can't, because I don't want to configure the IDE and then the style checker. And the the commit is rejected where it shouldn't have been because it could have been well formatted from the beginning and nobody cares about that because the editor does it for us (it's not totally true, since it doesn't remove useless endlines)
As far as I know different editors can't be made to produce the exact same code on automatic reformatting. And enforcing code style still doesn't help people switching keyboard, reading code or stuff like that. It's a team I'm building, not managing insulated people.
I enforce that everybody uses the same editor, if I find myself in a team where the majority votes for emacs, they'll just use emacs (and I guess I'll resign). Our last change was initiated by a team member.
As far as I know different editors can't be made to produce the exact same code on automatic reformatting. And enforcing code style still doesn't help people switching keyboard, reading code or stuff like that. It's a team I'm building, not managing insulated people.
I enforce that everybody uses the same editor, if I find myself in a team where the majority votes for emacs, they'll just use emacs (and I guess I'll resign). Our last change was initiated by a team member.
Why so you need to configure someone else's IDE? Just produce a style checker ruleset (like Checkstyle) and tell team members they can use a non-standard editor if they want, but that any output that doesn't match the style checker will be rejected.
It seems to me that if you never allow anyone to use a different editor than you close your team off to the possibility of finding improved toolsets or workflows.
It seems to me that if you never allow anyone to use a different editor than you close your team off to the possibility of finding improved toolsets or workflows.
I don't prevent people from trying stuff, I just don't ant them to keep with a different IDE. They try it for a while, after that either we try it with the rest of the team an decide to adopt it all together or we reject it.
I don't know what is the problem. We just adopted New Relic with this method, removing pingdom + a bunch of custom stuff after someone proposed it, tried it, extended the perimeter of the trial and then it was good to go. We delete the other stuff, and it's our new common tool.
We did the same with our deployment scripts, where a guy started in his corner, but after a while we decided to go whith it and now it's out of question to use any other way to deploy an instance unless we do a collective decision to change.
Concerning the workflow, one guy tried a new testing tool, it appeared good, we now use it. That's it, everybody uses the smae testing framework, the same monitoring tool, the same IDE, the same deployment system. And they can do trial on the side, we'll extend the trial if the first guy testing the tool thinks it's a good stuff for the team and then we'll decide together to adopt it or not. Mostly if the tool is not deemed good the first time, the others won't really ear about it, and if it's good and the extended trial is good, I'll ask we delete something else if possible, try to "trade" one tool/library for another and limiting the entropy.
I don't know what is the problem. We just adopted New Relic with this method, removing pingdom + a bunch of custom stuff after someone proposed it, tried it, extended the perimeter of the trial and then it was good to go. We delete the other stuff, and it's our new common tool.
We did the same with our deployment scripts, where a guy started in his corner, but after a while we decided to go whith it and now it's out of question to use any other way to deploy an instance unless we do a collective decision to change.
Concerning the workflow, one guy tried a new testing tool, it appeared good, we now use it. That's it, everybody uses the smae testing framework, the same monitoring tool, the same IDE, the same deployment system. And they can do trial on the side, we'll extend the trial if the first guy testing the tool thinks it's a good stuff for the team and then we'll decide together to adopt it or not. Mostly if the tool is not deemed good the first time, the others won't really ear about it, and if it's good and the extended trial is good, I'll ask we delete something else if possible, try to "trade" one tool/library for another and limiting the entropy.
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.
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.