Note: This document is work-in-progress. Please don’t publish it on news sites, or otherwise link to it in public without the author’s permission. Private linking is acceptable.

The Perfect IT Workplace

This work is licensed under the Creative Commons Attribution 2.5 License (or at your option any greater version of it).

Revision History
Revision 184130 April 2008shlomif
Forked the template from a previous work and began working on it.
Revision 576202 July 2008shlomif
The first revision as publicised on Reddit.com, by pkrumins.
Revision 597726 July 2008shlomif
Forked the revision 1 version and started working on revision 2. Fixed many typos. Added the motivation for automated tests. Added more text to the design section.
Revision 603602 August 2008shlomif
Started adding the essential tools section with more information, instead of just the knowledge in the Ether.
Revision 604804 August 2008shlomif
Added the “Building, Configuration and Packaging” section.
Revision 620114 November 2008shlomif
Added the Maturity, Mind-share and Distance from the Mainstream sub-section to “Choosing a Technology”.
Revision 2319 (svn)27 February 2009shlomif
Added missing id attributes to footnotes, so they won’t be randomly generated.

Table of Contents

Introduction
Sources from Which the Advice was Taken
The Elements of a Perfect Workplace
Hire the Best Developers
Openness
Great Working Conditions
Kitchen
Comfortable Offices
The Best Tools That Money Can Buy
Sane Working Hours
Location, Location, Location
A Lot of Paid Vacation
Avoid Over-Strict Firewalls
About the Salary
Conditions: Conclusion
Pair Programming
Give Your Employees the Freedom to Do What They Want
Phrase Your Job Ads in a Unique and Smart Way
Read a Lot of Software Management Material
Listen to Your Developers
Software Engineering Best Practices
Functional Specs
Automated Tests
Design and Planning
Refactoring
Software Engineering Methods to Avoid
Maintaining Two Codebases
Don’t Over-Specialise
Listen to Your Customers or Users
“Good Poets Borrow. Great Poets Steal.”
Study Psychology
Read Success and Failure Stories
Essential Organisational Software to Have
A Wiki to Prevent the “Knowledge in the Ether” Anti-Pattern
A Bug-Tracker
Version Control Software
Building, Configuration and Packaging
Choose Your Technology Carefully
Is it Open-source and/or Portable?
Expect some Unexpected Problems
The Technology’s Power
Habits
Reliability and Reputation
Maturity, Mindshare and Distance from the Mainstream
Case Study
Provide an Excellent Customer Support
Weekly Reports and Other Ways to Keep Track of Your Employees
Conclusion
Thanks

Introduction

I originally wrote “The End of Info-Tech Slavery” a few years ago, shortly after I was fired from a job I liked and for which I worked about three months. Some people who commented on the article found it of good value. However many people who commented on it have voiced some criticism.

One of the comments I received said that I kept giving bad examples for conditions I disliked from previous workplaces, instead of positive elements I would have liked to see or have seen. As much as I like liquidating negatives, I agree that I should also mention some good things that a workplace needs to adopt.

Another commenter told me in private, that he felt that the “End of IT Slavery” and other essays of mine reflected the fact that I had a “primadonna attitude” instead of a more positive “team-player” attitude. While this may be deduced from my “The End of IT Slavery”, I found that as a tech worker, I tended to just get my job done as I told, try to be as productive as I can be, try to adjust to the surroundings, and even be a little of what Israelis call “rosh qatan” (= “small-head”)

I can see why people would think so after reading the “End of IT Slavery”. However, my intention in the article was to guide employers (and employees) as to how to best treat their employees, and give them good conditions, so they’ll be happier and more productive. Going over the original article, I can see that I indeed had a very ranting tone, and had given bad examples for what not to do, exclusively.

So this time, I’m going to try again and hopefully be more successful. This article aims to cover the elements that great programmers would love to see in a perfect workplace. By implementing as many of them as possible, or at least giving them a serious thought, you can make such potential employees want to work for you, love to work for you, want to stay, and be happy as long as they are working for you. Furthermore, you will know better than to irrationally fire perfectly good employees.

I’m not trying to be original in this article, because an essayist (or any kind of artist) does not get credit for coming up with perfectly original concepts or ideas (as I note later in a different context). What I’m trying to do is summarise everything I’ve learned, judged and concluded, so far, based on the many sources I’ve read. I may be just a dwarf standing on the shoulders of giant, but hopefully I’ll still be able to see farther than most.

There is a lot of material on good software management out there, and not everybody took the time to read all the important one. This material can sometimes be contradictory, and sometimes false. Nevertheless, I decided to integrate it here into what I’ve perceived and concluded to be the best choices.

Sources from Which the Advice was Taken

This is a non-exhaustive list of major sources of influence.

  1. Eric S. Raymond’s Homepage and especially his the Cathedral and the Bazaar series and his “How to become a Hacker” document.

  2. The wonderful Joel on Software site by Joel Spolsky.

  3. Paul Graham’s essays - tend to be interesting, but often suffering from some problems.

  4. Extreme Programming - seems a bit too rigorous, but still has many good ideas.

  5. Damian Conway’s excellent book Perl Best Practices