The Tale of Tom, Dick and Harry

Posted: 2014-05-07

This article describes three fictional characters as they all learn how various tools and methodologies work in the world of technology, internets and programming.


Tom works with some massive clients these days and has been in the industry for 10+ years, seeing various tools, frameworks and methodologies come and go. He is very used to the "right tool for the job" idea and is happy to switch between tools, languages and workflows based on the project he is working on, and the team he is working on that project with.

Tom has recently decided to learn about InternetThingX, after he saw somebody give a great talk about it. In part his interest is down to his love of learning new things, but he also thinks it might solve a problem he has run into on a few other projects, and thinks it will help in some cases in the future.

Tom is an eager learner, an explorer and is motivated by playing with new things. He also has a real penchant for teaching, and after learning and successfully implementing InternetThingX in a project or two Tom starts to recommend that others take a look too.


Harry - like Tom - is interested in learning new things too, but is a little less experienced. He is also incredibly busy, being a respected Symfony and Drupal developer. He makes enough money to get all of his bills paid, and does not have much time outside of that due to his clients never ending demands.

Harry only knows PHP but never saw a problem with that. He sometimes uses Drupal when he needs a CMS, Symfony when he needs a framework, and his web stack uses XAMPP because he is on Windows.

Harry saw Tom give a talk about InternetThingX, and loved it. Harry struggled for a while with InternetThingX because it was quite new, but after finding some more documentation he eventually realized it's a really useful tool for some of his projects.

He has added this to his reasonably small tool-belt for occasional use, and will actively recommend it to others because he is proud about learning a new thing. After all, it's not often Harry has the chance to learn new technologies with all those bloody clients blowing up his phone around the clock.


Dick has only been a programmer for about a year. He is very confident in his skill-set and has built a few sites, but his tool-belt is restricted to just one of each type of thing, which he has learned as he needed to use it. Dick is actively looking for things to learn so that he can become a better developer.

Dick sees Harry suggesting that InternetThingX is good, so InternetThingX goes straight on Dicks todo list.

It takes Dick a really long time to get the hang of InternetThingX. InternetThingX is quite a bit more complicated than InternetThingA but Dick keeps at it because he saw Harry saying that it was good. Harry missed out some of the "InternetThingX in useful in this context..." because he was just proud about learning the tool, and so Dick just keeps on chugging away trying to learn it. He never used InternetThingA anyway, so he can't give up now after spending so much time to wrap his brain around it.

When Dick has finally learned all about InternetThingX he feels like a superstar for mastering it, and now uses it for absobloodyutelyeverygoddamnthing.

After spending that long trying to learn it, why wouldn't he? It has more features than that other thing and it can theoretically help Dick avoid some big scary problems that happen at large scale. Problems sound bad, so... cool!

Dick now goes around recommending it to everyone who mentions trying to do something near the problem space, not even necessarily in it. He doesn't have many options available so he proudly shouts about the closest one and it will technically work. If Dick spots anyone talking negatively about InternetThingX he pounces, telling them they're wrong. He might not even realize it's a defense mechanism, but whatever, they're stupid. They don't understand.

Dick screams at Tom when Tom suggests at a conference that InternetThingX might not always be the right tool for the job. Why the hell would Tom go spreading stupid shit like that? Dick remembers that it was complex to learn and took him a while, but maybe that was just because he was fairly new to things. Really it was good for Dick jumping in at the deep end. If others drown in missed deadlines due to not learning the tool quick enough then... well that is their fault. It's make or break. In the long run Dick feels better off for for doing things the complicated way.


Dick is well intentioned, but has been mislead to believe a meal must always be a four-course culinary masterpiece, when sometimes a basic meat and two veg will satisfy the criteria. He is likely to run around forcing beginners to get confused by overly complex solutions to problems that they (and he) do not have yet, and might not have for years.

Everyone has to start somewhere, but don't be a Dick.

Harry is a good lad, but he should have explained the uses cases a little better in the blogs he released.

Maybe Tom is just a know-it-all with too much time on his hands due to charging his clients through the nose.

Nobody is perfect.

In this story, InternetThingX could have been:

  • Vagrant
  • PaaS
  • Laravel
  • The "Repository" Pattern
  • TDD

These two were mentioned on Reddit as a joke, but they fit in here perfectly too:

  • NodeJS
  • MongoDB

Learn what you reasonably can in the time you have available. You can't learn everything, but you should learn more.

Try to learn when something is useful, but more importantly learn when not to use something. You don't need to use Vagrant for every project ever.

For example, Vagrant is excellent. I wrote about how excellent Vagrant is and how it can avoid obscure problems on production. I forgot to write that I use MAMP for basic CMS projects because the CMSs have all been built to abstract away those differences and most of the time it doesn't matter.

I also forgot to mention that sometimes clients don't really feel like paying you the day/week it takes to get their architecture moved over and all of their other staff upgraded and switched over.

Vagrant is cool. Use it when it fits. Don't bother if its trouble.

PaaS is cool. Use it when it fits. Don't bother if its trouble.

Laravel is cool. Use it when it fits. Don't bother if its trouble.

The "Repository" Pattern is cool. Use it when it fits. Don't bother if its trouble.

TDD is cool. Use it when it fits. Don't bother if its trouble.


Simon Bennett


Yes! This happens all the time!

Christian D.


One of your best posts if not the best! You are becoming wiser...or maybe that's the cider talking!



absobloodyutelyeverygoddamnthing should have been #absobloodyutelyeverygoddamnthing. Nice story btw!




Martin Dilling-hansen


I must admit, I started out like a Dick when I started learning Laravel, but that interest in Laravel and the community have really pushed me around learning a lot of different stuff ;) So hopefully I'm moving away from being a Dick ;)

Thanks for learning us not to be Dicks :P

Darren Miller


Agree with almost everything here .... except Vagrant. Over time it will always end up as "trouble" to install cruft on the machine you use to make a living.

Vagrant has allowed me to install only handful of apps and a couple of browsers on my laptop and that's it. All development is done on Vagrant VMs. A clean OS = faster boot, less maintenance, less problems = more work done.

I totally agree that you might not want to configure and spin up a dedicated VM to solve a simple problem. For these instances, I keep a low-memory "Sandbox" VM called running all the time. The one-off 15 mins it took me to set that up was a far better option than maintaining a LAMP stack or MAMP.

Daniel Newns


great post phil, and its great to see someone like yourself saying this.



Darren Miller: Unfortunately you're using words like "always" and throwing the same Dick approach at me that I was discussing in the article.

I know all about the benefits of Vagrant and how it helps you avoid installing cruft on your workstation. I know why that is good to avoid, and I know what sort of software we would both agree is probably cruft.

I would not agree that the basic LAMP stack is cruft. I'm talking not even a damn Redis box, no Memcache, nothing. I mean 100% plain-old LAMP.

So when Johnny Client comes along and says "Here's my codebase, we just use MAMP. Get it running and I'll show you how this all works." I am certainly not going to sit there and say "Oh hang on a minute mate, I need to write up a Vagrantfile and spin up up a Vagrant box first."

Even if I have a one-off catch-all vagrant box running (which leads to the exact sort of clashes vagrant boxes are intended to resolve anyway), I am still not going to say "Hang about, I need to go and edit my hosts file, and add a virtual host to the virtual hosts thing. Oh you have two domains and two codebases? Sorry, let me go back and do that..."

Your argument of reduced startup times is also a bit of a false argument, as I click "Start" when I want MAMP Pro to start, it doesn't happen automatically.

Sometimes, MAMP Pro is literally al you need. A lot of the time it isn't. This entire article was about asking others to consider the use-cases of others, and not tell them they are wrong based on their own personal experience.

Simon Hamp


I completely agree with the conclusion of this argument - the right tool for the job. However, one statement lets your argument down...."Don't bother if it's trouble"

As Teddy said: “Nothing in the world is... worth doing unless it means effort, pain, difficulty”

If we only ever did things when they fit, we'd all be putting round pegs into round holes and never advancing in new directions. Working out why something doesn't fit and working to either make it fit or make something that does is the genuine mother of invention.

Sometimes the right tool for the job is the one that you take the trouble to make.



Simon Hamp: I dont think that is the conclusion I was aiming for. I am not suggesting you dont ever try and do something if it is difficult, I am saying that using a tool that is only kinda what you want and struggling with it is not the right way to go. Hammering in a screw is difficult. Doing it does not mean you are pushing technology forward, you're just being a Dick.

"X is cool. Use it when it fits. Don't bother if its more trouble than it is worth, and try to find a more appropriate tool." Better?

Using MongoDB for a database which is largely relational is difficult. That lets you know you're using the wrong tool.

Does that make more sense?

Shawn Mccool


I like how the advice to Harry was to consider Dick when creating content. This is definitely something that I'm focusing on in my own pursuits and is something that could in its own way help people through the difficult nature of this industry.

With well intentioned contributions to education comes responsibility. We don't have to be perfect but we should at least pay attention and learn from our mistakes.

Simon Hamp


Apologies if I misinterpreted your conclusion.

I think it's a difficult thing to come up with an overriding principle for. We use different tools at different skill levels in different contexts for any number of different reasons.

Firstly we choose what we're familiar with.

Sometimes we choose convenience - which is why even the most conscientious of us still use the handle of a screwdriver to hammer in a nail sometimes (bloody hammer's in the garage).

Then we have to slot in awareness. If you didn't know that a ratchet screwdriver existed, you stock up on plasters and ointment for those blisters...

The difference of how we go about this method of deduction - to find the right tool for the job - is quite complicated. One of the main differences between green tradesmen and seasoned pros is being able to go through this process more quickly and with less chance of error.

I do feel this is a distraction from your main point though - well made as it is - that all too often you see folks becoming too vocal about a particular solution (and perhaps others misinterpreting their enthusiasm), when they haven't got the experience to make a fair consideration of individual problems.

As you say - nobody is perfect - so you can't take someone's enthusiasm for the new FuBar 3000 to mean that it's a great choice for you, your next project or that you're somehow less of a developer for not knowing how to use it.

Sometimes learning through your own successes rather than someone elses is the better way to go.




And this can be applied to all kinds of "jobs" of course.. not just developing, or basically just trends.

Usually it takes some years of experience in any field to feel comfortable with the choices you make. If you feel confident in how you build/create things (a website, a song, a treehouse or a 4 course dinner) and you know that you can do it correctly in different ways, then you don't care so much about other people telling you how it "should" be done. By then you just absorb new things (if you are interested) and use them (if you want) when you mastered them.



There was a mini shit storm about this on laracasts

I baw everytime someone recommends VAMP as an interchangeable solution to *AMP stacks and with zero side effects. Most of the time these people are referring to some basic apache, php setup on an ubuntu box which they could have just stuck with MAMP for. More complex server setups require effort and learning.

Dick is the guy who perpetuates the fad culture in the php community. I already here the celebre of DDD and thats sure to dominate for the next couple of months.



Diango12: I see a lot of conversations like this within the Laravel community which is why I generally leave them to themselves.

That conversation seemed to mostly consist of people who could only see in "for" or "against" VMs, and couldn't comprehend that maybe one person could be both for and against depending on the context. That is EXACTLY what I am talking about here.

That said, you made a few points which weren't a true reflection of the vagrant workflow, which may have spurred the pro-vagrant folks on and ignored the subtlety of your real complaint, that the recommendation is the problem and not the tool itself.

preseeding linux setting up networking configuring firewalls/iptables establishing permissions and file modes managing users and groups juggling packages and dependencies Wrestling with Selinux configuring apache or nginx configuring configuration files with config tools, so your configurations will have configurations and you can config while you config etc etc

None of those are really true, other than "configuring apache or nginx", which is a few lines of provisioning code. In around two years of using Vagrant extensively, I have not had to wrestle with selinux, and dependency management is just as much of a problem with homebrew and pecl outside of vagrant as it might be inside. brew install php56-mcrypt or trying to MAMP pecl install.... well it ends up being easier in Vagrant.

Usng these sorts of examples is going to get you hate, because they're going to switch from listening to assuming you dont know enough, then just "help you understand" for 5 pages. :)

But yeah, half the time php artisan serve would do too. Gotta love PHP 5.4.



Thanks for grossly misrepresented the arguments. I don't even know where to start.

"""That conversation seemed to mostly consist of people who could only see in "for" or "against"""

Wrong. Every other posters was staunchly pro vagrant and I was either agreeing with the neutral points some of them made or disagreeing with "against" and "pro" remarks.

""""""That is EXACTLY what I am talking about here."""""

No its not. You're trying to come off as some kind of neutral party. You reframed what I posted and worst of all, you fell into your own trap by saying "That said, you made a few points which weren't a true reflection of the vagrant workflow,". Thanks, I didn't know I was using the tool wrong. I'm glad there are experts around to correct me in the proper way.

""""""which may have spurred the pro-vagrant folks on and ignored the subtlety of your real complaint" "Usng these sorts of examples is going to get you hate, because they're going to switch from listening to assuming you dont know enough, then just "help you understand" for 5 pages. :)""""""

Stop with the uncategorical blaming and covert bias. I didn't say anything wrong and I didn't say anything 'subtle'. Just say that you have problem with what I was posting or more truthfully, say you have a problem with whom I was debating against. Here are my quotes:

" Yes you should start to 'move' towards using devops tools, as it will be a handy learning experience. But I don't think anyone should dive in head first.

I think it would better to warn people about going in willy nilly

If your reasoning is that you don't have to learn the hard stuff first because "you just want a simple lamp stack" then I suggest sticking with MAMP or WAMP as they do just that.

If your goal was to install php and apache using a 'simple bash script' then why did you feel that you needed to change away from WAMP?

I don't think we have a disagreement. I've never suggested that developers shouldn't use these tools. The point is solely against the recommendations

The benefits I see in switching over to a VAMP is that people can begin their learning journey while maintaining relatively the same setup (slightly improved for non nix users) they had with WAMP/MAMP

We have the same opinion and you don't even realize it. You're arguing that WAMP/MAMP stifled learning and abstracted the environment away under a GUI. I'm arguing that that is true, and the VAMP fad is doing the exact same thing.

Again, the argument seems to be that automation and virtualization are the best things since sliced bread. I agree. They are awesome. Vagrant is great for porting into vms. Packer is useful for creating those vms.

The whole point I'm making is against that very argument. Particularly the argumentation from the VAMP stack crowd prescribing 'lose weight fast' - 'use this weird little trick' - 'diet plan' solutions to a problem that ought to receive more attention.

I like fideloper's approach. I like sites like . It offers a little more than just Vaprobash. I even hear is active again. I like Puphpet, Vaprobash and smart vagrant + automation setups.

I'm not against the tools, I'm against the way they are being recommended."

The entire thread is filled with my posts reaffirming this point again and again. Repeat ad infinitum.

Can we add self serving bias and Outgroup Derogation to the cleaning list for the community?



Holy shit Diango12.

I was actually mostly agreeing with you, but you've misunderstood everything I've said in ways I never could have expected and taken offense to it in what seems like 5 different ways. I'm sorry about that, but calm down.

I completely understood and still understand your point of view. I was explaining that people in that thread (not you) were only talking in black and white extremes about wether its "good" or "bad" and the subtitles of your argument (the grey argument) was lost on them. That sucks.

I offered one explanation of why this may have happened, and explained that you started in with a series of things that will likely NEVER happen to these MAMP-replacement Vagrant beginners. It comes down to knowing your audience. Why would these people be concerned about iptables and firewalls? That is not even vaguely on their radar and doesnt need to be. Ever most likely, let alone be as extreme as your introduction about these issues saying: "In your first week I can guarantee you will accomplish very little, but you will learn a few things. You'll scratch the surface by learning about:" I think not. :)

> The whole point I'm making is against that very argument. Particularly the argumentation from the VAMP stack crowd prescribing 'lose weight fast' - 'use this weird little trick' - 'diet plan' solutions to a problem that ought to receive more attention.

I know, and I completely agree. I had thought that was clear.

I am just saying, when we explain the "understanding both sides" argument we have to do it properly, and listing a bunch of things that... well seem like weird unfortunate advanced topics that have only happened to a minority of people as a main and introduction reason against using a tool is not the best way to explain it to the mainstream user.

You definitely seem to be defending yourself from an attack I never made. :)

Bernhard Breytenbach


Great article! Reminds me of all the problems, pain and sleepless nights I caused myself in the past being a Dick, by trying new tools that I hardly know in tight deadline projects, just because I heard people say its cool!

Its best to start with new tools in small projects with flexible deadlines, so that if something goes very very wrong and it turns out not to be all that and a bag of chips, you can start from scratch using something you know.



After reading again I realize that you're right and I overreacted and misconstrued your post for something its not. I apologize for that.



Diango12: Glad we sorted that out. :)



Nice post Phil! I think you get alot of love on this one, as we can all relate to this. We all once were/will be a Dick/Harry/Tom as we go through the dev lifecycle.

Hidden For My Protection


Hey Phil,

I just want to say that i really could have used that advice earlier & I could not agree more. I have had a huge issue with this

  1. Developers can come off as huge dicks, which makes the new guys like me nervous about starting projects
  2. The arguments that attitude leads to always seems to end up at which tool/language/ whatever loads .0068 times fast on this or that server.......what the hell are you people talking about?!?!?!

Anyway, I come from a strong sales background but realized I wanted to create, so I got into coding, PHP and front end stuff, but I use Jquery and Bootstrap to save time. Every Dick has been telling me Im too new and to stay away from frameworks or my code will suck....well I just realized that I have a televised press conference on Saturday and maybe I should focus on what I do best and just use the tools that save me time. Laracast looks easy enough to watch, or maybe since I can build programs fasted in this method (copy and pasting) I'll just keep using procedural!! I code fastest that way, it fits my style of gun and go life, I love that I can just pop open my boilerplate set up and start hammering away spaghetti code and bam 16 hours later I have an MVP.

Anyway good article!

And too most of the Dicks on stack sound like idiots and the guy asking the question has no idea what your talking about.....I'm not entirely convinced you do either.

Posting comments after three months has been disabled.