My current LivingSocial cohort Shane Warden shared an article the other day titled “The steel man of #GamerGate”, which isn't really about #GamerGate but about steelmanning, “the art of addressing the best form of the other person’s argument, even if it’s not the one they presented.”

Which was timely, because the most recent This American Life features a bit where producer Alex Blumberg got to pitch a startup idea to Chris Sacca, and Sacca expertly steelmanned Alex:

At a certain point, Chris drops the pretense that this is an actual investor meeting and just starts coaching me on my pitch, feeding me questions, and then correcting my answers.

“Give me a second and I'm gonna give you your pitch back.”

And then, right there, not far from the freeway overpass near Pico and Bundy, he steps into the role of me, starts giving the pitch I should be giving.


Alex Blumberg: That was amazing!

Chris Sacca: That's your story, right?

Alex Blumberg: That is great. Holy [BLEEP]. I thought I was a storyteller. Now I feel bad about my job.

I'm thinking, oh, if he pitched my idea that well, he must be into it, right? He's going to invest. But then he goes on.


At this point, I have no idea what to think. I'm drained, my pits are drenched, and Chris Sacca has just given me two completely convincing cases in favor of and against investing in my business. Whatever shred of conviction I had about this process at the beginning is gone.

Audio for this portion starts around the 24 minute mark, though this story is the first in the episode, so you can also just listen from the beginning.

This also overlaps with the conflict resolution skills my wife and I were taught and what we also use when working with other couples, to endeavor to repeat back to another person what was heard, to make sure a problem is mutually understood before attempting to rectify anything.

A friend of mine recently asked for advice on pitching himself to a group of developers for a project management spot at his gig. He was feeling the weightiness of asking to help manage a group of people who do work he doesn't deeply understand himself.

Rather than try to pitch them on projects he had successfully managed before, we talked about what I want, and I came up with this pitch:

What would you say?
Rails 4 has moved its rails command to the bin directory of the application, but this collides with any existing rails command put there by the --binstubs flag, and the two are not compatible.

The recommended way to use binstubs with Bundler and Rails 4 is to not use the global --binstubs flag, but to call bundle binstubs [gemname] individually on gems you want in your local bin folder. For some background on these changes, check out these commit comment threads: rails bundler.

There was an attempt to make Bundler 1.3.x not override anything in the bin directory if --binstubs was in effect, but that change was reverted for semantic versioning. My understanding is this change will be re-attempted in Bundler 2.x.
I've been using the local path option with Bundler for some time now and it works really well. I use RubyMine and it won't browse . directories, so rather than using the .bundle dir for the local install path, I've taken to using ‘zz’ so I can still get all of the good RubyMine goodness for spelunking gem code while making sure gems are grouped at the bottom of my search results. Working on a project in the midst of a Ruby upgrade, it's also nice to have groups of 1.8 and 1.9 gems installed separately in the zz/ruby/1.x/gems paths.

One thing I find myself doing on occasion when trying to sort out gem troubles is removing an entire gem's directory structure, mistakenly thinking that'll get bundler to re-install the gem on the next bundle call.

The problem is Bundler (or actually RubyGems) doesn't check the gem's installed directory for its presence, but just scans the specifications folder for .gemspec files. In order for my little trick to work, I not only need to blow away the gems directory structure in zz/ruby/1.x/gems/, but also its .gemspec file in zz/ruby/1.x/specifications.

It would be nice if a bundle reinstall command existed to do this. `bundle update` isn't what I want since that will update to the latest matching version.
If technology is getting you down, gentle developer, you're not alone. It's easy to be overwhelmed by the sheer amount of stuff out there in the wide wide world of webs, not to mention the frustrations that come with trying to wrangle all of these tools into some semblance of order. Pile on some peer shame and unreasonable expectations of our own performance and it might be time to hide the razor blades. Take heart, however. Cue up some Billy Joel and when you can take no more of that (my max time is 49 seconds), switch over to my lightning talk on Technical Intimidation I gave at RailsConf 2013. Maybe some cheesy jokes and a dense helping of quotes from smart people will help put that spring in your typing once again.

I reference some TED talks by Brené Brown at the end of it - here they are - go watch them now:

Listening to Shame
The Power of Vulnerability

Here's the Ashe Dryden talk mentioned at the end of the RailsConf version:

Must Have 10+ Years People Experience

Greg Bauges also has some excellent content on Devs and Depression.


Many of the quotes from the talk I culled from my BlogKi here:


Jess Eldredge sketchnoted my talk! Check out all her RailsConf sketches.

Here's a prior version I gave at BigRubyConf 2013.

Trivia: Mythbuster Adam Savage is the nerdy kid drowning in that Billy Joel video.
Ken Levine (a writer who's worked on MASH, Cheers, Frasier and many other shows) discusses the intractable problem of fixing a script that just ain't funny, retelling an encouraging story about how early on The Odd Couple was failing to get laughs in its third act, and how a critic-inspired idea fixed it. Ken wraps up with a nice ShameAntidote:
When geniuses like Neil Simon and Mike Nichols can't put their fingers on a problem, what hope is there for the rest of us?

So when you get stuck just know, there is no Dr. House for writing. At times we’re all Frank Burns.

Are exceptions a good or bad thing in a language? Joel Spolsky, Anders Hejlsberg and others weigh in.

Joel doesn't like exceptions.
They create too many possible exit points for a function. To write correct code, you really have to think about every possible code path through your function. Every time you call a function that can raise an exception and don't catch it on the spot, you create opportunities for surprise bugs caused by functions that terminated abruptly, leaving data in an inconsistent state, or other code paths that you didn't think about.

A better alternative is to have your functions return error values when things go wrong, and to deal with these explicitly, no matter how verbose it might be.

Anders disagrees:
It is funny how people think that the important thing about exceptions is handling them. In a well-written application there's a ratio of ten to one, in my opinion, of try finally to try catch. In the finally, you protect yourself against the exceptions, but you don't actually handle them. ... because in a lot of cases, people don't care. They're not going to handle any of these exceptions. There's a bottom level exception handler around their message loop. That handler is just going to bring up a dialog that says what went wrong and continue. The programmers protect their code by writing try finally's everywhere, so they'll back out correctly if an exception occurs, but they're not actually interested in handling the exceptions. (quotes re-arranged for my emphasis)

Raymond Chen appears to weigh in against exceptions in Cleaner, more elegant, and wrong, but clarifies a bit with Cleaner, more elegant and harder to recognize:
The title of the [prior] article was a reference to a specific code snippet that I copied from a book, where the book's author claimed that the code he presented was “cleaner and more elegant”. I was pointing out that the code fragment was not only cleaner and more elegant, it was also wrong.

You can write correct exception-based programming.

Mind you, it's hard.

It's easy to write bad code, regardless of the error model.

It's hard to write good error-code-based code since you have to check every error code and think about what you should do when an error occurs.

It's really hard to write good exception-based code since you have to check every single line of code (indeed, every sub-expression) and think about what exceptions it might raise and how your code will react to it. (In C++ it's not quite so bad because C++ exceptions are raised only at specific points during execution. In C#, exceptions can be raised at any time.)

In practice, I've never really worried about it and simply fallen in line with how Anders describes the world and it seems to work out fine, but that's not to say I know what I'm doing.

Martin Fowler on metrics:
Metrics have a purpose and a place in organizations and teams. They cannot be used as a substitute for thinking. Nor can organizations think management by numbers is enough for effective software delivery. Organizations must be vigilant against the undesirable behaviors that emerge due to the inappropriate use of metrics.

Use the following guidelines to lead you to a more appropriate use of metrics:

1. Explicitly link metrics to goals
2. Favor tracking trends over absolute numbers
3. Use shorter tracking periods
4. Change metrics when they stop driving change
Rails 4 Turbolinks will mess with any Javascript hooking into the document/window ready event. This isn't news to those paying attention, but I wasn't until I ran across it while overhauling my site and my wiki (ClWiki) that runs it. There's an easy solution, however. Turbolinks provides some custom events that you can hook your ready code into. In my case, I had some Javascript to control element focus while searching the wiki and merely had to add one line:

$(document).on('page:change', findFocus);

New stuff at the bottom of the page.

November 2003 :: JoelSpolsky recommends Facts and Fallacies of Software Engineering, by Robert L. Glass as a good summary of the core things we know about software development so far (which is interesting in light of SwebokAndLicensing, and I've heard some other heavyweights in the development world are not in love the Glass book). Number one in Joel's summary of the facts presented in the book:
The most important factor in software work is not the tools and techniques used by the programmers, but rather the quality of the programmers themselves.

Joel also has a great essay on how attempts to codify the successfulness of talented people just don't work.
1. Some things need talent to do really well.
2. It's hard to scale talent.
3. One way people try to scale talent is by having the talent create rules for the untalented to follow.
4. The quality of the resulting product is very low.

I was listening to a local sports station the other day interview John Gagliardi, who, on 11/8/03, became college football's winningest coach. A lot of the interview centered around John's coaching style, and the fact that he does a lot of things different (no tackling during practice, for example). The overall gist was that he didn't have a very detailed infrastructure for his team -- much of what a big college football program would do, he doesn't worry with. In fact, he summarized his approach this way (and I paraphrase because I didn't write down the quote being in the car at the time):
What you really need are good players. Good players don't need a lot of rules.

(Or structure: “On the best teams, different individuals provide occasional leadership, taking charge in areas where they have particular strengths. No one is the permanent leader... The structure of the team is a network, not a hierarchy.” Peopleware: Productive Projects and Teams, 2nd ed., p. 155, Tom DeMarco and Timothy Lister -- via Dave Hoover's blog

January 2004 :: Bill Caputo posts this [quote is digestized]:
[Non-agilists] see nothing -- or very little -- in the XP process definition that will make people successfully deliver -- but its true of any process. [They] want a process that will make others succeed. Agilists believe this view of process is inherently flawed. No process makes you successful, but people who will succeed anyway can do so with a more or less painful process.

XP is simply the best collection of practices I have ever found that are generally useful in addressing the problems I try to solve on each project -- but in the end, I succeed because of me and the people around me, not our process, which we readily change in response to our current challenges.

[W]e don't claim XP will protect us from the harmful, we claim that it aids the successful.

Jerry Weinberg, in an interview on Borland's site (via Esther Derby), chimes in with some soundbites on this topic:
What do you consider the most important thing for a programmer to do when he begins working on a new project?

I think each should be sure they are in good physical condition without nagging psychological problems.

What do you consider the most important thing for a programmer to do when he begins working on a project that has already begun?

She should get sufficient information to decide, before signing on, whether she should sign on. Most programming projects that fail have already failed before most of the programmers have signed on, but through lack of courage or due diligence, many programmers sign on anyway. It's like doctors agreeing to do surgery on corpses.

Would you recommend a career in programming to young people today?

It depends on what the young person wants to do. I always give the same career recommendation: “Do what you want to do.”

What courses would you recommend they take? What languages/technologies should they key on?

They shouldn't key on languages and technologies. They should key on learning to communicate, to think, and to work well with other people. Once they have those, the languages and technologies become simple matters. Without them, no amount of language or technology expertise will do much good.

May 2004 :: Fast Company article on how good companies become great. The secret sauce? People. [via Clarke Ching]
Take David Maxwell's bus ride. When he became CEO of Fannie Mae in 1981, the company was losing $1 million every business day, with $56 billion worth of mortgage loans under water.

Maxwell told his management team that there would only be seats on the bus for A-level people who were willing to put out A-plus effort. He interviewed every member of the team. He told them all the same thing: It was going to be a tough ride, a very demanding trip. If they didn't want to go, fine; just say so. Now's the time to get off the bus, he said. No questions asked, no recriminations. In all, 14 of 26 executives got off the bus. They were replaced by some of the best, smartest, and hardest-working executives in the world of finance.

With the right people on the bus, in the right seats, Maxwell then turned his full attention to the “what” question. He and his team took Fannie Mae from losing $1 million a day at the start of his tenure to earning $4 million a day at the end.

November 2004
[O]nly a virtuous people are capable of freedom. As nations become corrupt and vicious, they have more need of masters.

Source: Benjamin Franklin, The Writings of Benjamin Franklin, Jared Sparks, editor (Boston: Tappan, Whittemore and Mason, 1840), Vol. X, p. 297, April 17, 1787.

found at

March 2005 :: MartinFowler has chimed in on this topic on his own blog:
If I had to pick one as my key to software development it's that the critical element in a software development effort are the people you have doing the work. The productivity of the best developers is far more than the average, much more than the difference in salaries.
He added another article in Feb 08 talking more about the productivity factor:
Although the technorati generally agree that talented programmers are more productive than the average, the impossibility of measurement means they cannot come up with an actual figure. So let's invent one for argument sake: 2. If you can find a factor-2 talented programmer for less than twice of the salary of an average programmer - then that programmer ends up being cheaper. To state this more generally: If the cost premium for a more productive developer is less than the higher productivity of that developer, then it's cheaper to hire the more expensive developer. The cheaper talent hypothesis is that the cost premium is indeed less, and thus it's cheaper to hire more productive developers even if they are more expensive.

August 2007 :: Alistair Cockburn:
People still trump process ... and theory, and ideas.

One of the great things I keep seeing (used to be “keep learning”, but at least by now I half expect it when things blow up in my face), is how the individual chemistry between people operates outside of all the nice theory we construct.

Mary Poppendieck (via InfoQ), offers an interesting quote that seems to come across counter to the other quotes on this page:
We get brilliant results from average people managing brilliant systems. Our competitors get average results from brilliant people working around broken systems. - Fujio Cho, Chairman Toyota Motors
Elsewhere at Poppendieck's site, this paper gives more insight:
[Scholtes] says, “All of the empowered, motivated, teamed-up, self-directed, incentivized, accountable, reengineered, and reinvented people you can muster cannot compensate for a dysfunctional system....” So where does this leave us? Which is more important - process or people?


[The answer is both, “Process AND People”] ... People like to use effective processes, and they also like to have control over their own environment.... Process improvement may be done only “at the gemba” [the place of the problem] and it is up to the workers to decide whether or not a proposed improvement should be implemented.

October 2007 :: Joel weighs in again, this time via
Mistake No. 1: Start with a mediocre team of developers.
Designing software is hard, and unfortunately, a lot of the people who call themselves programmers can't really do it. But even though a bad team of developers tends to be the No. 1 cause of software project failures, you'd never know it from reading official postmortems.


At Fog Creek, we tend to review about 400 candidates for every full-time hire, because the best developers can be 10 times as productive as the merely excellent developers.

DaveThomas in his Herding Racehorses, Racing Sheep presentation at QCon London 2007 quotes Capers Jones from his book Software Assessments, Benchmarks, and Best Practices:
“Without excellent personnel, even good to excellent processes can only achieve marginal results.”

October 2009 :: Michael Bolton on maturity models:
Maturity Models Have It Backwards

A mature person is one who is highly conscious of when it's appropriate to follow rules and when to break them. A mature person is largely self-guided. Only in exceptional circumstances does a mature person need to refer to or appeal to a rulebook at all.

May 2010 :: A dissenting opinion from Michael Hill (though it does align with the quote earlier on this page from Fujio Cho, Chairman of Toyota Motors, “We get brilliant results from average people managing brilliant systems.”):
“XP Requires High-Skill Teams”

This noxious notion burbles around the interwebs in various configurations, as it has since the beginning of XP. It’s mistaken.

I’ve worked with many more low-skill teams than high-skill ones, for two reasons:

I’m not cheap, therefore much of my business comes from teams that are in trouble. High-skill teams can hide and defer trouble far longer than low-skill ones.

There are far too few programmers, therefore the world of commerce has to settle for low-skill (and no-skill) ones. At least 75% of all programmers are low-skill ones.

I keep thinking I should give up before I start when I see a low-skill team. Fortunately, I am really bad at money, so I don’t refuse many clients. This has impressed upon me the complete irrelevance of skill level in adopting and adapting XP.

... and what Michael calls irrelevant, Brian Marick says is missing from the original Manifesto:
[Teams] should invest in one of the four values I want to talk about: skill. As someone who wants to remain anonymous said to me:
I’ve also been tired for years of software people who seem embarrassed to admit that, at some point in the proceedings, someone competent has to write some damn code.

Feb 2013 :: Re-reading through Cringely's Accidental Empires book as he's re-posting it on his blog, he makes this outlandish claim in Chapter 2:
Here is a fact that will shock people who are unaware of the way computers and software are designed: at the extreme edges of the normal distribution, there are programmers who are 100 times more productive than the average programmer simply on the basis of the number of lines of computer code they can write in a given period of time. Going a bit further, since some programmers are so accomplished that their programming feats are beyond the ability of most of their peers, we might say that they are infinitely more productive for really creative, leading-edge projects.

The trick to developing a new computer or program, then, is not to hire a lot of smart people but to hire a few very smart people. This rule lies at the heart of most successful ventures in the personal computer industry.
This makes me wonder how far back this notion of ‘X times more productive’ goes. 100x seems unlikely given any measure, but especially Cringely's measure of “lines of code.”

tags: ComputersAndTechnology AgileDevelopment