Learning one layer above and below

Many years back I heard from somewhere that you should learn one layer above and below where you do most of your work. This was specifically for programming and implied your programming stack.

For example, I do a lot of work in Ruby on Rails which is a server-side framework. What I learned then was:

  • Above – HTML, CSS, JavaScript
  • Rails itself
  • Below – MySQL/Postgres, Linux, Apache

The reasoning behind this is that you’ll need to leave your primary area of focus on occasion. When you do leave, more often than not it will be to debug something that is either above or below where you’re working. Maybe a Rails action is performing poorly, which is caused by your database server. Or perhaps you’re outputting JavaScript for the browser but it’s not running correctly.

This principle has guided my own self-learning in tech for awhile. By providing me a rule of thumb, I can decide how much time to learn something new.

Should I learn about TCP/IP? It’s two levels away from Rails (Rails->OS->Network stack). No.

Should I learn about Redis? It’s part of the data layer so it’s one level from Rails. Yes.

Should I learn about knockout.js? It’s JavaScript which would be one layer away but it’s a layer inside of Javascript, so it’s probably 1.5-2 layers away. Maybe.

You can see, sometimes this isn’t a clear cut decision. Some things might cross layers. Some might be in different layers depending on your project or how you use them.

And sometimes you just really want to learn something, even if it’s way outside your normal stack.

All of that is okay.

My point is that by having this rule of thumb or decision framework I can quickly make decisions. Which gives me more time for learning.

Eric Davis