

How to be a Programmer: A Short, Comprehensive, and Personal Summary (2002) - sgreen
http://samizdat.mines.edu/howto/HowToBeAProgrammer.html
A Short, Comprehensive, and Personal Summary
======
Jugurtha
>>But it is really child's play compared to everything else >>that a good
programmer must do to make a software system >>that succeeds for both the
customer and myriad colleagues >>for whom she is partially responsible.

Why the use of the word "she" ? I see a lot of articles written where the
undefined person will be a she. I speak french, and "person" is a feminine
name, so you can say about a person "she", but why in English ? Especially
when in male dominated jobs like programming. A programmer is likely to be a
he than a she, so why try _this_ hard to be politically correct.

~~~
aurelius
The grammatically correct generic pronoun in English is 'he':

[http://en.wikipedia.org/wiki/Singular_they#Generic_he](http://en.wikipedia.org/wiki/Singular_they#Generic_he)

Anything else is just politically correct nonsense.

~~~
kintamanimatt
It's not really any less correct than a genderless pronoun, even if one
particular panel disagreed. I see no reason to use a masculine pronoun when a
generic one will do, and could only call it "political correct nonsense" if an
author insisted on either alternating between he and she, or used "he/she".

~~~
jiggy2011
I find things written with lots of genderless pronouns can make the writing
unclear. Lots of "They" , "Their" feels unnatural and clumsy when talking
about people and it can become difficult to decipher which parts of the text
are referring to a person and which to some inanimate thing.

Just as frustrating is writing that switches pronoun gender when referring to
ostensibly the same person. However describing some operation between two
people "Alice and Bob" it can improve clarity to make both people belong to
different genders.

------
drunkpotato
What is wrong with us in this sick, perverted, twisted, dying and rotting
industry? If you encounter these problems, start applying to a new position.
Don't deal with management; don't "educate" them. Don't fix the organization
you've tricked yourself into joining. Just polish your resume and leave. It
seems like we're an industry that _defines_ Stockholm Syndrome.

~~~
fit2rule
Philosophically, programmers can do anyones job, as long as that person is
willing to describe it in a way that it can be abstracted properly.

Programmers are unique in the world, in a philosophical sense, in that the
skills and techniques of programming can be applied to any human subject, and
seriously productive results can be attained. Computers are an "infinity
machine" in that any single subject that a human being can describe, using
words, can be in some way supported by computerization.

So if you think an organization is broken, programming can often-times fix it.
Good programming, which encodes the domain-specific knowledge of the
organization, can be applied to any particular role in human existence -
including that of management. In that sense, programmers are able to operate
exterior to any organization - and must, in fact, if they wish to deliver a
productive result - and apply their skills to that organization in order to
improve it.

Programmers who have worked professionally in any industry have an intuitive
understanding of this fact, and its strengths.

So I would put it to you that its not Stockholm Syndrome you're observing, but
rather this simple fact: Programmers > Managers. (Well, Programmers who
_deliver_ working systems, that is..)

~~~
mseebach
Wow, that's .. incredible hubris.

There are good programmers and there are bad programmers. There are good
managers and there are bad managers. The good variants of either are very
valuable and can deliver huge value to very diverse businesses. The bad ones,
not so much.

Since the computer-based automation of everything is a reasonably recent
phenonomen, there have been more low-hanging fruit to be picked by bad
programmers. Management is a much more mature field, so having "Teach yourself
Management in 24 hours"-level competence is much less likely to have a
positive yield.

What you're describing is just general intelligence and analytical thought.
It's harder and rarer than most people think, and both managers and
programmers to be really good at their jobs. But just as there are less
demanding management positions in the world, there is an emergent class of
programmers who are perfectly capable of building and maintaining simple CRUD
apps to spec, but wouldn't need to know half of what is in this guide to be
effective.

------
JackMorgan
"Programming languages should really be called notations in that learning one
is not at all as difficult as learning a natural language."

Brilliant! This whole section on choosing a language is great.

"One tends to think of a large system that has components in three or four
languages as a messy hodgepodge; but I argue that such a system is in many
cases stronger than a one-language system..."

This part sounds insane until you start working with eventually consistent
messaging like:
[http://www.reactivemanifesto.org](http://www.reactivemanifesto.org)

------
ninetax
Woah you weren't kidding about "Comprehensive". Yet it really is short and
seems to encapsulate every thing it talks about pretty well.

Thanks a lot for this!

------
rrjanbiah
My favorite part is _How to Deal with Organizational Chaos_
[http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id28...](http://samizdat.mines.edu/howto/HowToBeAProgrammer.html#id2855892)
especially:

    
    
      Engineers have the power to create and sustain.

------
michaelchum
Interesting educational read, wise experience from a programmer, definitively
to read for beginner programmers like me!

------
shazzdeeds
The last section on organizational chaos and the magic power is key.

~~~
Iftheshoefits
I disagree. I think it is only very narrowly applicable, in particular to
companies that are technology-centric (i.e. that have as a primary product
something that is technology related, such as a software product), and even
then it only applies to a fraction.

In most companies, technology-centered or not, the non-engineers have a large
amount of power to "create and sustain" something far more important than code
or systems: institutional political power. I don't care how good a programmer
one is, in such organizations institutional politics almost always wins. The
old addage, "It's not what you know but who", applies here, as in any other
industry. Talent is only good to carry a person so far, within the confines of
somebody else's business.

------
wpnx
I kind of wish each section was a little longer. This would make for a great
book :)

------
vayarajesh
Nice read.

------
saddino
Here's a shorter version: Are you so inspired by a software product or service
that you are driving yourself mad thinking about how it was created? Great, do
whatever you can to write your own version. Keep at it. Seriously, keep at it.
Are you so obsessed with figuring this out that you are unaware that hours are
passing by while you work? Awesome. You have discovered a true passion. Now
you don't need to read things titled "How to Be a Programmer" because you will
drive yourself to become one innately.

For everyone else, go ahead and try to read things titled "How to Be a
Programmer" but don't expect it to actually help you, you know, BECOME one.

~~~
yeukhon
+1. Your short version pretty much summarize what other 1000 people would say.
And that's what I told people who came to my school's open house today: look
around you and see what kind of things you wish you could control. You want to
be able to get all the files with certain prefix? Figure out that
linux/windows command.

The title "A Short, Comprehensive, and Personal Summary". This is not short.
It's pretty verbose.

~~~
gknoy
It's hard to be short and comprehensive. This is shorter than a book, longer
than a magazine article. (55 pages: OK, maybe a short book.) "Short" is
relative. :)

His coverage of debugging, and how it's critical to overcome fear of breaking
things, and of asking the right questions of how things might fail in this
way, is a great explanation.

