Beefy Boxes and Bandwidth Generously Provided by pair Networks
Your skill will accomplish
what the force of many cannot

T.I.T.S. Or, Try It To See.

by Tanalis (Curate)
on Apr 27, 2006 at 10:38 UTC ( [id://545998] : perlmeditation . print w/replies, xml ) Need Help??


A number of factors recently have had me thinking back, in quite a nostalgic fashion, to my days as a novice (C/C++) programmer at University.

While it wasn't such a long time ago (I'm not that old, honest ..), a saying of one of my lecturers stuck in my mind, and it's come to mind repeatedly over the last few days following a couple of "what does this do?" and "how does this work?" type questions about pretty simple things in the Chatterbox, on SOPW and (more significantly) among friends in the Real World.

The phrase itself was simple: try it to see. If it's a command you don't know how to use, or a bit of syntax you haven't used before, take a look at the manual, and take your best shot. If it doesn't work, or it doesn't work as you expected, and you can't figure out why, then it's time to bother someone to ask why.

It's a good phrase. And it has an amusing acronym. It's something that can be applied to novices, experienced programmers, and everyone in between.

More and more often, recently, though, I get the impression that it's becoming easier to ask questions first, and jump straight from "I don't know how to do this" to "it works, though I wouldn't know how to do it again" - in other words, learning how things work, and why they work like that, is becoming a secondary concern.

While I can see the benefits of "just getting the job done", I don't think this way of working is anything I could subscribe to: I enjoy figuring out new bits of code and new problems for myself, learning from what I do, rather than having people just give me solutions. If nothing else, that moment of inspiration when suddenly something new falls into place and is understood is very satisfying indeed.

In this age of the ubiquitous Google search, where answers are sitting on plates waiting for you to just pick them up and use them, I think it's important to remember that often the best problem solving tool you have is yourself, trial and error, and the indexes of those books that sit gathering dust on the end of your desk.

Maybe I'm just old-fashioned. Part of me asks (cynically) whether I'm just bitter because I didn't have the Internet to fall back on when I was a student .. *grin*.

What do others think? Does the 'net make things easier .. maybe too easy? Are we creating a culture of people who expect (or worse, require) answers-on-a-plate in order to get their jobs done?

Replies are listed 'Best First'.
Re: T.I.T.S. Or, Try It To See.
by BrowserUk (Patriarch) on Apr 27, 2006 at 11:17 UTC

    I think it is easy to forget that if you have had any exposure to formal tuition in a subject, you picked up a lot of simple stuff through the process of having the more significant stuff explained. A lot of that simple stuff is universal--it holds true across languages and platforms--and despite having been acquired almost subliminally, it quietly stands you in good stead when you encounter new stuff for the first time.

    If you are approaching a completely new subject with no formal training, especially when every other word in the documentation is either completely new to you, or familiar, but used in a context that defies rational explanations in concert with the meaning you are familiar with; there are simply no hooks upon which to hang your hat. You are, until you acquire the equivalent grounding, completely out of your depth.

    To get a sense for what I mean, go to a Chinese, or Russian, or Greek or Arabic website (pick a language and symbol system you are not familiar with), and then try to make sense of it. Cut and paste lumps of text into your nearest on-line translation page and see just how long it takes you to get a feel for what the page is about. Look up a "Chinese for beginners" website (or book) and see just how frustrating it is to get started.

    Of course, there are the occasional persistent offender that never seem to progress, but mostly, the posts by the people I've seen over the last 4 years show a steady conversion from asking to answering and simple to sophisticated; and generally much more quickly than I would have believed possible before encountering this site.

    This site works!

    And the only time it doesn't work is when people get on their high horses (not you, your post was very gentle and enquiring), and rant about noobies who "cannot be bothered to read the manual". The first problems a noob encounters is "what to read?", and "where to read it?". This site is better than Google; your best friend and his grandmother (unless she was Ada Lovelace); and the entire Maths and Computing section of your local library or bookshop.

    What makes it work, is a constant supply of new blood with new (to them) questions, and sufficient retention of old blood with the time, patience and interest to answer them.

    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    Lingua non convalesco, consenesco et abolesco. -- Rule 1 has a caveat! -- Who broke the cabal?
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.

      While it's an interesting acronym, TITS is not always practical. In certain situations it can be a waste of time. If I know how to do something in one language and want to know if something in another language does that very thing, I can ask 'what will this do' and listen for clues of what i'm trying to do. I could try it but if it doesn't do what I want, I have to find the next thing. To ask the question saves time. For newbies like myself, I would rather ask than try 10 different modules and never find what I was looking for. Once I ask and hear that the module will do it, then I will TITS how to make it work for my purpose. IT'S GETTING TO THE RIGHT THING TO TITS!

      BrowserUk hit the nail on the head! This is a great site for these questions. They may seem minor to experts but i'm just looking for a starting point. How do I ask the question? How do I find what I want? How do I google for it? I don't know so I come to perlmonks and ask the question - what does this do?

      Thanks for this meditation. It was a great one and thanks BrowserUk for your comment! I look forward to learning from the more seasoned monks.

Re: T.I.T.S. Or, Try It To See.
by nimdokk (Vicar) on Apr 27, 2006 at 12:18 UTC
    I'm reminded of an ancient Chinese proverb (at least I think it's an ancienct Chinese proverb but I'm really not sure):

    Tell me, I forget;
    Show me, I remember;
    Involve me, I understand.

    I think the "try it and see" approach falls more under the "involve me" idea. Currently I am training a new team member who has no Unix experience and no Perl experience at all. Trying to get him up to speed as quickly as possible. Often I'll watch him stumble over a command and ask me if it's right. I'll look and even if it's wrong, I'll simply ask him to try it and see what happens (if he was going to do something that would cause a major problem, I'd correct the command). Then if the command works, great, if not, see if he can figure out why it did not work. It's working, I think he's getting more to where he can trust himself without having to rely on outside help in getting through things.

    Knowing how to do something is fine, but understanding why something worked (or didn't work) is better because when something goes wrong, it makes it easier to back up and figure out why so you can make it work again.

      I like the 'proverb'. I wonder if it is possible to be a programmer without being an "involve me" kind of person?

      There was a time when I was trying to learn shell (bash) programming and thought that I was understanding everything that I read -- it seemed almost too simple. It wasn't until trying it out and learning to troubleshoot really made the lessons stick in my mind (and realize that I wasn't really 'getting it').

      Same thing as I now try to learn Perl. I have only peeked at Appendix "a" one time before forcing myself to figure it out. Now at half way through the book, I am feeling very comfortable.

      Just thought I'd share.

      It's Confucious, and it goes (well, the English translation anyway): "I hear and I forget. I see and I remember. I do and I understand."

      Unfortunately, it only applies entirely accurately to visual/kinesthetic learners. Still, a good rule of thumb, since the majority of people tend toward the seeing-doing style of learning.

      A collection of thoughts and links from the minds of geeks
      The Code that can be seen is not the true Code
      I haven't found a problem yet that can't be solved by a well-placed trebuchet
        Thanks, I only remember see it once on a poster someplace and it simply said "Ancient Chinese Proverb" (or something to that effect :)
Re: T.I.T.S. Or, Try It To See.
by apotheon (Deacon) on Apr 27, 2006 at 10:58 UTC

    I guess this goes in the Free Acronyms and Initializations Repository, something I just invented that I'll probably start working on in the morning, along with STFW, RTFM, and other wise bits of advice for the chronic newbie. I tend to take the TITS approach myself, more often than not, but having an amusing acronym for it will probably help prompt me to pursue such a path more diligently.

    I think the availability of search tools like Google is a net win. For one thing, it actually makes autodidactism easier as a way of life in an age when it might otherwise be nearly impossible, since formal instruction is being more and more monopolized by Institutions Of Education that exist only by way of federal and state funding. Without the Internet, there wouldn't be any Linux, for instance.

    Without the Internet, I would never have heard of this great acronym, TITS.

    Plus, y'know, Wikipedia and PerlMonks.

    print substr("Just another Perl hacker", 0, -2);
    - apotheon
    CopyWrite Chad Perrin

      since formal instruction is being more and more monopolized by Institutions Of Education that exist only by way of federal and state funding
      I of E aren't all that bad. here's a goldmine I just found out about...well, maybe just diamonds in the rough. I guess you can decide. ;-) MIT OpenCourseWare
Re: T.I.T.S. Or, Try It To See.
by monarch (Priest) on Apr 27, 2006 at 14:43 UTC
    I have two thoughts on this topic. They are: "deriving works on your own" and "using other answers to help guide my answer".

    Deriving Works On Your Own: frequently through high school I often derived for myself methods for solving problems I didn't know had answers already. When I was young I had a tricky method of calculating the base 2 log of a number (to work out how many bits it contained). It wasn't until later in high school that I learned about the logen over loge2 method of doing the same.

    Likewise, with programming tasks, I have often found myself inventing ways of doing things, only to discover later on that there is an existing standard way of doing it.. and in fact it may well be patented.

    A lot is said for "original discoveries", that is, you can't obtain a Ph.D without contributing something new to the world of knowledge. Indeed, you are not allowed to use a patented method because the theory is the patent owner "discovered" the method and therefore owns it.

    But I believe there is value in discovering things for ourselves, even if they were discovered by someone else. In fact I believe the basis for a patent should be invalidated if someone discovered something on their own without having to learn about the patent through reading it.

    Using Other Answers to Guide My Answer: I am a perfectionist by nature.. now in this world of the internet there are a lot of answers out there, and sometimes they are the best darn answer one could reasonably expect to use. There are many top quality tools on the internet but, time and again, I find the exact answer I'm looking for isn't there, or it doesn't suit my exact needs.

    Thus I feel that yes the internet does make our lives easier in that it is easier to find answers to questions we would have otherwise spent a lot longer trying to answer.

    But I don't believe that the answers provided on the internet are always, or indeed usually, the answer we are looking for. Often answers are pointers to get us thinking about what exactly we'd like to concoct.

    I believe civilisations that used to conquer many nations would take the best of the cultures they'd invaded and mixed that into daily life; so it is with the internet - in this global village we have more opportunity to pick the best of what is out there for our needs, and weave that into an answer (the weaving is still up to the individual, however).

Re: T.I.T.S. Or, Try It To See.
by jpeg (Chaplain) on Apr 27, 2006 at 20:28 UTC
    If this acronym is NSFW, it's AKA TIAS - try it and see.

    Just FYI.

Re: T.I.T.S. Or, Try It To See.
by spiritway (Vicar) on Apr 28, 2006 at 03:59 UTC

    This is a good philosophy for Perl. It's not so good if you're in the cockpit of a military aircaft, wondering what that big red button does ;-).

    Much depends on whether you can afford the luxury of "trying it to see". If you're constantly under tight deadlines, you may just need to get the thing done, do it the way that works, and don't ask too many questions about the 'how' or 'why'. The amateur has a slight edge here - s/he can take the time to try it to see. OTOH, the pros often have each other to ask, so maybe it's not such an advantage after all...

Re: T.I.T.S. Or, Try It To See.
by TedPride (Priest) on Apr 27, 2006 at 19:39 UTC
    My view is that there's so much knowledge in the world that it would take several thousand lifetimes to learn it all, so why not just Google for the bits you need? Given, Google shouldn't be an excuse for not learning new things in your chosen field - you'll probably run across the same problems again in the future and it saves time if you have the answers in your head - but some things just take so long to understand that it's best to leave the algorithm design to people who make it their life's work to specialize in that area.

    Or to repeat a much-used phrase, why reinvent the wheel?

Re: T.I.T.S. leads to B.U.M.S.
by EdwardG (Vicar) on Apr 28, 2006 at 09:08 UTC
    While there are obvious benefits to the TITS approach, it can lead to BUMS - Breaks on User's Machine Syndrome - if the coder doesn't understand why it works. It's also known as programming in hope, or sunny-day programming.


      Actually, I think the chances of B.U.M.S are much higher, if you did not have at least one T.I.T.S phase in your career.

      Ok, the T.I.T.S approach should not be used in wrting software for the control of atomic power plants. But if you have a secluded sandbox, just get in touch with T.I.T.S!

      I disagree (and think you've maybe misunderstood the OP ..).

      I think there's more to be said for trying to figure out how something works yourself than for just looking for an answer. I'm championing understanding and learning over an "easy way out" - that of knowing how to type the right keywords into a search engine to get to an implementation.

      Maybe there is an aspect of programming in hope. I think it's more important to be able to read a man page, or look at a synopsis and examples in a book, and have the confidence to try it out to see what it does than it is to look for a fully-working implementation that you also don't understand. If it works, great, you've found a tool to add to your repetoire. If it didn't work (which is often much more likely for a novice), then you're forced to revisit the code, re-read the examples, and try to figure out why it didn't work. When you do finally get it working, chances are you have a better understanding of why it's working than you would have done if you'd blindly typed out a working line of code from the net.

      There has to be a starting point to any form of learning. Simply asking for the answers isn't (shouldn't be) one of them, in my opinion - and that's my point in the OP.

Re: T.I.T.S. Or, Try It To See.
by johngg (Canon) on Apr 28, 2006 at 14:01 UTC
    One thing I have observed is how often people haven't much idea how to use a manual or text book. They seem to think that if they pick one up and randomly flick back and forth, an answer will magically jump out of the book for them. As for looking at the index or (just as useful) the table of contents, how fuddy-duddy. Perhaps one of the fundamental subjects that should be taught on computer science courses is "How to use a manual" so that students become a bit more self-reliant with more than one tool for finding things out at their disposal. Whether this is due to the onward march of the 'net, I don't know; I do know that most of my daughters' homework assignments involve going to Google, not the bookcase.

    Much useful information can come via Google and the like but you often have to sort the wheat from an awful lot of chaff and sometimes the information is superficial or just plain wrong. That is not to say that there aren't some really excellent pages out there. There is nothing wrong with asking if you are not sure; in a live environment it is much better than diving in and breaking something. However, time pressures permitting, it goes down better with those being asked if you can show that you have made an attempt beforehand to find out for yourself.

    As for the much-mentioned wheel and it's re-invention, sometimes it is good to do that just for the fun of finding out how it works; that is one way you can gain a deeper understanding. Sometimes you need a better wheel. And after all, if we didn't re-invent, or at least, refine the wheel occasionally, we'd still be trundling around in Fred Flintstone's car.



Re: T.I.T.S. Or, Try It To See.
by samizdat (Vicar) on May 01, 2006 at 14:48 UTC
    Score one for non-PC MCP-ism... :)

    Seriously, I agree with the main thrust of your post. It IS all too easy to splash a 'whazzat?' on PM or google before thinking. I've done it myself (no, really?). Disciplining yourself to sit and think things through is easily as difficult as contemplating the head of a pin without thinking of sexy ladies dancing. :)

    I was fortunate in my first pressure-cooker programming job (four years into my career) to be writing assembly language for a machine control system where programming errors would leave embarrassing scars on custom-machined pieces. Perhaps not a nuclear reactor, but screwing up made truly awful (and expensive!) sounds happen! =8-O

    I think that having a BUMS period, or, even better, a situation like the above, is a Really Good Thing (RGT!) in the career of a programmer. Most of the time. the damage is less critical, and I have to admit that having a few BUMS moments in my own life has helped make me think a bit more before hitting <ENTER> and having to reload the damn thing from zero. It's rarely that bad, thanks to our Bell Labs and Berkeley forefathers.

    Is it too easy to ask? Yes, but, having been homeless myself, I side with the guy by the side of the road:

                                  "We all need a little help sometimes!"

    Don Wilde
    "There's more than one level to any answer."
Re: T.I.T.S. Or, Try It To See.
by sarani (Sexton) on May 27, 2006 at 10:36 UTC
    When you are Pretty Sure of the answer, but you want to confirm becuase it'll Muck Up Important Things, you'd ask. Or at least, I would.
    Sometimes you just don't have the time to understand the how and why of every bit of code you write. Eventually (or so you promise yourself) you'll learn, but the Boss needs the Answer now, if not yesterday.

    For instance, my contribution to the CB today was "what is the size of an array?" If someone asked me that, I'd probably thwap them and ask them to look it up (half because I don't know) - but my question was only probing to find out if there is some obvious value that everyone knows and I don't. (For the record, I did Google :P it up before asking.) I distinctly remember reading about 10000 elements in someone's array on this site, and I also remember defining the number of elements in an array in C. The answer I got was something to do with vroom. It, in a strange way, reassured me that there wasn't a number one could/would throw at me. So that was not the bug I was looking for in my program.

    Circular thinking, I know, but a whole bunch of us do it.

    BTW, if whoever did reply to me in the CB reads this - thanks. :) I got DCed before I could notice your name, or reply, and throwing a generic thanks wasn't really going to help (or was it?)