3 ms·

You don't really say what specific startup mentality you want to promote, but it seems to me a good generic startup mentality would include creativity and flexi

You don't really say what specific startup mentality you want to promote, but it seems to me a good generic startup mentality would include creativity and flexibility. That suggests the strategy: let each developer pick her own work rig. Give them a budget and maybe some suggestions, and let them spec and configure. If the developers you're bringing on board are any good, they'll have a favourite OS / IDE / byzantine .vimrc / etc. By letting them use it, you'll gain in productivity, and - particularly if they've previously worked for BigCos with silly tools restrictions - you'll gain a lot in morale. In my experience the thrill of "my employer bought me a shiny new Mac" wears off after a month, whereas "my employer encourages me to use the tools I'm best with" provides ongoing job satisfaction. Regarding the work/personal split, it sounds like what you're worried about is people wasting time at work, getting distracted, or otherwise being less productive. IMHO that's a motivation issue, not a hardware issue. Good developers with interesting problems to work on need to be reminded to eat, not trained to work harder.

dotBen 17y ago
The idea of "let the developer pick his own rig" had been mentioned by a lot of people - it's a fair point and has me reconsidering. My two thoughts are: Software Granted, the most important software is probably the IDE and those tend to be cross-OS (you can get eclipse or VIM to run on any OS) but you get issues on other software like Word. Suddenly that 5-seat license of Office for Mac doesn't accommodate my windows 7 developer so now I have to buy more licenses for him cos he uses Windows. And my Linux developer can't open the document in OpenOffice because it's using change tracking that his version doesn't support, etc. We also can't use stuff like SubEtherEdit or Coda for join-development, 2) Scaling a dev team's needs - if we're designing for scale then we might have 10 developers by the end of 2010. It becomes a nightmare when half of your dev team is on mac, thee on windows, one on debian/ubuntu, one on fedora, etc. But maybe these are not good enough reasons...
- dazzawazza 17y ago
  You need to so a simple calculation. Is the increased productivity/good will you will get by allowing developers to pick worth more then enforcing a heterogeneous environment and loosing some productivity. There are nearly always ways to work around compatibility differences. Sure you need word to talk to banks/accountants but most developers will be more then happy to work within a wiki. They have no need for Office (although sometimes Excel is worth having as a developer but open office will suffice for that) The cost of finding these alternative routes is minimal especially if you find good developers who will no doubt have experience in this sort of thing. In fact you might create a more nimble work space if developers are used to accommodating others and are more open to change. Good luck and be sure to let us all know how it goes :)
- etherael 17y ago
  1) Standardising on office software tools that are essential to the work of the dev team is in my humble opinion, a terrible idea. Yes, this means the microsoft stack, it tends to make people jump through hoops they're not fond of jumping through and in all instances I can think of it's actually better to be doing it some other way. 2) Standardising on anything that requires Mac OS means that you're pretty much stuck with people that are happy with Mac OS, and while admittedly that is not a small number of capable devs, others really hate it, and with very good reason. 3) Virtualisation can offset "essential" items in the standard operating environment, as long as they can run on platforms that can actually be virtualised, which is my Mac OS is such anathema here. 4) Having virtualised environments that are self contained working images of everything required to "be productive" takes the guess work out of "Does employee X have everything necessary" and drastically alleviates any crippling hardware issues, if all it takes to keep going is a virtualisation image and a new machine, disaster recovery becomes very trivial. 5) If you're really insistent on the whole "having everyone at the office" idea, you could even try trading out virtualisation for remote access to various environments. Once again, this is an Everything But Mac OS solution as OS X remote access is terribly bad compared to Windows or Linux based solutions (RDP / NX vs VNC) 6) That said, I think tying your team to their desks is a good way to annoy some people, long term if you decouple your team from the requirement to remain physically present you are a much more attractive opportunity than otherwise. Go distributed whenever possible, this means dev environments that have full deployments of whatever is necessary to work 100% offline. Git over subversion, make sure they have copies of databases that are required to actually run the code they're writing, etc etc etc. Long term goal should be that they can work from absolutely anywhere any time regardless of network access.

dotBen 17y ago

The idea of "let the developer pick his own rig" had been mentioned by a lot of people - it's a fair point and has me reconsidering. My two thoughts are: Software Granted, the most important software is probably the IDE and those tend to be cross-OS (you can get eclipse or VIM to run on any OS) but you get issues on other software like Word. Suddenly that 5-seat license of Office for Mac doesn't accommodate my windows 7 developer so now I have to buy more licenses for him cos he uses Windows. And my Linux developer can't open the document in OpenOffice because it's using change tracking that his version doesn't support, etc. We also can't use stuff like SubEtherEdit or Coda for join-development, 2) Scaling a dev team's needs - if we're designing for scale then we might have 10 developers by the end of 2010. It becomes a nightmare when half of your dev team is on mac, thee on windows, one on debian/ubuntu, one on fedora, etc. But maybe these are not good enough reasons...

dazzawazza 17y ago
You need to so a simple calculation. Is the increased productivity/good will you will get by allowing developers to pick worth more then enforcing a heterogeneous environment and loosing some productivity. There are nearly always ways to work around compatibility differences. Sure you need word to talk to banks/accountants but most developers will be more then happy to work within a wiki. They have no need for Office (although sometimes Excel is worth having as a developer but open office will suffice for that) The cost of finding these alternative routes is minimal especially if you find good developers who will no doubt have experience in this sort of thing. In fact you might create a more nimble work space if developers are used to accommodating others and are more open to change. Good luck and be sure to let us all know how it goes :)
etherael 17y ago
1) Standardising on office software tools that are essential to the work of the dev team is in my humble opinion, a terrible idea. Yes, this means the microsoft stack, it tends to make people jump through hoops they're not fond of jumping through and in all instances I can think of it's actually better to be doing it some other way. 2) Standardising on anything that requires Mac OS means that you're pretty much stuck with people that are happy with Mac OS, and while admittedly that is not a small number of capable devs, others really hate it, and with very good reason. 3) Virtualisation can offset "essential" items in the standard operating environment, as long as they can run on platforms that can actually be virtualised, which is my Mac OS is such anathema here. 4) Having virtualised environments that are self contained working images of everything required to "be productive" takes the guess work out of "Does employee X have everything necessary" and drastically alleviates any crippling hardware issues, if all it takes to keep going is a virtualisation image and a new machine, disaster recovery becomes very trivial. 5) If you're really insistent on the whole "having everyone at the office" idea, you could even try trading out virtualisation for remote access to various environments. Once again, this is an Everything But Mac OS solution as OS X remote access is terribly bad compared to Windows or Linux based solutions (RDP / NX vs VNC) 6) That said, I think tying your team to their desks is a good way to annoy some people, long term if you decouple your team from the requirement to remain physically present you are a much more attractive opportunity than otherwise. Go distributed whenever possible, this means dev environments that have full deployments of whatever is necessary to work 100% offline. Git over subversion, make sure they have copies of databases that are required to actually run the code they're writing, etc etc etc. Long term goal should be that they can work from absolutely anywhere any time regardless of network access.