Square’s @jackdanger wrote a great post on his blog titled “The Upside Down Org Chart.” It’s a great read on improving how reasonably-sized companies are structured. His use of a tree that expands upwards, showing how management supports subordination, is genius. It visually explains the role of management:

For a tech company to describe their structure this way requires some humility from the leadership. It requires accepting that senior positions must be evaluated based on the support given to individuals on the team rather than the support given to the CEO or executives. But it makes the structure one in which nothing is extracted from the laborers – indeed it provides help that an individual could not find working alone.

His blog post’s description of traditional top-down management structures brought back memories of teams I’ve been on that, despite having favorable org charts, were unpleasant. The problem was that I was treated as (and acted like) a producer of diffs, rather than a problem-solver.

Sitepoint recently published Introduction to Thor and, to be honest, I don’t think Thor is a great tool for writing command-line apps. Thor is a great for writing Rails generators (likely the only reasonable tool), but I wrote GLI specifically because I wanted a tool tailor-made to write awesome command-line apps.

With the re-release of my book, which uses GLI to demonstrate how to build amazing command-line apps in Ruby, I thought I’d mimic Sitepoint’s post with a GLI version, and let you decide for yourself.

If you’ve ever been on a vacation where you don’t have perfectly fast network access, and tried to use popular social-networking apps, you can probably identify with my tweet:

This I know: the developers of Instagram, Facebook, and Tripit have never been on a vacation where they used the app they develop.

— ❺➠ David Copeland (@davetron5000) October 26, 2013

I use a lot of applications from companies that present themselves as developer-friendly, agile, forward-thinking, and product-focused. Despite that, these products have very obvious flaws that, to my thinking, reduce the value to both the company and its users (unlike, say, Google Ads, which only reduce value to users).

Tearing apart the three apps I mention above will be an undertaking, so I’d like to start with an app I really, really like, and use almost every day: Square Wallet.

I get asked occasionally about the self-publishing process and how it compares to the “professional” publishing process, since I have done both. I thought it might be interesting to compare and contrast these two approaches. The professional approach is regimented, organized, and carries many advantages, while self-publishing allows total freedom, at the cost of doing a lot more work for a lot less money.

Jeff Atwood (AKA codinghorror), introduced a new computer keyboard, produced by WASD, called the CODE keyboard:

I told him that the state of keyboards was unacceptable to me as a geek, and I proposed a partnership wherein I was willing to work with him to do whatever it takes to produce a truly great mechanical keyboard.

Jeff is heralding this as a “truly great mechanical keyboard”. I was very eager to see what such a beast looked like. Here it is:

Oh wait, sorry, that’s the original 101-key version of the IBM PC Keyboard, introduced in 1985. How’d that get there? It’s been almost thirty years, so the CODE keyboard must be awesome, right?

Quick, which is better: MiniTest or RSpec? HAML or ERB? SASS or LESS?

If you are building your first Rails app at your company, it doesn’t matter. They all work more or less the same, so just pick one and go. Take a vote or declare by fiat, but get on with your life. No project ever failed because they picked HAML over ERB.

If, on the other hand, you are building a new Rails application that runs in an existing technical infrastructure (which is far more likely), then these are the absolute wrong questions to be asking. Use what your team already uses unless there’s a good technical reason not to. Why?

Because consistency is far more important than most other factors.