A hypothetical based on an amalgamation of my own experiences during a co-op:

You work as a programmer at a company that writes websites with the programming languages VBScript and VB.Net. You have learned enough about those languages to do your job, but you think the Ruby language is much more efficient, and you write your personal programming projects in Ruby. You occasionally go to meetings in your city for Ruby programmers, which talk about new Ruby-related technologies and techniques.

You are nearing the deadline for the new feature you were assigned to write. You had promised you would get the web page looking good in all browsers by today’s followup meeting about that feature. Fifteen minutes before the meeting, you realize that you forget to test in Internet Explorer 8. You open it in IE8 and find that the web page looks all messed up. You spend fifteen rushed minutes frantically looking up the problem you see and trying out code fixes, and you manage to fix the problem just before the meeting.

It’s just you, the technical lead, and the project manager at the meeting. You explain that you’ve finished your feature, and he nods, congratulates you, and makes note of that in his project tracker. Then he tells you what he wants you to work on next: an XML Reformatter. The XML documents used internally in one of the company’s products are poorly formatted and organized, with incorrect indentation and XML elements in random order. He suggests that you talk to the technical lead about how to get started, and leaves the meeting.

This project sounds like something that will be run only once – a one-time project. You have worked with XML in Ruby before, and are excited at the idea of being able to use your Ruby expertise in this project. You suggest to the technical lead that you write this program in Ruby.

“Hmm… no, I don’t think we should use Ruby for this project. We’re going to be using this program for a long time – running it periodically on our XML files. And all of our other programmers know VB.Net. We should write it in VB.Net, because I am pretty sure that another programmer is going to have to make a change to your program at some point.”

If you’re not thinking straight, at this point, you might complain, “I could write this program so much faster in Ruby. We should use Ruby anyway.” Yet that does not address the technical lead’s point, and ignores the fact that one of your assumptions has been revealed to be wrong.

If you are aware enough of your emotions to notice that you’re still on adrenaline from your last-minute fix, you might instead think, I don’t like the sound of missing this chance to use Ruby, but I might not be thinking straight. I’ll just accept that reasoning for now, and go back and talk to the technical lead in his office later if I think of a good argument against that point.

This is a contrived example. It is based on my experiences, but I exaggerate the situation and “your” behavior. Since I had to make many changes to the real situation to make an example that was somewhat believable, that would indicate that the specific tip you quoted isn’t applicable very often – in my life, at least.