We, as people, spend a lot of time talking about happiness. How to get it, how to keep it, when it’s missing, who has the most, etc. Actually, what I wind up hearing more than talk about happiness is talk about everything everyone thinks will make us happy, talk that really winds up being one logical step away from a more useful kind of discourse. Possessions, experiences, connections, impact. We’re constantly bombarded by everyone else’s idea of how to be happy. “If you do X, you will be happy. If you do Y, you will not be happy.” What if we step back a little bit?

I’m going to take the easy route for now and just define “happiness” as what we all want in life. It is the reason we exist. This almost self-referential definition is also what a mathematician might call non-constructive, since it really only tells you how to recognize it (at best) and gives no guidance about how to create or find it. Defining our purpose in life as maximizing happiness sounds selfish at first, but only until you realize that for most people who aren’t sociopaths, the happiness of others does indeed play a huge role in our own individual happiness. Our individual happiness is the weighted sum of a whole bunch of terms, many of which are dependent on the happiness other people (or entities, such as “the world” or “my university” or “my company”). So how do we maximize happiness then?

Here is my three step plan for maximizing happiness.

Step one toward achieving happiness is figuring out what makes you happy. Figure out what terms enter into your happiness equation, and figure out how much each one matters to you. I’ve learned about myself that, for now, I value things like experiences (good food, good conversation, dancing) and impact (my happiness equation includes a heavily weighted term for the happiness of everyone).

Step two is just making a plan to make yourself happy, based on your happiness equation. One of the things that inspired me to work so hard in school was so that I could have a chance to work at a company like Google, where making a positive difference in the world is baked into the organization’s mission. I’m lucky enough to go to work every day knowing that what I do will positively impact millions of lives (even if just a little bit), and while luck and privilege are undoubtedly parts of why I managed to achieve my goal, I had to understand what my goal was in the first place in order to work toward it.

Step three is go back to step 1 and repeat constantly. Beyond just taking the time to figure this all out, it’s equally important to realize that your happiness equation will change over time, and as a result your plans should change over time to adapt. Make it a daily habit. If what you’re doing with your life drifts out of alignment with your happiness equation, it’s important to recognize it early and address it. As a people, we tend to constantly underestimate how much we will change in the future, and as a result we don’t make it a habit to constantly reevaluate what’s making us happy and what isn’t.

Some of you might recognize the above algorithm as a naive gradient ascent optimization. I leave it as an exercise to the reader to find more effective approaches.

Happiness should be simple, not necessarily easy, but I think this is a good place to start.

I think metaphors are extremely important in understanding. Personally, trying to understand one topic deeply is much easier and more natural when it is expressed in terms of other things I already understand. Even better, drawing these connections between seemingly disparate ideas can often lead to newly synthesized ideas, which to me is arguably the most satisfying moment in learning.

The idea of metaphor probably sits very close to the heart of most software engineers, whether they realize it or not. It’s a natural result of working with something that is inherently completely abstract. How else do you begin to grasp what it is exactly that you’re trying to manipulate? You could even go as far as saying that object-oriented programming might be better described as metaphor-oriented programming. “What does this grouping of code do?” “Well this chunk of code is meant to represent a user.”

So metaphors are important, and maybe even fundamental. I would argue, though, that drawing more non-obvious connections between domains can help with problem solving and understanding. As a dancer, we are taught to entertain audiences by essentially manipulating their perception and expectations: drawing their eye to one hand with a sharp movement, suppressing unnecessary movement like the other hand flopping around carelessly, avoiding repetition, and maintaining a coherent narrative throughout a piece. These are all ideas that have analogues in the software engineering world. Even the goals of the two paths are similar. It is often said of truly great dancers that they “make it look easy, even effortless.” I would argue that many of the best engineers also exemplify this trait.

Recently a friend and I were talking about the differences in choreographing for 4 dancers instead of 30. It’s certainly easier to make all of the movements look the same (cleaning, in the dancer jargon), but it’s also harder to have the same visual impact with fewer people. I started thinking that the situation wasn’t all that different from comparing a string quartet to a symphony. What if you were choreographing for the first time, but maybe had composed a string quartet recently? Are there lessons you could transfer from one domain to the other? It turns out that this is exactly the situation I found myself in. My experience was that many concepts from music composition translate quite naturally into their dance counterparts. All instruments playing the same notes at the same time maps to all dancers moving together. Instruments playing different notes of the same chord in parallel maps to dancers doing the same choreography at different levels, or maybe facing different directions. The ideas of canon and counterpoint map almost unmodified to the dance domain. Somehow, I managed to cobble together a piece with formations and dynamics without really having been directly taught how to do so. Of course, I was also emulating what I had seen from other choreographers around me, but I think the lessons synthesized from other domains helped tremendously in understanding the underlying ideas.

I think learning through metaphor can be extremely rewarding, and can lend to deep understanding if applied correctly. As a corollary, I think it’s extremely valuable to just learn about a whole bunch of seemingly unrelated things (in your spare time, of course). You could even say that it’s a good idea to be a jack of all trades, if it helps you to master one.

It occurred to me that despite the number of times I’ve been asked to talk about what my Masters thesis work is all about, I’ve never really bothered to sit down and describe it outside of my own personal notes and drafts. So I’m going to talk a bit about the motivations and ideas behind what I’m doing, since the actual technical side isn’t particularly interesting.

The idea of code review is a very simple one: if you have someone else look over your code, they can probably help you make it better. Many software companies incorporate this into their development workflow, and it is not uncommon for code review to be mandatory before new code is accepted. While this works well in industry (not to say that it is without faults), it relies on the assumption that every developer writing code is also a code reviewer. If all code gets a second set of eyes and you assume that reviewing code is a much less time-consuming task than writing it in the first place, then the overhead of mandatory code review is fairly palatable.

When we look instead at teaching a moderately large programming class with a significant amount of programming work, it becomes essentially impossible for the teaching staff to look over student code with any amount of detail beyond superficial correctness, code style, and maybe some high-level concepts. While this is depressing, it is also inevitable when you look at the numbers (we’ll use some approximate numbers from a recent iteration of MIT’s 6.005: Elements of Software Construction):

100 students × 3 projects × 3000 lines per project / 3 students per group
= 300,000 lines of code

300,000 lines of code / 4 TAs / 15 weeks per semester
= 5,000 lines of code per TA per week

I’m not comfortable with the idea of looking at 1,000 lines of code per day as a TA. That’s not even including the smaller problem sets we had throughout semester.

How can we make sure that student code gets looked over and corrected?

One approach is to bring in more people by bringing the students into the review process. This has three advantages: reducing the load on the teaching staff, teaching the students how to review code, and exposing students to each other’s code and comments. It is easy to imagine a class where after an assignment is due, each student is then given the task of reviewing some amount of code written by classmates, after which the feedback would be collected and presented to the students for their own benefit, and also to the teaching staff to facilitate the grading process.

While existing review systems are built for small teams of experienced developers whose primary goal is to improve code quality, our problem is fundamentally different. A classroom code review tool needs to be built for a large group of students of varying levels together with a small group of (hopefully experienced) teaching staff. Furthermore, while code quality is important, the primary goal in a classroom is to teach the students how to be better software engineers. By designing a few key features into the system with the characteristics of our reviewer population in mind, we can accelerate and improve both the quality of the code review and the quality of the student learning that result:

• Code partitioning – Because it would be unfeasible to simply distribute an entire project to a student for review, student code needs to be partitioned into small “chunks”, perhaps on the order of 50 lines each, to distribute to peers.
• Discussion support – Users can reply and vote on existing comments, allowing students to directly communicate with each other in the context of code.
• Reputation system – Users are rewarded for high-quality comments, incentivizing  participation. This can be in the form of “karma” points, achievements or badges, or both.

The other approach is to bring in better tools to help streamline and automate the review process as much as possible. This is something that doesn’t quite exist yet in the wild. Our current state-of-the-art tools to ensuring code quality fall largely into two categories: completely automated systems like testing frameworks and static analysis, and completely user-driven tools like existing code review systems (Gerrit, Rietveld, Review Board).

Ideally, our tool would sit between these two extremes and aim to increase the efficiency and quality of the code review by automating tedious work and gathering relevant data. Our users are experience-rich and time-poor, so the it is the primary responsibility of the tool to decide how best to target their attention.

• Automatically generated feedback – Existing static analysis tools (Checkstyle, FindBugs) can often generate many of the same comments that human reviewers would otherwise leave. Why not add the output of those tools into the same interface that human reviewers use and allow users to upvote/downvote/reply to them.
• Clustering similar code – If a piece of code is unfamiliar to the reviewer, it could be extremely helpful to look at a piece of similar code somewhere else in the system that has already been reviewed and annotated.

In short, my thesis work is to improve both the code review process itself and software engineering education by adding students (and others) into the review process and giving them an intelligent, easy-to-use tool to make that process as easy and streamlined as possible.

Walking home from lab earlier this week, my roommates and I stumbled on one of the more exciting things to happen to me this week: a new cafe had just opened along the way between our apartment and campus. Was it any good?

• Pastries? Homemade. Check
• Decor? Pretty, lots of natural light. Check
• Espresso? Barrington Roasters, locally-sourced. Expertly prepared. Check plus
• Attitude? Just enough. Check

It should have been, by any measure, a tremendously exciting discovery. Who doesn’t love finding a great cafe in the perfect location? They served some of the best espresso I’ve had since I was in Seattle (I miss you, Vivace…), and their almond croissant was delicious. I’m pretty sure those are the two most important things you can ask for in the morning. Normal people don’t care you say? Skewed priorities? I don’t know what you’re talking about.

Yet the feeling in my heart was as bittersweet as the (wonderfully complex and aromatic) espresso drink in my hand. I had already made up my mind that this was my new daily cafe, and was anxious to get home and finally get to be the first person to review a place on Yelp. I was going to be so cool. But something heavy weighed on my mind, a feeling that only grew worse as we kept walking.

I was going to have to break up with my old cafe.

How was I going to tell them? Would they be angry, or maybe just sad? I don’t know which would be worse.

“I’m…I’m sorry, I just walked in and saw those single-source espresso roasts and beautiful bare naked portafilters, and I couldn’t hold myself back.”

“You monster.”

Am I going to regret this? Am I going to miss walking in and making cheerful small talk about the weather while they automatically prepared my usual drink without me even having to say anything? Will things ever really stop being awkward? Can you really be “just friends” with a cafe?

“Oh… hey…”

“Um, can I just get a chai latte? You know, for old time’s sake?”

“Yeah, sure.”

“…I’m really sorry about everything.”

“I know.”

What is it really that makes someone the leader of an organization? Is it that they are persuasive, and can influence people to think or act a certain way? Is it that they consistently act in the best interest of the organization itself? Or is it that they receive the credit and recognition for the organization’s actions?

All of these things are what I would consider either side-effects of leadership, or properties of good leaders.

I think we could all agree that the act of making someone a leader is a specific and definite action. Think back on every election or inauguration that you’ve ever seen. There is a moment where some previously unimportant person is through some magical means made the leader of some group. What really happens at that moment? You can’t instantly force someone to be persuasive. You can’t force someone’s goals to align with the group’s. You can’t force the rest of the world to acknowledge a positive contribution. So what wizardry, at that very moment, suddenly makes them a leader?

The zen of leadership is that being the leader of a group means that you are accountable for the group’s actions.

You are the person that people blame when something goes wrong, or when something doesn’t happen. You can delegate tasks to subordinates, of course, but ultimately if they fail then it is your own failure as well. The flip side to this is that, in the purest sense, a leader isn’t directly tasked with actually doing anything.

I would argue that the ideal leader of an ideal group does nothing at all.

So when the President of the United States is inaugurated, or when a small group of students all subconsciously elect the one poor schmuck among them to be “the responsible one,” there is no magical process that instantly makes that person the confident, persuasive visionary that we often associate with a position of leadership. What really happens is that we have chosen the person to blame when things go wrong, hopefully because we trust them to make it right when they do. Nobody wants wars to break out, or projects to run behind schedule, or budgets to run over, but because these things are so inevitable, we need some correcting force to make sure that those problems aren’t the end of us all.

Leadership is about being the one to blame when things go wrong. It is about making up the difference between that perfect ideal of completely competent people acting completely selflessly, and the reality of imperfect people all pulling at their own individual goals and interests.

This semester I have the pleasure of teaching a recitation of about 15 students the basics of software engineering as part of my TA duties (this Master’s degree won’t pay for itself, sadly). The course, 6.005, is taught in Java and is more or less the replacement for the old 6.170 Software Engineering Lab that MIT once offered.

One of the points I made during the first class was that programming is more about a conversation with other people rather than a conversation with a machine.

When one first starts learning to program, it really does feel like you are somehow talking to a computer. You type some words in a text file, save it, and when you run it, your silicon companion will either helpfully respond with the correct answer or squawk at you irritably and tell you to try again. For small programs that never grow beyond one-off scripts and toy projects, this is about the highest level of discourse that really ever gets reached.

As your projects grow in both the amount of work that needs to be done and in the time it takes to complete them, it becomes increasingly important to write your code not just as instructions to a computer, but as documentation to anyone else working on that code. You are just as much, if not more, telling the computer what to do as you are telling the next person to read the code what you mean to do. Sometimes, the next person to read the code might even be yourself in the future, well after you have forgotten the thought process behind the original code.

I’ve found that thinking of programming this way has inevitably led me to write clearer, better code and clearer, better comments. I imagine a colleague sitting next to me and then I pretend that I’m not allowed to communicate in any way other than the contents of the text file that I am editing. If the code is obvious, then my intentions are clear. When I do something that looks funny, or pause to think about a decision (perhaps some trade-off or compromise), I imagine the furrowed brow and confused expression on my friend’s face. These are then quickly remedied with an illuminating comment or bit of documentation.

Writing clear, understandable code isn’t a once-over kind of process after the fact, and it doesn’t have to be difficult either. I’ve found that by keeping my imaginary friend in the back of my head while I do my work, the output is inevitably better for myself and for others. Or maybe this is all just an excuse to justify having an imaginary friend.

Here comes one of those watershed moments, where our young Homerian hero, once starry-eyed and full of naive curiosity and innocent ignorance, looks back on his past and recalls all that he has learned through his travels. What a marvelous and fantastic journey! A long, winding tale filled with feats of daring, moments of great happiness and equally great anguish, foes conquered and friends won and lost.

And so, what wisdom can I impart, you ask?

Trader Joe’s Frozen Tamales. They are very tasty, and very convenient on a late night after all other dining options have closed. Always keep a few reasonably healthy, tasty, and filling food options in your freezer. “Break glass in case of emergency” if you will, although I’m sure your kitchen-mates will be displeased if you choose to smash your fridge open in the event of a hunger pang.

A few other things:

• Dress up every now and then, even if you feel terrible. A lot of times, if you feel tired or upset, dressing to look the part will only make things worse. As much as your outside reflects your inside, sometimes the inside can follow the outside too.
• Get off campus at least once in a while; it is healthy and will make you less crazy and more happy.
• No matter how many friends you think you have, there are usually about 10 times that many people on campus that you will never get to know, but would make wonderful friends with you if you ever met them. Moral of the story is to always meet new people, especially outside of your regular social circles.
• Everyone and everything will clamor for your time: clubs, classes, friends, enemies, girlfriends, boyfriends, hobbies, jobs, and a million other things. Learn to say no. Consciously taking time for yourself, even if it’s just 5 minutes in a day to listen to some music, catch up with an old friend, or even just dancing/singing in your room alone to a silly song, is invaluable to your mental health and happiness. “Me” time is a precious commodity.
• Sleep.

Oh, and greek yogurt. Buy it and eat it, especially the honey-flavored kind. Mmm.

I finally managed to finish painting my room and move all of my furniture back to some semblance of a reasonable layout. It’s quite a stunning paint job, if I may blow my own proverbial horn a bit, involving vertical stripes (to draw the eyes up) of varying (semi-random) widths (to generate visual interest and balance) in an alternating color scheme of medium gray (studio gray) and fluorescent green (green apple) separated by a nice warm white (loft living). I’m a sucker for paint names. Almost the same way most people are suckers for Crayola color names. Macaroni and cheese was always disappointingly waxy (“This isn’t food at all!”).

Finally, at 4:30am, I decided it was time to go to bed. This was a mistake, however. What I hadn’t anticipated were the splotches of dark blue that the previous resident of the room (damn you Wesley!) had careless splashed on the ceiling when he painted it last. Since I had carefully taped off the ceiling, the blue spatters remained. Taunting, haunting me. “What if people think they’re my fault?”

No.

So at approximately 4:35am, I (in my pajamas) grabbed a paint brush and stood on my bed, carefully holding a paper towel underneath the brush to prevent any drips onto my sheets. I think what really pushed me over the edge was the fact that I had just enough paint left in one of my paint trays to fix the error. I didn’t even have to open up the paint can again.

Dip dip. Dab dab. Dab. Squint… Brush brush. Dabble. Wash wash wash wash.

There, I can sleep now.

A jacket on a pile of clean but unfolded laundry. It was all approximately clean anyways, not too much of a dirtiness gradient going on. Standing quietly, meekly, behind the burgeoning cotton hill, was a dusty monolith trying hopelessly to hide its ebony black bulk from sight. An old grand piano. In better days, she was a magnificent New York Steinway Model D with a black satin finish and a penchant for Debussy, whose glittering whole-tone runs and lush, yet restrained, 20th century vocabulary perfectly showcased her sparkling high end and responsive yet firm action.

But, like an old retired spinster, she fell into disuse and faded into obscurity. What was the point?

I wandered around the apartment restlessly, looking for something of interest, even though I knew I wouldn’t find it. Everything was so familiar, old, worn from overuse. What was the use in buying another useless trinket? I’d only bore of it over time, another lap in the infinite race to achieving something more than a passing interest in anything.

Shelves. Endless shelves. At least, they once seemed endless. Hard disks, CDs, LPs, cassette tapes, printed scores, even inane wind-up toys playing out-of-tune “Twinkle, Twinkle”s and “Frere Jacque”s. Slowly, carefully, I’d gathered them all. What started as a few of my favorite piano works grew to encompass the complete oeuvre of the Romantic piano masters. Why stop there though? Bach, Berlioz, Boulez, Count Basie, Beatles, The. 25 letters left to go, might as well try. Try to finish it, complete what I’d started. All the music in the world. And when someone created something new? It would be mine. I would wait.

All the music there would ever be.

The academics argued, the news outlets exaggerated. It happened, eventually. Frustrated composers wondered what other soundworlds existed, if theirs was the only one. Searching, hoping for some forgotten detail, in vain. Same old laundry. Same old shelves. Same old sounds. There would be no more music.

No celebration. No joy that my long task was finally done, that no more shelves were to be conscripted into eternal servitude in those dark corridors.

My muse was mortal, after all. And she was dead.

Somehow, today, I felt something new. Anger. What foolish endeavor had led me here? Broke and alone, left with only these obsolete, meaningless trifles from another age. This bereaved widower had mourned long enough in the shadows. Turning away from the suffocating mass of plastic and vinyl, I noticed something on my desk: a match. Taking it carefully, I struck it against the brick wall and watched a flame spring into life. I watched as my hand let the flickering light fall to the ground. I left.

And it burned. All the music in the world burned on a funeral pyre made of wood, and brick, and linoleum. My apartment burned. And while it burned, it crackled and roared. The timbers groaned and creaked, crashing down occasionally in a thunderous cacophony.

I thought to myself, with a smile, “Nobody has ever heard the burning of all the music in the world. Nobody has ever heard a phoenix sing so beautifully.”

This is going to be a quick post about a tiny detail that I feel makes for a big increase in happiness for a lot of people.

A lot of computer users, when using text editors or any other application that use monospaced (having the same width for every character, useful for programming and related tasks) fonts to render text (source code, plain text, e-mails, markup, etc.), stick with the default font. On some platforms, notably Mac OS X and most modern Linux distributions, this default font is a fairly reasonable and attractive typeface like Monaco or Monospace. On Windows XP and Vista, however, the default monospaced is Courier New.

Courier New, 10pt

Recently, Microsoft released several new fonts with its new operating system, Vista. One of these fonts is a monospaced font specifically designed for programming, called Consolas. This font, and a few other nice fonts, is available by default in Vista and Office 2007, and can also be downloaded as part of the Office Compatibility Pack for free.

Consolas, 10pt

Isn’t that better?

The only caveat is that Consolas is designed with ClearType font smoothing in mind, and if you do not have ClearType enabled, then things will look very ugly.