Hacking Hip Hop History

Raul Rubio & Jumpei Kato

With the announcement of YP’s Hackathon XI, everyone starts thinking about what they can do to contribute. Both being musicians, June and I quickly realized we wanted to work on something music related that would motivate us and take advantage of our tech and music skills. Early on, we decided on doing a retro drum machine but really didn’t discuss more than that at the time. As the date drew closer we brought it up again and weren’t actually sure we could pull anything off.

On the day of the Hackathon was when we finally got into the details and decided to model our drum machine after the 1981 Oberheim DMX. We then brainstormed our strategy and tool sets, agreeing that we wouldn’t pressure ourselves to present unless something cool happened.

Knowing that June holds a strong talent for UI design and development, it was obvious that he would definitely cover that portion of the work in addition to contributing on the various inner workings. Being web developers we turned to HTML, CSS and Javascript to tackle the challenge.

First things first, we needed to be able to play audio from the browser so we turned to the Web Audio API. Next, we needed historically accurate drum sounds which were easy to come by from my personal collection. Then we needed a functioning UI. Working from old photos of the real instrument, June was able to design and implement a great looking and intuitive interface and wire up the basic sound engine to it.

At this point we realized we had actually created something interesting and set out to add the functional features that would make it legit. We started by adding pattern support so you can write a basic drum line. Then we followed that with a “Swing” function which adds a more human-like groove to the normally rigid timing (technically speaking we introduced some timing anomalies on every other note). Then we mapped keys to control start/stop, tempo changes and to trigger additional sounds for added giggles.

before and after

Needless to say, that’s when we decided we were going to present. In the end we landed a respectable 3rd place for “Coolest” hack!
Click here to see our work.

What was cool about it?

Being a hackathon, we wanted to do something challenging that utilized our skill sets yet unrelated to our daily role as YP engineers. This allowed us to think without constraints and exercise our imagination while still honing our craft. We found the overall experience to be incredibly exciting and inspiring.

Why the Oberheim DMX?

This iconic instrument was everywhere in music beginning in the 80’s and still present and influential today. Paying an homage to the DMX is like hanging out backstage with your favorite artist at a concert. It just seemed like the right choice.

Technically, the original machine’s design is conceptually easy to understand which made it a good candidate. It contains a fixed set of drum sounds and songs are built using a “step sequencer,” which provided June with a good amount of UI direction. The key difference between our version and the original is that the UI exposes the sequencer and hides the more complex controls, making visual drum pattern creation a breeze.

The Future

Since we had so much fun on this project we have continued to develop more advanced features for it. We are thinking of additional projects for future hackathons that we hope will continue to inspire us (i.e., many more music related projects).

Try it for yourself


before and after

First Day at YP: A local perspective.

Diana Horn

"I hate riding my bike and treasure hunts." Said no one. Ever.

Back when I was still studying architecture, there was an exercise we did in order to become more aware of our personal perspective on transportation design and the architecture around us, the stuff we actually paid attention to. It went like this (participation is encouraged!):

Take out white paper and pen. Decide on an area of interest, for example: Glendale, California. Start drawing the local ground layout, include anything you can think of, roads, coffee shops, details on buildings, parks, underpasses, and even landscape characteristics. You’ll be on the right path if it starts looking like a treasure map from your childhood - mine below as an example. (When you’re done, send these to me: mylocalmap@hotmail.com).


What you will see is that the local landscape is very much subjective, and the image we have in our heads is ever changing. Reality is subjective after all. This local world is important to me, especially after my psychology studies which have brought home the importance of a personal sense of belonging to a community.

'The bicycle is a curious vehicle. Its passenger is its engine. ' -John Howard

I knew moving here that I would have to get a car eventually, but before I do, I am determined to explore the local scene by my own “curious vehicle”.


"Anyone who has never made a mistake, has never tried anything new." Said that smart white-haired guy at some point.

A little background: I’m interning here at YP and found housing with a local Armenian family where one of the sisters had a bike that she sold me my first evening here. What luck! It had stood in her garden for almost two years, untouched. Dusty, dirty, but sturdy and perfect for my height, I was pretty thrilled. She kitted me with a helmet, two locks, and all the fixings for a great start on my first day.

D-day. I woke up at 5:30 (jet-lag, I arrived the day before from Stockholm, Sweden), gathered myself and ate a big breakfast before saddling up my sturdy steed and heading down the hill into the Chevy Chase Canyon valley. Not 5 minutes into the estimated 15 minute journey something started sounding like slapping. Not a good sound. A quick check told me the back tire was coming off, and the loose side of it was slapping into the frame. I’m a stubborn and conscientious person so I thought “It’s my first day, I better just get to the office and then I can deal with fixing the tire.”

Have you heard the saying ‘Man plans, god laughs’? Well someone was laughing, I’m sure, when the tire blew with a loud pop on the corner of Adams and Doran. Nothing to do but walk the useless sturdy lug all the way to the office, where, beyond reason, I was only 5 minutes late for orientation.

The day was jam packed with new concepts, people, departments, and terminology. I am part of the Technology Organization and Nathan Cunningham was my guide through all things YP. When he heard about my debacle, he offered to take me to the bike shop, which was fortunate because by that time the back tire had given out completely, not budging an inch. I told him the bike had been bought at Bicycle Land (one of the few landmarks I know), and we headed there to get it fixed. They were incredible, getting me on my way in less than 20 minutes! I’ve since found out that they are one of the advertisers on YP.com and one of the top rated bike shops in the area to boot!

Now, beyond having saved me from carrying by bike all the way up the canyon, YP is going to be my go-to for all things I need here while I try to stay car-free in LA! Since YP recently integrated with Uber, this might be easier than you might imagine (especially if you’re an LA local.)


YP Women

Saralee Kunlong

Mission Statement

Women Empowerment

YP Women is a group aiming to connect, inspire, and support women in the technology industry. Internally, we are creating a space where women can seek advice from their peers, motivate each other, and allow their voices to be heard. Externally, we desire to be impactful in our local communities through events, outreach, and advising younger generations of women about our journey to succeeding in the world of technology. Our goal is to build camaraderie and mentorship for women who are up and coming in technology. Simultaneously aiming to build a community of support and resource for women who are already rooted in the industry.

As of today, women in technology industry are still a minority and we want to create a space where women can build a strong positive relationship and support each other. We want to build a community where we can empower each other through sharing skills, expanding our professional knowledge, and building networks. As a group, we hope to be able to mentor each other to overcome the challenges we face as a minority in the workplace. In addition to supporting each other, we believe that involving younger generations is the key to bridging the gap and making women in technology more prevalent than ever before.

Mailing Subscription


Subscribing to our mailing list is simple! Check out our Wiki Page
for instructions!

Email us: ypWomen@yp.com

Events Calendar

YP Women Team

Our steering committee members are the driving force that makes the magic happen!

Women Empowerment


We teamed up with YP Social Media team for our latest event to support the #ILookLikeAnEngineer campaign aimed to spotlight the diversity of highly skilled female engineers who know how to get the job done. It demonstrates that engineers are not limited to one specific image--especially when it comes to gender. - Check out the pics in our gallery showcasing how YP women are enriching the world of engineering!

Read more about our culture: here

Women Empowerment

Intro to Docker

Docker Logo

What's Docker?

Per Docker;

Docker is an open platform for developers and sysadmins to build, ship, and run distributed applications. Consisting of Docker Engine, a portable, lightweight runtime and packaging tool, and Docker Hub, a cloud service for sharing applications and automating workflows, Docker enables apps to be quickly assembled from components and eliminates the friction between development, QA, and production environments. As a result, IT can ship faster and run the same app, unchanged, on laptops, data center VMs, and any cloud.



Docker is a container, allowing you to easily run an application in complete isolation, locked away from the core host OS. It allows for creating "gold master" images of the entire system, including your application, which can be started, stopped, modified and destroyed easily with no risk to the underlying host.

Packager Manager...

Docker allows you to build, ship and run your application in a distributed fashion with minimal overhead. Providing a simple interface for pulling and starting your application on virtually any host, any where. Because Docker uses SHAs to manage versions on container segments, it allow for quick build development, returning to cached container components where possible.

"Syntactic Sugar"...

Docker makes tried and true technologies, like lxc and chroot -- which have been around for decades -- simple and easy to use via its relatively lightweight build system. Because its underlying technologies aren't actually new, there's a feel of maturity and familiarity to it as well.


In Docker Hub, you can socialize your containers, or use a wide array of containers, simply by searching the open Docker registry for what you need.

What does it attempt to solve?


With Docker, developers can create and easily distribute development environments which are identical to the targeted production environment. In addition to assisting in on-boarding new developers, this allows for accurate development conditions, minimizing risk in environmental inconsistencies. It also allows for developers to build contained and portable applications. No more "it worked on my machine". "My machine" is now all machines.


Docker allows for deployment of standardized and identical environments across development, testing, stage, and production environments. Additionally, it allows for easy separation of build time and run time actions, allowing for fast application start times.

With Docker's build mechanisms, segmenting, and caching system, repeated builds should get incrementally faster, allowing for more rapid build times as well.

Hardware utilization?

Out of the box, Docker is designed for rapidly scaling application instances up and down, giving users the power to control hardware density based on resource needs. Coupling Docker with other products, like MesOS, allows you to take this a step further in easily building out a cloud-like infrastructure where nodes can be added and deleted at will.

How is it used?


In these examples I'll be using CentOS 6.5 to meet my need, but please refer to Docker's installation documentation for your specific setup.

Installing Docker

# Ensure Centos 6.5
cat /etc/redhat-release

# Install Docker
sudo yum install docker-io

# Start Docker
sudo /etc/init.d/docker start

# Docker Help
sudo docker -h
sudo docker

Basic Commands

Docker by default requires sudo as it's managing host level actions. There are ways around this but I won't be covering that here, as I don't recommend it.

docker pull

Docker's pull command fetches images based on their name and tag (<name>:<tag>).

sudo docker pull centos:centos6

Note; If you pull by name only, all tags will be fetched and this can take a while and eat up a fair amount of disk space.

docker images

Docker's images tag lists all images currently on your system.

sudo docker images
docker run

Docker's run command starts a new image from a specified container, with the requested command.

#                    {image}:{tag}   {command}
sudo docker run -i -t centos:centos6 /bin/bash

The -i flag tells Docker that the container should be interactive and the -t flag tells it to allocate a pseudo-tty. The combination makes your container fully interactive and kills it on exit.

Play Time

Start a Docker container using the above run command and type the following;

ls -l
rm -rf /bin
ls -l

Now start a new container using the same run command and type the following;

ls -l

You'll see that you've made no changes to your base image and done no lasting damage.

docker ps

Docker's ps command shows you information on containers you've been playing with.

# running containers
sudo docker ps

# last container
sudo docker ps -l

# all containers
sudo docker ps -a

Expanded Example

In this expanded example, I'll cover modifying the centos:centos6 image pulled from Docker's public registry and saving a custom image.

First we'll start a named container, using the CentOS image we pulled down.

sudo docker run --name="docker_demo" -i -t centos:centos6 /bin/bash

Now you should see a command prompt within your "docker_demo" container. Let's install a few things by running the commands below.

yum install epel-release -y
yum install nodejs -y
node --version

We should now be able to diff our container against the original centos:centos6 image with Docker's diff command to see what's changed.

sudo docker diff docker_demo

Then we can use Docker's commit command to create a new image, here I'm calling it centos6-nodejs.

sudo docker commit docker_demo centos6-nodejs

Note; Docker convention says images should be named with a user name proceeding the image name. Additionally, I recommend using a tag, in this case to label the Node.js version installed. At the time of this writing, Node.js was at v0.10.32, so were I planning to publish this image, its name would look like this jmervine/centos6-nodejs:v0.10.32

The image you've just created will now appear in your images list.

sudo docker images

We can now run this custom image, just as we ran centos:centos6 before, but with our baked in changes contained within.

sudo docker run -i -t centos6-nodejs /bin/bash

Running node --version inside at the containers prompt will show that Node.js is installed and available.

For some tip in using Docker that I've compiled in my travels, see Docker Tips

Final Thoughts

Initially, I was not totally sold that Docker is the silver bullet that it's been proposed to be by some of my peers – especially in large scale, high availability, production environments. My primary concern was that it puts too much responsibility in the hands of developers on the systems side. I saw this as being a potential issue, only in the fact that developers have an area of focus, which is not at the same depth as in the operational side of the house. This can be overcome by Developers, DevOps/Site Reliability Engineers and Systems Engineers working closely together to build solid top level images and agreeing on best practices.

Docker really shines for the weekend warrior style developer – the guy who's building his own application and spinning it up himself on Digital Ocean, AWS, etc. For him, Docker does the exact opposite by removing all that extra overhead, allowing him to pull an image built by someone who has more expertise than he may posses and focus simply on the code and basic server implementation surrounding it.

Docker is also a drastic paradigm shift from more common development practices I've seen in larger development environments. To take full advantage of its full power, development teams need to think in smaller independent service segments, as opposed to the larger, more monolith applications frequently seen coming out of larger teams. This is something we've seen as a driving force behind the Node.js and Golang communities and lends itself really well towards Agile methodologies. While I consider this a very good thing, I also see it being a possible barrier in larger development teams being able to leverage it's full potential.

All in all, I'm very excited about Docker, especially when coupled with something like MesOS or Kubernetes. I'm very much looking forward to a future where we're no longer concerned about tying hardware (physical or virtual) to applications, and instead can focus on treating application roll outs and releases much like stacking disposable and replaceable containers.


Thanks to;

  • Charlie Wilkins for editorial comments and corrections.
  • Adam Avilla for pushing me to tackle this subject in an educational capacity.

2014 in Review

Editorial Team

Twice and thrice over, as they say, good is it to repeat and review what is good. -- Plato

January was very quiet on the blog - some interesting things in the works for January 2015 though, come back soon!

In February Greg provided a helpful overview on how to develop tests with Mocha and Supertest and how to generate code coverage reports with Istanbul.

March saw an early mention of Docker in these comments on Ghost - Wordpress lite - and client-side JavaScript. Ask a YP engineering insider about the significance of the reference to Docker and look for a post in 2015. We also learned about Maker's Schedules and Manager's Schedules and got some wise time management advice from General and former President Eisenhower via Jeff (one of several new regular contributors to this blog).

In April, we lost a dear friend. We still miss you Philip!

We had a highly successful Hackathon in May, but Flappy Birds are all we have to show for it here on the blog. Also in May another new regular contributor to the blog, Chris, gave Rubyists a very useful overview of Ruby version management tools.

June saw an uptick in blogging activity with a Scalding Tutorial on ..., well, scalding. And the start of our first multi-series, which covers YP's VOICE operating principles (Velocity, Ownership, Innovation, Collaboration, and Execution) from an unusual perspective - a 16th century Samurai Warrior. Final parts to come in 2015.

We also learned about Aaron Swartz, and then started learning from our illustrious 2014 interns - with us from June to early September:

Have you ever heard of Tox? Neither had we till August 2014. Its a secure, open-source Skype replacement.

In October we heard from a new hire about his first week at YP, and like him, didn't panic with this Hitchhiker's Guide to Node. We celebrated Diwali, made the front page of the L.A. Times, and kicked off a series on Procrastination.

No procrastination from Chris as he followed up with part 2 and part 3 of his excellent series in early November.

And we end the year, like we did on Thanksgiving and the 4th of July with gratitude for our freedom to innovate and thrive in 2015.

Happy New Year.

What a 16th Century Samurai Teaches Us About VOICE - Part Three

Jeff Leeson

This is the third post in a series on YP's VOICE principles and the philosophy of Miyamoto Musashi as written in The Book of Five Rings. The translation of The Book of Five Rings used here was sourced from WikiQuote.

You can start from the beginning of the series here.

We at YP practice the VOICE principles (Velocity, Ownership, Innovation, Collaboration, and Execution), striving to embody each of them in order to become more effective at not only our jobs, but in our personal lives.

In the 16th century, a Japanese Ronin (a lord-less samurai) named Miyamoto Musashi wrote The Book of Five Rings. In it, Musashi describes his philosophy, called “The Way” of sword fighting, which is still studied today and can be applied across any discipline.

This series explains how the sword fighting principles of The Way can be generalized to each VOICE principle, leading you to a more productive life. In the previous entry, I wrote about how Musashi’s teachings relate to Ownership. In today’s post, I’ll be covering Innovation.


Use of the word “innovation” has increased dramatically over the past 65 years, and for good reason. The definition of innovation, per Merriam-Webster, is “the introduction of something new” or “a new idea, method, or device.” Given the rapid pace of change in this time frame alone, it’s understandable why the term has increased in popularity, particularly in the fields of technology and organizational development.

Innovation is something we strive for both as an organization, as well as individually. As an organization, we work to be innovative in our field by creating new products, customer service processes, or sales techniques. Individually, we innovate by trying a new time management system, cutting the cord to our cable/satellite TV, or learning a new language. Only by staying innovative at both the micro and macro levels can we hope to not only stay relevant but earn greater successes.

Here is what Musashi says about Innovation:

Develop intuitive judgment and understanding for everything.

At its core, to be truly innovative, you must have complete understanding and the ability to accurately perceive situations. Understanding for everything doesn’t only mean an understanding of the “thing” that you are trying to innovate, but an understanding of many things, including those unrelated. The common phrase of “thinking outside the box”, or peripheral knowledge, refers to the ability of one to apply seemingly unrelated principles or theories to a given problem.

Developing intuitive judgment is similarly necessary, as an understanding of everything is only useful if it is filtered to eliminate irrelevant information. A product manager for YP for Business can utilize understanding for everything by drawing inspiration from a dating app, but (s)he also has to judge whether a feature in that dating app will translate and still be intuitive to a YP for Business user. A sales trainer might want to apply the Unix philosophy to his/her curriculum and methodology, but that requires judgment of what parts of the philosophy are more or less valuable to sales than to software. The combination of understanding of everything and propensity for intuitive judgment is invaluable when attempting to innovate in any area.

When the fight comes, always endeavor to chase the enemy around to your left side. Chase him towards awkward places, and try to keep him with his back to awkward places. When the enemy gets into an inconvenient position, do not let him look around, but conscientiously chase him around and pin him down. In houses, chase the enemy into the thresholds, lintels, doors, verandas, pillars, and so on, again not letting him see his situation....

Always chase the enemy into bad footholds, obstacles at the side, and so on, using the virtues of the place to establish predominant positions from which to fight.

What the heck does chasing someone around with a sword have to do with innovation? Nothing! It’s a metaphor for pursuing your enemy (the problem or task) into awkward and unusual circumstances, forcing yourself to examine them from diverse perspectives and attack them in uncommon ways.

Innovation requires us to not only pursue a challenge unrelentingly, but to do so in unconventional ways. We can’t always use a cookie cutter to solve problems; they often require creative problem solving, or more specifically, red teaming. Take a big step back, throw out all of your preconceived assumptions, and re-evaluate how to best tackle the challenge.

"To release four hands" is used when you and the enemy are contending with the same spirit, and the issue cannot be decided. Abandon this spirit and win through an alternative resource.

In large-scale strategy, when there is a "four hands" spirit, do not give up - it is man's existence. Immediately throw away this spirit and win with a technique the enemy does not expect....

"To renew" applies when we are fighting with the enemy, and an entangled spirit arises where there is no possible resolution. We must abandon our efforts, think of the situation in a fresh spirit then win in the new rhythm. To renew, when we are deadlocked with the enemy, means that without changing our circumstance we change our spirit and win through a different technique.

These strategies are similar, and can be interpreted in several ways. One is that we (YP and other companies in the local space) are competing with one another in equal ways and with equal vigor, and we (YP) must abandon this head-on battle and fight via other methods to succeed. Another is that we cannot win by duplicating the features of others, whether they’re products, processes, or methods, but we must creatively solve these for ourselves. A third is that to simply fight with an opponent in the space, using the same methods, will not decide the battle. Innovation is required to disrupt the status quo and become more than we are now, more than just the sum of our parts.

Many things can cause a loss of balance. One cause is danger, another is hardship, and another is surprise. You must research this.

In large-scale strategy it is important to cause loss of balance. Attack without warning where the enemy is not expecting it, and while his spirit is undecided follow up your advantage and, having the lead, defeat him.

Innovation in an area causes a loss of balance. It puts competitors off balance (in a bad way, for them) and it puts customers off balance (in a good way, for them). Danger, hardship, and surprise can cause one to lose stability, all of which are inevitable situations one will face without change and innovation driving us forward.

Stagnation is also a loss of balance, but in the opposite direction. Disruptive change is necessary to prevent that stagnation, but too much disruption can also cause one to lose balance, not allowing a foothold to be gained.

To defeat one’s “enemy”, whether it be a competitor in the market, a challenge to solve, or a conflict with another person, one must maintain one's balance, while working to throw off the balance of the other. Correspondingly, to simply innovate isn’t enough. It’s equally important to follow through with the advantage provided by that innovation, as others will be quick to duplicate it.

In this world it is said, "One inch gives the hand advantage", but these are the idle words of one who does not know strategy… From olden times it has been said: "Great and small go together."… In my doctrine, I dislike preconceived, narrow spirit.

Here Musashi is saying to throw out all preconceived notions and assumptions. All options are available and should be used. To narrow one's viewpoint is to limit one's options, therefore limiting one's possibility of success.

In order to innovate, we have to throw out traditions, conventions, and rules. We must work without rules to create something new, something better. Iteration is not innovation, and assumptions about what has worked in the past can’t be used when strategizing for the future.

To innovate, we must free our minds of the boundaries we unconsciously raise within them to make our lives easier.


Innovation is key to strategy in battle and in business. I’ve set out how Musashi’s Way teaches that innovation comes through the understanding of everything, intuitive judgment, freeing yourself of preconceptions, maintaining balance, and creative thinking.

While we can’t expect to wake up tomorrow and decide to innovate, we can set the foundation required for innovation by applying The Way to our thinking. Begin by studying what may appear to be peripheral or unrelated subjects, and examine how your own biases and assumptions may prevent you from hearing or accepting alternative ideas. Lastly, apply the rules of Red Teaming by having someone without prejudice look at it from the outside.

Next in the series we’ll read what Miyamoto Musashi writes about collaboration.

Gratitude is Good

Nathan Cunningham

Gratitude is not only the greatest of virtues, but the parent of all the others.

— Marcus Tullius Cicero (106 BC-43 BC)

Science is increasingly reinforcing what the ancients have told us: Gratitude is a good thing. From Berkley's Greater Good Science Center:

For too long, we’ve taken gratitude for granted. Yes, “thank you” is an essential, everyday part of family dinners, trips to the store, business deals, and political negotiations. That might be why so many people have dismissed gratitude as simple, obvious, and unworthy of serious attention. But that’s starting to change. Recently scientists have begun to chart a course of research aimed at understanding gratitude and the circumstances in which it flourishes or diminishes.

Their findings (read the whole article and lots of other good related content here) support the idea that other good things come from gratitude.

So in the spirit of this, THANK YOU to all the readers of and contributors to this blog and THANK YOU to the leadership of YP for the opportunity to contribute to YP's conversation in this way.

Ways you can show Gratitude: Support the SMB Community

Remember its Small Business Saturday this week - between Black Friday and Cyber Monday - so you can do your bit to support the incredible economic engine that is American small business with your shopping dollars on Saturday. See here for more on that and YP's involvement.

Ways to Give Thanks: An example

In Cicero's words its a virtue, and can lead to other good things, to thank those who help make you successful. Here is a great example written to Peter Drucker by someone who Drucker had directly influenced - full context here.

Alt text

Ironically, all of us have been indirectly influenced by Drucker. He's had a huge impact on business and commerce and life as we know it. We owe him (posthumously) our gratitude as well.

So I ask the same question posed in the article above:

Is there someone with whom you might share a similar sentiment today?

Happy Thanksgiving!

Procrastination from the Inside Out, Part 3: Don't Think Too Hard

Chris Fincher

This post is the final post in a series investigating the ways that procrastination influences and is influenced by the way the brain works. Here is part 1 and here is part 2.

By now, most of the working world has come around to the idea that breaks improve productivity because tired workers don't do good work, and they don't do it very quickly. But there's another reason you should make sure that you take breaks in your work: it makes you more creative. Have you ever gotten a great idea for something when you were taking a shower? There's a reason that tends to happen.

The brain thinks in two modes, called the focused mode and the diffuse mode. The focused mode is exactly what it sounds like. You're concentrating intensely on something and putting all of your energy into solving the problem at hand. The diffuse mode is when you're not doing that, and your mind can wander freely from idea to idea. The focused mode is great for analyzing new facts and patterns, as well as applying the ones you already know. It helps you figure out the fine details of a problem and how to make things work together seamlessly. The diffuse mode, on the other hand, is good for making new connections and approaching problems in new ways. Essentially, your brain is rubbing together the ideas it already has and seeing what makes sparks start flying.

These two modes work best if you can alternate between them. Focused thinking lets you pick up new ideas, diffuse thinking lets you bounce the new ideas off of each other to create more new ideas from them, and then another session of focused thinking lets you explore those newer ideas in detail and flesh them out. Lather, rinse, repeat. It's simple! Unfortunately, that doesn't necessarily mean that it's easy.

A huge amount of literature on how to be productive relies on scheduling, and while schedules can indeed be very helpful, diffuse thinking takes more effort to integrate with a schedule than focused thinking does. Scheduling is easiest when one knows exactly how long a task will take to finish, and while making time estimates is always hard, making time estimates for a diffuse thinking breakthrough is especially hard, since returns can be unpredictable. On top of that, it can feel lazy or self-indulgent to set aside time for diffuse thinking. It doesn't feel like what we've come to expect work to be. This makes some people try to count the time they spend working on one task as diffuse thinking time on another task, and while this sometimes works if the task you're working on is somewhat brainless (e.g. taking a shower, washing dishes, folding clothes), you have to be careful when you're trying this kind of substitution that you're actually clearing your mind and not making it stay in the focused mode for your new task.

Since it's so hard to schedule creativity, it's a good idea to give yourself generous amounts of time in which to create, and that's where procrastination enters the picture. When you procrastinate, you force yourself to do your creative work in one long sitting, which stifles your diffuse thinking and hence your creativity. So when you know you'll have to get creative for something you're working on, fight the urge, and start early! The sooner you focus, the more time you give yourself to have that breakthrough while you're shampooing.

A Brief Summary

So what have we learned in our past three weeks together? (After all, repetition is a virtue!) In order to create, you have to think diffusely, and that takes time. In order to learn and remember, you have to repeat over several days and take the time to do, rather than simply read. That takes time, too. Since procrastination deprives you of time, it's not compatible with maximal learning or creativity. What's worse, there are biological factors making all of us want to do it. The good news is that the urge to procrastinate falls off quickly, so a little bit of grit might be all you need to get past it.

I hope this brief look into the biology of procrastination was interesting and useful to you. I personally find it a lot easier to follow advice when I know why it's supposed to work, so even if you didn't hear any recommendations from this you hadn't heard before, I hope you've gained some background that makes the strategies you already know a bit more convincing. Keep fighting the good fight!

About This Series

I wrote this series to relate some of the things I learned in Learning How to Learn, a course on Coursera taught by Barbara Oakley and Terrence Sejnowski. Any assertions I've made about how the brain works (as well as the term "metabolic vampires") is taken from there. I am usually very skeptical of anything that essentially claims to make you smarter, but I hoped a course with the backing of a UCSD neuroscientist would stay clear of anything pseudoscientific. The material might not be quite what I'd call university-caliber, nor the production values Hollywood-caliber, but it was very approachable and gave me some interesting new approaches for self-improvement. If you're interested in taking it yourself, another session of the class is starting in January. If you just plan on following along and don't think you'll do the assignments (which, admittedly, is what I did), you can join up and read through the material at your own pace. If you'd like a more interactive experience, however, make sure you join an active session. The session I participated in had over 170,000 students, so I suspect they'll be offering this course for the foreseeable future.

Procrastination from the Inside Out, Part 2: The Nonpersistence of Memory

Chris Fincher

This post is part 2 of a series of posts investigating the ways that procrastination influences and is influenced by the way the brain works. You can read part 1 here.

There's a trick you might have seen before that authors and speakers like to use to convince people that they don't really know how their brain works. It's pretty simple: just ask them what they had for dinner three days ago. Unless that dinner was some kind of special occasion, the victim is usually unable to remember. The perpetrator will usually rub in the fact that it was only three days ago, and, if (s)he is a speaker, will turn to the audience with a smug expression that says, "Look at this genius who can't even remember three days ago!"

Should you find yourself being asked this question, here's what I want you to do: contort your face in such a way as to suggest that you cannot imagine the sort of absurdity that would prompt such a question, and ask why in the world you would remember that. If they point out that it was only three days ago, point out that it happened once and it wasn't very important, and those aren't things people remember.

Actually, that might make you look like an uncooperative jerk in front of a lot of people. Use your judgment on whether you want to say that.

Still, that's the way that things work. Things that happen once, unless they evoke some kind of emotional response, tend to fade away. To borrow a phrase, the "metabolic vampires" of the brain sweep them away with all of the minutiae of the day. Did I see a Honda Accord on Sunday? I don't know. Hasn't come up. What did I have for lunch? I don't know. Hasn't come up. How do you use guard clauses in Haskell? Oh, that's easy. You just, uh... Well, you put "if" somewhere. And, uh... I... I don't know. Oops.

This is a problem I'm a little too familiar with. It's the problem with cramming. If I study something long enough in one sitting, I can get to where I feel like I've mastered the material and everything makes sense, and then, when I wake up the next morning, it's all gone. It's especially evident if you study lanugages, programming or otherwise. Immediately after reading a chapter in Learn You a Haskell for Great Good!, I can solve all of the problems in my head, and it seems like the easiest thing in the world. Then, a week later, I might decide to sit down and try to do something as simple as print out the numbers one through ten, and when I sit down at the keyboard, I manage to type about four characters before I realize I don't remember the syntax for something that seemed so intuitive only a week ago. Perhaps you know the feeling. I realize now that it was the metabolic vampires at work.

Since it's somewhat impractical to make all of things we want to learn emotionally significant ("Promise me that if you ever break up with me, you'll read the first 100 digits of pi when you do it. Then I'll never forget them!"), we have two options for keeping the metabolic vampires at bay.

  • Repetition. Revisiting a topic multiple times will multiply the chances that you hold on to that information. Doing something 500 times in one sitting doesn't count as repetition. Instead, split your time between days and spread whatever you're studying across a week.

  • Going hands-on. Actually do the thing that you're trying to learn. If you're learning a language, make some sentences. Say them out loud if you can. If you're learning a programming language, fire up an editor and play with the language. Use the things you're reading about.

You've heard this advice before. Practice makes perfect. But for a long time, I let the quick confidence I got from rushed studying deceive me into thinking I could condense learning into big, isolated blocks. I would read about languages and skip doing exercises on constructs I thought were simple because I felt like I already understood them. Then, when I did come across an exercise I deemed worthy of my time, I would get stuck on the basics. Reading about how the brain cleans up one-time occurrences helped me realize why that kept happening. I'm not going to say I've managed to stop 100%... but, hey, things have improved.

So what does this have to do with procrastination? Well, you can't repeat something over several days if you only work on it the day before you need it. Procrastination begets cramming, spending hours of studying just in advance of when you need new knowledge. While it's possible you can cram enough knowledge into your short-term memory to get through a test or a deadline, don't expect it to stick around afterwards. As night falls, the metabolic vampires will come... and if they come before then, you're in real trouble. Procrastination also deprives you of time to practice what you're learning, which means you might not actually be learning how to do something. To put it simply, procrastination just isn't compatible with learning new things.

In my next post, I'll be finishing out the procrastination series with a look at how procrastination affects the creative process.

Procrastination from the Inside Out, Part 1: Everyone's Got the Itch

Chris Fincher

A lazy cat. Procrastination incarnate.

Procrastination is bad.

"What a bombshell," you're probably thinking, "what a fresh perspective! Why didn't anyone tell me before? This will revolutionize my life!"

Yes, I know I'm probably not the first person to tell you that procrastination is bad. I don't think you can get a high school diploma today without being told at least four hundred times that procrastination is bad. I can only remember reading that procrastination is good once, and that was in The Four-Hour Workweek, which is... non-traditional, to say the least. Anyway, I'm not planning to dispute that procrastination is bad, but I do want to change the way you think about it with a little neuroscience.

What We Already Know

Analyzing how the brain works is tough, so most writing on procrastination avoids talking about the brain itself. Instead, it focuses on how your environment affects what you do and how that, in turn, affects your work. This philosophy of treating the brain as a sort of "black box" is called behaviorism. You might have heard of it if you've taken a psychology class. It's taught us a lot of useful things about procrastination, for instance:

  • People make mistakes. When you procrastinate, you don't leave yourself time to find mistakes and fix them.
  • Procrastination leads to stress. Stress can be bad for your work, your relationships, and even your health.
  • When you procrastinate, you don't leave any extra time to work, so if you underestimate how long your task will take, you miss your deadline. Unfortunately, people aren't very good at estimating time.

These are all great reasons to fight procrastination, but most of us know them and we still do it anyway. With this series, I'd like to explore the things we can learn about procrastination by analyzing it from the inside out, that is, putting aside behaviorism and seeing how procrastination relates to the brain on a physical level. Let's start by looking at how the brain causes procrastination, and how we can use the way the brain works to avoid it.

The Problem

Speaking from experience, I know that it's easy to feel cursed when you seem to struggle with procrastination more than your peers. Well, the good(?) news is that they're probably dealing with it, too. We are all wired to procrastinate. When the brain thinks about doing something unpleasant or tedious, it's actually a little traumatic. The same part of your brain that reacts when you see a baseball sailing toward your head is reacting to what you're thinking of doing, and it's objecting strenuously. So when you open Facebook, Reddit, YouTube, or whatever it is you do to avoid working, even if the content is stale and you're not entertained, you still start to feel better simply because you made the bogeyman of work go away. You can't reason your way out of it. Even when you know that the only logical thing to do is start working, there's always part of you that is only living in the moment and does not approve. So unless you've found a way to avoid ever thinking that something you have to do is unpleasant, your brain will want to procrastinate as a matter of survival.

The Solution

The bright side to this instinctive procrastination is that it fades away about as quickly as it appears. If you can push through that initial panic and make yourself start working, then work stops being a baseball sailing towards your head. It's not a danger anymore. It's just the way things are. The part of your brain in charge of keeping you out of peril doesn't notice it anymore, and the more analytical part of your brain, which can consider the ramifications of procrastinating versus working, takes over. While this doesn't mean that the task at hand will be easier, it does mean that the things you know about procrastination and the work you need to do will be clearer when you decide whether to keep working.

In other words, it's easier to keep working than to start working. It's a bit like Newton's First Law of Motion. Objects at rest tend to stay at rest, and objects in motion tend to stay in motion! When it seems just unbearable to get started on something, and you want to watch some videos instead ("just for a few minutes"), try to remember two things: what you're feeling is normal, and if you can make yourself start and get even a little momentum, then the urge to slack will fall away very quickly.

The Lesson

You'll never win the war on procrastination. Sorry to break it to you. I won't, either. It's just not how we're wired. There's always going to be another battle with it around the corner. Thankfully, each of those battles is more winnable than it seems at first glance, so fight on! You might surprise yourself with what you can accomplish with only a little more grit.

In the next part, I'll look at what happens in the brain when you learn and how procrastination impacts it.

Photo credit: Flickr/gRuGo CC BY 2.0