Philip Guo

Philip Guo wrote a great post several years ago under the title "Helping my students overcome command-line bullshittery"[1] that seemed to get somewhat mixed but mostly positive reception. Much of the negative reception seemed to be chained to sophomoric arguments originating from folks stuck in the second panel of the glowing brain meme who wrongly thought of Guo being stuck in the first.

The real truth behind the mess we're in[2] is that there is a ubiquitous, universal runtime that almost every computer comes equipped with, and the problem lies with the folks responsible for those ecosystems who either don't see these things as problems, or somehow believe that what the future somehow holds is native support for R/Python/what-have-you in the browser.

Tooling is a massive problem, though, and one that the browser vendors themselves don't seem to care to get right. (Although there is the Iodide project, in part supported by Mozilla.) And it really doesn't help that the browser realm has come to be conflated with the NodeJS community because they share a common language.

I've written a fairly thoughtful post[3] before, tying these two topics together:

> After finding out where to download the SDK and then doing exactly that, you might then spend anywhere from a few seconds or minutes to what might turn out to be a few days wrestling with it before it's set up for your use. [...]

> the question is whether it's possible to contrive a system (a term I'll use to loosely…

My advice: don't worry too much about picking a field (and definitely don't focus too much about what people who happen to be the same age as you are up to -- it's a big world).

'elonmollusc's advice is really sound: at least at the beginning, choose the advisor or collaborators, not the subfield. You can probably get yourself interested in any problem if you put effort into it and enjoy the work or the people you're working with. And even if you don't enjoy it, you'll learn something about your own preferences and what kind of environment and style of work you want to build around yourself. Is there a class you've taken where you really enjoyed the material or the professor's style? Go to their office hours and talk to them about research. It's even better if you bring some of your own ideas for what you might be excited to work on (perhaps keying off some of the professor's own recent work; do you have an idea for a way to extend it or a new place to try it?) -- faculty love it when students are a source of new ideas.

If you want to do grad school in CS, here is some stock advice:

- Read some of the essays that people have written about "what grad school in CS is like." I did an interview on this with my friend Eugene Wu (http://www.pgbovine.net/PhD-interview-eugene-wu-keith-winstein.htm), and our friend Adam Marcus (http://marcua.net/writing/gradschool-guide/) also wrote a guide after finishing his PhD. Our other friend Phil Guo also wrote a depressing book about his…

I'm a little confused about what the author is really trying to say. In this article, it sounds to me like he is saying that all of this interaction with the command line is arcane, stupid and just needs to go away.

But then I read the other article he wrote which he referenced in this article ("The Two Cultures of Computing" -- http://pgbovine.net/two-cultures-of-computing.htm). In that article he discusses how there are two groups of people -- the "User" group that just wants to do everything with a GUI interface, and the "Programmer" group that likes the intricacies of the command line. There he discusses the difficulty he had with explaining to students the justification for learning the command line tools (which included the fact that they provided more flexibility than the GUI tools alone could achieve).

He concludes the "Two Cultures" article by encouraging folks in the "Programmer" group to bridge the gap between the two cultures:

"You need to gently introduce students to why these tools will eventually make them more productive in the long run, even though there is a steep learning curve at the outset"

Although I dislike the notion that the command line is "bad" or "arcane" just because it has been around for a long time (which the "Two Cultures" article seemed to harp on a lot), I do agree that bridging the cultures is an excellent idea.

And then I go back to the article referenced in this post, which seems to be saying that all this interaction with the…

Hey, Philip - thanks for posting this and also the previous write-up of your experiences as a helper in the 'boot camp' (http://pgbovine.net/teaching-librarians-programming.htm). It is very valuable, including the photos. Very nice, multi-generational group - must have been quite a challenge!

But I agree with calhoun137 when he says there is no fundamental user/programmer culture divide. Programmers are users with a deeper understanding and wider toolset. We all want to get stuff done quickly and move on with our lives rather than drown in computer-driven drudge work. So it seems like a course for beginners should start from that common point, and really be focused on (a) uncovering the problems they're already solving by hacking together the tools they know (e.g. getting data into Excel charts, or whatever) and (b) using the inefficiencies in their solutions to motivate learning or building tools with more leverage, etc.

I can't help but think from your description, the student "regular users" are the ones with a pragmatic/hacker approach, using the limited tools they know -- while the instructor "programmers" are the users stuck in religious attachment to their arcane tools. Maybe the course would go better adopting some of that "regular user culture", AKA hacking ;)

I'm sure it was more complicated than that and for one thing I can really empathize with having to deal with massive variety of platforms etc. Might be worth setting up a common VirtualBox image that…

> That's actually a problem with things like
> "Girls Who Code" or whatever it's called:
> while getting girls coding, it also introduces
> the idea that girls don't code, and that when
> they do, it's "novel". Anyway, I don't have a
> solution for that (and I'm not opposed to those
> efforts in any way), it's just something to
> keep in mind.

You make a valid point. But there is some research that suggests that limiting membership to certain groups does make members of that group more likely to participate[1][3]. It sounds counter-intuitive to me, but the research and examples are there.

I agree that in an ideal world, we would simply find the idea of "girls who code" equally weird as the idea of "girls who breathe"

But the unfortunate truth is, there is a gender gap in programming. Its very real - we all know the stats. There is a reason for this gap, and it very likely has something to do with our society, culture, and us. I don't know about you, but I'd like to find out more about what those reasons are, and if there is something I can do to change that, I would. Why not? It would be great!

The one thing I disagree about is that angry attacks or lynch mobs are a good strategy to go about this. Most male programmers are highly intelligent individuals - if the reasoning behind an idea is explained to them in a calm and logical manner, I believe they will be very likely to accept the explanation. In contrast, if the explanation or actions are…

Here is a different perspective, all be it in a cynical tone:
http://crypto.junod.info/2013/09/09/an-aspiring-scientists-frustration-with-modern-day-academia-a-resignation/

And here's another, with much more objective tone:
http://www.pgbovine.net/PhD-memoir.htm

My take on the subject matter is that:

- When getting into the PhD. track, one should be aware of what he/she is getting into, and be prepared for the resulting lifestyle.

- One should have an extraordinary drive (even to the point of personal obsession) to search for answers towards the unsolved problems in his/her field of study despite knowing the consequences that will be imposed onto his/her life by this intellectual journey.

- One should find a PI whose personality clicks with his/hers, and whose research he/she is motivated to work on. It is pretty rare to match these two parameters perfectly, but one can weigh trade-offs, and work with the best available while still maintaining his/her aspirations.

- One should realize that, regardless of popular belief, academia is business with its own business model: understanding the intricate business logic behind the model will facilitate one greatly in his/her quest.

- One should realize that like every human society, academia has its own fair share of personalities and egos, and intrapersonal skills matter, a lot.