Productivity

Why do We Need Productivity Gains in the Education Sector?

1. Antiquated Lectures

2. Baumol’s Cost Disease

3. Lack of specialization

Robo-Socialism

So ... as we programmers fully automate everything, what happens to the work week?

In the future, we’ll only work 15 hours a week. So said John Maynard Keynes in 1930. Keynes’s utopianism is nothing new – it’s been a common refrain since the Enlightenment, when French philosopher Condorcet pushed it to absurdity by suggesting that an infinite expansion in human height was just around the corner.

John Quiggin has a great, nuanced re-evaluation of Keynes’ prediction. He writes that “for the first time in history, our productive capacity is such that no one need be poor” and that it is possible to achieve Keynes’s vision by 2060. The biggest obstacle won’t be productivity, but social norms

Counterparties via Felix Salmon. I enjoy the Jetsons reference.

Brains Plus Brawn

I'm slightly off charter again, but I love this article by Daniel Lieberman on the evolution of humans as big-brained runners:

Why did brains get so big? There are a number of obvious reasons. One of them, of course, is for culture and for cooperation and language and various other means by which we can interact with each other, and certainly those are enormous advantages. If you think about other early humans like Neanderthals, their brains are as large or even larger than the typical brain size of human beings today. Surely those brains are so costly that there would have had to be a strong benefit to outweigh the costs. So cognition and intelligence and language and all of those important tasks that we do must have been very important.

...

Until extremely recently, you couldn't live, you couldn't survive as a human being without being an endurance athlete. Not just hunting and gathering requires athleticism but also being a farmer. Subsistence farmers have to work extremely hard. Until the invention of industrialized machinery, farmers had to work even harder than hunter-gatherers, often spending many thousands of calories a day. They have to dig ditches and throw vast quantities of hay into bales and they have to schlepp stuff all over the place. Farmers had to work brutally difficult, hard, exhausting lives. It wasn't until, again, the invention of new technologies such as domesticating animals or even more recently machinery such as the internal combustion engine, that farmers were able to live non-grueling lives.

To be true to your nature, don't let that desk job take over completely. Sit on a yoga ball, and go for a hike (or run) now and then.

Conservatives and Science

I'm veering off-charter a bit. Do read the sidebar to your right for a learn to program gameplan.

I'm struck by a few things though, reading Mike Dwyer's Conservatives and Science at The League of Ordinary Gentlemen.

Dwyer quotes a bit about "the growth of regulatory science," and then says "we have a scenario where science is allowing itself to be politicized." He's talking from his perspective as a archaeologist and anthropologist. My question to him would be, what if you had been a fisheries scientist?

I think a parallel world Mke Dwyer, one who became a fisheries biologist, would view all this very differently. I don’t think he’d view the loss of North Atlantic cod as a “political” issue. I mean, politics are a reality of the mind. They are philosophy. A fishery that is gone for good is gone for good.

(For those who don’t track fish news, the North Atlantic has sadly entered a stable state without the return of cod. For a good read, see Cod: A Biography of the Fish that Changed the World)

Also for what it’s worth, I think “young earth evangelicals” were the wedge that split conservatism from science. I got a chem degree in the 70′s myself, and at the time that was compatible with Republicanism. Now, not so much.

Small Science

This article confirms a hobby horse I've had for some time, that big science is too much loved, and small science is neglected as a result:'

I am a big fan of Small Science. In spite of the riches unearthed by Big Science in the fields of biology and physics during the last fifty years, historically speaking much of scientific progress has come from small groups or individuals working with relatively cheap equipment and resources. For instance consider discoveries like the structure of DNA, the structure of proteins, nuclear fission, the cosmic microwave background radiation and the transistor. All of these have been the beneficiaries of Small Science. Even in those cases where large organizations have supported these developments, the key findings themselves have come from small groups left alone to pursue their own interests. The work done by these groups benefited from a maximum of flexibility and a minimum of bureaucratic interference.

More at SciAm: In praise of Small (and Cheap) Science

Cheap Notebook Computers

I designed my study plan (in the sidebar) around cheap computers. At the time I wrote it, I thought good Linux-ready desktops were going for around $50. That wasn't much to spend if you couldn't find one in your closet.

I'm browsing Craigslist right now, and I'm kind of amazed. There are some good notebooks for less than $100. As an example:

IBM Thinkpad T43, Wi-Fi, 1.86Ghz, 1GB, Fantastic Condition - $80

I think we might be about to ubiquitous computing. From this point on computing power is approximately free. Of course, you can still drop a thousand on a new Mac notebook ... for however long that lasts.

The PHP Singularity

Coding Horror does a long piece on the awfulness of PHP. It surprised me, frankly. I saw PHP as a good low level tool. I don't see it as a high-powered or high-level computer language. And maybe that's the key. There are a lot of computer languages in the world. You can either learn one really well, and use it as your tool to attack every problem, or you can learn a few and select one for the job.

I see PHP as a simple tool for creating the simple websites that make up 80 or 90 percent of our web universe. You certainly can create a restaurant's website, complete with menu, map, and daily specials, without taxing the language. You can do an auto dealer's site, list current inventory, and take service reservations.

At some point though, PHP will top out. It will be when the things you are trying to do become a bit too data intensive and computationally demanding. If you want your auto site to have a "build your car" page, first showing a wirefrime, and then showing it in your color, etc., that could be a bit much. You probably could do it in PHP, but then you'd run into the kind of frustrations Coding Horror shares with us.

That's my perspective as a former Java programmer, coming from a world where we were carrying around a lot MORE language and complexity than we needed for simple jobs.

Lectures Don't Work

The full article is worth a read:

Science Finds a Better Way to Teach Science

The basic idea is that students who put knowledge to immediate use remember it better. I guess that's not a surprise to those of us who prefer internet tutorials to dry lectures. It might even be a defense of my "go do it" method in the sidebar.

If you have a game plan, google for answers, and build a LAMP server, you'll learn a lot.

Egoless Programming

As mentioned earlier, the odd name for these pages comes in part from the idea of Egoless Programming.  To help get the idea across, I'll throw out some suggestions:

1. You are not your code.
2. You discard your code for something better.
3. You look for strengths in other people's solutions.
4. When you criticize, it is "defects only," and not style points.
5. You are ready for the next person in the door to have a great idea.
6. You work with others to (re)combine ideas in pursuit of excellence.

I think these reminders work in parallel to whatever management hierarchy is in place.  In general, co-workers will respond in kind.  Now and then you get a guy stuck on his idea being best .. let him be, and of course try not to be that guy ;-)

Should You vi?

When I was coming up through UNIX programming, GUI editors were not that common, and certainly not across the Sun, HP and IBM systems I commonly used.  On the other hand, vi was always there.  It's old-school.  It's infrastructure.

I'm going to say that yes, you should learn it if you are taking a Linux/UNIX centered development path.  There will be a time when you just need to quickly edit some dumb little text file, maybe over a telnet or ssh connection, and vi will do it.

Google "vi tutorial" and spend some time.  It might be fun, as well as a little frustrating ;-).  Just remember, when in doubt, pound that Esc key!

A few additional comments:

1) I run vi from the command line.  When I'm in a GUI mood I choose something else.

2) Whenever I load a new Linux system, I add the full vim package.  Vim is vi plus nice things like colored syntax highlighting.  When I can, I vim rather than vi.

3) Back in the old-school days there were "vi versus emacs" arguments (see Editor War).  I won't comment on that.  I ended up a "vi guy" alternately because I like a light environment, or I just happened to use vi first.

Should You CLI?

In the beginning, computers were not really connected to users at all.  Programmers wired jumpers, and later fed stacks of cards.  When the connection came, it was with a line-oriented text interface.  First there were teletypes, and then there were CRT terminals.  The user typed, and the computer (programs) responded.  The user typed again, the computer responded again.  This command line interface (CLI) was in a very rudimentary sense "conversational."  Users couldn't ask anything ("sudo make me a sandwich") but if they learned the basic lingo of the computer, they could get a lot of work done.

Graphical user interfaces (GUIs) crept in, first on rare and expensive computers, but over time on everything down to a phone.  GUIs offer a more control-panel interaction.  It is look and click.  It is navigational.

There are many good reasons for programmers to be skilled at both modes.  A GUI has bandwidth and delivers massive amounts of information on a modern display.  On the other hand, the CLI conversation is a natural mode for performing a sequence of actions.

We can run a modern SQL database, like MySQL, from a GUI (or web-based) interface.  It makes it very easy.  On the other hand, there is no record or structure to the conversation.  When we connect to a database with a CLI client, we start conversing, and have a scroll-back history of every action performed.

When I connect as root to a production MySQL database, I do it with a CLI for this reason.  I can type once, and look twice, before hitting that sometimes scary "enter" key.

When I say "connect" I raise the second strength of the CLI.  It requires very low bandwidth and can be done with a telnet or ssh connection from one UNIX system anywhere in the world to another anywhere else in the world.  I've telneted across the office and (via a secure connection) to servers thousands of miles away.

You can do remote operations with GUIs, if they are set up, and if their crash isn't what you are trying to fix!  But the CLI will pretty much be there as long as a UNIX box is alive.  It is the ultimate fall-back, as well as a powerful tool for daily operations.

So yes, I'd say you should CLI (as well as GUI), but by all means Google "CLI versus GUI" for more opinions!

When you hit steps 4. Learn UNIX Basics and 9. Learn MySQL Basics value those CLI lessons.

True Names

When I began work, programmers typed their resumes on paper and mailed them (in trucks!) to prospective employers.  Once there, the resumes were read (or at least skimmed) by a human being before being handed up to managers.  In those days our online persona (such as they were) were usually separate and distinct from our real self.  There were individuals who piloted on-line persona with their True Names and built a personal branding on that basis.  They were rare, but it changed over time.  There have been a lot of incremental changes, with job sites, personal web pages, and ultimately LinkedIn.

I think that if I were beginning today, trying to build a working reputation as a programmer, I'd do it with my True Name.  There's an old saying from business that "every customer contact is a sales opportunity."  In the web, as we grow, learn, and network, every contact is an opportunity.

As you build points and badges at programmer's forums, you build a rep.  It's probably better do start that now under a True Name.

How you integrate that, or separate that, from a social persona on Facebook or something ... that might be a harder problem.  Luckily, I'm too old to worry about it.

Egoless Boots

How did I name this thing? Well, never fault a dot-com name that is simply available, but beyond that, I want this to be about bootstrapping on an egloless path.

Bootstrapping is an old word. It refers to pulling oneself up by one's own boot-straps. The phrase made the jump to computing sometime in the 1950s and has stuck. It generally means starting small and working your way up. I hope to provide one path for "pulling oneself up" into computer programming, using the resources of the web.

"Egoless" might seem a strange word to add, but I think it's important. It refers to Egoless Programming. The idea is that, as much as possible, we should keep our egos out of it and just pursue the best answer. When two programmers trade ideas, it should be about what's best for the user at the end of the day, and not just "mine's better." Having that attitude makes us better students, and teachers as the years go by.

If that sounds good, continue on to my sidebar

Cognitive Surplus and Walled Gardens

The phrase cognitive surplus describes the idle capacity that people have available to engage in collaborative activities, especially in building and sharing knowledge on the web.  Wikipedia is often cited as the prime example of what cognitive surplus can do.

This site represents my cognitive surplus.

In tension with this is the idea of a walled garden.  A walled garden is an entity, sometimes a web site, that encourages users to stay withing its borders.  Commercial vendors have an interest in capturing cognitive surplus to expand their gardens and make them more attractive destinations.

I'm an outsider on edu-hacking, and the future of education, but I think there is a clear competition going on now between the network of "sites without walls" and those more aggressively pursuing "walled garden" status.

I would bet long-term on the open systems, but if I'm going to be "egoless" on this too, I should say it's all good.  If an ed-tech business can help you learn, and provide decent ROI, go for it.  Of course, you might browse for the free and open alternatives.

Two Families

When I started programming, in the late 70's and early 80's, it was common for both programming languages and operating systems to pass away, and to be supplanted.  At all levels of computing, from desktops to mainframes, system software would enjoy a few years in the sun, and then fade.

What's really interesting is that changed, something happened to break the dynamic nature of the market.  I think it was just the sheer number of users who arrived with IBM PCs and who settled on UNIX for back-office systems.  When it was a few thousand programmers, they were a mobile pool, and seduction to a new standard was possible.   With a few million programmers the equation changed.  Suddenly the standard had a huge weight.

And so we are left with the two surviving families, Windows and UNIX, into the future.  (I lump Apple and Linux into the UNIX family.)  They are infrastructure now, and might last a really long time.  Other curious standards, like wall voltage, and the railroad gauge, were set a long time ago.  So it could be with these.

We are moving to the cloud now a bit, and that might seem different, but it is just an abstraction layer.  As I understand it, essentially all cloud servers are running UNIX, and those few that aren't, are running a Windows variant.

So, I think my sidebar recommendation to bootstrap the LAMP stack is a good one.  It's infrastructure, and will be slow to change.

Ten Years?

Peter Norvig, Director of Research at Google, wrote a pithy web page called:

Teach Yourself Programming in Ten Years

It is a reaction to all the "Learn Foo in 7 Days" books we see in bookstores.  Personally, I always took those titles as a challenge.  If they said "7 Days" I'd think I could do it in 2.

I tried that as an interview question for a while, "If you saw a book that said 'in 7 Days' how long do you think it would take you?"  Some thought that was a mean question, but I think it's good for a programmer to have some confidence.

In my sidebar I say:

There are many guesses about how long it should all take. I'd say you can be writing simple web programs in a few weeks, be turning out solid work in about a year, and be an expert in a few more. That's assuming you really get into it.

I guess the hedge there is "assuming you really get into it."

But still, if you do get into it, you should develop your independent learning ability, and scoff at "7 days."