Xaprb

I’ve been increasingly questioning the current model of university education in the US. Not only the value for the money, but just the entire notion that it’s a good way to learn. I got my Bachelor’s in Computer Science from UVA, which has been going through utter facepalm-worthy madness recently. It may be biasing my point of view.

A friend recently sent me this:

This shop was written up in the WSJ last week: http://devbootcamp.com My daughter is looking at it. What do you know about them, if anything? What do you think?

Here’s how I responded:

I don’t know any of them personally. That looks like a much better use of my time than the 5 years I spent getting my CS degree. The curriculum covers a lot of good material. Someone who goes into that with zero programming background will likely come out of it with enough knowledge and context to start doing something productive, but no awareness of deep underlying principles and fundamentals. That is the exact opposite of UVA’s CS curriculum. People often see someone do silly things due to lack of CS background, and say you should have the fundamentals first and then learn the specifics, but I’m not convinced that isn’t elitist BS. It strikes me that an apprenticeship model might actually be a better way to learn than the ivory-tower-then-someday-you-will-code way.

It’s only 9 weeks. What does she have to lose other than 9 weeks and some cash? She could stand to gain tremendously.

The current model of higher education in the US currently seems completely broken to me, and I’m really interested to see how some of the alternatives shake out. One thing is for sure: higher education, and the university model in particular, is about to get disrupted. Hard. Like being hit by a freight train.

I was discussing how to avoid surprising users and someone pointed out that what seems intuitive and rational to one person is often complete insanity for others. The mental gap between a developer and a user can often be a chasm far too wide to cross. Of all the bug reports I’ve filed against MySQL, here is my all-time favorite:

select * from t where a >= 1.0order by a;

Does not cause an error. I believe it should, because there should be a whitespace before ORDER BY.

Similar syntax errors such as “select 1e0from dual” were also accepted as valid SQL. Much soul-searching later, the official reply from MySQL’s development team:

The server behaves properly here:
- “1″ alone can not be an identifier, because it’s followed by a “.”
- therefore, the lexer parses “1″ as the beginning of a number, and ends up with “1.0″ as one token.
The next token will be “order”, a keyword.

There is nothing special to document here either. What was reported is not a bug in the server, and is not a documentation bug.

What just happened here? It’s fairly simple. Never attribute to malice that which can be adequately explained by tunnel vision. The developer decided that the SQL isn’t a syntax error because the lexer is designed to parse it. If the developer were able to stand in a user’s shoes for a moment, this answer would be obviously absurd. But when you live deep in the dungeons of a large codebase, you lose the ability (despite your best intentions) to see a normal user’s point of view.

For this reason I often doubt my own judgment. I’m ignorant of my ignorance. It’s a very “meta” problem. I have to rely on others to give me a sanity check.

I suggest, as a topic of discussion, that the willingness and ability to accept others’ judgment over one’s own is an essential characteristic of good leadership. I also suggest that knowing when this is appropriate is another attribute a good leader must have. Both of these are very difficult in my experience.

A couple of months ago I bent the ear of a friend whose opinion I really respect. She’s a totally sharp engineer who actively writes code for a living as well as managing large teams. She’s held top-level technical roles at some large and extremely respectable companies. In short, her perspective and experience is very valuable.

One of my most important questions was what technologies she saw as established or emerging winners — good technologies to use as the foundation for a startup. I had a list of requirements I needed my technologies to meet, but I wanted to know what other requirements she thought would be important to consider. For example, the ability to hire engineers to work with the technologies.

My prime candidate for a main programming language was Go, and I was also considering Java, Scala, Clojure, and C/C++. Most languages were easy to eliminate based on my requirements. I tried to summarize my reasons for Go and against others, and asked what she thought.

Her response was that Go was probably not a good choice. As she pointed out, one could make the case that it’s immature and unproven, and it’s not clear whether it’s gaining significant mindshare. It’s probably hard to find people who know it, and risky and costly to hire people and then train them in it. She recommended that I consider Java and C++ at the top of my list, because they are safer options for many of the reasons Go would be risky. She also recommended that I consider “cool” languages and environments in order to attract great talent. She put JavaScript and Node.JS onto my list of things to evaluate.

In the weeks that followed, I did a lot of hard thinking, and also sought the advice of many other people. In the end, I chose Go as a main language, and so far I don’t see a reason to change that decision.

Why would I choose Go when so many factors seemingly weigh against it? Partly because it’s easier to meet many of my specific requirements in Go than it is in other languages. Meeting these requirements gives a lot of business benefits (significantly lowering the barrier to customer adoption, for example).

So regardless of the negatives, the positives for Go for my specific use case are very strong.

In addition, the usual benefits discussed about Go are turning out to be very true in my experience. You can read some articles or watch some talks on golang.org to see what those benefits are. It’s not hype; Go really is that good. Check out this great talk.

The real reason I chose Go, though, is that I took it for a test drive and found out for myself. Not just reading about it or doing code tours and walk-throughs — building systems with it. I decided to reimplement my most recent Perl program in Go and see how it went. The program does adaptive fault detection on time-series data at a fine resolution. It takes 1m16s to run on a sample dataset I use a lot. After rewriting it clumsily in Go, it runs in a few seconds. Keep in mind that I’m not a novice Perl programmer, and I don’t think my Perl program could be made much faster. This is an illustration of the execution speed difference between a scripting language and a compiled language.

That was a nice validation, but I wasn’t close to being ready to decide on Go. I spent a few weeks implementing throwaway prototypes for risky or uncertain parts of my planned system in Go, as well as writing portions of things that I knew would be humdrum turn-the-crank code. Along the way I learned a bit about designing to Go’s strengths, and started to become a little bit more productive (I am not as fast a learner as many of the people who say they’ve learned Go in a couple of weeks). I probed into things like how robust its support for MySQL client libraries is, and how easy it is to work with C or C++ libraries in case something doesn’t exist in Go but does in a C library.

I also dug a lot into the community: the mailing list, the blogs, the projects that companies build in Go. It turns out there’s a lot more adoption of Go than I thought at first. There are many major systems written with it, some of them at hot up-and-coming companies, some at older companies. It’s not just Google.

In the end, I still really appreciate the advice from my friend. It was good advice and pointed out a number of things I needed to think about more or investigate further. But you have to make your own decisions, not just follow advice. And that’s the difference between asking a friend for an opinion, and asking a friend to decide for you.