Philip Guo

This is the KLEE project mentioned in "The PhD Grind" book [0], which was also on HN recently. I recommend reading it for a behind-the-scenes look at the effort required to complete a PhD in CS. [0] http://www.pgbovine.net/PhD-memoir.htm

I have a Ph.D. in CS from the University of Washington. I'm glad I did it, but it's not for most people. Academic research is like a marathon and the Ph.D. is like a marathon training program. If you don't want to run a marathon, you probably don't need a marathon training program. Yes, a marathon training program is an interesting and rewarding way to improve your running, but it's very likely you can find equally interesting and rewarding ways to improve your running that don't have the grind of a marathon training program. I'd strongly recommend you read The Ph.D Grind at http://pgbovine.net/PhD-memoir.htm before you consider starting a Ph.D program. It's a good summary of what a Ph.D. experience at a top CS university in the US is like.

Philip Guo's "The Ph.D Grind: A Ph.D Student Memoir" is an amazingly well-written and sage chronicle of getting a Ph.D at Stanford from 2006-2012. http://www.pgbovine.net/PhD-memoir/pguo-PhD-grind.pdf https://news.ycombinator.com/item?id=4179982

Philip Guo has an excellent set of video lectures on CPython internals, which includes an overview of parts of ceval.c: http://pgbovine.net/cpython-internals.htm

Here are links to two of my favorite essays that make a similar point: Java for Everything[1] Too DRY[2] And then there's a third, which is not quite the same topic, but still in the same vein. It's arguably even more relevant today than three years ago when it was written, especially given how much attention is being captured by ecosystems that attract folks who end up generating a morass of terrible tooling: Helping my students overcome command-line bullshittery[3] 1. https://www.teamten.com/lawrence/writings/java-for-everything.html 2. http://jamie-wong.com/2013/07/12/grep-test/ 3. http://pgbovine.net/command-line-bullshittery.htm

You might enjoy reading the section, "Intensely Single-Task," in this article, Philip Guo's "How to Be Effective." http://pgbovine.net/productivity-tips.htm He also expanded that section into a full article: http://www.pgbovine.net/intense-single-tasking.htm Here is an excerpt I think you might find useful: "This tip has had the greatest benefit to my effectiveness: When you want to work on a task (e.g., from your to-do list), get your mind to enter a specific 'mode' where it only knows how to do that task. Forget everything else. Remain fixed in that mode until you get tired and have to "break character". Then move onto the next task and repeat." I think it addresses: "Tasks take way longer to complete with forced breaks, especially if the breaks are longer."

I'll add to mcbit's excellent description that there's also advantages in verification. Passes on a simple, intermediate language can more easily be equivalence-checked by symbolic (eg KLEE) or formal (eg VeLLVM) methods to ensure the transformations didn't break the program somehow. So, you get piles of people contributing optimizations plus potential improvements in verifying they work. https://klee.github.io/ http://www.pgbovine.net/PhD-memoir/ucklee-cav-2011.pdf https://www.cis.upenn.edu/~stevez/vellvm/

I, too, wanted a Unicorn Job of this sort: http://pgbovine.net/unicorn-jobs.htm After some trial and error bouncing around in industry/postdoc/etc., I've found that being a PI in a field where I have to raise relatively small amounts of money (compared to Big Science labs) to be the best balance for me at this point. I agree with Fomite that unless I magically get amazing at grant-writing, there's no way that I could afford to sustain full-time staff ... I don't envision myself going down this path since I want to minimize time spent writing grants and maximize my research/teaching/service time.

Python needs a new runtime. This talk shows how bad of shape it's really in. https://www.youtube.com/watch?v=qCGofLIzX6g&list=PLRdS-n5seLRqszBq… Basically, the language doesn't have a "spec" per-se. The language is whatever the defacto CPython implementation happens to do within it's giant eval loop. Another great talk about CPython internals: http://pgbovine.net/cpython-internals.htm

Slightly related, but if you're helping someone start out learning to code, it's worth reading this: http://pgbovine.net/programmers-talking-to-beginners.htm You don't _need_ react to build a cool site in 2016, but if you're dead set on that, then this piece is a good intro to the set of questions that arise!

pgbovine's profile is not as high as it deserves to be See http://pythontutor.com/ and http://www.pgbovine.net/cde.html - but really, all of https://github.com/pgbovine?tab=repositories is worth looking at.

Phillip Guo, the creator of this software is also the author of a very nice book called The Ph.D. Grind. I would definitely recommend reading it. http://www.pgbovine.net/PhD-memoir.htm

I also enjoyed his post on the "Two Cultures of Computing": http://pgbovine.net/two-cultures-of-computing.htm Definitely something worth thinking about as we build tools for other developers/engineers to use.

It's such a shame then that they promote themselves as only caring for the part of their community that has a particular colour of skin. I honestly can't tell if you're trolling here. In case you aren't: that is not what they are doing, and it also isn't a shame. Helping out people who are historically disadvantaged and face current discrimination is nothing to be ashamed about. The goal is to level the playing field. As a white guy, I got plenty of people helping me out for no good reason: http://whatever.scalzi.com/2012/05/15/straight-white-male-the-lowest-d… And I am not the only one who has noticed this. E.g.: http://pgbovine.net/tech-privilege.htm As somebody who financially supports BGC and aims to mentor at some of their workshops, I think they're doing great stuff.

I would recommend reading "The Phd. Grind" by Philip Guo [1]. [1]: http://pgbovine.net/PhD-memoir.htm

For a similar but non LXC version of the same idea check out http://www.pgbovine.net/cde.html Basically it records all the dependencies an application touches while running and creates an environment you can tar up and use on basically any system of the same arch. It even works cross distro. Wouldn't really work for 'the cloud' as you don't get the same security and isolation as LXC and you have to make sure all the execution paths are triggered but for a lot of apps it works great and it's ridiculously easy to use with no setup.

I've found the following guide to be a good refresher for interacting with the non-programmer crowd: http://www.pgbovine.net/geek-behaviors.htm

Turns out the author wrote about that problem, too [1]. The advice is mostly on how memorize names when you get introduced personally, but admittedly this is an even more important problem. Recommended read. [1] http://www.pgbovine.net/on-names.htm

Credit and recommendation are fundamental to any human endeavor - whether applied to Ph.D candidates, poverty and access to capital, patents, or a plethora of other complex societal issues. If nothing else, I always find it interesting to learn how different sections of the society deal with these issues. Though, I did like the other PhD article(http://www.pgbovine.net/PhD-memoir/pguo-PhD-grind.pdf) on HN better as it provides a more balanced story.

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…

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…

Yes, it is a small part of text, but one that may persuade someone into doing PhD, or give a false impression (e.g. the typical one, in which I used to believe: "follow your dreams in academia or get money at a dull job"). (BTW: I guess you know http://www.pgbovine.net/PhD-memoir.htm. Also from an uber-successful PhD student, but the full story, rather than a set of advice.) It may be something about the field (growth, competition with industry). I think it was not a coincidence that out of many friends of mine who did their PhDs, only Wojciech Zaremba (now in OpenAI) had some non-trivial impact on the world. I don't want to imply that even if everything works (topic, advisor, funding, the sense of meaning, the sense of progress, ...) it is any easy path. And I am really sure that even with your skills, work ethics (and luck) it was a challenge. Still, even if one field is rosy (DL or maybe CS in general), a typical PhD experience is hardly sth I would recommend blindly (vide links there: https://pinboard.in/search/u:pmigdal?query=academia+depression). (On an unrelated note: thank you for "The Unreasonable Effectiveness of Recurrent Neural Networks", ConvNetJS and CS231N - they brought me into the deep learning world. :))

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…

> 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…

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…

Here is a different perspective, all be it in a cynical tone: http://crypto.junod.info/2013/09/09/an-aspiring-scientists-frustration… 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.

Not quite a sequel, but he recently gave more details on the post-phd transition here: http://pgbovine.net/one-weird-year.htm.

http://www.pgbovine.net/python-tutor-ten-years.htm seems dead already, in fact.

There is a full course on the subject at http://www.pgbovine.net/cpython-internals.htm.

I'm sorry about that. Maybe you can switch tracks without losing what you've already accomplished. There's a paper by Phillip Guo about conversational programmers. These are people who do not program, but seek to learn programming so that they can be better at some non-programming task. He's got three papers one this topic, but you're most interested in this one: http://pgbovine.net/publications/conversational-programmers-in-industr… Particularly look at table 2, which is a summary of the motives of conversational programmers.