Get in touch to talk startups and web apps!

Best bet is to email me or ping me on Linkedin.

A Wealth of Information Creates Poverty of Thought

“We wear our ability to multitask like a badge of achievement when really it’s the worst thing we can do to our brain,” declares Dr. Sandra Bond Chapman of the Center for BrainHealth in Dallas.

Quotes and platitudes were leaping off the page as I read a fabulous article in Southwest’s Spirit magazine. Having read brain books by Dr. Rober Cialdini and John Medina (of the Brain Rules Book fame), I’m constantly on the lookout for further insights into our mega-complex minds. Having been a recent victim of the information overload syndrom, statements from Chapman such as,

“A wealth of information creates poverty of thought.”

and,

“The most powerful part of our brain is it’s blocking ability, but teens aren’t learning it because of information overload.”

seem to resonate with a crystal clear signal: we need to absorb less and produce more. Chapman’s single biggest whack at the root cause comes from this directive:

“When you’ve got something that needs to get done, block out everything else and tackle it in 30 minute uninterrupted intervals.”

MRI Ruby Consumes 2x Memory on 64-bit Linux

I stumbled upon a nugget of wisdom on this post answered by Hongli Lai on the Phusion Passenger Google group:

This is normal. On 64 bit all pointers are double the size. MRI is
implemented with a lot of pointers so all Ruby apps use almost twice the
memory. Go back to 32 bit if you don’t like this.

Five Interview Tips for Techies

Why not a Top 10 list? Because when you’re in the hot seat, you’ll be lucky to recall two of these tips, let alone 10!

1. Your timidness could cost you the job (or fetch you a lower salary)

The president of my company often inquires if the candidate we’re introducing him to can “fog a mirror.” Partly in jest, but mostly from experience, he adopted this phrase resulting from numerous interviews with stereotypically shy, timid and quiet computer programmers.

Do you have to be bubbly and gregarious to land a job? No. But making a concerted effort to ditch your shyness and in place, present yourself confidently with a projected voice will go a long way to making a strong first impression. Don’t forget to smile and appear excited to be given the opportunity to interview.

2. Be ye neither terse nor verbose

There is a saying that conversation is the art of telling people a little less than they want to know. An interview is an opportunity for a conversation. From my experience, many technology candidates blow this opportunity by ditching or dominating the dialog.

When the candidate provides abrupt, terse answers to open-ended questions, it causes the interviewer to work too hard to build a compelling story about YOU. It’s okay to keep your answers short and simple, but mindful to keep your answers interesting, invoking the interviewer to ask follow up questions.

Almost worse are the candidates who, when asked a question such as, “Tell me about the project you are currently working on”, start talking and don’t come up for air until interrupted by the interviewer that the evening janitor is waiting outside to empty the trash can and vacuum the floor. Do not, I repeat do not talk for more than a handful of sentences before you give the ball back to the interviewer. Remember, the point is to have a dialog, which is at least twice as enjoyable as a monolog.

3. Treat the interview like a working session rather than an interview

Odds are very high that you are going to answer a question incorrectly; whether you misunderstood the question or the interviewer misunderstood your answer, it’s bound to happen. Without going overboard, take advantage of this extremely useful tip: ask for clarification before answering.

If the interviewer hits you with a difficult problem or scenario, restate to them exactly what you think they are asking. That alone will cause you to stand out. Besides, it’s good business. In the real world, the client almost always finds a way to ask their questions in the most ridiculous, unintuitive way.

What if you don’t have an answer? My advice is to be honest. Tell them, “I don’t know.” In fact, you could even turn it into a bigger win with an answer like this, “Hmm…I’m not sure I know where you are going. Can you give me an idea of how a previous candidate approached this same problem?” With luck, you’ll figure out where they are wanting you to go and the recovery will be perceived as skilled and professional.

4. When they hand you the ball, score a touchdown

At the end of the interview, I hand the ball off to the candidate by saying something to the effect of, “I’ve been asking all the questions thus far. Let me turn the table and give you a chance to ask me any questions you’d like.” Most candidates fail. Miserably. They either dodge the opportunity completely or offer up something really lame like, “what does your company do?”

What does my company do? If you can’t ask a more specific question to the company with whom you’re about to sign over your daylight hours, you’re not a compelling candidate. Google and Linkedin are your friends! Go into the interview with highly specific questions, such as, “I see from your website that most of your clients are out-of-state. Why is that and what advantages would there be to bringing business closer to home?” It gives me goosebumps to imagine a candidate getting real like that. Do it and you’ll land the job. Guaranteed*.

My personal favorite is to skillfully interview the interviewer. Questions like,

“Tell me about your experience in the company.”
“Has it met your original expectations?”
“What would you say are among the top three perks for working here?”

These types of questions add both transparency and clarity to your own decision making process.

* assuming they are convinced you are adequately qualified for the position.

5. Whether they ask for it or not, clearly state your value proposition

Many, if not most, interviewers are horrible at interviewing. Often, they don’t ask the right questions and even when they do, they don’t know how to evaluate the answer.

Be prepared with a truthful, yet confident statement that proves you have given thought into why this specific employer would be crazy to hire somebody else over you, even if you are not as qualified. Something like the following can work wonders:

“Before we conclude, I just wanted to thank you for the opportunity to interview me. I know your time is precious, so I appreciate that you have taken time to talk with me. I feel strongly that I can become a solid Ruby developer with a minimal learning curve. I have a passion for the language, which means I’m eating, sleeping and drinking it to be the best Ruby programmer on the team. I look forward to hearing back from you.”

Be careful not to make preemptive or unnecessary concessions when delivering your value proposition. I have hear candidates make statements such as, “I know I don’t have the 2-3 years worth of Ruby experience that you’re looking for, so I’m willing to come in at a lower salary if you just give me the chance.” It’s fine to negotiate, just do it only if necessary and at the right time.

Your Predictions are Futile

I love the honesty and candidness with which seasoned architects and engineers address the futileness of predicting, forecasting and estimating. Much like the open markets in the real world (eg. NYSE), software projects take on a life of their own, neither being fully guided, nor proving to be completely unpredictable.

CTO and founder of Gowalla, Scott Raymond, was recently interviewed via e-mail. Because his shop is a Ruby shop and given that Gowalla is built on the Rails framework, he of course was asked how big of an issue Ruby’s performance has been as his application has seen massive growth and scaling. He said the “Rails can’t scale” meme is outdated and most likely misguided in the first place.

What was even more interesting, however, was his statement about scaling in general. While discussing the criticality of scaling a popular service, he confessed,

In my experience, it’s harder to predict these things than you would think. I have spent many hours trying to “pre-scale” parts of the app that never became a problem, which often leads to maintenance headaches.

How much time has been spent on software projects spec’ing out the details of a feature that is never needed? Or designing systems that aren’t useful? Or solving problems that never come into fruition? I believe the root of the issue is that too much planning and too much predicting can rob a project and its resources of valuable time that could be spent on more productive activities.

A well disciplined team with deep knowledge and insight into how to solve difficult domain-specific issues appeals to me as being the right way to prepare for unforeseen events. In the words of Musashi,

You should not have a favorite weapon. To become over-familiar with one weapon is as much a fault as not knowing it sufficiently well. You should not copy others, but use weapons which you can handle properly. It is bad for commanders and troopers to have likes and dislikes. These are things you must learn thoroughly.

One Man’s Trash is Another Man’s Enterprise Software

Having been on multiple “enterprise-grade” software projects, I couldn’t help but re-post the following definition of enterprise software by Rob Conery that a friend of my sent me the other day. The hyperbole is a bit extreme, but as any seasoned programmer can testify, completely justified.

Before I post the quote, I should say that enterprise software is a necessary evil and most often a cash cow for the businesses that own them. It is really unfortunate that the software industry has given itself (and allowed the business leaders to give) such a big black eye for encumbering projects with massive amounts of technical debt.

Let me tell you what “Enterprise-ready” typically means to me. And this perspective is from someone who’s hired (typically) to come in and “fix” an existing “Enterprise” app.

Usually “Enterprise-ready” software is a steaming pile of XML served up with crap-sauce, a shot of Best Practices, and a side of 4-year Old Framework. It’s Frankenware, it’s horrific, and usually always wants to kiss your sister in front of you. With tongue.

Rob Conery, Massive for the Enterprise

Using rack-debug in a Rails 3 Application

For some dumb reason, I stopped using ruby-debug several years ago. I think it had to do with Passenger compatibility, but I don’t recall specifically. After beating my head on the wall over a particularly nasty bug, I decided to get reacquainted with my old debugger friend.

This time around, I opted to try ddollar’s rack-debug. It is a rack-compatible wrapper for the ruby-debug gem. The README page for the project was both helpful and a bit lacking. Since my project is using REE (1.8.7), it stated I needed the 1.4.2 version of the rack-debug gem.

In order to get the gem rack-debug gem working with my Rails 3 application, I had to add the following line to my Gemfile:

gem "rack-debug", "1.4.2", :require => "rack/debug"

Then, it was simply a matter of adding the rack app to the middleware stack inside config/environment/development.rb:

config.middleware.use Rack::Debug

And requiring the rake task in Rakefile:

require ‘rack-debug/tasks’ if Rails.env.development?

If you get any strange errors when you run the ‘rake debug’ task, such as the following:

$ rake debug<br />
Unable to connect to debugging socket: Connection refused &#8211; /apps/my_project/tmp/sockets/debugger.server
or
$ rake debug<br />
Server is not running or Passenger has spooled down

Then be sure to issue a restart to passenger (touch tmp/restart.txt) and refresh your browser window. You should then be able to start the debugger via the rake task.
Oh yeah, back in action with the debugger. Use this handy ruby-debug reference that should ensure hours of happy debugging in Rails 3 and Rack applications in general.

Quick Specs on RetHat Linux Box

I needed to quickly get some specs on a cluster of RedHat linux boxes that were running a Ruby on Rails project our company is enhancing for a client. While this is far from a comprehensive list, running the following commands gave me useful information about the server, linux os, etc.

Server Info:
cat /proc/cpuinfo

OS Info:
cat /etc/redhat-release

OS Architecture (32 v. 64):
uname -a

RAM:
free or grep -i memtotal /proc/meminfo

Disk Space:
df -h

Public IP:
curl checkip.dyndns.org

Private IP:
/sbin/ifconfig | grep ‘inet addr’

Hostname:
cat /etc/sysconfig/network

Mapped Hosts:
cat /etc/hosts

Coming Soon…The Perfect [online] Fit

I’ll confess: I love buying shoes. Zappos probably has me on their about-to-be-fired-as-a-customer list, given how many shoes I’ve ordered and subsequently returned due to sizing issues. A few weeks ago, I ordered a few pairs of Clarks, some Saucony Jazz Originals, and some Hush Puppies. Since I’m typically between an 11 and 11 1/2, I opted to go with size 11 1/2. I was batting .500. Clarks & Puppies: way too big; Sauconies: too squishy.

That’s where Shoefitr enters the picture. Their 3D scanning technology scans the inside of shoes to get the exact measurements of a given shoe, which can then be compared against every other pair of shoes. The only requirement on the part of the consumer is to find at least one pair of shoes that fits perfectly. From there, it’s just a matter of using this shoe as a benchmark when shopping for other shoes.

For example, I’ve recently declared the Brooks Cascadia 5 size 11 1/2 to be the most comfortable shoe I have ever warn. I plugged this shoe, along with my size, into the Shoefitr calculator and it determined that I am a size 11 in the Asics GT-2150. Brilliant! It is just a matter of time before this technology is commonplace on shoe manufacturer and e-commerce websites.

Installing RVM on Ubuntu

I recently did a fresh install of Ubuntu on a Dell laptop for a Rails project I’m working on. Everything was cruising along perfectly until I tried getting RVM installed, which I erroneously assumed would be a breeze. I kept bumping into issues where an installed gem was complaining that it wasn’t compiled against the correct libraries. For each error, I needed to invoke a special rvm package install uninstall the ruby, reinstall the ruby and reinstall the gems. It was turning into a nightmare.

It turns out that Chris Irish had a much cleaner approach: install all the libraries via apt-get and be done with it. Too simple. I followed the steps in his post and was rollin’ with RVM in no time. It appears that the following packages needed to be installed prior to installing the gems:

sudo apt-get install build-essential bison openssl libreadline5 libreadline-dev curl git-core zlib1g zlib1g-dev libssl-dev vim libsqlite3-0 libsqlite3-dev sqlite3 libreadline-dev libxml2-dev git-core subversion autoconf

Trevor Linderman Takes State in Deca Competition

Image for Trevor Linderman Takes State in Deca Competition

A colleague and friend of mine, Trevor Linderman, is a gold medalist! Last weekend he took part in the Utah Collegate Deca competition. Considering he entered the contest almost on a whim, it’s amazing that he took the gold medal in the Financial Statement Analysis (FSA) competition and a silver medal in the HR event.

For the FSA he and a partner compared and contrasted the finanical position of two companies in the same industry. They presented their recommendations in the form of a prospectus to a pannel of judges acting as potential investors. Their pitch was to advise on the “best” place to put the investor’s money. I guess he’s a better BS’er that we thought, because he and his partner took first in state.

The HR event was case based. He received a case and had 30 minutes to prepare a solution and then presented to a panel of judges acting as the CEO of the company. This was an indvidual event in which he took second place in the state.

In April, he’s headed off to Florida to compete at the national tournament. Good luck, Trevor!!

A short bit on me…

First and foremost, I am a husband to the most incredible woman alive, a father of four amazing children and in general, I love being alive.

After that, I am a passionate Ruby on Rails developer, a {biking|climbing|hiking|swimming} enthusiast, a paleo chef (ahem…in my own kitchen), an avid reader, and a huge fan of tech startups.

My current role is software engineering manager at OveractDev Technology Partners in St. George, UT. We build custom web applications with pride and craftsmanship.

On Approaches and Manifestos

A list of several approaches and manifestos that I try to practice. Know of another one that I would be interested in? Send me a link!

Git Workflow and this one, too.

Getting Things Done

It’s All in { Jira | Tracker | Rally | etc }…Anywhere but Email!

five.sentenc.es

Agile Manifesto

Software Craftsmanship Manifesto

A child is the ultimate startup, and I have three. This makes me rich. — Guy Kawasaki, The Art of the Start