Not How, But What

A happy developer is a productive developer. That fact should be obvious to everybody who interacts with a developer of any sort.

Developer happiness is affected by a lot of things. The work environment, the projects they are given, their managers, the flexibility of their schedules, and the quality of their tools. This last one is very important. If a developer doesn't like the tools they are using, it's a safe bet they won't be happy, and thus won't be as productive as they could be.
There's a long-standing so-called "religious war" in the development community as to which text editor is best. "Vim!!" screams one side, "Emacs!!!" screams the other, and nobody ever agrees, because each side is comfortable with their particular preference. If an emacs enthusiast were to be forced into using vim (or vice-versa), it's likely they would be unhappy.

But when it comes right down to it, we shouldn't care. And when I say "we", I'm actually talking about project managers, team leads, product managers, and executive officers. This isn't a group in which I usually include myself, but I've been reading some about project management, and I do have this rather prestigious title of CTO (of a three-person company). And this means I've been thinking a lot about how to manage projects, and how to manage developers.

It comes down to this: We should care more about the result, and less about the tools used to get there.

In the case of SlickText, as long as I get code in the GitHub repository that runs under LAMP, and does what it's supposed, to, I don't care how you got there.

As an example, we'll compare the software stack that I use to develop for SlickText, and the software stack that our CEO/Designer uses. First up, me:

• Windows 7
• git-bash to manage my local git repos
• SublimeText2 to edit code
• MySQL command line for running queries
• Chrome for primary browser

Now him:

• OSX
• Some git GUI that I don't remember the name of
• A few different text editors, from ST2, to Dreamweaver
• A MySQL GUI
• Firefox for primary browser

It's a completely different stack. I feel most comfortable using command-line interfaces, while he's most comfortable using GUI's. But it doesn't matter, because we both end up with a working result.

This is because the list of requirements is short. As long as the software works, and looks good, it doesn't matter how you got there. In contrast, Microsoft stack development tries to dictate the tools developers use on a daily basis. Visual Studio is required. Windows is required. It becomes significantly more difficult to manage projects and solutions if you aren't using these tools.

Yes, *AMP (whatever OS you want, plus Apache, MySQL, and PHP) still requires you have those processes running, but they're quiet about it. They sit in the background, and they'll do what you want when you ask them to. They're not in-your-face, heavy, singular, one-stop solutions like Visual Studio tries to be. They're modular, and can be swapped out if necessary; They're the what, and not the how.

I'd encourage more shops to embrace this. You have to dictate the what, but you shouldn't have to dictate the how. It will make for a happier developer, and a more productive environment.