Install this theme
How to add a little Pulp Fiction / Tony Stark glowing box action to your marriage proposal

First you’re going to need a power supply.  Strip a 9v for it’s interior cells.

but, don’t use cheap batteries

Assemble some tools.  You’ll need a multimeter, soldering iron of some kind, solder, hookup wire (I used 20 gauge), a 3.7v led (max 4.5v), and some electrical tape.

Make a battery pack by soldering 3 of the cells in series and including the led.  Check your voltage after each cell is added.

Using a standard ring box (I bought mine at Micheal’s): Cut a hole through the back of the fold where the ring goes with an hobby knife.

Now I proposed with just the stone (a sapphire (don’t get me started on diamonds (especially the mined ones)))

Cut clear poster tack to hold the stone in place.

Assemble et viola!

Provided the proposal goes well…. Take your new Fiance to a local jeweler to pick out a setting

Being productive with the limitations of attention inherent in humans

or, how to schedule your tea break most productively

Let’s start with some nomenclature.  

System 1 / R-Mode : The kind of thinking that results in Aha! moments (people who shower regularly are aware of this phenomenon)

System 2 / L-Mode : The kind of thinking that is hard and results logical well ordered results (people who hold largish problems in their heads know what I’m talking about)

Ultradian Rhythm : Sub-day length cycle of arousal.  Like your cycle through different phases of sleep at night this takes you through different phases of awake during the day.

Humans are actually quite poor multitaskers.  What most people would call multitasking is actually very rapid context switching.  This is killer on productivity especially if you are working on something that requires you to grasp a large number of factors to solve effectively.

Enter the Tomato

The Pomodoro Technique (pomodoro being Italian for tomato) is a discipline for bringing the benefits of single tasking to your life.  Simply enough you set a timer, work on a single task with all your attention until the timer goes off, take a short break, rinse, repeat as necessary and take a longer break after a few cycles.  The usual suggested ratio is 25/5 that is 25 minutes of focus followed by a 5 minute break and a longer break of 30 minutes.

Knowing that the frequency of the average persons’ ultradian rhythm is 90 to 120 minutes this technique makes a whole lot of sense.

Hacking the break

This is not just another blog post singing the praises of the almighty pomodoro.  I would like to offer some tips that I have found will increase the number of R-mode generated Aha! moments when you walk away from the keyboard.

  1. Don’t start working on another problem.  Only do things that do not require focus, this is not the time to be hacking on a side project.
  2. Do something that requires attention but, not focus.  Activities that like taking a shower require you to attend but, are common enough to not require much actual thought.  This is where the making tea (or coffee) comes in.
  3. Move.  Step away from the keyboard.  Not only is a break from keyboarding good for your wrists and eyes, you’ll oxygenate your brain.  Even light movement like walking at 0.8 mph will dramatically increase the oxygenation of your brain.
Tweak, Tweak, Tweak

Play with the length of focus time and “break” time and measure your results.  A good place to start would be to assume that you can focus for 90 minutes and then require 30 minutes of recovery.  Recovery is actually a good way to think about it.  Treat the time between focus sessions like the space weight lifters keep between sets and workouts.  In addition to measuring your overall work productivity also start to measure your level of mental exhaustion at the end and throughout the day. 

One personal tweak

After a number of years using The Pomodoro Technique I’ve started skipping the breaks.  I gradually increased the number of focus minutes over a period of weeks until I reached 90.  

Being accountable

As a developer (a maker) in an organization you have lots of power.  Power you may not even realize you have.  It is important to be responsible with that power to be count-on-able to use that power in good faith.  When you say it is so, others will believe you and act as if it is so.  You create the world for your collaborators.  You tell them what is and is not possible and how fast and when it is done.

Do not ever knowingly deceive them.


Not to look good.

or, to avoid looking bad.

Nor to cover up a mistake you made….

even accidentally.

even if it will never happen again.

Ruby Class Variables

class variables in modules have a different scope/context than the class variables of the class variables that the module has been mixed into.

Because Macros are evaluated first

I don’t know why this didn’t occur to me before.  Probably because when they are used they look like regular function calls.

Remember in SICP where you talk about the substitution model of computation?  Macros turn that on it’s head (a little).  You can think about it in two passes. Go through the code and make substitutions for the macros (expand the macros) and *then* go through and do substitutions for the functions and their arguments.  <- Check them out.  If you do it the way it’s designed you will feel like you really *got it*  

Metrics vs. Goals

The common knowledge is to create a goal and then work towards it.  Looking back, one of the achievements that I’m most proud of happened without a set goal.  I decided to lose weight and lost 150lbs doing it wrong.  I didn’t have a target weight and I weighed myself every single day.  

That’s weight as a metric vs weight as a goal.  I could try new things and see if they worked without it being a failure or a ‘back-slide’.  My choices were defined by a very small feedback loop in terms of weight loss, one day.  

Yesterday, I decided to throw out all my goals.  Today I’m putting in place metrics for everything that’s important.  I figure if relevant metrics and tight feedback loops work for tech startups and car manufacturing they should work for my life and I have anecdotal evidence to back it up :-)  I’ll let you know how it goes.

Prefer send over eval [ruby]

You don’t loose your stack trace when you use send like you will with eval

Problems with the office : There’s always somebody screwing around

Suggested prerequisite Stephen Pressfield’s The War Of Art: Winning the Inner Creative Battle

Go ahead, I’ll wait.

The resistance is always looking for a way to get you to not do your work.  Especially if it’s important.  The problem with an office is that there’s always someone screwing around.  I’m actively in favor of screwing around.  I believe that it’s one of the best ways to recharge your batteries and let your R-mode work on the problem in the background.  The thing is, the time to screw around is when you’ve “done the work” not right now.  When you look up and find the people around you checking youtube or twitter it’s just more fuel for your resistance.  Worse is; In an open environment listening to loud music or other drunken carousing.   Something that I’ve noticed in my time working “in weird places at weird times” is that there is almost no “screwing around” at a co-working space.

The Pomodoro Technique provides me with a great way to clearly delineate “doing the work” from not. 

Procrastination of BIG Ideas

No surprise in the fact that it has taken me a long time to get to writing this.

The Bigger the Idea, the bigger the impact, the bigger the Resistance.  

Cut down the Big Idea to a quick win.  Cut down the Resistance. 

Ruby 1.9 tap; Is it dangerous?

Can anyone explain why that behaviour is happening?  If you’re using tap you rightly expect the input to equal the output.  I’m really curious on this one.

The path of the righteous programmer is beset on all sides by the inequities of the clueless and the tyranny of evil project managers. Blessed is he, who in the name of achievement and solid technology, shepherds the users through the valley of ineptitude, for he is truly his customer’s keeper and the finder of lost solutions. And I will strike down upon thee with great vengeance and furious anger those who would attempt to deploy without testing. And you will know my name is zedshaw when I lay my software upon thee.
Don’t Write Tests

Writing code without tests usually looks like this for me.  Let me know if it sounds familiar.

  1. Open the console
  2. Create some base objects (usually Active Record Models)
  3. Write some code reopening classes along the way
  4. See if it works the way I expect it to
  5. Copy the code to a scratch space
  6. Repeat 3 - 5 until I think I’ve got what I’m looking for (occasionally jumping back to 1 to clear the environment)
  7. Put the code in the files where it belongs
  8. Checkin

The process gets a little longer when I get to working with the full stack and am looking at the browser.

  1. Create some basic models with known values
  2. Go to the URL in the browser needed to see what I’m working on
  3. See if it works
  4. Go back to the editor and try something different
  5. Repeat steps 3 & 4 until satisfied
  6. Checkin

Hey I’ve watched (some of) the Abelson and Sussman lectures and know that programming by wishful thinking is useful so sometimes I create functions/methods that use a not complete implementation.  That looks like:

  1. Realize that I’m going to need a function/method that I haven’t created yet
  2. Figure out a name for it
  3. Give it a minimal implementation
  4. Go back to what I’m working on
  5. Finish what I’m focused on
  6. Checkin
  7. Go back and finish off the helper
  8. Checkin

This should sound familiar to some if not many of you. 

What if I told you there was a framework for automating many of those steps?  Wouldn’t that be awesome? 

Steps like:

  • Creating basic objects to play with
  • Seeing if the code you’re writing does what you expect
  • Pretending that functions/methods that don’t exist yet exist with a basic implementation

It’s call rSpec people (optionally with Guard).  You can create those basic objects and wishfully-thought-of functions with rSpec stubs and mocks.  You can check if your code works the way you think it should with should.  You can even have those steps happen automatically with guard.

I invite you to not write tests (that’s boring), automate your process.  Machines should work and people should think.  The fact that you have a suite of tests and documentation at the end of the day is a bonus not the point.


I ain’t mad at’cha

[excuse the poor grammar in the title, it’s a song title.]

I was directly effected by the recent EC2 outage as a Heroku customer. I’ve heard a lot of chatter about how this proves that the cloud isn’t “all that”.  I disagree.  Simply put downtime happens.  One of the things that I pay for as a hosted (cloud) customer is that when downtime happens, I’m not stressed out trying to find the problem.  Some very smart engineers are already working on the problem. 

Yes, you should have redundant systems in place.  It’s like backups, or making sure you don’t enter the crosswalk when the red hand is flashing.  We all know that we should do it but we get burned so infrequently that it doesn’t often occur to us as important until we get singed.  I’ll be looking for another cloud to host a backup in but I’m not going to be running scared to a colo or putting a server in my basement.

Furthermore, I’m going to keep offloading the things that I’m not good at (because I don’t choose to make it my focus) to providers that are good at them, in the cloud.  Simple Worker is my next target.  I looked at setting up a delayed job queue and immediately knew the direction I would be going when I saw that Simple Worker had made it their focus.  I’m going to trust the person with focus to do it better than the dabbler even if the dabbler is me.

Beauty in action

When I am working on a problem, I never think about beauty but when I have finished, if the solution is not beautiful, I know it is wrong.
R. Buckminster Fuller

I want to write more on this subject but for now I’m putting this out in the universe to remind me.

On flawed heuristics

Philip Greenspun has a post that has caused a bit of an uproar in the Rails community. You have to scroll down quite a way to get to the moral of the story. Actually you have to scroll all the way down to the comments.

The point of the story was to show that the MIT-trained programmer with 20 years experience and an enthusiasm for the latest and greatest ended up building something that underperformed something put together by people without official CS training who apparently invested zero time in exploring optimal tools. Could some team of Rails experts have done a better job with Obviously they could have! But in the 2+ years that our MIT graduate worked on this site, he apparently did not converge on an acceptable solution.


I like this story because (1) it shows the fallacy of credentialism; a undergrad degree in CS is proof of nothing except that someone sat in a chair for four years…

From a business perspective; in a day and age where most of MIT’s CS catalog is available online for free in addition to a vast supply of other sources, why would you employ someone who payed $40k+ for a chunk of sheepskin with a fancy script font to build your next killer app or architect your environment? Likewise to the programmers of the world; why would you choose to work for someone so rigid and unimaginitive they’ve never questioned the “BS in CS or related” heuristic? One has to question whether such a hiring manager is interested in results or appearances.