Filed under Projects

Graduate School Semester 2

I’m about a month into my second semester of graduate school at Cornell’s excellent Computer Science department. (Shameless plug: If you applied and got admitted you should definitely come visit, we’re awesome. If you’re thinking of applying contact me with questions.) The first semester involved a fair amount of getting used to grad school life. It’s pretty different from undergrad and I covered my initial impressions before. There’s a lot of autonomy (even in the first few semesters) but that means it’s all that much easier to screw up. The most important lessons I’ve learned are to start early, make plans and schedules and set up routines and environments that make getting the work done the default (this applies to both school work and research). I’m definitely not perfect at it, but I try to suck a little less each day.

While last semester was a good learning experience I got a lot less done than I could have. While I don’t want to cry over spilt milk I certainly don’t want to make the same mistakes again. My class load and TA work are about the same as last semester. However I have a better idea of how much time each takes so I can schedule blocks of time more effectively to get large chunks of work done at a time (and not worry about it otherwise). That in turn means that I can have more time for research (which is something I definitely want to do more of this time around).

I’m really happy about the choice of classes I have for this semester. I’m taking Advanced Programming Languages and Datacenter Networks – both are areas in which I have an interest but I know less than I would like to. I have great professors in both and so far the material has been very interesting (and useful). I’m the TA for a class on functional programming which is turning out to be a good learning experience as well. I’ve done some amount of functional programming but not a lot and not in a structured way. I’m working through the exercises and homeworks myself so that I can better help out the students and learning a lot in the process. Since I’m going to be doing a lot of functional programming in the future (Haskell programming in particular) this a good way to level up as well as get my TA duties done.

Last semester I had a small research project which was more of way to get familiar with the concepts and tools I’ll be using later. I am a little disappointed in that my final deliverables weren’t as complete as I would have liked but the experience will come in handy. This semester I have a more concrete (and more ambitious) project. I’m also starting sooner and thanks to last semester I have a far better idea of the challenges I’ll face and how much work it will take to get around them. My main interest in programming languages and right now the project isn’t very language-oriented. But there is a lot of cool systems-hackery involved and once the foundations are laid I can move on to the more higher-level language-oriented parts of it. I’m still taking baby steps (figure out build systems, building testbenches and having rather intense discussions with my compiler) but within a week or two I want to progress to the real meat of the project.

Aside: In case you’re wondering, it involves networks and trusted computing, but more on that in a future post.

Apart from school and research work I’m hoping to do some more exploring. Cornell has a really nice campus but I only saw a small fraction of it last semester (and probably spent a bit too much time in my apartment). I’d like to be able to get out more and take advantage of everything that Cornell has to offer. That’s a bit easier said then done in winter, but that’ll change as things get warmer.

I’m still trying to work out the best “work life balance”. While things like Cal Newport’s fixed schedule productivity seem appealing it might be unworkable for me right now. More importantly, I’m still not sure how separate my work and my life should be, or even what constitutes “work”. I haven’t decided if I consider my writing or my on-the-side hacking (which I’ve been doing far too little of recently) to be work, play or something else. Part of me would like to think that the work-life distinction is only applicable to a more Industrial Age setting where you don’t like your job and want to spend as little time doing it as possible. Ideally you should do work you love (which I’m gradually approaching) and have no need to draw a distinction. While that seems appealing I’m afraid it might lead to sitting (or standing) in front of my machine all day which is not what I want to do. Luckily these aren’t questions I have to answer definitely right now, but I can keep refining my answers over time.

I’m hoping that the rest of the semester will have lots of great learning, cool hacks and maintaining some semblance of a life away from my machines. I know that graduate school can easily become a drag and very stressful and I’m determined to not let myself end up in such a position. Luckily I’m in a good department with great support from friends, family and professors. I’d like to see this semester be more productive and a step on the way to deciding exactly how I want my grad school experience to turn out.

Tagged ,

Screenplays for the Web

Yesterday I sat down to put some of my old screenplays online. Screenplays have a very specific format – monospaced fonts, fixed directions for margins, etc. Unfortunately all those rules are for paper and if there’s one thing I really don’t plan on doing, it’s distributing my writing on dead trees. But I still wanted to put my work online and have it look like a screenplay.

When I was taking my creative writing class last semester I used LaTeX to output nicely formatted PDFs to submit and I wrote directly in LaTeX. Though PDFs are great for class submissions and printing I’m very much an HTML fanboy when it comes to publishing online. Unfortunately LaTeX doesn’t seem to export directly to HTML. That’s understandable, HTML still has a way to go before it supports all the beautiful typographic nuances that LaTeX is capable of. There are some LaTeX-to-HTML converters out there, but I couldn’t them to compile on my Macbook. Instead of trying to debug the compile process I threw some regexes at the existing LaTeX source and turned it into fairly semantic hypertext.

HTML is a flexible markup language, but there was some abuse of existing HTML elements involved in coming up with a structure that worked for screenplays. Each piece of dialog becomes a section tag and I’ve really abused the header and paragraph tags. If you can come up with a more semantically “correct” interpretation, I’d love to see it. Anyways, the translation went quickly and with some CSS the result isn’t bad, in my opinion. I converted one of my shorter pieces and put it on my website, if you care to take a look. The whole process took about half an hour including fiddling with regexes and CSS.

So much for taking a LaTeX screenplay and translating it to HTML. But what about writing a screenplay for the web first? By way of inspiration, Stories and Novels is a beautiful site that features complete stories and novels in a beautiful web format (as well as Kindle editions). I’d love to see something similar for screenplays. Now admittedly, people don’t usually read screenplays the same way they read novels or stories, but who’s to say that once the trend starts it won’t pick up (and it would be a interesting experiment regardless)?

Of course, writing HTML (or any form of XML) by hand is not something I would wish on my worst enemy. It’s ok when working on a design and layout but I’d rather not write entire screenplays (or stories or novels or even blog posts) in HTML by hand. Recently, lightweight markup languages such as Markdown and Textile have become popular. They’re designed to be easily converted to HTML and they feel natural to write in. Maybe we could come up with something similar for screenplays? Sounds like an interesting weekend project, I’ll let you know how it goes on Monday.

Happy New Year

Happy New Year Everyone! Hope you all have a great year ahead of you. Apparently the world is supposed to end sometime this year but I’m sure there will be enough time for crazy hacks, awesome technology and interesting new happenings before then. Personally I’m looking forward to branching into serious functional programming, learning more about networks and networked applications, experimenting with cool new programming languages and maybe even making a few forays into mobile development. I hope there’s going to be a lot of learning, lots more programming and even more personal projects that I can release to the public. Glad to have you all along for the ride!

Tagged

Beat Procrastination with Science

Another day and another poor soul on Hacker News grieving about losing the day to procrastination. I’ve been there, done that. Too many times to count. And I’ve heard the story retold in many variations. But the one thing that struck me about this particular story was that the author says, “I’ve still no clue why humans procastrinate (sic).”

Now that strikes me as strange because it’s not like procrastination is some deep mystery of the universe. There are people who actually study procrastination and why humans do it (and by extension, how to fight it). They’re called scientists, more accurately, neuroscientists and psychologists. What’s even better is that someone else has gone and done the work of curating much of the available research in the area and tried to offer a coherent, scientific strategy for beating procrastination. That article (and the references) are a veritable treasure trove of information, but here’s the quick start version to get you up and fighting procrastination right now.

Essentially beating procrastination comes down to three steps:

1. Increase your expectancy of success

Do this by starting properly on small tasks that you can finish easily. This helps to build success spirals where one victory gives you the mental boost to make it to the next. Join groups (like Toastmasters) and create situations that will improve your chance of success. Visualize your goals but be honest about your current situation so that you can plan a realistic strategy to what you want.

2. Increase value

Engage in tasks that are meaningful to you and provide you with ample opportunities for entering a state of flow. Reduce errands and other short, distracting tasks so that you can focus on the things that really matter to you.

3. Control impulsiveness

Set clear and frequent goals. Measure repeatedly and correct course accordingly. Acknowledge that humans are creatures of habits and set ones that are biased towards putting you in a favorable position to get work done.

In conclusion

The breadth and depth of human knowledge can be very surprising, especially when it comes to knowledge about yourselves. If you ever catching yourself saying “I don’t know why I do this” consider the possibility that someone else does know (and has published about it). Science and rationalities can be powerful allies when we are our own worst enemies.

Getting to Work

There is a danger to doing what you love as part of your day job. For a few weeks I’ve been working on a programming project. The project should have been very interesting and motivating. It involved combining programming languages (which I love and have been learning about for years) and networks (which I don’t know that well, but have a growing interest in). This should have been an ideal project – a project with just the right combination of personal skill and challenge. It was a project with definite goals, with people who supported me and wanted me to succeed and were willing to give me regular feedback. And yet it was so hard to actually get myself to do the work.

The Motivation Problem

I think the problem is that for most of my life programming was something I did on the side. In school, programming and computers were never the main course of study. In fact, more than once my parents had to tear me away from the computer. In college I decided to be an Electrical Engineer because I wanted to know how the machine worked from the lowest level up. Though that was an interesting and very fulfilling learning experience I realized at the end of four years that I would rather use computers to do something interesting rather than improve the machine itself. Though I did do a good bit of programming in college, most of my classes did not involve programming as the focus.

But now I’m in graduate school and programming is supposed to be part of the job description. Yes, I know that large areas of computer science are essentially mathematics and you can get away with writing very little code, but that’s not where my interests lie. For me, programming is no longer just something I do for the fun of it. It’s something I do because my grades depend on it and because I’m getting paid for it. It has become work and that has been fairly disastrous to my ability to get things done.

As knowledge about our psychology improves one of the interesting facts that has come up is that intrinsic motivation is a much stronger force than any form of external motivation. In a specific sense that means I need to have an internal reason for doing my work. In a more general sense I need to have an autotelic personality: to “have a purpose in and not apart from itself”. The good news is that I’m in a line of work that favors autotelics. The bad news is that it seems to be all too easy to lose the sense of self-motivation, to feel like that the only reason I’m working is because I’m expected to and I’ll get something definite out of it.

However one more piece of good news is that starting is often the hardest part, especially for something you think you should want to do, but can’t muster the motivation for it. I’ve noticed that once I’ve started and am making progress it’s easy to keep going. The trick is to both start and end in the right way.

Start and Stop

Whenever I start out reading and thinking too much about my problem I sabotage myself. I tell myself the problem is too hard, there’s too much other stuff I need to know first, surely someone else has already solved the problem and I can just use their code. Down that path lies madness (and not getting anything done). Though I’m all for thinking before pumping out code, for starters I like to just jump in and get going.

Diving in and hacking away helps produce the feeling that I’m making progress. Whatever I do at this phase is pretty basic: code cleanup, documentation, minor refactoring, maybe fixing a small bug. The point isn’t to get productive immediately, it’s to load the working context of the program into my brain, to get minor victories that help get past the resistance to start. Once I’m past the initial hump I can pause and think deeply about the core of the problem. Since I’ve already loaded up the problem in my head that also becomes easier.

I’ve learned the hard way that stopping probably is just as important. The key is momentum. During each coding session I build up a certain amount of momentum as I build up a mental model of the problem and the solution. Unfortunately I have to re-acquire that momentum every time I start again. I want to pick the proper stopping points so that the re-acquisition is quick and smooth.

I make sure that I always leave code in a relatively clean state: everything has been committed, there is some amount of documentation and most importantly I’ve identified what I need to do next. That way the next time I sit down with the code I can look up the README or the TODO file and pick off the next thing on the list. If the last commit was broken the next thing is usually something to fix. If the last commit was good I can add a new feature. I use a version control system that makes it easy to roll back changes and commits so I don’t hesitate to put in a “checkpoint” commit, even if it’s broken. The less time and effort I have to spend in deciding what to do next the better a chance I have at actually getting something worthwhile done.

This isn’t about computers

…or computer science or programming. This is about getting work done, work that I love. But sometimes love isn’t enough to get me out of the browser and into the text editor. Habit is often stronger (and less demanding) than will power. The good thing about habits is that they can be both formed and broken. I’m starting to learn that the key isn’t to beat yourself up for being a slacker, but rather engineering your life so that getting stuff done is on the path of least resistance.

And now it’s time to get back to my project.

Follow

Get every new post delivered to your Inbox.

Join 301 other followers