Archive for the 'programming' Category


Sig. Na. Ling.

So over at Unqualified Offerings Thoreau has a great blog post up.  You should go read it.

He considers philosophy majors (in the broader context of Whether Brick And Mortar Colleges Can Survive In The Face Of The Internet), and notes that philosophy majors make (relatively speaking) a shit-ton of money… because they’re smart.  I have no reason to doubt that he’s correct; the only philosophy majors I met in undergrad who were dumber than I was — I’ll note, perhaps unpleasantly, that I went on to get a doctorate — were in a bunch of required courses whose names started with “one-” and, maybe, “two-“.  So yeah, the PHIL majors in my sample tended to be pretty clever.

Thoreau, however, wonders whether “[t]here is value in training capable people to attain the level of intellectual sophistication that a good philosophy program instills.”

I submit that this conundrum is a catastrophic conflation of correlation with causation.  (I don’t even have an English Lit degree and I pulled off some pretty awesome polysyllabic alliteration there.  Govern yourselves accordingly.)

I’ve been reading a lot of The Last Psychiatrist lately, partly because he drinks more than I do but also because he’s put a fair bit of effort into unravelling why people send their kids to college at ruinous expense (mostly, but not always, to the kids) for absolutely no good goddamn reason at all.  In the first part of his epic Hipsters on Food Stamps rant — go ahead and click through, I’ll still be here in an hour when you’re done — he wonders:

I am not anti-liberal arts, I am all in on a classical education, I just don’t think there’s any possibility at all, zero, none, that you will get it at college, and anyway every single college course from MIT and Yale are on Youtube.  Is that any worse than paying $15k to cut the equivalent class at State?

Now, let me tell you a story a friend of mine loves to tell, from his perspective.  Text in brackets is mine.

The three of us — William [not his real name], me, and Matt, took Advanced Software Engineering last semester [or whenever].  It was basically User Interfaces In Java, although we saw the Design Patterns book for a few minutes in the second lecture.  William loved that shit, so he went to all the lectures, and he got a seven [out of nine].  I didn’t really care, so I skipped most of the lectures, and somehow I got an eight.  But Matt only attended the first lecture, the midterm, and the final, and he got a nine in that class.

(Yes, I’m the Matt in that story.)

I tell you that not to convince you that I’m amazing — the Ph.D. will have either done that already or convinced you irretrievably otherwise by now — but to convince you that that course was a waste of my fucking money.  Not my time, I spent all of maybe twenty hours on it that semester, and I can’t say it wasn’t a little bit educational.  I learned that I hate Java with the burning fire of a thousand suns, and also that 2000-vintage Swing was, while eminently hateable, better than anything else on the GUI-widget-set market at the time.  Also, in the first lecture one of the other guys in the class found out the hard way that he was colour-blind, so that was a thing.  I dunno what the fuck else I was supposed to have been educated upon in that course.  And they gave me the highest mark they could!

So if you’re an undergraduate programme committee member — and if you really are, I’m sorry — why would you put a course like that on the required list in the syllabus?  There are a lot of excellent cynical reasons, but the only pedagogical reason I can come up with is “so that every student we graduate must demonstrate, at the end of a semester of either skipping or attending class, that s/h/it knows how to make a calculator in Java.”  Actually I did that in high school, but thanks for taking four months to make me prove it to you.

This is not to say that I got no knowledge or skills of value from my undergrad.  If nothing else, the compilers course was worth the price of admission (and if you’re a CS student reading this blog, for fuck’s sake take a compilers course, it will change your life).  But I kind of doubt that I had to go to university to learn any of this stuff… maybe I had to go to university to be persuaded to study LL languages before attempting to write a compiler, but if you’re reading this sentence you don’t.  In any case compilers wasn’t a required course; I selected into it (as did both of my friends from the anecdote above).  And, of course, I got a B.Sc. and a GPA that convinced a grad school to admit me, whence I got a Ph.D. and a bunch of publications, whence I got a useful job.

And that last sentence is my point.


Stuff I’ve been thinking about lately

I’ve been meaning to write a post about the 2012 Australian GP, but I kind of can’t be arsed.  McLaren’s obviously onto something.  Red Bull are having trouble with their exhaust, which is awesome but a bit too clever for its own good.  Ferrari seem to have created an absolutely vicious car, possibly as an overreaction to the too-conservative strategies of 2010 and 2011, and I’d not be surprised if it comes down to “who the hell understands a pull-rod front suspension these days?”.  Mercedes has a damn cool combination of DRS and F-duct, probably.  Williams doesn’t look like they’re going to suck, provided that Maldonado grows a bit of maturity.  Marussia might finally beat HRT.

So far, so good.  The new Pirellis are good for the racing, and as usual for Albert Park even double DRS zones weren’t enough to make things stupid.  Give the teams a few races to learn the tires and F1 will probably get a bit more boring, as it did last year, but for now I’ll enjoy it.


I spend a lot of time reading, writing, and thinking about weight training — all of it in the context of self-improvement, not for any particular sport.  This has led me to get more deeply into general mobility issues, which I’m starting to work up on for similar reasons.  Given that I make a living as a programmer, why the damn hell haven’t I been putting at least as much effort into making myself a better programmer?

If strength and mobility are the foundations of physical performance (you might add endurance/conditioning on top of that, but that’s a more specific beast IMO), then theory and — for lack of a better word — cleanliness are  the foundations of programming performance.  Knowing when to use an Abstract Factory pattern is useful, but in a specific way, just like being able to sprint a five-second 40 is a specific kind of athleticism.  Having a deep understanding of graph algorithms is more akin to having a strong posterior kinetic chain — you can use the former to do anything from packet routing to mesh optimization to parse tree analysis, just as you can use the latter to do anything from deadlifts to snatches to sprints.

Probably I should start working on three InterviewStreet problems a week.  That won’t (much) help me write better-factored code, but it’ll work the theory aspect.


Damn but C++11 looks cool.  Yeah, I can’t believe I just wrote that either.  I dunno, you give me a language with malloc(3) and type inference and lambdas all at once and I start to get all hot and bothered.


Toyota built a Prius race car.  Yes, really.  They did mostly what I threatened to do here, but rather more so — well, just have a look for yourselves:

So… tube-frame chassis, tons of aero, mid-mounted V6 turbo powerplant, rear-wheel drive… yeah, that’s a priAPus all right.

And naturally it leaked gas and caught fire.

Still, it’s a pretty awesome thing.


Jim Wendler is the man.  Break his writing down past the trigger points that’ll get the Social Justice crowd all excited and you basically have this method for evaluating any given use of your time, money, and/or energy:

  1. Is it awesome?  Do it.
  2. No?  Is it making you awesome?  Do it.
  3. No?  Do something else and 30 GOTO 10.

(Bear in mind that, quite often, recovering from a workout — either physical or mental — is both awesome and making you awesome.)

Squat.  Sprint hills.  Prove theorems.  Write code.  Listen to metal.  Drink bourbon.  Sleep.  Repeat.  (Not necessarily in that order.)


Overhead squats are never the wrong thing to do, provided that you’re not going to wreck your shoulders losing the bar behind you or something.  (And if you are, you need to do overhead squats with a broomstick until you get that “packed shoulders” thing down.)


David Henderson is also the man.


I’ll have a more structured post for you in the near future.


Dear C++: What the fuck is wrong with you?

I’ll just leave this here:

That’s a perfect example of “Just because you can doesn’t mean you should“, right there.


Fixing higher ed: You’re doing it wrong

First we discover that the NSF is dreadfully concerned about Craigslist job ads:

I am now wondering how to best take my recent indoctrination about the value of Scratch, Processing, and programming-free computer science and leverage it to gain employment in a STEM field. I was told that we are facing a shortage of STEM workers of critical proportions and that we must educate students — especially those from under-represented demographics — so that they can solve this crisis in our nation.

Yes, it is true. Your tax dollars flew me to Washington, DC so that the NSF could tell me about these important issues. The NSF is very, very interested in there being more computer science majors because a recent survey of craigslist jobs in the Bay Area showed that all of them required technology — including the ad to hire a new dogcatcher (MS Access databases). Thus, we need to teach more Scratch and Processing so that students can major in computer science to become Access-using dogcatchers.

Oh-kay.  The NSF is desperately interested in “programming-free computer science”.  Remember when Java was going to save the world?  This is the same idiotic optimism brought up to buzzword-compliance for a new decade.  Colour me skeptical.

But at least the NSF is looking at real problems and, in its endearingly inept way, trying to solve them.  The Arizona state legislature, on the other hand, is making up problems from whole cloth and then trying to solve them in an endearingly inept way.

In what has to be the most hilariously unconstitutional piece of legislation that I’ve seen in quite some time, senators in the Arizona state legislature have introduced a bill that would require all educational institutions in the state — including state universities — to suspend or fire professors who say or do things that aren’t allowed on network TV. Yes, you read that right: at the same time the Supreme Court is poised to decide if FCC-imposed limits on “indecent” content in broadcast media are an anachronism from a bygone era, Arizona state legislators want to limit what college professors say and do to only what is fit for a Disney movie.

Good luck with that, AZ.


Giving some thanks

Since gratitude’s apparently health-improving, here’s a quick list before I get back to work:

  • I’m thankful for my current freelancing gig, which has me doing interesting geometry-processing work instead of the PHP/Javascript web-dev grind I had earlier this summer and even pays a little bit better;
  • I’m thankful for dmr’s gifts of C and Unix;
  • I’m thankful for being both American enough and Canadian enough to “celebrate” Thanksgiving twice a year, even if that celebration mostly involves watching football while I write code; which reminds me that
  • I’m thankful for telecommuting, wi-fi, and laptops, and incidentally for Charles Woodson interceptions;
  • I’m very thankful for the robust West Coast craft beer market;
  • I’m thankful for Ricardo’s Law of Comparative Advantage; and finally
  • I’m thankful for Porsche 935 build threads.

That was fun.  Back to work.


Dennis Ritchie has died

So it goes.

Update: I suppose it’s a fitting tribute to dmr that I’ve spent the day writing C — in 1TBS, of course — on a Unixlike.  Not out of any mawkish sentimentalism, mind you: I’m Getting Shit Done.  Not as clumsy or random as a scripting language, but an elegant platform from a more civilized age.


The superstar economy, software edition

Auren Hoffman has a post up about the future of the programming industry (helpful hint: software development isn’t exempt from the real world):

Most of the post is elaboration on the title, with terms like “Jedi Master” and “A-player” substituted for “awesome programmer” every once in a while to add variety.  I can’t find much to argue with in the general thrust of the argument, although I could nitpick a few details.  But then we come to this:

Over the next generation, we are moving to a world where most (like 90%) software developers will earn a decent wage (say $50k/year) and a few (like 10%) amazing developers will earn over $500k.  Yes, the income distribution for the same profession of people who went to the same university and had the same SAT scores could actually be that stark. 

I want to point out that I’m not advocating that this divergence in compensation happen.  I’m not.  It has the potential to fracture society.   And it seems like it will massively reward people that have lucky breaks.  But I’m worried that regardless of how we feel about this growing division between the A-players and B-players, it will happen anyway.

This stark division is already happening at companies like Google.  Most engineers there have similar backgrounds and all get paid well.  But a few of the amazing engineers earn compensation over ten times the average.  Yes, 10x.  One day, every company will look like Google.

(Emphasis added.)

This is all true.  But for reasons which I cannot fathom, it’s presented as if it’s a bad — even outrageous — thing.

Hoffman spends the entire post talking about how programmer skill is the only thing standing between you and me and our jobs being outsourced to India or an unusually clever Ruby script, and then drops the subject like a live hand grenade the minute money comes up.  Only in the last paragraph does he admit that the Google engineers who earn over ten times as much money as their colleagues might be “amazing” at what they do.  Even so, he insinuates that those “amazing” engineers have some sort of unfair advantage — the others have “similar backgrounds”, but (it is implied) not the superstars.  Obviously they lucked out in the genetic lottery, or chose the right parents, or something.

Otherwise, we are treated to a litany of pathetic excuses for the B- and C-players.  They had the same SAT scores as the A-players!  They went to the same universities!  They did all the right things, apparently, but didn’t catch the “lucky breaks” that blessed the A-players.  It’s unfair!


The A-players are A-players because they’re fucking good at what they do.  They are “Jedi Masters”, “awesome” developers whose skills and professional acumen leave their compatriots in the dust.  Probably some of them got lucky with genetics and came away with a better working memory, or were born into families that prized learning and building and doing, but the rest of them got there by working their asses off — if you want a better working memory (and you should, if you’re a progammer), all you have to do is spend half an hour a day n-backing.  It’s tedious, and it works.

Programming in particular leaves one with vanishingly few excuses for mediocrity.  It’s not like TIG welding or thoracic surgery: all the tools you need to learn how to do it (or improve your craft) are available online for free, and there is no cost for failure.  Getting into the game isn’t such an easy business, but once you’re in — and if you’re in Hoffman’s intended audience, you’re in — the only thing holding you back from excellence at your craft is your own ambition.

Before someone comes along and claims that by “lucky breaks” Hoffman means “launching the right product at the right time” — well, buddy, that’s a matter of skill, effort, and ambition too.  If you’ve been keeping track of Google, you’ll have noticed that they’ve launched a thundering herd of services that never took off (about half of which were attempts to compete in the social-networking market).  Apple didn’t “luck out” when they launched the iMac and began their resurgence: they’d had two decades of experience in the microcomputer market when the iMac G3 came out in 1998, which included plenty of failures from which to learn.  One successful product launch might — might — be a lucky break, but sustained success isn’t.

Spare me the whining about classmates who make so much more money than the rest of their cohort.  I could look around at my B.Sc. convocation and see plenty of people who’d half-assed it for five years and learned just enough to graduate… and a handful of people who put me utterly to shame.  I suspect that a few of the latter had better analytical skills than I did, but I can vouch for the fact that the vast majority of them spent more time working and less time drinking than I did.


The economy as (metaphor)

Arnold Kling points us to Paul Rosenberg pointing us to Anat Shenker-Osorio, who notes that:

The dominant metaphor in public discourse is a conservative one – the economy as body – with implications that tend toward passivity and acceptance of whatever ills there may be. The dominant progressive metaphor – the economy as machine, particularly a vehicle – has opposite implications towards action, and taking steps to fight against economic disasters.

I’m not immediately persuaded that either of these metaphors dominates public discourse.  Neither is Kling, who adds:

If the economy is a machine, then perhaps it can be tuned by skilled mechanics. If it is not a machine, perhaps those skilled mechanics will get things wrong. It is not surprising that progressives think in terms of the machine metaphor, while others of us do not think in those terms.

Lately I’ve come to think of “the economy” in comparison to a large software project.  Most people assume that this follows the “economy as machine” metaphor, because software is almost entirely deterministic and created by engineering types.  This assumption is astoundingly wrong, and the fact that it persists among people who commission and manage software projects explains most of the cataclysmic fuckups in computing history.

Lemme ‘splain.

Assuming we’re not talking about crawling horrors from the 1960s, software is composed of small, well-defined pieces at its lowest levels.  Just as I don’t care where my pencil came from or how it was created, the chunks of code I write don’t care where their input comes from or how it was computed. We write software this way to break its complex problems down into manageable chunks.  If I’m writing a webapp, I don’t need to care about how to decode voltage levels on an Ethernet bus into bit patterns, or how to set pixels on the screen of a MacBook Pro; I just need to care about rendering HTML and wrangling HTTP requests.  Similarly, if I’m running a grocery store, I don’t need to care about building the diesels in the container ships that deliver Pocky to this continent; I just care about whether the Pocky I ordered gets to my store before I run out of inventory.

Much like a machine — that diesel, for example — a software package sure looks like it can be designed: like the whole thing can be specified carefully ahead of time by a clever designer and manufactured to precise tolerances by diligent software engineers.  The problem with software design is, again, a problem of scale: the number of components needed is intimidatingly large, and the number of interactions between those components is larger still.  Each of these interactions affects the implementation of each component, and the implementation of a single component often creates new interactions that weren’t obvious at the design phase.  Imagine designing an engine, and discovering that the oil channels cut into the block weaken it at a critical juncture.  You reinforce the block, only to find that the added thermal mass makes your existing cooling system inadequate.  Beefing up the cooling system requires a larger oil pump, which affects the propshaft placement, which means the crankshaft races, which means more changes to the block… and now this relatively simple, century-year-old technology has defeated your ability to design it up-front.  Software is like that, but thousands of times more so, because the interaction between parts isn’t limited by physical constraints.

So while software architects will try to design systems in their heads or on whiteboards before a single line of code is written, real software is designed — in the engineering sense of the word — as it is written, or if you’re lucky slightly before it is written, one component at a time.  Then it gets redesigned when other components upon which it depends are implemented (or themselves redesigned) and the underlying assumptions change slightly.  Maybe the team working on one of those other components figures out how to make it ten or twenty times faster, and you can change your component to take advantage of that new capability.  Maybe there’s a subtle bug in your component’s output that doesn’t manifest itself until those erroneous data have been folded, spindled, and mutilated and passed to a component five or six levels removed from your own, costing weeks of debugging effort.  Software is predictable at the micro level but very unpredictable at the macro level.  Sound familiar?

One of the first — and still one of the best — books to be published on software design is Fred Brooks’s The Mythical Man-Month.  In it, Brooks introduced the proposition that “adding manpower to a late software project makes it later”, which is now known as Brooks’s Law.  The main insight here is that software isn’t produced simply by having N programmers cranking away on their keyboards for T hours until T*N exceeds the complexity of the project.  Programmer time can’t be aggregated into a common pool and reassigned arbitrarily; neither programmers nor lines of code are fungible.  The patterns of interaction between specialized components, and the adaptation of those components to the required interaction, are critical.

Of course, all metaphors suck in one way or another, and this one sucks in the end result.  Software is designed — however imperfectly — and it is intended for a specific use, to solve a specific problem or to implement a specific set of features.  Economies aren’t like that.  You might do your level best to build a manufacturing economy and end up with a service economy instead.  I’m sure there are other limitations.

anarchocapitalist agitprop

Be advised

I say fuck a lot



Statistics FTW