3 ms·

I generally ask people to all use the same tools so that they can interract on each other's machine, and so that the code is all looking the same (unless someon

I generally ask people to all use the same tools so that they can interract on each other's machine, and so that the code is all looking the same (unless someone is trying a new tool, of course). Development is about collaboration and thinking, it's not about typing fast or other time sensitive things. But i explain all this at the interview, so that candidates can determine themselve before accepting a job. Switching to linux would emcompass convincing the whole team.

capisce 13y ago
On the other hand, I see a developer's tools as an extension of his or her mind. Enforcing that everyone uses the same tools seems like a great way to encourage hive mind thinking. Especially proprietary tools that can not be automated or extended is something you should be wary of pushing onto for example a bash and vim wielding programmer, unless your business has no need for major productivity gains to grow or to sustain itself.
- nraynaud 13y ago
  I don't encourage hive mind, by other means. The proprietary tools I recently used where automatable with either apple script system or in java for jetbrain product, but generaly we would do a lot of command line automation because we are more proficient in that. And I try to push products designed for their users instead of designed for their licence or their developers to my product team. But also i leave the freedom to my team to change the tools, every wednesday, we can change some tools, for the whole team.
7Figures2Commas 13y ago
> Development is about collaboration... It some cases development might require or benefit from the collaboration between more than one developer, but I think it's quite a stretch to write "Development is about collaboration." There does exist successful software and applications written by a single developer.
- nraynaud 13y ago
  It's totally true, in those rare cases a team leader would not be there and the whole discussion about hiring developers is completely irrelevant, and nobody is really there to check the tools. But I tend to bend the world around me my way: team work, emphasis on innovation, more or less agile, continuous deployment, don't be afraid of change, try to keeep the code clean etc. By being clear during the interview, I give everybody the opportunity to make their mind about each other. Not everybody is welcomed in my team, and my style is not welcomed everywhere.
georgemcbay 13y ago
I currently work at a place that is mostly Macs and I use a Thinkpad. 3 of us are working on the same Android app and one of us uses Eclipse with stock ADT, one of us uses vi and ant to build and I currently use Android Studio (was previously using Sublime Text and ant to build). I've worked at other places on other types of software in similar situations where each dev may have had a very different setup, and in my experience while this may introduce a bit of one-time hardship at the very beginning of a project, it actually leads to a much better and robust product later because there tend to be issues with the code or overall process that are hidden from you (but can still bite you) in a homogeneous environment that become extremely obvious quickly in a heterogeneous environment. But to each their own. As long as you're upfront about your one-size-fits-all process I can easily avoid working for you!

capisce 13y ago

On the other hand, I see a developer's tools as an extension of his or her mind. Enforcing that everyone uses the same tools seems like a great way to encourage hive mind thinking. Especially proprietary tools that can not be automated or extended is something you should be wary of pushing onto for example a bash and vim wielding programmer, unless your business has no need for major productivity gains to grow or to sustain itself.

nraynaud 13y ago
I don't encourage hive mind, by other means. The proprietary tools I recently used where automatable with either apple script system or in java for jetbrain product, but generaly we would do a lot of command line automation because we are more proficient in that. And I try to push products designed for their users instead of designed for their licence or their developers to my product team. But also i leave the freedom to my team to change the tools, every wednesday, we can change some tools, for the whole team.

7Figures2Commas 13y ago

> Development is about collaboration... It some cases development might require or benefit from the collaboration between more than one developer, but I think it's quite a stretch to write "Development is about collaboration." There does exist successful software and applications written by a single developer.

nraynaud 13y ago
It's totally true, in those rare cases a team leader would not be there and the whole discussion about hiring developers is completely irrelevant, and nobody is really there to check the tools. But I tend to bend the world around me my way: team work, emphasis on innovation, more or less agile, continuous deployment, don't be afraid of change, try to keeep the code clean etc. By being clear during the interview, I give everybody the opportunity to make their mind about each other. Not everybody is welcomed in my team, and my style is not welcomed everywhere.

georgemcbay 13y ago

I currently work at a place that is mostly Macs and I use a Thinkpad. 3 of us are working on the same Android app and one of us uses Eclipse with stock ADT, one of us uses vi and ant to build and I currently use Android Studio (was previously using Sublime Text and ant to build). I've worked at other places on other types of software in similar situations where each dev may have had a very different setup, and in my experience while this may introduce a bit of one-time hardship at the very beginning of a project, it actually leads to a much better and robust product later because there tend to be issues with the code or overall process that are hidden from you (but can still bite you) in a homogeneous environment that become extremely obvious quickly in a heterogeneous environment. But to each their own. As long as you're upfront about your one-size-fits-all process I can easily avoid working for you!