6 ms·

And it may be that what they want is a Ruby/Python developer where the stack happens to run on Linux. Deployments are most likely to be to Linux environments (

And it may be that what they want is a Ruby/Python developer where the stack happens to run on Linux. Deployments are most likely to be to Linux environments (eg AWS). Consequently "Linux" in job descriptions really means a familiarity with the command line, and a propensity to build smaller components that can be run together. We do all our development on Linux with one or two developers using Mac. I expressly forbid doing any development on Windows even though everything could run on Windows. This is purely because it takes longer, has more hassles, the tools aren't better (eg valgrind), awful package/dependency management, and it doesn't match deployment environments.

xradionut 14y ago
Obvious developer is being Obvious. If you are developing for Linux deployment, it doesn't make sense to develop on Windows. This is a no brainer. Likewise if I was to develop for IIS/SQL Server I wouldn't do so using my Linux environment.
- dagw 14y ago
  I develop for Linux deployment on Windows. Why? Because I also develop other things and use other tools that are Windows based, and its easier to have just one setup rather than changing machines or dual booting all the time. Windows with a Linux server in a VM is a perfectly fine solution, and unless your Linux dev machine runs exactly the same distro and config as your production server, you're going to need a separate VM or dev server to test on anyway.
  - walshemj 14y ago
    Your Dev system should be the same as your live server (same distribution and ideally the same hardware) other wise your just a hobby programmer. Back in the day at BT we even brought all our systems (Dev, Test and Live at the same time so we had identical systems from the same production run from sun.
    - dagw 14y ago
      Well I guess that makes me a hobby programmer. Half the time I don't know what server the code will be deployed on when I start coding. 9 times out of 10 the hardware is completely out of my control (often it's whatever cloud server provider X decides to spin up that week, which can often be something completely different from what they decided to spin up last week). Obviously making sure your test environment is as close to possible as your production environment is important, but I don't get too bothered about making sure the machine my text editor runs on is identical to the machine I will end up deploying to. But then again, I'm just a hobby programmer.
      - jimwhitson 14y ago
        By the GP's definition there are a lot of us hobby programmers. I used to write code to run on all kinds of weird servers, SPARCs, IBM POWER kit, ARM dev boards and so on - I hate to think how a non-hobby programmer would have approached that job...
      - walshemj 14y ago
        What you use as a dev client is not the point its the dev and test hardware the application running on that needs to be as close (ideally identical) to live as possible. And the random approach to hardware that clouds use well maybe thats why they have such poor up time when compered to the carrier grade gear a telco uses.
    - jrabone 14y ago
      Rubbish. Spotting the hobby programmer is easy - they're the ones hardcoding "/" or "\\" instead of File.SEPERATOR. At Amazon most of the teams I worked with developed our entire Java service stack on Windows, and shipped on Linux - because the Windows tooling was just better. To this day Eclipse on Linux needs endless tweaking to fit the same content to the same screen resolution, and the double monitor support back then was hilariously poor.
  - rogerbinns 14y ago
    An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is in the path). That script had to be runnable by outsiders so I had to make it run on Windows too and had to do all sorts of grovelling through the registry (it is possible to have Java installed but not registered for jar files, and we need to supply parameters to the java command). Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards. When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile. Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM. It all adds up to a death by a 1,000 cuts.
    - asveikau 14y ago
      If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
      - rogerbinns 14y ago
        > If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).
- snarfy 14y ago
  I dunno, it works for me. I can build my web service app in VisualStudio on Windows and run+debug it, then once it's working, copy the folder over to linux. Linux is setup with mono fastcgi + nginx + servicestack.net. I don't even have to do anything on linux after the copy is done - just refresh the web page.
jrogers65 14y ago
The cost of your developers using environments that they aren't adapted to is higher than the cost of dealing with inconsistencies introduced by the fact that they use Windows. It's more of a hassle for you, sure - but it's not your needs which matter in this context. I say that from the experience of having worked with people with a similar mind-set. The job of a manager is not to bend the environment to his needs but to aid the people that do the work.
- rogerbinns 14y ago
  The problem is that platform choices impact other developers. If for example the developers are predominantly using a Windows software stack and tools and Linux user comes along then there is a burden to make things portable (eg a deployment or analysis script). So who does the effort for that portability? Are all the Windows developers also supposed to add it (ie adapt to another platform - Linux) or is the Linux developer supposed to do so (ie adapt to another platform - Windows)? Our situation is the other way around where deployment is to Linux (AWS/AppEngine) and there are several internal tools that work seamlessly on Linux and Mac. Having to add conditionals all over the place for Windows (not to mention the additional testing) is not free. The new developers can adapt to Linux or they aren't very good developers. (Note we make it abundantly clear that we use Linux and Mac for development in our job ads.)
  - jrogers65 14y ago
    In my opinion, it would be better to create an OS abstraction layer for the application so that conditionals do not have to be added everywhere and people are able to use whatever tools they are comfortable with.

xradionut 14y ago

Obvious developer is being Obvious. If you are developing for Linux deployment, it doesn't make sense to develop on Windows. This is a no brainer. Likewise if I was to develop for IIS/SQL Server I wouldn't do so using my Linux environment.

dagw 14y ago
I develop for Linux deployment on Windows. Why? Because I also develop other things and use other tools that are Windows based, and its easier to have just one setup rather than changing machines or dual booting all the time. Windows with a Linux server in a VM is a perfectly fine solution, and unless your Linux dev machine runs exactly the same distro and config as your production server, you're going to need a separate VM or dev server to test on anyway.
- walshemj 14y ago
  Your Dev system should be the same as your live server (same distribution and ideally the same hardware) other wise your just a hobby programmer. Back in the day at BT we even brought all our systems (Dev, Test and Live at the same time so we had identical systems from the same production run from sun.
  - dagw 14y ago
    Well I guess that makes me a hobby programmer. Half the time I don't know what server the code will be deployed on when I start coding. 9 times out of 10 the hardware is completely out of my control (often it's whatever cloud server provider X decides to spin up that week, which can often be something completely different from what they decided to spin up last week). Obviously making sure your test environment is as close to possible as your production environment is important, but I don't get too bothered about making sure the machine my text editor runs on is identical to the machine I will end up deploying to. But then again, I'm just a hobby programmer.
    - jimwhitson 14y ago
      By the GP's definition there are a lot of us hobby programmers. I used to write code to run on all kinds of weird servers, SPARCs, IBM POWER kit, ARM dev boards and so on - I hate to think how a non-hobby programmer would have approached that job...
    - walshemj 14y ago
      What you use as a dev client is not the point its the dev and test hardware the application running on that needs to be as close (ideally identical) to live as possible. And the random approach to hardware that clouds use well maybe thats why they have such poor up time when compered to the carrier grade gear a telco uses.
  - jrabone 14y ago
    Rubbish. Spotting the hobby programmer is easy - they're the ones hardcoding "/" or "\\" instead of File.SEPERATOR. At Amazon most of the teams I worked with developed our entire Java service stack on Windows, and shipped on Linux - because the Windows tooling was just better. To this day Eclipse on Linux needs endless tweaking to fit the same content to the same screen resolution, and the double monitor support back then was hilariously poor.
- rogerbinns 14y ago
  An example of wasted productivity on Windows is that we have several utility scripts. One of them needs to run a jar which is trivial on Linux and Mac (java is in the path). That script had to be runnable by outsiders so I had to make it run on Windows too and had to do all sorts of grovelling through the registry (it is possible to have Java installed but not registered for jar files, and we need to supply parameters to the java command). Some status information is saved in an ini file. On Linux and Mac I make it hidden by having a dot prefix in the filename. To make it hidden on Windows I had to use a Win32 call (SetFileAttributes) and wrap the access in a call to unhide it and then rehide it afterwards. When the tool finds problems it can open the browser on a local copy of the documentation shipped with the tool. However opening web pages with anchors has the anchor ignored on Windows making things that much more hostile. Those were just the waste of time on one utility, not to mention all the testing to find them. Multiply by everything else and it just isn't worth it. Some of our stuff does intensive file I/O. This is a lot slower in a VM. It all adds up to a death by a 1,000 cuts.
  - asveikau 14y ago
    If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command. Most of this is just "it's different, wah." Maybe it's not so bad to people who are used to it the other way. Maybe to some the dotfiles are the weird thing.
    - rogerbinns 14y ago
      > If you wrote an application that does nothing but call SetFileAttributes I suspect you've not heard of the attrib command I didn't explain clearly enough. The python script uses an ini style file to remember one value between runs. On Mac/Linux I can hide that file purely by putting a dot in front of the name. On Windows I hide it by changing attributes to hidden, but have to unhide for the portion of the script that access the file. The attrib command isn't relevant in this case. (And yes I've heard of it.) Just to make things clearer, these are the non-mobile operating systems I've used beyond the superficial as well as doing software development on the vast majority: Prodos, MSDOS (3 through 6), Windows 2, Windows 3 (including real mode), Windows for Workgroups, Windows NT, Terminal Server, 2000, XP, Vista and 7, Pyramid Unix, SunOS, SVR4 (several derivatives and flavours), Linux, and MacOS. I've used several more but deeply enough to make the list (hello GEM, OS/2, AS/400, BeOS, a zillion Unix flavours ...).
snarfy 14y ago
I dunno, it works for me. I can build my web service app in VisualStudio on Windows and run+debug it, then once it's working, copy the folder over to linux. Linux is setup with mono fastcgi + nginx + servicestack.net. I don't even have to do anything on linux after the copy is done - just refresh the web page.

jrogers65 14y ago

The cost of your developers using environments that they aren't adapted to is higher than the cost of dealing with inconsistencies introduced by the fact that they use Windows. It's more of a hassle for you, sure - but it's not your needs which matter in this context. I say that from the experience of having worked with people with a similar mind-set. The job of a manager is not to bend the environment to his needs but to aid the people that do the work.

rogerbinns 14y ago
The problem is that platform choices impact other developers. If for example the developers are predominantly using a Windows software stack and tools and Linux user comes along then there is a burden to make things portable (eg a deployment or analysis script). So who does the effort for that portability? Are all the Windows developers also supposed to add it (ie adapt to another platform - Linux) or is the Linux developer supposed to do so (ie adapt to another platform - Windows)? Our situation is the other way around where deployment is to Linux (AWS/AppEngine) and there are several internal tools that work seamlessly on Linux and Mac. Having to add conditionals all over the place for Windows (not to mention the additional testing) is not free. The new developers can adapt to Linux or they aren't very good developers. (Note we make it abundantly clear that we use Linux and Mac for development in our job ads.)
- jrogers65 14y ago
  In my opinion, it would be better to create an OS abstraction layer for the application so that conditionals do not have to be added everywhere and people are able to use whatever tools they are comfortable with.