I spend plenty of time thinking about the kinds of questions most ambitious college students do: how should I prepare for the future? What kind of career should I pursue? What’s worth learning?

Most of my college friends plan their next semester, next year, and the year after graduation. Most of my friends in industry plan about as far as their next job. This is a pretty good strategy. I don’t believe in planning any further out than a couple of years, because I can never predict how things change in my life. The future is hard to predict.

I don’t mean you shouldn’t think about the future and have long-term goals. You should have an idea of where you want to be four years from now. Maybe even ten years from now. But you shouldn’t start from where you want to be four years from now and plan out the steps in between [1]. The details of the future are hard to predict.

But if it’s possible to have some idea of where you want to be four years from now, it’s also possible to have an inkling about the world fifty years from now. We know that the world fifty years from now is going to be completely different. There we have it - we know something. Compare the 1960s to today: a total transformation. In the 1960s the Vietnam War was escalating. Cancer was a death sentence. Colonialism in Africa was still unwinding. ALGOL was just invented. The civil rights movement in America was beginning. [2]

Society will change. Even if you don’t share my beliefs about the direction of the future, and even though you can never predict how things change in your life, you can predict something: change is coming. Technological change, social change, and economic change. It’s obvious, but we don’t think about this much. We usually watch events as they happen, as spectators. Every so often we’ll stop and realize what happened. So it’s a useful exercise to think about the future now.

Some specific trends that I believe will play out in my lifetime:

1. We will discover magic (again). Life and society will be transformed several times over by advances in science and engineering. I don’t have a single shred of doubt about this. I can’t tell you exactly what will change, though, except that they will involve rapidly growing fields like biotech, energy, and computing [3]. If only to prepare myself, I like to describe the future as having the kind of change we would call magic: sufficiently advanced technology.

2. We will live drastically longer lives. As a result of advances in medicine, I will probably live beyond the age of 120.

   And there is some chance I will live to an age beyond 300.

   Historical data actually doesn’t support this idea - in recent decades life expectancy has only inched up a year or so per decade (roughly one year from 2002-2010 in the US). This is a problem whenever you look at the past and try to use that to look towards a future of what I believe to be accelerating change. I still believe medicine will be one of the fields that is transformed in the next fifty years. The seeds have already been planted in genomics and biotech.

3. The divide between labor and capital will grow. During my longer lifespan, those with capital - financial resources, machinery, and organizational clout - will gain a growing and disproportionate share of wealth and power over those with labor - employment and time that people have to put into their work. This is closely related to rising income inequality in America [4]. This will significantly alter the political landscape of the future.

   We might be tempted to believe this is an trend that we or society will stop through political action. I read an interesting idea on this: with increasing inequality, larger and larger swaths of the populace would be excluded from access to wealth and power. Most modern nations are democracies, so rising inequality might eventually be checked by majority support for redistributive economics policies (heavier taxes on the wealthy, and so on). But I wouldn’t count on this to let us safely ignore the trend. Inequality will continue increasing for some time. Entrepreneurs and those with capital, expertise, and financial resources will generally emigrate to nations with less economically restrictive policies (more economically liberal policies). And technology is inherently a multiplier on productivity - even if the rising tide of technology lifts all boats, it will still widen the gap.

I don’t believe in planning too far for the future, but I always try to keep these trends in mind.

These ideas as a whole don’t paint a clear picture of the best path forwards. The concentration of wealth in those with capital suggests entrepreneurial careers or careers in leadership. The scientific revolutions that await us suggest deep study in rapidly advancing areas like biotechnology, computing, or energy. And the long lifespans we will enjoy suggests taking time off - after all, we have long working lives ahead of us.

You can’t ever optimize over everything, so picking the two trends you think are the most likely and will have the most influence on the future paints a clearer guiding path. If you believe science and the labor-capital divide are more relevant, that would direct you towards an entrepreneurial career in science. If you believe science and longer lifespans are more relevant, that would suggest a career in research - the academic path takes a long time, but you’ll live longer. And if you think longer lifespans and the labor-capital divide are more relevant, that suggests pursuing any relevant entrepreneurial or leadership career that you enjoy.

What do you think? Let me know!

A crazier side note:

I am much, much less convinced of these things, but I foresee two outcomes for us over the next two centuries or so. Humanity reaches an unimaginably advanced level of technological achievement (exponential technological progress), or we end up killing ourselves off. This binary outcome is a fun thing to think about, but not anything that applies to decisions I make today.

[1] A microcosmic example of this is planning out college. Originally I carefully planned out all the classes I’d take during my four years at Berkeley. That plan was abandoned within my first year at Berkeley because I realized: 1) the professor teaching a class is the most important factor (and it changes every semester), 2) every semester I’d learn about a new topic I hadn’t been interested in before, and 3) new classes emerged every year.

[2] With hindsight we can notice the seeds of the fifty years that followed. Chemotherapy had barely emerged, and is today firmly established in medicine. African nations - independent - still struggle with the legacy of colonialism. And computing has exploded and taken over our lives.

[3] I have no idea if I’ll live to see specific technologies like artificial general intelligence or whatever else is going to be hyped tomorrow.

[4] Income inequality in the United States. Income inequality is falling globally - but largely due to the catch-up development of the third world, where people are finding employment as inexpensive labor. Labor holds value in the third world, ironically contributing to the decline in labor’s share of wealth in America.

A few of the frameworks and factors I’ve encountered for thinking about the decisions and choices I make.

When facing multiple priorities and opportunities that you can take, consider these ideas:

1. The regret-minimization framework: Ask yourself which opportunity you will regret not taking. Ask yourself if you will regret doing something. This has probably been the most influential for me. [1].

   Regret-minimization often helps me think about action versus inaction and risk versus safety. This can be mundane: should you go out to eat with friends or stay inside and eat by yourself? This can be a major life change: would you regret having worked at a startup? Or would you regret having stayed at a stable company? The answers to these questions can change depending on where you are in life. There are cases where you truly might regret going to a startup.

2. Focus on optimizing a single factor and only then seek ways to mitigate the tradeoffs. We tend to evaluate choices based on tradeoffs. [2]

   For example, an engineer friend of mine was trying to decide on which company to join. He felt that joining a rapidly growing startup would maximize his potential upside (through equity), whereas joining a big tech firm would give him the opportunity to learn more, earn him more money (expected value), and boost his resume. Staying at his current company would increase his opportunities for internal advancement. Under this framework, he should examine the most important factor (pick one of: education, salary, upside potential, advancement) to optimize, and ignore all other factors. This is useful because the most distracting part of making a decision is having to consider all of the tiny little tradeoffs that have to be evaluated.

3. Consider which choices are time-dependent.

   Some opportunities can only be seized now. An example would be a job offer about to expire. A subtler category of opportunities consists of opportunities that are better taken now, rather than later. For example, traveling is usually done better when you’re younger, because more activities and more social circles are open to you. But you can travel any time you’re physically fit. Similarly, attending college is usually better done when you’re younger, because of the people you meet and friendships you form, but you could still attend college at any point in life. Then there are opportunities that you have years and years to pursue in the future, like writing a book.

4. Consider your comparative advantages. Which opportunities are specific to your skills, and which are general opportunities open to all? You’re going to have a better chance of success pursuing an opportunity that suits your skills. I wrote more about this in a previous blog post.

5. Potential is greater than what is possible right now. I try to refrain from judging opportunities by what they mean today. Judge them by what they mean for the future. This is more specifically geared towards technological opportunities.

   A relevant example is the recent trend of cryptocurrencies and Bitcoin. I personally don’t find Bitcoin to be very useful. I think it’s very flawed, and I’ve observed that most applications of cryptocurrencies seem like the result of engineers trying to come up with ideas for Bitcoin, rather than trying to solve actual problems with Bitcoin. But I try to stop myself from dismissing cryptocurrencies out of hand, simply because most flaws of cyptocurrencies are only flaws that exist today. They’re implementation flaws, not necessarily inherent flaws. These flaws might be eliminated in the future. A better cryptocurrency might arise. Better exchanges might arise. Brilliant and obviously useful applications of cryptocurrencies might arise. Potential is greater than what is possible today.

These are just ways of thinking about decisions, not hard rules on how to act. I don’t always follow these frameworks myself. Often these frameworks don’t apply. Sometimes they might even conflict!

[1] I encountered this in an interview of Jeff Bezos.

[2] This was a piece of advice I read online, but I forget where I found it.

Like most developers, you probably keep a running list of ideas for apps you might build. I do. They all seem promising and potentially useful. How do you prioritize what to build? One way I try to decide what to work on: I think of my comparative advantages.

Work where you have a comparative advantage. Consider the unique skills, insights, networks of people, networks of beta users, and marketing channels that are available to you as a result of your where you are today and what you’ve done in the past. What you choose to work on should take advantage of those things [1].

College students, like myself, will probably have greater insight into the social behavior of teenagers and twenty-somethings than other demographics [2]. They have access to an extremely broad and dense group of fellow students, all close to their age. They have access to college-specific activities - dorm life, taking classes, parties, homework - and close access to a set of potential beta users in a narrow demographic, other students. A college student can access a huge variety of college-specific marketing channels - friends, clubs, campus billboards, club tabling, and classes. An experienced engineer will have a different set comparative advantages. An engineer might have insight into the problems companies face with software architecture, databases, servers, testing. An engineer will have access to a strong network of engineers, managers, and CTOs. An engineer might have better access to other marketing channels - meetups, invite-only networking events, and technology conferences.

Domain expertise is a subset of comparative advantage. A college student would be hard-pressed to build a better CRM that takes the market. They don’t have domain expertise. On the other hand, an operations leader with years of enterprise experience would be hard-pressed to build the next trendy social networking app. They don’t have any domain expertise. They don’t necessarily suffer from handicaps; they just don’t have any legs up on the competition - twenty-somethings with the same ideas. So they would be better off competing elsewhere and exploiting their own comparative advantages.

Take a moment to think: what are your comparative advantages? What networks do you have access to, both as a result of your location and your experience? What skills do you have? What kind of beta users can you test your projects with? What insights do you have as a result of your experience? What other distribution/marketing channels do you have?

I’m in college right now (after a hiatus). That’s why my latest side project is tackling the problem of buying and selling things locally - a quintessentially college student problem.

A cautionary note: This is only one way to think about choosing your work. Working where you have comparative advantages can sometimes conflict with other valuable goals. Examples include: trying becoming well-rounded, trying to change careers, and trying to learn about new technologies. In those cases you have to take other factors into account!

[1] I don’t use the term as precisely as it’s used in economics. Technically, comparative advantage is the idea that economies are better at producing different goods. Perhaps China produces cars more efficiently than software. Perhaps America produces software more efficiently than cars. Even if America is more efficient in absolute terms at mass-producing cars than China, the idea behind comparative advantage is that if America focuses on software, China focuses on cars, and both trade with each other, both will be richer than if they didn’t focus on their comparative advantages.

[2] I use the term “probably” very loosely, on the assumption that “you get the point.” None of these are absolutes. There are definitely college students who don’t know anything about their fellow students. There are definitely people 10 years out of school that have deep insight into teenage social behavior.

Beezlebubbly is stuck in heaven, and you need to help him escape from the not-too-happy angels chasing him. Fling statues and harps around and protect Beezlebubbly from the arrows.

It’s completely free with no ads or in-app purchases, though I might add in-app purchases if the game gets popular enough.

Like it? Text a link to your friends!

Built with coocs2d-iphone and Kobold2D. Published by MakeGamesWithUs.

The Process

Originally the game was meant to be titled Demolition Gauntlet - featuring a knight running through Hell, chased by demons and devils. That was a pretty uninspiring theme, so I inverted the concept, giving the game the whimsical twist I wanted it to have from the start.

Devils in Heaven was a project I worked on in short bursts, a project that I left dormant for months at a time. I started the game in June of 2012 when I interned over the summer with MakeGamesWithUs (MGWU) after high school. The internship program, which continues today, is unlike your typical internship - it’s more like an incubator where you work on our own game alongside the MGWU developers and other interns. Over three months I finished roughly half the game - while learning Objective-C and cocos2d.

Afterwards, I joined the MGWU team full-time as I took a full year off from school. I worked on the game here and there, bringing it up to 90%, before largely shelving the project for nearly a year until the past few weeks.

There were a couple of difficult challenges. The game features ragdoll physics for the devil and angels, and setting up the parameters for the physical bodies was quite a lot of work. Dealing with physics in general was challenging at times: all the objects in the game are objects that can fully interact with the physical world, which meant dealing with unexpected behavior like being tipped over.

One cool part: I got to use some of the physics I learned in school when I was calculating the velocity of the arrows in the game, using the kinematic equations of motion.

The project was the first 10,000+ lines of code, object-oriented program I ever worked on, and it shows - the code is in dire need of serious refactoring, probably a month’s worth of work. My first target? The entire class inheritance and object protocol (interface) system. The OOP structure that I originally created in the game over a year ago is convoluted, tightly coupled, and distinctly non-modular.

But it works! Hope you like it!

By the way, I’m looking for a summer internship! So contact me!

This was inspired by some bits and pieces on StackOverflow. The gist of it is that you place your textarea inside a wrapper div, set the textarea height to 100% so that it fills the parent, and then insert a div behind the textarea that maintains a copy of the textarea text. The browser will correctly size the hidden div, which will stretch the parent and stretch the textarea.

Here’s a jsFiddle:

A copy of the code is below:

1
2
3
4

<div class="textarea-container">
  <textarea></textarea>
  <div class="textarea-size"></div>
</div>

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53

.textarea-container {
  position: relative;
  /* you should change this*/
  width: 50%;
}

textarea, .textarea-size {
  min-height: 25px;
  /* need to manually set font and font size */
  font-family: sans-serif;
  font-size: 14px;
  box-sizing: border-box;
  padding: 4px;
  border: 1px solid;

  overflow: hidden;
  width: 100%;
}

textarea {
  height: 100%;
  position: absolute;
  resize:none;

  /*
  "pre" or "preline" or "normal" fixes Chrome issue where
    whitespace at end of lines does not trigger a line break.
  However, it causes the text to exhibit the behavior seen with
    "pre" that is described below.
   */
  white-space: normal;
}

.textarea-size {
  visibility: hidden;

  /*
  Pre-wrap: preserve spacing and newlines, but wrap text.
  Pre: preserve spacing and newlines but don't wrap text.

  "pre" does not wrap well on Firefox, even with word-wrap:break-word.
  "pre" on Chrome works with word-wrap, but exhibits different behavior:
  Instead of entire words being moved to the next line for wrapping,
  the browser will cut words in the middle for wrapping.
  "pre-line" has Firefox issues
  */
  white-space: pre-wrap;
  /* Required for wrapping lines in Webkit,
    but not necessary in Firefox if you have white-space wrapping
    (pre-wrap, normal, pre-line) already set */
  word-wrap: break-word;
  overflow-wrap: break-word;
}

1
2
3
4
5
6
7
8
9
10
11
12
13
14

var textContainer, textareaSize, input;
var autoSize = function () {
  // also can use textContent or innerText
  textareaSize.innerHTML = input.value + '\n';
};

document.addEventListener('DOMContentLoaded', function() {
  textContainer = document.querySelector('.textarea-container');
  textareaSize = textContainer.querySelector('.textarea-size');
  input = textContainer.querySelector('textarea');

  autoSize();
  input.addEventListener('input', autoSize);
});

This theme fits in with my observations of frequent users of Instagram and Snapchat. Instagram photos seems to lean towards the aspirational and idealized - an expression of a desired identity. I see my friends posting idealized pictures of food, activities, moments, scenery, and people. Filters get users to share photos of mundane moments when they would otherwise exercise self-restraint.

Snapchat seems to lean towards reality and the moment - a way of communicating your current status. I have friends that just post pictures of their faces (very specifically and almost exclusively their faces) throughout the day. Snapchat has in that sense become Twitter for photos: the disappearance of photos is not a gimmick but just a way to get users to take and share unflattering photos of themselves (the unflattering photo seems to be the hallmark of a Snapchat photo), when they would otherwise exercise self-restraint.

[1] The fact that Snapchat does not have any technology that will actually ensure a photo’s disappearance is largely irrelevant, for the same reason that it’s irrelevant that Instagram does not guarantee your photos will actually look good.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

var module = (function (module) {
  var _private = module._private = module._private || {};
  var _seal = module._seal = module._seal || function () {
    delete module._private;
    delete module._seal;
    delete module._unseal;
  }
  var _unseal = module._unseal = module._unseal || function () {
    module._private = _private;
    module._seal = _seal;
    module._unseal = _unseal;
  };
  // permanent access to _private, _seal, and _unseal

  return module;
}(module || {}));

_unseal must be called by a function (probably some sort of loader function) that was initialized before _seal was called (so that _unseal will be present in its closure scope).

For example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22

var loadScript = function (scriptUrl) {
  module._unseal();
  var script = document.createElement('script');
  script.src = scriptUrl;

  if (script.readyState) {
    script.onreadystatechange = function () {
      if (script.readyState === "loaded" ||
          script.readyState === "complete") {
        script.onreadystatechange = null;
        module._seal();
      }
    };
  }
  else {
    script.onload = function() {
      module._seal()
    };
  }

  document.getElementsByTagName('head')[0].append(script);
};

So… In semver and bower (I’m assuming bower since it relies on the node-semver module), a hypenated version suffix (postfix) decreases precedence <(1.0.0 > 1.0.0-alpha > 1.0.0-1) and non-hypenated suffixes are invalid (1.0.0alpha is invalid).

Whereas in npm, hypenation with a numeric suffix increases precedence (1.0.0-1 > 1.0.0) whereas anything that is not a hypenated number decreases precedence (1.0.0 > 1.0.0alpha). So 1.0.0-1 > 1.0.0-1-a > 1.0.0 > 1.0.0alpha. versioning does in fact follow semver. Npm will automatically append a hypen if you leave it out (1.0.0alpha is 1.0.0-alpha). The (outdated?) npm documentation had led me to believe otherwise. The docs have been updated!

Enter Grunt by Example! A blow-by-blow tutorial. Just the way I like it. Let’s dive in.

The catch - Grunt configuration files can be fairly convoluted at first glance, usually due to the fact that developers add more and more steps to their workflow over time.

Grunt is just a task runner. Every unit of functionality that you would want is usually achieved with a separate npm package (a grunt “plugin”).

npm search grunt to view literally every grunt plugin available.

Get the command line interface: npm install -g grunt-cli

Add the actual grunt task runner as a development dependency to your project (--save-dev adds the package as a dependency to package.json): npm install --save-dev grunt

Let’s follow a process of gradual expansion.

Create an empty Gruntfile.js file in your project root. This will contain all of your task configuration.

Let’s say that the first task we want to add to our workflow is to be able to concatenate several JavaScript files into one. Let’s say those files are all in the scripts/ sub-directory. We’d want to do this before deploying a website, for example.

Run npm install --save-dev grunt-contrib-concat.

Let’s look at our Gruntfile configured with just this one task.

A quick preview of the result before we look at the code. After setting up our configuration object, running grunt concat, grunt concat:dist, or grunt build in the shell in the project root will all do the same thing: concatenate all scripts in the scripts sub-directory into a single script called main.js.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

//Grunt is just JavaScript running in node, after all...
module.exports = function(grunt) {

  // All upfront config goes in a massive nested object.
  grunt.initConfig({
    // You can set arbitrary key-value pairs.
    distFolder: 'dist',
    // You can also set the value of a key as parsed JSON.
    // Allows us to reference properties we declared in package.json.
    pkg: grunt.file.readJSON('package.json'),
    // Grunt tasks are associated with specific properties.
    // these names generally match their npm package name.
    concat: {
      // Specify some options, usually specific to each plugin.
      options: {
        // Specifies string to be inserted between concatenated files.
        separator: ';'
      },
      // 'dist' is what is called a "target."
      // It's a way of specifying different sub-tasks or modes.
      dist: {
        // The files to concatenate:
        // Notice the wildcard, which is automatically expanded.
        src: ['scripts/*.js'],
        // The destination file:
        // Notice the angle-bracketed ERB-like templating,
        // which allows you to reference other properties.
        // This is equivalent to 'dist/main.js'.
        dest: '<%= distFolder %>/main.js'
        // You can reference any grunt config property you want.
        // Ex: '<%= concat.options.separator %>' instead of ';'
      }
    }
  }); // The end of grunt.initConfig

  // We've set up each task's configuration.
  // Now actually load the tasks.
  // This will do a lookup similar to node's require() function.
  grunt.loadNpmTasks('grunt-contrib-concat');

  // Register our own custom task alias.
  grunt.registerTask('build', ['concat']);
};

You might still be confused about the notion of a “target.” More on that:

Let’s say there’s another set of files you want to concatenate. All script files in deploy/ should be concatenated into deploy.js (in the project root). Let’s say we want that task to look like grunt concat:deploy

To achieve that, our concat task now looks like:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

concat: {
  options: {
    separator: ';'
  },
  dist: {
    src: ['scripts/*.js'],
    dest: '<%= distFolder %>/main.js'
  },
  deploy: {
    // options that are specific to the 'deploy' target
    // target-level options override task-level options
    options: {
      // separator:';;;' would override the parent setting
    },
    src:['deploy/*.js'],
    dest:'deploy.js'
  }
}

If you run grunt concat:dist, all scripts in scripts/ will be concatenated into dist/main.js. grunt concat:dist runs the concat task with the config settings that are specified under dist. grunt concat:deploy runs the concat task with the config settings specified under deploy. grunt concat will run concat with both targets, separately. The parent-level options setting specifies config settings that are shared by both targets. grunt build is an alias for grunt concat.

Now let’s tackle a common, yet relatively complicated task.

Let’s get Grunt to run certain tasks in response to changes in files. An extremely powerful and common use-case: reloading a static website when you change its HTML/CSS/JS. It’s fairly complicated and it’s usually something you just copy-and-paste. Here are the steps to setting this up using the watch and connect plugins, along with the connect-livereload (a piece of Connect middleware that is not grunt-specific). For this example, let’s assume that your static website is located in the client/ folder.

Install the three plugins:
npm install --save-dev grunt-contrib-watch grunt-contrib-connect connect-livereload

Add this basic initialization code to the top of your Gruntfile:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18

// This is the default port that livereload listens on;
// change it if you configure livereload to use another port.
var LIVERELOAD_PORT = 35729;
// lrSnippet is just a function.
// It's a piece of Connect middleware that injects
// a script into the static served html.
var lrSnippet = require('connect-livereload')({ port: LIVERELOAD_PORT });
// All the middleware necessary to serve static files.
var livereloadMiddleware = function (connect, options) {
  return [
    // Inject a livereloading script into static files.
    lrSnippet,
    // Serve static files.
    connect.static(options.base),
    // Make empty directories browsable.
    connect.directory(options.base)
  ];
};

Add to your grunt.initConfig object the following two tasks configurations:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30

// The connect task is used to serve static files with a local server.
connect: {
  client: {
    options: {
      // The server's port, and the folder to serve from:
      // Ex: 'localhost:9000' would serve up 'client/index.html'
      port: 9000,
      base:'client'
      // Custom middleware for the HTTP server:
      // The injected JavaScript reloads the page.
      middleware: livereloadMiddleware
    }
  }
}
// The watch task is used to run tasks in response to file changes
watch: {
  client: {
    // '**' is used to include all subdirectories
    // and subdirectories of subdirectories, and so on, recursively.
    files: ['client/**/*'],
    // In our case, we don't configure any additional tasks,
    // since livereload is built into the watch task,
    // and since the browser refresh is handled by the snippet.
    // Any other tasks to run (e.g. compile CoffeeScript) go here:
    tasks:[],
    options: {
      livereload:LIVERELOAD_PORT
    }
  }
}

Finally, we need to run the connect and watch tasks in sequence. To save ourselves from having to type in two shell commands, we can register a task alias:

1

grunt.registerTask('preview', ['connect:client','watch:client']);

Running grunt preview will now run both tasks.

Some more grunt plugins to be aware about (contrib plugins are officially maintained):

• grunt-contrib-uglify for minifying your JS files. It works similarly to grunt-contrib-concat.
• grunt-contrib-jshint for running JSHint.
• grunt contrib-coffee for compiling CoffeeScript.
• grunt-contrib-sass for compiling SASS.
• grunt-concurrent for running tasks concurrently (instead of sequentially) - useful if you want to run multiple watch tasks concurrently.
  • If you have a series of tasks, the watch task must be run last. watch is a task that never ends until you terminate it. Thus, Grunt won’t ever reach tasks that come after watch.
• grunt-nodemon for running nodemon with your node app. This runs your node app and reloads it when files change.
• grunt-simplemocha for running mocha tests.
• grunt-open for opening files and URLs.

Some tips:

1. If your Gruntfile starts getting too unwieldy, you can break it up by using grunt.file.readJSON().
2. Tired of copying and pasting loadNpmTasks? Try this:
   • npm install --save-dev matchdep
   • use require('matchdep').filterDev('grunt-*').forEach(grunt.loadNpmTasks); where you would otherwise list out all your multiple grunt.loadNpmTask calls.

For more advanced concepts, read the Grunt docs! They’re pretty good.