Source

shlomi-fish-homepage / lib / docbook / 4 / xml / end-of-it-slavery.xml

  1
  2
  3
  4
  5
  6
  7
  8
  9
 10
 11
 12
 13
 14
 15
 16
 17
 18
 19
 20
 21
 22
 23
 24
 25
 26
 27
 28
 29
 30
 31
 32
 33
 34
 35
 36
 37
 38
 39
 40
 41
 42
 43
 44
 45
 46
 47
 48
 49
 50
 51
 52
 53
 54
 55
 56
 57
 58
 59
 60
 61
 62
 63
 64
 65
 66
 67
 68
 69
 70
 71
 72
 73
 74
 75
 76
 77
 78
 79
 80
 81
 82
 83
 84
 85
 86
 87
 88
 89
 90
 91
 92
 93
 94
 95
 96
 97
 98
 99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
<?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"
"/usr/share/sgml/docbook/xml-dtd-4.1.2/docbookx.dtd"[
]>

<article id="index">
    <articleinfo>
        <title>The End of IT Slavery</title>
        <authorgroup>
            <author>
                <firstname>Shlomi</firstname>
                <surname>Fish</surname>
                <affiliation>
                    <address>
                        <email>shlomif@shlomifish.org</email>
                    </address>
                </affiliation>
            </author>
        </authorgroup>
        <copyright>
            <year>2007</year>
            <holder>Shlomi Fish</holder>
        </copyright>
        <legalnotice id="main_legal_notice">
            <para>
                <!--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).
            </para>
        </legalnotice>

        <revhistory>

            <revision>
                <revnumber>4872</revnumber>
                <date>5 June 2011</date>
                <authorinitials>shlomif</authorinitials>
                <revremark>
                    Convert single and double quotes from ASCII to Unicode.
                </revremark>
            </revision>

            <revision>
                <revnumber>1746</revnumber>
                <date>1 May 2007</date>
                <authorinitials>shlomif</authorinitials>
                <revremark>
                    Corrected many errors courtesy of a reviewer from the
                    IRC.
                </revremark>
            </revision>

            <revision>
                <revnumber>1742</revnumber>
                <date>1 May 2007</date>
                <authorinitials>shlomif</authorinitials>
                <revremark>
                    Corrected many things, added more bolds, and a few extra
                    text for completeness.
                </revremark>
            </revision>

            <revision>
                <revnumber>1740</revnumber>
                <date>1 May 2007</date>
                <authorinitials>shlomif</authorinitials>
                <revremark>
                    Finished the article.
                </revremark>
            </revision>

            <revision>
                <revnumber>1705</revnumber>
                <date>17 April 2007</date>
                <authorinitials>shlomif</authorinitials>
                <revremark>
                    Forked the template from a previous work and working on
                    it.
                </revremark>
            </revision>


        </revhistory>
    </articleinfo>

    <section id="introduction">
        <title>Introduction</title>
        <para>
            This is the year 2007. This is Shlomi Fish, <emphasis role="bold">a good hacker</emphasis>,
            where hacker
            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.
        </para>
    </section>

    <section id="facts-about-working">
        <title>Some Facts about Working</title>

        <para>
            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.).
        </para>

        <para>
            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
            producing output.
        </para>

        <para>
            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
            <ulink url="http://www.joelonsoftware.com/items/2004/12/06.html">a
                “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.
        </para>

        <section id="achieving-productivity">
            <title>Achieving Productivity</title>

            <para>
                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.
            </para>

            <para>
                Paul Graham called these developers
                <ulink url="http://www.paulgraham.com/gh.html">“Great
                    Hackers” in an essay he wrote</ulink>. As I said before,
                I can testify I’m a good (or “above-average”) programmer (and
                <ulink url="http://www.shlomifish.org/">other
                    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
                hackers.
            </para>

            <para>
                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.
            </para>

            <section id="reuse">
                <title>Re-use instead of Start-over</title>
                <para>
                    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
                    <ulink url="http://www.catb.org/~esr/writings/cathedral-bazaar/cathedral-bazaar/ar01s02.html">wrote
                        about it in “the Cathedral and the Bazaar”</ulink>:
                </para>

                <blockquote>
                    <para>
                        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:
                    </para>

                    <para>
                        2. Good programmers know
                        what to write. Great ones know what to rewrite (and reuse).
                    </para>

                    <para>
                        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
                        all.
                    </para>
                </blockquote>

                <para>
                    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
                    <ulink url="http://www.joelonsoftware.com/articles/fog0000000348.html">“Rub
                        a dub dub”</ulink>, and it’s also been extensively
                    documented elsewhere.
                </para>

                <para>
                    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
                    under-productive.
                </para>

                <para>
                    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.
                </para>

                <para>
                    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.
                </para>
            </section>

        </section>

    </section>

    <section id="we-cant-find-good-programmers">
        <title>“We Can’t Find Good Programmers”</title>

        <para>
            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.
        </para>

        <para>
            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.
        </para>
    </section>
    <section id="how-to-find-great-developers">
        <title>How to find Great Developers?</title>

        <section id="open-source">

            <title>Open Source</title>

            <para>
                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
                and offline.
            </para>

            <para>
                Most importantly, great developers in this day and age work on
                <ulink url="http://en.wikipedia.org/wiki/Open_source">open-source
                    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.
            </para>

            <para>
                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
                contributors.
            </para>

            <para>
                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.
            </para>

            <para>
                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.
            </para>
        </section>
        <section id="language">
            <title>Language</title>

            <para>
                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
                <ulink url="http://en.wikipedia.org/wiki/Edsger_Dijkstra">famous
                    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. )
            </para>
        </section>
        <section id="philosophy">
            <title>Philosophy</title>

            <para>
                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
                bloggers.
            </para>

            <para>
                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
                mind.
            </para>

            <para>
                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
                opinion.
            </para>

            <para>
                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
                their opinions.
            </para>
        </section>
    </section>

    <section id="how-to-treat-great-developers">
        <title>How to treat Great Developers</title>

        <para>
            So you want to hire a great hacker. That’s great!
            What should you do? Great hackers, are not too concerned with getting
            <ulink url="http://www.catb.org/~esr/writings/cathedral-bazaar/homesteading/ar01s19.html">an
                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?
        </para>

        <para>
            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.
        </para>

        <para>
            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.
        </para>

        <para>
            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.
        </para>

        <para>
            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!!
        </para>

        <para>
            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!
        </para>

        <section id="best-equipment-money-can-buy">
            <title>The Best Equipment Money can Buy</title>

            <para>
                The
                <ulink url="http://www.joelonsoftware.com/articles/fog0000000043.html">Joel
                    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
                that.
            </para>

            <para>
                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
                <ulink url="http://subversion.tigris.org/">Subversion
                    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.
            </para>

            <para>
                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
                to.
            </para>

            <para>
                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.
                They <ulink
                    url="http://www.fysh.org/~katie/computing/no-net-access.txt">want
                    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.
            </para>

        </section>
        <section id="leave-your-developers-alone">
            <title>Leave Your Developers Alone</title>

            <para>
                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
                    moment</emphasis>.
            </para>

            <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
                <ulink url="http://www.paulgraham.com/opensource.html">Paul
                    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
                productive.
            </para>

            <para>
                <ulink
                    url="http://tech.groups.yahoo.com/group/hackers-il/message/4784">In
                    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:
            </para>

            <orderedlist>
                <listitem>
                    <para>
                        Usually won’t work more anyhow.
                    </para>
                </listitem>
                <listitem>
                    <para>
                        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).
                    </para>
                </listitem>
                <listitem>
                    <para>
                        The things they’ll do in the rest of the time will
                        inspire them and allow them to be more productive.
                    </para>
                </listitem>
            </orderedlist>

            <para>
                Another issue are <emphasis role="bold">the
                    working hours</emphasis>.
                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
                <ulink url="http://www.igda.org/articles/erobinsonncrunch.php">crunch
                    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.
            </para>

            <para>
                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.
            </para>

        </section>

        <section id="be_honest_to_your_developers">
            <title>Be Honest with your Developers</title>

            <para>
                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.
            </para>

            <para>
                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,
                and they
                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.)
            </para>

            <para>
                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.
            </para>

            <para>
                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.
            </para>

        </section>
        <section id="let_them_grow">
            <title>Let Them Grow</title>

            <para>
                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
                appropriate chance.
            </para>

            <para>
                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.
            </para>

            <para>
                The reason people want experience is
                <ulink url="http://www.joelonsoftware.com/articles/LordPalmerston.html">not
                    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
                easily.
            </para>

            <para>
                A different programmer, also from the UK,
                <ulink url="http://www.perl.org.il/pipermail/perl/2006-June/007956.html">testified
                    that while
                    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.
            </para>

            <para>
                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.
            </para>

        </section>

        <section id="take-some-advice">
            <title>Take Some Good Advice</title>

            <para>
                Here is some good advice I found about software management:
            </para>

            <orderedlist>

                <listitem>
                    <para>
                        <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.
                    </para>
                </listitem>

                <listitem>
                    <para>
                        <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.
                    </para>
                </listitem>

                <listitem>
                    <para>
                        <ulink url="http://www.paulgraham.com/">Paul
                            Graham</ulink> - many essays on different topics
                        including Lisp, language design, dynamic languages,
                        startups, and general philosophy.
                    </para>
                </listitem>

                <listitem>
                    <para>
                        <ulink url="http://www.extremeprogramming.org/">Extreme
                            Programming</ulink> - a software management
                        methodology intended primarily for developing in-house
                        software, but with some good, general ideas.
                    </para>
                </listitem>
            </orderedlist>

            <para>
                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.
            </para>
        </section>

        <section id="respect-and-cherish">
            <title>Respect and Cherish Your Developers</title>

            <para>
                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.
            </para>

            <para>
                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.
            </para>

            <para>
                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.)
            </para>

            <para>
                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.
            </para>

            <para>
                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.
            </para>

        </section>
    </section>

    <section id="conclusion">
        <title>Conclusion</title>

        <para>
            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.
        </para>

        <para>
            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.
        </para>

        <para>
            Happy Hacking!
        </para>

    </section>
</article>    <!-- End of the article -->