10,000 hours part 2

Of course 10,000 hours wisely invested in becoming a spreadsheet guru isn’t going to be much help if you get a problem that would be best solved with a relation database right?

In skiing either you have developed the core skills to ski most terrain or you havent. You don’t get into a heavy powder field and think “bugger I should be snowboarding”. (Well I would actually, being more of a snowboarder these days).

In football you wouldn’t get to a position where you think “Damn I should have done this with a hockey stick”.

With spreadsheets, I have seen many ‘experts’ who can create a mega monster array formulas to solve all sorts of things. Way beyond what I can or would do.

To me any expertise has to include the ability to select the appropriate technology for the task. And potentially the confidence to say “you should do this in Java, for these reasons…I don’t do Java but I can recommend someone”.

Do you think being an expert in only one small area of IT means you really aren’t an expert in IT?



12 Responses to “10,000 hours part 2”

  1. Harlan Grove Says:

    OK, so what’s best suited to spreadsheets?

    IMO, Excel shouldn’t be used for any but the simplest multivariate statistics and NEVER for Monte Carlo simulation – it’s too slow, too inaccurate (better in Excel 2003 and presumably 2007 than in older versions, but still 2nd rate compared to real stats packages), and too inflexible (details upon request, but the flexibility I mean requires VBA coding to reinvent packaged routines already available in most stats packages). It’s also often misused for text processing/list processing that could be done much more simply and quickly with awk or Perl.

  2. Jayson Says:

    Are you an IT expert if you recommend the wrong solution for a client’s problem? I would say probably not, but you might still be very good at what you do.

    I agree with Harlan. Excel can do a lot of things, but should it? That’s the question.

    I do feel that sometimes it isn’t the developers making the decision to use Excel for something that would be better housed in a database, stats package etc. Too often clients want something that is familiar (little grids on a screen), or that they can look at and easily tie (can’t trust those developers!). I’m not saying that’s all of the time, but it does happen. (Or is that just me?)

  3. Simon Says:

    I think you have to consider social issues as well as technical.
    If the users want a spreadsheet, then you at least have to give them a powerful grid based UI.

    I did a reconciliation spreadsheet that was .net and jet, with just a list of non-reconciled items in the ss (and a go button that called straight out to the .net exe). Everyone was happy, even though they insisted they had to have a ss. I was happy as all the work was done in SQL rather than some 2 way INDEX(MATCH horror.

    Jayson users don’t trust me either, and they always want a spreadsheet, well nearly always. So they can ‘follow the logic’ (which is fantasy sadly for some of the monsters I see).

  4. Jayson Says:

    Simon- I’ve been looking at getting into using SQL for the backbones of some of the projects I am on while still using Excel for the interface. Do you know of any good references to start with?

  5. alastair Says:

    Your penultimate paragraph says it all about (programming and DBA) expertise, although as Jayson’s question indicates this is a tall order. I also think you are right about social issues. Excel is ubiquitous, and people love to share! I have written many vba things that appear to be but are not really spreadsheets! And there is a big demand for it – what could be better than that?

  6. Mike Staunton Says:


    I think your comment about never using Excel for MC simulation is kinda true but let me just amplify my thoughts – certainly I never trust some of the built-in Excel functions such as NORMSDIST since they’re accurate only to 7dp whereas I can code up an 16dp approximation as a VBA user-defined function and use it instead

    But, in my field of option valuation, regular MC simulation as found in stats packages is pretty useless – you should be using low-discrepancy sequences such as those by Faure and Sobol and, again, there can be implemented via VBA user-defined functions

    The value of Excel is that everyone has it – and even if not used for heavy-duty code, will still be useful for prototyping

  7. Paul in Brum Says:

    If someone approaches you to design a spreadsheet it sounds like they have already decided on the solution. The first step surely is to review that decision to see if it is valid and then apply your specific product knowledge or say that a different approach is required which may not be your forte and point them in the right direction.

    Beware of ‘experts’ who will tell you all they know on a subject (triggered by a few key words or phrases) instead of addressing the question. To (mis)quote Commander Data “The first step to acquiring knowledge is to simply say ‘I do not know'”

  8. Dick Kusleika Says:

    I think one lesson here is that you shouldn’t invest 10k hours in becoming an expert at using a tool. Become an expert in carpentry, not an expert in hammer use. Become an expert in web design, not FrontPage. I became proficient in Excel because I became an expert in Accounting.

  9. Harlan Grove Says:


    Guess it depends on which stats package you use. See, for example, the following package for R (which should also work in S-Plus).

    Click to access fOptions.pdf

    Myself, what I do could more accurately be classified as survival analysis with some cluster analysis tossed in. And God knows I prefer writing calculation-intensive code in a language like R that operates over entire arrays than VBA that requires way too many For loops.

    Don’t confuse the ubiquity of a tool with its fitness for any particular task. Just because hammers are more common than screwdrivers doesn’t mean it makes sense to use screws like nails.

  10. Simon Says:

    Chance to tie up a couple of metaphors here:
    For many site joiners a screwdriver is only for removing screws, and the correct tool for putting them in is the hammer.

    Dick I think that is a very good point. The question is which trade/profession? Plenty of accountants create spreadsheet monsters, few software devs will touch Excel, spreadsheet dev is too narrow. Dennis (and Dick M?) has suggested business dev, but that doesn’t really exist currently as a profession.

    Jayson I have had a look around my IT book collection and the SQL books seem to be in pristine condition, as if they havent been opened much. I think probably the most useful has been the Access 2000 Dev handbook by Litwin Getz etc:
    Dunno if anyone has better suggestions? Or if there is a more recent version?

  11. Marcus Says:

    “…being an expert in only one small area of IT means you really aren’t an expert…”
    In almost any professional discipline, people specialise. Think medicine, law, engineering, accounting. I’d be more comfortable with the diagnosis of a foot ailment from a podiatrist than a GP. Meanwhile a GP (usually) has enough knowledge to know when a specialist is required. Similarly, wouldn’t you expect someone who is an expert in a particular IT domain to have enough knowledge to know when a spreadsheet isn’t the most appropriate solution (don’t answer – the question was rhetorical). Sadly the “when you can only use a hammer every problem looks like a nail”. Note that this ailment occurs at all levels when we witness an IT department insisting on implementing a BusinessObjects solution when a simple spreadsheet may have sufficed.

    “To me any expertise has to include the ability to select the appropriate technology for the task.”
    Hmm, I’d probably phrase this the other way; sometimes you don’t know what you don’t know. Perhaps an expert has to include the ability to know when their technology expertise is inappropriate for a task, even though they may not know what is.

    Jayson, the book Simon mentioned is excellent (breadth and depth wise) for Access development. If you’re specifically looking at retaining an Excel front-end to a relational (SQL) back end, you may wont to consider these:



    Regards – Marcus

  12. Harlan Grove Says:

    With regard to physicians/lawyers/priests, while specialists will know more about their specialty than generalists, generalists will usually know lots more about these specialties than nearly all laymen. For example, an ENT should know more about diseases of the sinuses than a GP, but the GP should know more about those diseases than you or me.

    Then there are the modern ‘professions’ of engineering and accounting, which head towards specialization right after one learns the basics. I wouldn’t want to bet many chemical engineers know much about computer network protocols. I’m not even sure a ChemE working for a paper mill would know much about how petroleum refineries work beyond the high level similarities between the two physical plants. And how many ChemEs know much about software engineering?

    So I agree with the comment that an IT specialist probably doesn’t know much about IT outside their specialty. Few DBAs know much about optimal layout and cabling for mainframe or server rooms. Few hardware support people know much about network protocols. Etc.

    CIOs/CTOs and their immediate subordinates aren’t IT generalists. If they even started in IT, they were specialists in some narrow field, but they learned something about general business management and/or finance.

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.

%d bloggers like this: