The Perfect IT Workplace

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.