<?xml version='1.0' encoding='utf-8' ?>
<?xml-stylesheet href="docbook-css/driver.css" type="text/css"?>
<!DOCTYPE article PUBLIC "-//OASIS//DTD DocBook XML V4.1.2//EN"
<title>The End of IT Slavery</title>
<!--Creative Commons License-->
This work is licensed under the <ulink url="http://creativecommons.org/licenses/by/2.5/">Creative Commons Attribution 2.5 License</ulink> (or at your option any greater version of it).
<date>5 June 2011</date>
Convert single and double quotes from ASCII to Unicode.
<date>1 May 2007</date>
Corrected many errors courtesy of a reviewer from the
<date>1 May 2007</date>
Corrected many things, added more bolds, and a few extra
text for completeness.
<date>1 May 2007</date>
Finished the article.
<date>17 April 2007</date>
Forked the template from a previous work and working on
This is the year 2007. This is Shlomi Fish, <emphasis role="bold">a good hacker</emphasis>,
is a good enthusiastic programmer, not necessarily a computer
intruder. And I have an announcement to make: <emphasis role="bold">I refuse to be an IT
slave</emphasis>. Moreover: if you want to employ people like me (and you
do), you should not give us only good conditions - <emphasis role="bold">you should give us
exceptional ones</emphasis>. Otherwise, we’ll probably leave, or be
fired, much to your misfortune.
<title>Some Facts about Working</title>
Do you honestly believe that if you employ someone for 9 hours,
you’ll get an average of close to 9 hours worth of code writing
a day? Probably not. Programmers tend to get distracted. They
find it hard to start coding. They need to think about what
they do. They need to take breaks for various things (like
drinking, eating, talking with their co-workers, etc.).
Furthermore, actual <emphasis role="bold">code writing is not the
most productive activity</emphasis>, as surprising as it
sounds. That’s because if one writes code exclusively for too
long, his mind will run in circles and he’ll lose his edge. And
there’s something that is even more productive than actually
That thing is <emphasis role="bold">revolutionary
decisions</emphasis>. Decisions that make
one more productive in the future, restructure one’s code (or one’s
text or whatever) in completely better ways, or allow the worker
to do something in a better way. The more such decisions he reaches,
the more productive he is, and the more value he is to his company.
He’s no longer just a code monkey - he’s
“Rosh Gadol” and innovative programmer</ulink>, who is of much
more value to the company than just someone who writes the code
that other people told him how it should behave.
If you want your programmers to be as productive as possible,
make sure you hire good programmers, who can reflect on what
they do, learn more, and who are enthusiastic about writing
code and like it. Only they can be of value to you.
Paul Graham called these developers
Hackers” in an essay he wrote</ulink>. As I said before,
I can testify I’m a good (or “above-average”) programmer (and
things</ulink>), but not that I’m a great one. That’s
because the baker cannot testify for the quality of his
dough. However, I know some people whom I can tell are great
Who are they? They are people who come up with wonderful
ideas. Who are interested in many things inside or outside
computers. They often can write a lot of good code, but often
their code is wonderfully ugly, but still very functional,
mostly bug-free, feature-rich and efficient.
<title>Re-use instead of Start-over</title>
Another important factor, that is not always present in
nascent programmers, is their desire or even necessity to
re-use code, however ugly it may seem. Eric Raymond
about it in “the Cathedral and the Bazaar”</ulink>:
So, did I immediately launch into a furious whirl of coding
up a brand-new POP3 client to compete with the existing
ones? Not on your life! I looked carefully at the POP
utilities I had in hand, asking myself “Which one is
closest to what I want?” Because:
2. Good programmers know
what to write. Great ones know what to rewrite (and reuse).
While I don’t claim to be a great programmer, I try to
imitate one. An important trait of the great ones is
constructive laziness. They know that you get an A not for
effort but for results, and that it’s almost always easier
to start from a good partial solution than from nothing at
Later on Joel Spolsky expanded on it in <ulink url="http://www.joelonsoftware.com/articles/fog0000000069.html">“Things You Should Never
Do, Part I”</ulink>, and
a dub dub”</ulink>, and it’s also been extensively
If your programmer is keen on labelling a code as “ugly”,
“unusable” or “I’d like completely rewrite it from
scratch”, then he’ll waste your time and be unhappy and
Instead he should say: “give me some time to whip this
code back into shape, by refactoring it [= cleaning it up]”.
Believe it or not, but refactoring actually saves time, as
Joel demonstrates in “Rub-a-dub-dub” and Martin Fowler in
his “Refactoring” book.
So if you hire a beginning programmer with a good potential
who’s full of this (bad) attitude, give him or her this
reading list. It will be faster and more fun to improve the
quality of the code, rather than to rewrite it from scratch.
<title>“We Can’t Find Good Programmers”</title>
How many times have you heard this phrase? I’ll tell you why you can’t
find them. It’s because you treat them like dirt.
<ulink url="http://www.paulgraham.com/gh.html">Great Hackers</ulink> are
exceptional people: they won’t work for you, unless they’re completely
happy. Some people who read the original article by Paul Graham,
thought that they won’t fix bugs or do routine tasks. That’s not
true - they will and often stay up late to do that. But they refuse
to take abuse.
So if you want to hire great developers, you’d better make sure you
offer them the best. Not only that, but you’d better make sure you
recognise a great developer when you see one.
<title>How to find Great Developers?</title>
Great Developers experiment on their own - they love to “hack”:
create new things, enhance existing things, and make the elements
of nature do things God did not intend them to do. No, most great
developers don’t intrude into other people’s computers. And most
of the so-called “script kiddies” (at least those who are computer
intruders) while usually being perfectly nice people, are not great
developers - at least not yet. Great developers instead spend hours
on end improving the quality of existing code by simple, mechanical
actions. They love learning new languages. They chat endlessly with
people from all over the world. They read a lot of things online
Most importantly, great developers in this day and age work on
projects</ulink>. While open-source became popular with software,
it later expanded to many other fields: there’s now
open-content/free-content texts, pictures and photographs, music,
videos, and anything else. There are open patents, open science,
open access, etc. But let’s focus on open-source code.
If you want to hire a great developer you can bet your life, that
he’ll contribute for an open-source project. Why? Can you imagine
him starting his own shareware project? Shareware is practically
dead on Linux and other UNIXes, which are the development environment
of choice for most people. And shareware doesn’t pay: you work on
a shareware program a lot, then you release it for a pay, receive
pay from at most 10 people (if you’re lucky), and no-one can or is
willing to contribute back. On the other hand, if your program is
open-source, and you publicise it on
<ulink url="http://freshmeat.net/">freshmeat.net</ulink> or a similar site,
some people will gladly take a look, some of them will try it
(instead of immediately ignoring it for being non-open-source), some
of them will send you a good input, and some will even become
Naturally, most starting open-source projects amount to nothing. But
most shareware programs have died along the way too. If you have a
good discipline and want your program to succeed, nowadays open-source
is what all the cool kids are doing, and practically no one will
respect you if you’re just a non-open-source shareware (or even just
non-open-source “freeware”) developer.
So if you want to hire good developers, your best bet is to find
people who are free software enthusiastic. Other people are just
either not good developers, or have the wrong character, which means
they will not improve, but become worse in time. Technology is
progressing and workers who are not open (literally), cannot
keep up with it.
It is known that great programmers almost consistently have very
good lingual skills. All of the great programmers I know have a very
good level of English. The
computer scientist Edsger Dijkstra</ulink> once commented that he
preferred to hire English majors over Computer Science majors because
the former made better programmers. If you see someone with an
obviously broken English - don’t hire him! (I’m not talking about a few
problems - these are common and people with an audible
cognition are more susceptible to them. )
So language is one element. Another element is philosophy. I’m not
talking about the standard ivory-tower philosophy, which is mostly
either useless or completely harmful, but rather of the process of
“loving-the-wisdom” and seeking wisdom. Nowadays, most of the
greatest philosophers don’t write books. Instead they write essays and
articles online, emails, weblog entries or comments, or even cartoon
strips or other art forms. The great philosophers of today are
Some great programmers I know purposely maintain a low profile and
don’t comment on everything. I can respect that. Others (including the
writer of these lines) are completely sincere and always express their
If you want to tell if someone is a great developer - ask him about his
opinion on a few things. Possibly political. Possibly related to
software management. Possibly something less serious, like popular
culture. If they’re a great developer, they’ll eventually
have something innovative and opinionated to say about something.
Not necessarily an opinion you’ll agree with, but a good, well-thought
When asked why he changed his opinion from the day before,
Mahatma Gandhi replied: “Yesterday I was more stupid.”. And indeed,
you’ll see that the really good programmers may eventually change
<title>How to treat Great Developers</title>
So you want to hire a great hacker. That’s great!
What should you do? Great hackers, are not too concerned with getting
exceptional salary</ulink>. They probably won’t work for free, but they
will often prefer a better job with a smaller pay than an abusive
job with a higher pay. But what do they like?
Great Developers like to <emphasis role="bold">work on stable, well-proven platforms</emphasis>
that are preferably open-source. In today’s world it means either
C or C++ using gcc and g++; Perl, Python, Ruby and to a lesser extent
PHP; Java and possibly also .NET on Windows 2003 or the open-source and
cross-platform <ulink url="http://www.mono-project.com/">Mono</ulink>. If
your platform doesn’t work, has bugs that delving into the source
won’t reveal (if the source can be read at all) - they’re not going
to be happy.
At a workplace I worked for a few days, I was given a task to
automate a buggy Hebrew windows application written using
PowerBuilder, which was incredibly quirky. It took me three or
four days to write less than a hundred lines of Perl code. I was
never so unproductive. After answering the wrong question in an
interrogation, I was fired, and was heavily relieved. Such
applications should not be tested - they should be rewritten using
a more modern and less quirky technology.
Another thing great developers hate is to <emphasis
role="bold">forced to be consumed by their work</emphasis>. In
Israel, some workplaces require at least 9 hours of daily work. How
can you work like that, and still work on open-source projects,
have a girlfriend or a boyfriend, go to the meetings of social or
technical clubs, hang with your friends in coffee shops,
restaurants, or pubs, and other activities like that. All of these
things are not <emphasis role="bold">strictly part of
work</emphasis>, but they are what <emphasis role="bold">make
great developers productive</emphasis>. That’s because coding
happens in your mind, not in your editor or IDE, and because the
more inspired a developer is, the more happier he is, the better
code he writes, and the better ideas he has. A programmer who just
works all week, without leisure time is heavily underproductive.
Here’s another thing: in Israel the law mandates at least
12 paid vacation days per year. At my previous workplace, I received
14 paid vacation days? Thank you, Workplace!!
But guess what? <ulink url="http://www.fogcreek.com/">Fog Creek
software</ulink>, best known as the company co-owned by
<ulink url="http://www.joelonsoftware.com/">Joel Spolsky from the
“Joel on Software” site</ulink> gives people 6 weeks of paid vacation
annually. And they’re doing very fine, and people there are
super-happy and productive. So, why should I work for you if all I
get are 14 stupid days? Get real!
<title>The Best Equipment Money can Buy</title>
Test</ulink> specifically says that you should give your
developers the best tools and equipment money can buy - from
hardware to software, to office conditions, to food, to
location, to everything else. Many workplaces don’t understand
In a previous workplace of mine, I was given a recycled
computer - it was still fast but its hard-disk was
only 40 GB. It was a pain to get some Windows XP virtual
machines running there. Another computer we
developed on still had a 40 GB hard disk too. We ran out
of space there because we had a huge checkout of the
version control system</ulink> there. And the only
hard-disks that our lab had were whopping 80 GB ones, bought
because they were the cheapest ones, which probably wouldn’t
have been sufficient for too long, either.
The most amazing thing was that the computer’s sole CD drive,
was just a CD drive - no CD writing, no DVD reading or writing
- a CD drive. It gave me a lot of grief. I had to copy a few
DVDs I burned at home on my supervisor’s computer, and copy
them over the network, and could not install a Linux
distribution from its installation DVD even if I wanted
Some people can still happily use old hardware or play with
relatively buggy software. But good developers should not be
concerned with this. They want a hardware with enough space,
RAM, and processing power. They want a screen that they can
easily move around (a flat-panel LCD screen). They want good
food in the kitchen. They want talkative, interesting and
benevolent people to talk with. They want a spacious office.
Internet connectivity</ulink> so they can surf the web and
search for answers, chat with their friends, ask people on the
IRC for help, and contact some people who know more about the
software they are using than they do.
<title>Leave Your Developers Alone</title>
At a previous workplace of mine, my bosses <emphasis
role="bold">did not like the fact that I sometimes
played</emphasis> card solitaire games or Sokoban. I’m not
much of a gamer and don’t spend hours on end playing high-end
games. But they didn’t like that people who passed by <emphasis
role="bold">saw me not working at that very
<para> I needed these games to bring my mind back into cycle. I was
also labelled as a “strange bird”, because I often stood and
looked at our building’s garden and lawn through the window. As
Graham notes</ulink> there’s a large difference between
<emphasis role="bold">“pretend work”</emphasis> and <emphasis
role="bold">“real work”</emphasis>. Playing games and
looking through the window do not make you less productive. If
you’re just writing code for the same codebase all the time,
your mind will soon run in circles, and you won’t be
a mission statement to an innovative software
company</ulink>, I said that I expected developers to work
for only 20% of the time? Why? They:
Usually won’t work more anyhow.
Since so little is expected of them, they will feel
willing to work more than that. (Assuming they are
indeed great developers with a wonderful character).
The things they’ll do in the rest of the time will
inspire them and allow them to be more productive.
Another issue are <emphasis role="bold">the
Make sure your developers can normally come to the office when
they want and go when they want. If you sometimes need more
time or better attendance, then great
developers will be happy to comply - temporarily. But
mode is a recipe for disaster</ulink> - your developers
will be over-worked, under-productive, and unhappy. And if
they’re smart, they will soon quit.
And here’s another anecdote: at a previous workplace, I was
instructed to fulfil my hours quota at least precisely,
so they can get enough benefits from the Israeli Chief
Scientist. But what is more beneficial for them: a happy,
productive developer who does very good work, or a few
extra shekels? I can never understand this skewed logic.
<title>Be Honest with your Developers</title>
The first thing about being honest with your developers is
<emphasis role="bold">telling them exactly why they weren’t
hired</emphasis> if this was indeed
the case. Most companies I’ve been to, either rejected me
after an otherwise seemingly successful interview, or even
sent me an uninformative rejection letter before any
interview. This will cause the exceptional developer to
wonder what has he done wrong, or what’s wrong with him.
As an employer, you should have the
<emphasis role="bold">minimal decency to inform the star
developers what they did wrong</emphasis> and how to
further improve. Otherwise, you’re not being fair with them,
also may tell all their friends how pointless it was to try
to apply for you. (Or tell their friends how good a different
company that’s also looking for great hackers treated them.)
Honesty is also <emphasis role="bold">telling your
developers when they did something
right</emphasis>, like finding bugs, fixing bugs, having
good ideas, implementing something on schedule, handling a
situation properly, etc. and when they did not do something
properly. Even the greatest developers make mistakes, but you
should be honest enough to evaluate their total performance so
far and not just their isolated mistake. A great developer
who’s worked for you for a few months, made a mistake recently
learned from it, and is determined not to repeat it,
<emphasis role="bold">is a better asset than a
new developer</emphasis> who still has a lot to learn
at the company.
Obviously, <emphasis role="bold">honesty goes in
both ways</emphasis>. Great developers should
be honest enough to tell their future employers, present
employers, and co-workers what they think about them, or
if they believe themselves or the latter are doing something
wrong or exceptionally well. Honesty is both liberating, and
makes sure one avoids problems and problematic patterns.
<title>Let Them Grow</title>
Here’s another insight: let your developers grow. If you
know they have potential, then hire them regardless if they
have the appropriate experience you’re looking for.
<emphasis role="bold">No-one is born</emphasis> a kernel
developer, an experienced mod_perl developer, a Java developer
with 5 years of experience, or a C/C++ systems
programmer. But many people who are <emphasis role="bold">fresh out of college or
even high school</emphasis>, and who like to program for
fun, are capable of becoming that by being given an
On the IRC, I’ve been talking to someone who graduated in
Electrical Engineering from a British university. Since he
doesn’t want to work for the defense industry, he became
a system administrator at a high school. Now he knows Perl
and uses it extensively, but he doesn’t think he can get
a more lucrative job as a Perl programmer (of which there’s
a lot of demand for in England) because he doesn’t have a lot
of mod_perl experience.
The reason people want experience is
because the people with experience are more productive, but
because they know how to handle problems they encounter
better</ulink>. I don’t claim experience is not important.
However, if you’re using a platform which is both reliable and
predictable (<quote>it just works</quote>), give your
programmers access to the Internet (with the Web,
search engines, and IRC), to good searchable books, and to
fellow developers who are more experienced than them in that
platform, you can make sure they overcome such problems
A different programmer, also from the UK,
he started working with Perl and liked it and was good,
no one was willing to give him a chance to grow</ulink>.
What is important about great hackers is not their knowledge
or experience but their potential, attitude and
autodidacticism. Given proper conditions they will accumulate
a lot of knowledge, and surpass “medium-level” techs with
a small amount of experience.
So when hiring, don’t ask them highly specialised questions.
Otherwise, not only you won’t find too many “experienced
developers”, but you will also reject many great developers,
who will be excellent for what you do. Training a great
hacker is cheap. But hiring an experienced mediocre
programmer, is a bad idea.
<title>Take Some Good Advice</title>
Here is some good advice I found about software management:
<ulink url="http://www.catb.org/~esr/writings/cathedral-bazaar/">Eric S. Raymond’s <emphasis>The Cathedral and the Bazaar</emphasis> series</ulink>.
Also see his <ulink url="http://www.catb.org/~esr/faqs/hacker-howto.html">“How
to Become a Hacker” document</ulink>. Concentrates
on open-source hacking.
<ulink url="http://www.joelonsoftware.com/"><emphasis>Joel on
Software</emphasis></ulink> - a collection of articles and
essays and a weblog by Joel Spolsky. Concentrates on
writing commercial, marketplace software.
Graham</ulink> - many essays on different topics
including Lisp, language design, dynamic languages,
startups, and general philosophy.
Programming</ulink> - a software management
methodology intended primarily for developing in-house
software, but with some good, general ideas.
After reading all of those you’ll become much more clueful
about good software management than without it. Reading them
taught me a lot, and even if I disagreed with some of the
opinions they voiced, they were still good food for thought.
<title>Respect and Cherish Your Developers</title>
The final advice I can give you is to respect and cherish
your developers. If you <emphasis role="bold">lose one great
developer</emphasis>, you’ll have
a very hard time finding an adequate replacement for him,
if you ever can. So <emphasis role="bold">listen carefully to
what they say</emphasis>, and
instruct them to tell you everything that bothers them. Make
sure they are working on exciting tasks most of the time, and
that they are happy.
Don’t over-work them, give them the proper tools and
equipment, treat them like they were kings (rather than
slaves), and make sure they are happy working for you. While
it does not guarantee that they won’t leave you, it will
probably prevent most premature quitting or getting fired.
Make sure your developers are the people who ultimately dictate
what is possible and what isn’t. At a previous workplace of
mine, I was instructed to re-implement a PHP (and Flash 8)
application in Perl. At first I thought it was some legacy
code, but as it turned out it was done because the marketing
department decided that our programs should run on either PHP,
Perl or ASP. However, it is common knowledge that maintaining
three different codebases in three different languages is close
to impossible. (The only real solution is to have a compiler
from one common language into the three languages, but I wasn’t
instructed to do that.)
If the marketing department had understood what PHP, Perl and
ASP were all about, then they would have known that writing it
in PHP was enough. But there wasn’t a feedback from the
developers back to the marketing department.
If your developer wants to work half-time - give it to him.
If he wants to work from home, or have his own office instead
of working from home - give it to him. Great developers are
a scarce resource, and you can’t afford to lose them.
If you implement all of these suggestions, you’ll become known
as a workplace where great developers love to work, and which
they will recommend to their friends. In this day and age, great
developers can easily start their own companies, become
freelancers, or simply remain “unemployed” while doing paid-for
gigs. Or they can find a better workplace, perhaps with lower
pay, but one where they will be happier.
If you’re a good developer - know your worth. Refer potential
employers to this essay, tell them they have a slim chance of
finding someone as good as you on the market, and that you
deserve the best.
</article> <!-- End of the article -->