Script for Episode 78: Done And Gets Things Smart

78 – Done And Gets Things Smart

Episode 78 of the All The Responsibility, None Of The Authority podcast

By Nils Davis

Rub-A-Dub-Dub and Done & Gets Things Smart – those are the names of two essays I read way  back in the day – in the 2000s! – that influenced me a lot in my product management practice and thinking.

In this episode I’m going to talk about how these two articles created new mental models for me, and that maybe you will also find valuable to think about how to make our products successful. 

Hi, This is Nils Davis and you’re listening to episode 78 of the All The Responsibility podcast. For show notes, including links to the articles and sites I mention, check out 

The background – the articles

Rub-a-Dub-Dub, by Joel On Software

Back in the 2000s there was a very influential blog in the software engineering world called “Joel On Software.” Written beautifully by Joel Spolsky, who at the time ran a company called Fogbugz, and was one of the founders of Stack Overflow, it ended up with over 1,100 great articles about software engineering, entrepreneurship, management, and strategy.

From all these articles – and I definitely read most of them, if not all – the one that made the biggest impression on me was called “Rub-a-Dub-Dub.”

It was about the folly – which the old Netscape company was going through at the time – of rewriting the code base of their web browser and other web tools. He’d written several times about this. 

Rub-a-dub-dub was about the “right way” to rewrite.

Over multiple releases *his* product – Fogbugz – had gotten crufty. He wanted to clean it up – refactor the code – but not in the way that Netscape was trying to do and failing at.

His approach, based on very simple rules, was to go through the application carefully, line by line and function by function, leaving the functionality exactly the same, but cleaning up the actual code.

Take what’s working, and refactor it to make it more resilient, robust, safe, etc., using only what you might call “mechanical transformations.” 

The article is a very fun read because Joel did the work himself, supposedly over roughly three weeks. It’s a great story. (

  • The rules were:
    • No new Features, not even small ones, would be added.
    • At any time, with any check in, the code would still work perfectly.
    • All I would do is logical transformations — the kinds of things that are almost mechanical and which you can convince yourself immediately will not change the behavior of the code.
  • The point of Rub-a-dub-dub is you’re starting from something that works but that has sanitary problems – dirty code, etc. – and cleaning it up, but otherwise not changing it. 

This was a very influential article to me. 

Now, Joel also has another concept, this time about hiring developers for his team. In fact, he used the phrase as the title of his book – Smart and Gets Things Done. His goal in hiring is people who are Smart and Get Things Done. Sounds great, and Joel w as very successful, so it’s clearly a good rubric. The original article was called The Guerrilla Guide To Hiring. 

How do you know whether to hire someone?

In principle, it’s simple. You’re looking for people who are

  1. Smart, and
  2. Get things done.

That’s it. That’s all you’re looking for. Memorize that. Recite it to yourself before you go to bed every night. 


People who are Smart but don’t Get Things Done often have PhDs and work in big companies where nobody listens to them because they are completely impractical. They would rather mull over something academic about a problem rather than ship on time.


People who Get Things Done but are not Smart will do stupid things, seemingly without thinking about them, and somebody else will have to come clean up their mess later. This makes them net liabilities to the company because not only do they fail to contribute, but they soak up good people’s time.


However, Steve Yegge, an engineer at Amazon at the time, wrote an amazing article called “Done, and Gets Things Smart,” about another rubric for hiring. A nearly impossible rubric to actually hire for, but one that has a great application to actual products – the ones that can potentially change everything. (

Yegge says, about Joel’s rubric: 

People quote Joel’s Proverb all the time because it gives us all such a nice snuggly feeling. Why? Because to be in this industry at all, even a bottom-feeder, you have to be smart. You were probably the top kid in your elementary school class. People probably picked on you. You were the geek back when geeks weren’t popular. But now “smart” is fashionable.

He goes to say that due to the Dunning-Kreuger Effect, it’s darn hard to recognize people who are smarter than you. And it’s hard to find out in the interview process if they can actually get things done. As a result the Smart and Gets Things Done rubric tends, at best, to guide you to hire people who are much like you.

But he challenges us with this thought experiment:

Let me ask you a brutally honest question: since you began interviewing, how many of the engineers you’ve voted thumbs-up on (i.e. “hire!”), are engineers you’d personally hire to work with you in your first startup company? 

I posit that most of you, willing to admit it or not, have a lower bar for your current company than you would for your own personal startup.

The people you’d want to be in your startup are not of the Smart and Gets Things Done variety.

For your startup you don’t want someone who’s “smart”. You’re not looking for “eager to learn”, “picks things up quickly”, “proven track record of ramping up fast”.

You want someone who’s superhumanly godlike. Someone who can teach you a bunch of stuff. Someone you admire and wish you could emulate, not someone who you think will admire and emulate you.

You want someone who, when you give them a project to research, will come in on Monday and say: “I’m Done, and by the way I improved the existing infrastructure while I was at it.”

Someone who always seems to be finishing stuff so fast it makes your head spin. That’s what my Done clause means. It means they’re frigging done all the time.

Yegge’s point is that there are programmers who, when you give them an assignment to research something, they’ve already done the thing you’re asking for, or they did it instantly, because they are so insanely intuitive and productive. 

But as a side effect, they’ve also fixed other systems so that they work more smoothly, interact better, are easier to maintain or use, etc. In other words, they made the system “smarter” as a side effect. Hence the phrase “Done And Gets Things Smart.”

Yegge argues that you really want some people like this on your team, because they have transformational powers. But he also notes that they are nearly impossible to hire, because a) they know their worth, and b) more importantly, their current employer’s know their worth and aren’t about to let them go.

If you’ve ever heard about Jeff Dean at Google, he was this kind of person. 

(Unfortunately, Jeff Dean has become a top manager at Google, and there are some problems. But when he was a programmer, he was one of the best ever.)

(Check the show page for a sidebar on Jeff Dean)

There are pages and pages of “Jeff Dean Facts”, that come in the same form as the well-known Chuck Norris facts (

  • Once a cobra bit Chuck Norris’ leg. After five days of excruciating pain, the cobra died.

My favorite Jeff Dean facts are… (

  • Compilers don’t warn Jeff Dean. Jeff Dean warns compilers.
  • Jeff Dean is still waiting for mathematicians to discover the joke he hid in the digits of Pi.
  • Google search went down for a few hours in 2002, and Jeff Dean started handling queries by hand. Search Quality doubled.

But you get the idea about the legend of Jeff Dean as a programmer – and this is the kind of person Steve Yegge was talking about in Done and Gets Things Smart.

Applying these ideas to making sw products

But, you might be asking, how do these ideas – originally presented as “guides to hiring” and “how to refactor successfully” – apply to making software products?

The rest of this episode we’re moving from ancient history (back in the 2000s, of all things!) how to apply these two different ideas – Rub-A-Dub-Dub and DAGTS – to building applications.

The reality is that DAGTS is really how we want our customers to feel about our product. That is, I’m taking this idea from Steve Yegge and I’m applying it to the thing we’re building – and our customers’ experience of it.

Most brilliant and delightful software is done and gets things smart – not only has it already done the heavy lifting, it’s also organized things in a way you never thought of that’s brilliant that will make your life better.

Examples? Instagram, of course. Gmail. Many softwares that learn from you. Nest thermostats – great example.

But Rub-A-Dub-Dub – keeping the functionality the same, but making it faster, more convenient, nicer looking – is the basis for a few highly successful products as well. Let me run through a few examples of both.

The canonical Rub-A-Dub-Dub example 

If you’re a long-time listener you know that I use this product as an example a lot. It’s the exception that proves the rules – or in fact, that shows that a lot of the rules we think we know, we don’t really know.

And that’s Craigslist. Craigslist is nothing more than refactored classified ads, from the old days when newspapers were an actual money-making business – because of classified ads.

Craigslist didn’t really change anything about classified ads except the container, so to speak. It didn’t come up with a new flow for making classified ads, or a new structure for ads. They remained locale-based. 

And since we’re talking about newspapers, it turns out that many applications that replace legacy pre-digital things are much more rub-a-dub-dub than “done and gets things smart.” 

And this was really true of Photoshop, to a large degree, especially early on. 90% of Photoshop was taking well-known processes from legacy photography and photo journalism and importing them onto the computer. You get the same functionality but it’s much faster, much easier to use, much more scalable, requires less physical equipment, etc.

Almost everything you could do in early photoshop, at least in terms of image editing, was something you could do to photos on paper, or in negative form, or in photostat form. But instead of needing a darkroom and acids and things, you could do it on the computer. This is not 100% true, but actually for most of what people used it for – it was the same things they did on paper and darkroom previously. 

But it was well-known to be extremely difficult to use effectively. You have to really understand photo editing to be able to use it.

Normal people would just make a mess of their pictures if they tried to use Photoshop, if they could even figure out how to get started.

It was a tool for experts. It provided unmatched capabilities, but it didn’t do anything for you – you had to be in control the whole time.

Many photo apps, of all different levels of “difficulty” and I’m putting that in air quotes because they were pretty much all difficult to use, were like Photoshop – traditional concepts and traditional tools – contrast adjustment, histograms, hue, saturation, and value tools. Lots of dials and sliders. Selection tools. Making masks, etc. All familiar concepts from legacy photography.

Examples of Done and Gets Things Smart


Then Instagram came along. Instagram was different, especially when it first came out. It didn’t have any of the dials, like for contrast and brightness. You couldn’t select regions of a picture and do things with it. You couldn’t create masks. What it had was pre-built filters that could take your normal snapshot and make it look really awesome. You didn’t have to know anything about real photography to make a pretty cool looking picture – from something you just shot on your phone!

Instagram has changed over the 10 years it’s been out, but that was how it started. Not at all tied to legacy photography, except insofar as your pictures kind of looked like shots from the great legacy photographers.

Instagram is an example of an application that comes from the Done and Gets Things Smart ethos. 

I don’t know if the makers of Instagram knew about Steve Yegge’s article, but you could imagine a conversation where someone asked “What does ‘done’ look like from a user’s perspective? Oh, a beautifully enhanced snapshot from their camera? That they can easily share to their friends?”

And that’s Instagram. No dials, no knobs, no expertise required. It was just about being done. Take a snapshot, make it beautiful with no expertise required. And “get things smart” – make it super easy to share it to your friends.

Now, it turns out that in enterprise software, this can be a really powerful model to work from as well.


What does it mean to be “done” in the case of enterprise software? I think you can interpret that a lot of ways. Some examples I came up with quickly:

  • When given data (perhaps it needs to be formatted correctly), it gives you a useful and correct answer with no messing about. In a form that is directly useful.
  • You don’t have to do any configuration to make it understand your version of the problem.
  • You don’t have to do customization to make sure it knows about your special variables or situations or conditions.
  • You didn’t have to tell it how to do something – it just knew how to do it.

What about “gets things smart?” What does that look like in enterprise software?

  • It could mean an algorithm that is better than the one you have been using already. Meaning it’s actually coming up with a better solution than you could have done before getting this product.
  • It might mean that in addition to giving you the right answer, it also makes it easier for you to collect the data it uses – or it even collects the data on its own.

And in fact, most successful enterprise software products align to some degree with this idea – Done and Gets Things Smart.

Let’s think about an example. is a good example, given its dominance.

What is the fundamental most important job of a CRM? To give management an insight into how sales are going. An accurate – as accurate as possible – sales forecast. Right? That’s really why the execs are willing to spend money on it. 

There are a lot of other benefits, in particular to individual salespeople if they use it. But if it didn’t result in an accurate sales forecast, those other benefits would just be “who cares.”

So, how does Salesforce make the sales forecast “Done?” Well, obviously – and this isn’t brain surgery, right – it has a built in sales forecast report. If the sales team puts their data into the system a sales forecast will come out. And of course, there are all kinds of other kinds of reports.

Contrast that to a system that was not “Done.” It gives you a place to put the sales team’s data, but you are expected to then download that data and create the sales forecast report yourself. 

That is, the sales forecast, the most important thing from the standpoint of the people with checks, isn’t “Done” yet.

In case you were wondering, you could actually buy systems like this in the past. Either they didn’t have reporting built in, or they didn’t have out-of-the-box reports. This used to be true of a surprising number of enterprise applications – reporting was an add-on, and you had to write your own reports, or pay a very expensive implementation partner to write them for you.

SFDC has pretty much killed this type of system.

And of course, if you don’t have any CRM system, you are not only collecting the sales team’s data manually, but you are creating the reports manually yourself in Excel. Not at all done.

So, let’s talk now about “gets things smart.” How does SFDC do this? 

Well, I’m going to say it’s the flipside – the data collection side. 

Giving the sales team a place to put their sales data is a great benefit, but it’s a much less important benefit than the sales forecast itself. … Except, of course, that the sales forecast can only be as good as the data that goes into it. 

So of course SFDC provides a place to put that data. But the way it “gets things smart” is two-fold – first of all, knowing which data to collect, what’s important, what the templates should be for the sales people entering their information. 

This means that the right data – the data needed for a good sales forecast – will be collected. 

But second, since it’s not just about the quality of the data, but the “quantity” so to speak – getting data from every salesperson, the good performers, the great performers, and the poor performers. 

So SFDC puts a lot of effort into making sure the salespeople enter their data. How do they do that? By making it as easy to use as possible. By templating the data. By giving good defaults. By making their system available remotely, and on mobile devices, and so on.

So, SFDC is an example of enterprise software that’s “Done, and Gets Things Smart.”

SFDC not only came up with a new container, but it also included knowledge and smarts and it was already done for you. 

Three things you can do today

Now, what else can I say about done and gets things smart? Obviously, it applies to people – that was Steve Yegge’s original point in his original article. I can recommend a bunch of his articles – they are all pretty old at this point, but they are all still true just like Shakespeare is still true. Yes, I just compared Steve Yegge to Shakespeare. Perhaps too … audacious? 

They’ve been as influential on me as Hamlet or As You Like It; perhaps your mileage will vary.

  1. Go read the articles – links in the show notes – they are great, fun, and enjoyable, and you will definitely learn some things. 
  2. How is your product “Done and Gets Things Smart?” Can you make it more “Done?” More “Gets Things Smart.” Customers love that stuff – because they are coming to you as the expert – they see you as their solution to the problem – not the means to a solution, but the solution itself. That means … “Done.” 
  3. This episode is an example of a very powerful meta-mental model, which is that ideas from different domains, about different things – in this case hiring software developers – can give us powerful insights into how to make our products better. Part of your meta-job as a product manager is to keep your eye out for those outside ideas.  

Blurb for the online course CTA

So, hopefully, I can say something about looking for a job in the new year, it’s something that for a lot of people this is the time you start thinking about it. If this is you, you should definitely take my “Tell Your Story” online class. There are three great reasons to do it now:

* It’s really good! It tells you how to tell amazing stories about your own accomplishments.

* For a limited time it’s free! It’s regularly priced $49.99, but for the first 50 podcast listeners who sign up, I’m discounting the price 100%. So, it’s a great time to get in on it.

* Finally, the tools you learn to tell *your own* stories – which will definitely help you get that next job and differentiate you from other candidates – those same skills, the structure, the tips, the questions you ask to find the good story material – they are totally applicable to all the times you need to tell stories as a product manager,  product marketer, or founder. Whether you’re pitching for new funding, or trying to convince a prospect to become a customer, or handling sales objections – the storytelling you learn in this course will be directly applicable.