Development Environments - Optimizing for Developer Happiness

The longer you practice something, the more you start identifying the really important stuff about it. One such thing is what makes you perform better and what hold you back. Being forced to use a tool for the job that you have no or little experience of will most likely hold you, your efficiency, focus and developer happiness back.

Development Environments

Development environments are one such thing. It is a core component of any project or setup. You spend countless of hours working in your dev environment. Mostly in some kind of IDE, maybe VIM (most people won't call that an IDE but I just might), Emacs, Sublime, Textmate, Visual Studio, Web Storm or some other tool.

Most of my web developer friends have their own favourite dev env to get the job done. They most likely know its shortcuts, having spent a lot of time with that one tool.

The ones who do not have their favourite environment are usually the ones who are commanded to work in a way that fits the project better. Heavy server side development or testing are two such things. In some projects you are bound to use a tool for the job, because the production environment is really specific or really closed. Like Microsoft related stuff for instance. Microsoft tend to decide a bunch of stuff for the developer just by being Microsoft and developing its closed platform.

But lets face it, its the 21:st century and the web has always been open. How long does it take for Microsoft to figure that out?

Hrm, anyway this post is about development environments and I'm not here to throw shit (swedish expression) at any platforms or environments whatsoever. I'm here to educate you how to become a better programmer.

Programmers - The Carpenters of The 21:st century?

In some ways that is true. We are responsible for infrastructure that will and do serve many many people with information and communication related services. And just like the carpenter, we too have our own set of tools. Mostly our own, but in many cases also a shared set of tools.

The build process for instance is usually shared, the deployment and the language(s) also. The documentation is also shared (even though in an open format). Like carpenters share drawings and scaffolding.

But just like the carpenter our own set of tools are really important to us. Any old crappy hammer is not getting the job done for me. I want to use the hammer that fits me the best, the one that I'm getting the job done with the best. And having someone telling you to use a certain tool for the job is like putting a sign on that someone's forhead saying "I don't trust your choice of tooling for this job". Are we that incompetent, really? I beg to differ.

Making it your own

As most setups mirrors the way you think and assist the way you do stuff, any dev environment will most likely be even more personalized. You launch stuff differently than your colleague, you move files in a different way and so on. You have found ways to accomplish things that really works good for you. Why is it that still, in some projects, you don't get to choose the tools that fits you the best? It is either your boss (that unfortunetaly in most cases does not work in the same way you do) or the platform that keeps you from doing that.

I'll tell you what; have her look at this: