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 working on it.
Revision 576202 July 2008shlomif
The first revision as publicised on, by pkrumins.
Revision 2319 (svn)27 February 2009shlomif
Added missing id=""'s to footnotes, so they won't be randomly generated.

Table of Contents

Sources from Which the Advice was Taken
The Elements of a Perfect Workplace
Hire the Best Developers
Great Working Conditions
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
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
Avoiding "Knowledge in the Ether"
Choose Your Technology Carefully
Is it Open-source and/or Portable?
Expect some Unexpected Problems
The Technology's Power
Reliability and Reputation
Case Study


I originally wrote "The End of Info-Tech Slavery" about a year 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. Another commentator 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.

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 gave 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