A lesson I have learned the hard way is that we aren’t smart enough. Even the most brilliant programmers routinely make stupid mistakes. Not just typos, but basic design errors that back the code into a corner, and in retrospect should have been obvious. The human mind can not grasp the complexity of a moderately sized program, much less the monster systems we build today. This is a bitter pill to swallow, because programming attracts and rewards the intelligent, and its culture encourages intellectual arrogance. I find it immensely helpful to work on the assumption that I am too stupid to get things right. This leads me to conservatively use what has already been shown to work, to cautiously test out new ideas before committing to them, and above all to prize simplicity.

Jonathan Edwards

In his memoirs, computing pioneer Maurice Wilkes wrote of the moment in 1949 when, hauling punch cards up the stairs to a primitive computer called EDSAC in Cambridge, England, he saw the future: "The realization came over me with full force that a good part of the remainder of my life was going to be spent in finding errors in my own programs."  From Wilkes's epiphany to the present, despite a host of innovations, programmers have been stuck with the hard slog of debugging.  Their work is one percent inspiration, the rest sweat-drenched work; their products are never finished or perfect, just varying degrees of "less broken."

Scott Rosenberg, Dreaming in Code

Once upon a time in the dead of winter in the Dakota Territory, Theodore Roosevelt took off in a makeshift boat down the Little Missouri River in pursuit of a couple of thieves who had stolen his prized rowboat. After several days on the river, he caught up and got the draw on them with his trusty Winchester, at which point they surrendered. Then Roosevelt set off in a borrowed wagon to haul the thieves cross-country to justice. They headed across the snow-covered wastes of the Badlands to the railhead at Dickinson, and Roosevelt walked the whole way, the entire 40 miles. It was an astonishing feat, what might be called a defining moment in Roosevelt’s eventful life. But what makes it especially memorable is that during that time, he managed to read all of Anna Karenina. I often think of that when I hear people say they haven’t time to read.

David McCullough

That's me at my second computer: a Tandy 1000 SX.  Note the *two* double-density 5.25" floppy drives.  This picture has to be about 1986, which would make me roughly 13 years old.  At this point in my life, I was splitting my time at the keyboard fairly evenly between coding BASIC and playing Infocom games.  That ratio shifted a little more to the gaming side the following year with the release of Vohaul's Revenge.

I always find it somewhat ironic when I hear people complain about programming abstractions not being good.  Especially when these complaints are published via blogs – whose content is displayed using HTML, is styled with CSS, made interactive with JavaScript, transported over the wire using HTTP, and implemented on the server with apps written in higher-level languages, using object oriented garbage collected frameworks, running on top of either interpreted or JIT-compiled byte code runtimes, and which ultimately store the blog content and comments in relational databases ultimately accessed via SQL query strings.  All of this running within a VM on a hosted server – with the OS within the VM partitioning memory across kernel and user mode process boundaries, scheduling work using threads, raising device events using signals, and using an abstract storage API fo disk persistence.  It is worth keeping all of that in mind the next time you are reading a “ORM vs Stored Procedures” or “server controls – good/bad?” post.  The more interesting debates are about what the best abstractions are for a particular problem.

Scott Guthrie

I look at creative projects like they were Sudoku puzzles — you can stare at them as long as you like but you won’t suddenly see all the numbers.  You have to start.  You have to find one box to fill in, and from that — another one reveals itself.  You might not be able to solve all of them, but as long as you know it’s possible, you’ll keep trying.  And no matter how many you solve, each new one begins with a bunch of empty spaces

Ze Frank