8 Reasons Why Better Nutrition Makes You a Better Developer

Software developers are not known for having the best nutrition. When it comes to development work, the stereotypical late night Red Bull-fueled coding binge is often not too far from the truth. It’s hard to imagine a hackathon without a stack of pizza boxes and a mountain of empty soda bottles. In addition, no good tech firm lets their kitchen run out of chips or Vitamin Water. Proper nutrition is, however, about more than just being thin; it’s about providing proper fuel for your brain so you can code smarter, faster, and better. In this post I’ll give you some anecdotal evidence about why nutrition matters, some resources on how to eat and train properly, and finally give you a list of 8 concrete benefits I’ve enjoyed since I started eating properly.

For over 3 years, I’ve been following a paleo diet along the lines of what Mark Sisson advocates in his blog, marksdailyapple.com. The benefits across all aspects of my life have been nothing short of incredible, and what has surprised me the most was the improvement in my mental performance. I started my diet the summer before my senior year of college. Suddenly I found myself able to finish work in 2 hours that would have previously taken 10 hours and multiple energy drinks. Later that summer, in a burst of effort that I would have considered impossible before, I built out a simple dating app called Grapevine during a 36 hour fast with no stimulants. By senior year my newfound clarity allowed me to simultaneously achieve one of my best academic semesters and land a prestigious job, all while living in a frat house.

Not convinced? Here are the 8 most important benefits I’ve noticed since switching over to the paleo diet:

1) Improves focus over long periods of time
Ask yourself this question – when’s the last time you honestly sat down and worked for 5 hours straight, without having to get yourself some caffeine or a snack? Your body is very good at breaking down simple carbohydrates, such as bread, sugar, or those chips you’re thinking of snacking on. When it breaks these foods down too quickly, your blood sugar spikes. After this spike, your blood sugar will return to normal. Unfortunately for your would-be six-pack, your body interprets this decrease in blood sugar as a hunger signal and causes you start to feel tired and hungry. You know that “2:30 feeling” that Five Hour Energy is always talking about? It is actually a direct symptom of your blood sugar dropping back to normal from that PB&J sandwich you had at 11:30. The 2:30 feeling saps your focus and productivity. You can either fix this feeling temporarily by reaching for a Five Hour Energy, or you can fix it permanently by going paleo.

2) Hunger stops being a distraction
When I was growing up, it became extremely difficult to focus when I was hungry. Not only that, I would become irritable in a manner reminiscent of the Snickers “you’re not you when you’re hungry” advertisements. One day about a month after I went paleo, I noticed around dinnertime that I wasn’t particularly hungry. This was surprising to me, because by the time 7pm rolled around I was always ravenously hungry. Feeling adventurous, I decided to just roll with it and see what happened. Pretty soon I hadn’t eaten for 24 hours and still felt perfectly normal. Ever since then I’ve noticed that hunger has stopped becoming agonizing; instead it’s more of a gentle reminder that I probably need to eat something in the near future. Now I can spend more of my effort focusing on my work and less trying to ignore painful hunger every few hours.

3) No need for energy drinks
Caffeine has its time and place, but caffeine late in the day is a terrible idea and starts a vicious cycle of dependency. You have a cup of coffee in the afternoon only to have trouble sleeping, so you have two cups of coffee the next day to keep yourself going, but then you have trouble sleeping again and the cycle repeats itself. Pretty soon you can’t get through the day without multiple Red Bulls. This may work for a while, but you’re not at peak performance when you’re depending on energy drinks to keep you going and eventually you’re going to crash.

4) No worrying about burning calories
The primitive “calories in, calories out” model of weight loss has been disproven time and again, but somehow gyms and the exercise industry in general have yet to catch up. Nutrition and stress hormones have every bit as much to do with weight loss and gain as caloric expenditure, which is why spending an hour a day on a treadmill is at best inefficient and at worst counterproductive. If you’re not getting the results you want from your daily treadmill workout or spin class, odds are you’re feeling stressed out about it, which in turn makes it less likely that you’re getting the results you want. Even if you’re doing well with your outdated “cardio” workout, wouldn’t you much rather be enjoying quality time with friends, loved ones, and/or Netflix? I got into the best shape of my life around 2 years ago and have been getting in progressively better shape ever since with approximately 20-30 minutes of exercise per week, often even less. I haven’t even touched an elliptical or treadmill in nearly 4 years. If you’re interested in learning more as to how this is possible and why this is the way to go, check out Body by Science by Doug McGuff.

5) Look good
Looking good not only has obvious benefits in your personal life, it can help your career as well. While it may seem irrational and politically incorrect, the fact of the matter is, humans are very visually oriented, and, for better or for worse, we make judgments about the health and competence of other humans based on our visual observations. In the wise words of Harvey Specter from the TV show Suits, “Doing good work isn’t the whole job. First impressions last; if you start behind the eight ball, you’ll never get in front.” Being in good shape may seem like a minor detail, but in can help you stand out in an interview, in a VC pitch, or in your day-to-day.

6) Fewer headaches
I used to get headaches almost on a daily basis before going paleo. I’m not entirely sure whether this was due to sugar crashes, mycotoxins, or something completely unrelated. Now, the only headaches I get are from the occasional late night out.

7) Less time being sick
Having a cold sucks. You spend a few days lying in bed feeling disgusting and then have a mountain of work to catch up on when you feel better. Thankfully, you can avoid particularly bad colds by eating properly – while I do still get a cough occasionally, I haven’t taken a single sick day since going paleo. That’s a far cry from my pre-paleo days, before going paleo I’d spent much of the previous 6 months on antibiotics to fight off chronic sinus issues.

8) More enjoyable life beyond work
Life is all about feedback loops and exponential growth – success breeds success. Succeeding in one area of your life helps the other areas of your life. You’ll work a lot better when the rest of your life is in order, whereas if you’re spending energy worrying about your sore throat or regretting that you can’t go out for drinks because you have to spend quality time with the elliptical, your performance will suffer. Paleo isn’t about renouncing your favorite foods and depriving yourself; if you’re paleo and feeling miserable, you’re doing it wrong. It’s about being able to get more out of life. It’s about being able to eat a late lunch when you’re in the zone without sacrificing your mental acuity. It’s about being able to stay up late enjoying the company of good people every once in a while without paying for it the next day. It’s about not skipping out on good times after work hours because you ‘have’ to go running.

Want to learn more? Dave Asprey has an excellent one-page explanation of the paleo diet on his blog The Bulletproof Executive. Marksdailyapple.com is an excellent resource that got me started, and Mark Sisson’s book The Primal Blueprint is an excellent introduction to how paleo works and what benefits you can expect. I intend to write a few more blog posts along the lines of nutrition for coding and mental performance in the near future, if you want to get updates you can follow me on Twitter (@code_barbarian) or Facebook. William Kelly (@idostartups) was my superstar editor for this post, thanks to him for all the help.

Advertisements

Mistakes You’re Probably Making With MongooseJS, And How To Fix Them

If you’re familiar with Ruby on Rails and are using MongoDB to build a NodeJS app, you might miss some slick ActiveRecord features, such as declarative validation. Diving into most of the basic tutorials out there, you’ll find that many basic web development tasks are more work than you like. For example, if we borrow the style of http://howtonode.org/express-mongodb, a route that pulls a document by its ID will look something like this:

app.get('/document/:id', function(req, res) {
  db.collection('documents', function(error, collection) {
    collection.findOne({ _id : collection.db.bson_serializer.ObjectID.createFromHexString(req.params.id) },
        function(error, document) {
          if (error || !document) {
            res.render('error', {});
          } else {
            res.render('document', { document : document });
          }
        });
  });
});

In my first post I touched on MongooseJS, a schema and usability wrapper for MongoDB in NodeJS. MongooseJS was developed by LearnBoost, an education startup based in San Francisco, and maintained by 10gen. MongooseJS lets us take advantage of MongoDB’s flexibility and performance benefits while using development paradigms similar to Ruby on Rails and ActiveRecord. In this post, I’ll go into more detail about how The Ascot Project uses Mongoose for our data, some best practices we’ve learned, and some pitfalls we’ve found that aren’t clearly documented.

Before we dive into the details of working with Mongoose, let’s take a second to define the primary objects that we will be using. Loosely speaking, Mongoose’s schema setup is defined by 3 types: Schema, Connection, and Model.

A Schema is an object that defines the structure of any documents that will be stored in your MongoDB collection; it enables you to define types and validators for all of your data items.

A Connection is a fairly standard wrapper around a database connection.

A Model is an object that gives you easy access to a named collection, allowing you to query the collection and use the Schema to validate any documents you save to that collection. It is created by combining a Schema, a Connection, and a collection name.

Finally, a Document is an instantiation of a Model that is tied to a specific document in your collection.

Okay, now we can jump into the dirty details of MongooseJS. Most MongooseJS apps will start something like this:

var Mongoose = require('mongoose');
var myConnection = Mongoose.createConnection('localhost', 'mydatabase');

var MySchema = new Mongoose.schema({
name : {
    type : String,
    default : 'Val',
    enum : ['Val', 'Valeri', 'Valeri Karpov']
  },
created : {
    type : Date,
    default : Date.now
  }
});
var MyModel = myConnection.model('mycollection', MySchema);
var myDocument = new MyModel({});

What makes this code so magical? There are 4 primary advantages that Mongoose has over the default MongoDB wrapper:

1. MongoDB uses named collections of arbitrary objects, and a Mongoose JS Model abstracts away this layer. Because of this, we don’t have to deal with tasks such as asynchronously telling MongoDB to switch to that collection, or work with the annoying createFromHexString function. For example, in the above code, loading and displaying a document would look more like:

app.get('/document/:id', function(req, res) {
  Document.findOne({ _id : req.params.id }, function(error, document) {
    if (error || !document) {
      res.render('error', {});
    } else {
      res.render('document', { document : document });
    }
  });
});

2. Mongoose Models handle the grunt work of setting default values and validating data. In the above example myDocument.name = ‘Val’, and if we try to save with a name that’s not in the provided enum, Mongoose will give us back a nice error. If you want to learn a bit more about the cool things you can do with Mongoose validation, you can check out my blog post on how to integrate Mongoose validation with AngularJS.

3. Mongoose lets us attach functions to our models:

MySchema.methods.greet = function() { return 'Hello, ' + this.name; };

4. Mongoose handles limited sub-document population using manual references (i.e. no MongoDB DBRefs), which gives us the ability to mimic a familiar SQL join. For example:

var UserGroupSchema = new Mongoose.schema({
  users : [{ type : Mongoose.Schema.ObjectId, ref : 'mycollection' }]
});

var UserGroup = myConnection.model('usergroups', UserGroupSchema);
var group = new UserGroup({ users : [myDocument._id] });
group.save(function() {
  UserGroup.find().populate('users').exec(function(error, groups) {
    // Groups contains every document in usergroups with users field populated // Prints 'Val'
    console.log(groups[0][0].name)
  });
});

In the last few months, my team and I have learned a great deal about working with Mongoose and using it to open up the true power of MongoDB. Like most powerful tools, it can be used well and it can be used poorly, and unfortunately a lot of the examples you can find online fall into the latter. Through trial and error over the course of Ascot’s development, my team has settled on some key principles for using Mongoose the right way:

1 Schema = 1 file

A schema should never be declared in app.js, and you should never have multiple schemas in a single file (even if you intend to nest one schema in another). While it is often expedient to inline everything into app.js, not keeping schemas in separate files makes things more difficult in the long run. Separate files lowers the barrier to entry for understanding your code base and makes tracking changes much easier.

Mongoose can’t handle multi-level population yet, and populated fields are not Documents. Nesting schemas is helpful but it’s an incomplete solution. Design your schemas accordingly.

Let’s say we have a few interconnected Models:

var ImageSchema = new Mongoose.Schema({
  url : { type : String},
  created : { type : Date, default : Date.now }
});
var Image = db.model('images', ImageSchema);

var UserSchema = new Mongoose.Schema({
  username : { type : String },
  image : { type : Mongoose.Schema.ObjectId, ref : 'images' }
});

UserSchema.methods.greet = function() {
  return 'Hello, ' + this.name;
};

var User = db.model('users', UserSchema);

var Group = new Mongoose.Schema({
  users : [{ type : Mongoose.Schema.ObjectId, ref : 'users' }]
});

Our Group Model contains a list of Users, which in turn each have a reference to an Image. Can MongooseJS resolve these references for us? The answer, it turns out, is yes and no.

Group.
  find({}).
  populate('user').
  populate('user.image').
  exec(function(error, groups) {
    groups[0].users[0].username; // OK
    groups[0].users[0].greet(); // ERROR – greet is undefined

    groups[0].users[0].image; // Is still an object id, doesn't get populated
    groups[0].users[0].image.created; // Undefined
  });

In other words, you can call ‘populate’ to easily resolve an ObjectID into the associated object, but you can’t call ‘populate’ to resolve an ObjectID that’s contained in that object. Furthermore, since the populated object is not technically a Document, you can’t call any functions you attached to the schema. Although this is definitely a severe limitation, it can often be avoided by the use of nested schemas. For example, we can define our UserSchema like this:

var UserSchema = new Mongoose.Schema({
  username : { type : String },
  image : [ImageSchema]
});

In this case, we don’t have to call ‘populate’ to resolve the image. Instead, we can do this:

Group.
  find({}).
  populate('user').
  exec(function(error, groups) {
    groups[0].users[0].image.created; // Date associated with image
  });

However, nested schemas don’t solve all of our problems, because we still don’t have a good way to handle many-to-many relationships. Nested schemas are an excellent solution for cases where the nested schema can only exist when it belongs to exactly one of a parent schema. In the above example, we implicitly assume that a single image belongs to exactly one user – no other user can reference the exact same image object.

For instance, we shouldn’t have UserSchema as a nested schema of Group’s schema, because a User can be a part of multiple Groups, and thus we’d have to store separate copies of a single User object in multiple Groups. Furthermore, a User ought to be able to exist in our database without being part of any groups.

Declare your models exactly once and use dependency injection; never declare them in a routes file.

This is best expressed in an example:

// GOOD
exports.listUsers = function(User) {
  return function(req, res) {
    User.find({}, function(error, users) {
      res.render('list_users', { users : users });
    });
  }
};

// BAD
var db = Mongoose.createConnection('localhost', 'database');
var Schema = require('../models/User.js').UserSchema;
var User = db.model('users', Schema);

exports.listUsers = return function(req, res) {
  User.find({}, function(error, users) {
    res.render('list_users', { users : users });
  });
};

The biggest problem with the “bad” version of listUsers shown above is that if you declare your model at the top of this particular file, you have to define it in every file where you use the User model. This leads to a lot of error-prone find-and-replace work for you, the programmer, whenever you want to do something like rename the Schema or change the collection name that underlies the User model.

Early in Ascot’s development we made this mistake with a single file, and ended up with a particularly annoying bug when we changed our MongoDB password several months later. The proper way to do this is to declare your Models exactly once, include them in your app.js, and pass them to your routes as necessary.

In addition, note that the “bad” listUsers is impossible to unit test. The User schema in the “bad” example is inaccessible through calls to require, so we can’t mock it out for testing. In the “good” example, we can write a test easily using Nodeunit:

var UserRoutes = require('./routes/user.js');

exports.testListUsers = function(test) {
  mockUser.collection = [{ name : 'Val' }];
  var fnToTest = UserRoutes.listUsers(mockUser);
  fnToTest( {},
    { render : function(view, params) {
        test.equals(mockUser.collection, params.users); test.done();
      }
    });
};

And speaking of Nodeunit:

Unit tests catch mistakes, encourage you to write modular code, and allow you to easily make sure your logic works. They are your friend.

I’ll be the first to say that writing unit tests can be very annoying. Some tests can seem trivial, they don’t necessarily catch all bugs, and often you write way more test code than actual production code. However, a good suite of tests can save you a lot of worry; you can make changes and then quickly verify that you haven’t broken any of your modules. Ascot Project currently uses Nodeunit for our backend unit tests; Nodeunit is simple, flexible, and works well for us.

And there you have it! Mongoose is an excellent library, and if you’re using MongoDB and NodeJS, you should definitely consider using it. It will save you from writing a lot of extra code, it’ll handle some basic population, and it’ll handle all your validation and object creation grunt work. This adds up to more time spent building awesome stuff, and less time trying to figure out how to get your database interface to work.

Have any questions about the code featured in this post? Want to suggest a better approach? Feel like telling me why the MEAN Stack is the worst thing that ever happened in the history of the world and how horrible I am? Go ahead and leave a comment below, or shoot me an email at valkar207@gmail.com and I’ll do my best to answer any questions you might have. You can also find me on github at https://github.com/vkarpov15. My current venture is called The Ascot Project, and you can find that over at http://www.AscotProject.com. Huge thanks to my partner William Kelly (@idostartups) for all of his work helping me get this post together.