A master programmer passed a novice programmer one day. The master noted the novice's preoccupation with a hand-held computer game. ``Excuse me,'' he said, ``may I examine it?''
The novice bolted to attention and handed the device to the master. ``I see that the device claims to have three levels of play: Easy, Medium and Hard,'' said the master. ``Yet every such device has another level of play, where the device seeks not to conquer the human, nor to be conquered by the human.''
``Pray, great master,'' implored the novice, ``how does one find this mysterious settings?''
The master dropped the device to the ground and crushed it under foot. And suddenly the novice was enlightened.
You'll note that sometimes optimizing for time may cost you in space
or programmer efficiency. Them's the breaks. If programming were easy,
they wouldn't need something as complicated as a human being to do it,
now would they?
-- Larry Wall,
Tom Christiansen, Randal L. Schwartz: Programming Perl
I feel I should have told you earlier on just how hard
the software business can be. It's fun for me because I get to write
code; I'm into it for the intellectual stimulation and because I was
raised to be a scientist that reward is tremendous to me. Great
rewards can come, often do come, but you have to watch out.
-- ... and other hard-won advice from Michael D. Crawford
Debugging is twice as hard as writing the code in the
first place. Therefore, if you write the code as cleverly as possible,
you are, by definition, not smart enough to debug it.
-- attributed to Brian Kernighan; an
interview with Brian is here.
It seems surprising to me that any employer would be
reluctant to let hackers work on open-source projects. At Viaweb, we
would have been reluctant to hire anyone who didn't. When we
interviewed programmers, the main thing we cared about was what kind
of software they wrote in their spare time. You can't do anything
really well unless you love it, and if you love to hack you'll
inevitably be working on projects of your own.
-- Paul Graham,
Hackers and Painters
So if you take Wikipedia as a kind of unit, all of Wikipedia, the
whole project--every page, every edit, every talk page, every line of
code, in every language that Wikipedia exists in--that represents
something like the cumulation of 100 million hours of human thought. I
worked this out with Martin Wattenberg at IBM; it's a
back-of-the-envelope calculation, but it's the right order of
magnitude, about 100 million hours of thought.
And television watching? Two hundred billion hours, in the U.S. alone,
every year. Put another way, now that we have a unit, that's 2,000
Wikipedia projects a year spent watching television.
Teach Yourself Programming in 10 Years, by Peter Norvig.
An interview with
James Gosling
on inheritance, composition, interfaces, programming
by contract,...
An interview with
Bjarne Stroustrup
on C++.
Back in the days of the command-line interface, users were all
Morlocks who had to convert their thoughts into alphanumeric symbols
and type them in, a grindingly tedious process that stripped away all
ambiguity, laid bare all hidden assumptions, and cruelly punished
laziness and imprecision. Then the interface-makers went to work on
their GUIs, and introduced a new semiotic layer between people and
machines. People who use such systems have abdicated the
responsibility, and surrendered the power, of sending bits directly to
the chip that's doing the arithmetic, and handed that responsibility
and power over to the OS. This is tempting because giving clear
instructions, to anyone or anything, is difficult. We cannot do it
without thinking, and depending on the complexity of the situation, we
may have to think hard about abstract things, and consider any number
of ramifications, in order to do a good job of it. For most of us,
this is hard work. We want things to be easier. How badly we want it
can be measured by the size of Bill Gates's fortune.
As soon as you start to think about how to get everything to really,
really, really, really, REALLY work, it becomes much more
complicated. So software starts out with a simple vision and it grows
a million little hairy messy things. And depending on the quality of
the initial vision, those hairy things may be more or less hairy, but
they're going to exist.
And therefore, because software seems so simple and is actually
complicated, you can't implement it until you specify the
complication. And all these people that are trying to make the same
perpetual-motion machine -- where you just write your specification
and it automatically becomes code -- don't realize that the
specification has to be as detailed as the code in order to work.
1983 - Bjarne Stroustrup bolts everything he's ever heard of onto C to
create C++. The resulting language is so complex that programs must be
sent to the future to be compiled by the Skynet artificial
intelligence. Build times suffer. Skynet's motives for performing the
service remain unclear but spokespeople from the future say "there is
nothing to be concerned about, baby," in Austrian accented
monotones. There is some speculation that Skynet is nothing more than
a pretentious buffer overrun.
Rich Pattis at CMU has the
best
collection of computer science quotations that I know of.
Though the
collection at sysprog.net is also worth browsing...
In mechanical structures and contrivances, I have always endeavoured
to attain the desired purpose by the employment of the Fewest Parts,
casting aside every detail not absolutely necessary, and guarding
carefully against the intrusion of mere traditional forms and
arrangements. The latter are apt to insinuate themselves, and to
interfere with that simplicity and directness of action which is in
all cases so desirable a quality in mechanical structures. PLAIN
COMMON SENSE should be apparent in the general design, as in the form
and arrangement of the details; and a general character of severe
utility pervade the whole, accompanied with as much attention to
gracefulness of form as is consistent with the nature and purpose of
the structure.
"Fear always accompanies the making of art and it is generated
by the shock of seeing an idea taking form."
"By using these cheap and so far unforbidden instruments you can at
once rid yourself of the pressure of boards, policies, and editors.
They will speak your own mind, in your own words, at your own time, at your
own length, at your own bidding. And that, we are agreed,
is our definition of `intellectual liberty'."
If you are a good information designer or Web/db developer you can
easily make enough money to live better than 95 percent of Americans,
but it is unclear how to make enough to push past an additional 4
percent to become obscenely wealthy. If you aren't richer than Bill
Gates, there is really no distinction in being rich. So unless you
have a credible plan for becoming richer than Bill Gates, it is
probably best to try to achieve something worthwhile.
One guideline for all programmers is to never tie
yourself to one computer language or system. While we often develop
our specialties over time, we should never abandon the search for new
tools, new languages and new opportunities... Never let yourself
stagnate, even if you are primarily programming in one particular
language. Don't become a dinosaur.
Tom Van Vleck has collected some software
engineering proverbs here.
Here's some advice on interviewing for a CS job. Who knows, it may
come in handy: Joel Spolsky, Kuro5hin, Slashdot.
One success story on doing good
work in corporate America.
Here are Roedy Green's tips on how NOT to write
code... and here the Advogatos discuss
some pitfalls of
object-oriented programming.
"Since I'm going to college in two years, I was wondering if there
were any colleges that offer 'intensive' computer training. Most
colleges offer computer programming in C++ and whatnot, but what about
schools that offer programming in languages like ColdFusion, ASP,
JavaScript, Java, and Perl, along with courses like system
administration, unix, databases, and networking. A College that deals
with all computers all the time with cutting edge machines and cutting
edge topics."
We define software engineering professionalism with the following
objectives:
Pretty important.
-- Clay Shirky,
Gin, Television, and Social Surplus
--
Neal Stephenson
--
Joel Spolsky
--
A Brief, Incomplete, and Mostly Wrong History of Programming Languages, by James Iry
-- James Nasmyth, a century before software
--
Andy Goldsworthy
--
Virginia Woolf
--
Philip Greenspun
-- Douglas E. Welch
-- Ask Slashdot!
--
Philip Greenspun