Big Gaps

  • Peter Bellis (9/23/2011)


    What we need in this industry are less product experts and more out-of-the-box problem solvers.

    I was going to post my thoughts but Peter did it for me. I, like him see that a problem solver is the one who learns the keys to open the opportunities to success and uses them no matter what the technology. And those problem solving skills never get out-of-date, they only become more valuable.

    M.

    Not all gray hairs are Dinosaurs!

  • Some areas that I know I have knowledge gaps in are SSAS, PowerShell and CLR. I am working to learn more about those.

    Jason...AKA CirqueDeSQLeil
    _______________________________________________
    I have given a name to my pain...MCM SQL Server, MVP
    SQL RNNR
    Posting Performance Based Questions - Gail Shaw[/url]
    Learn Extended Events

  • majorbloodnock (9/23/2011)


    I've been doing a lot of nodding whilst reading some of these replies.

    For me, the following are major gaps I see, often in surprisingly senior IT people.

      Understanding what it is you want to achieve. So many times, I'll see someone diving into detail before simplifying the problem so as to understand the fundamental requirements. It's not a purely IT skill, and it's not rocket science that the better you understand a problem the better your solution will end up solving it, so it baffles me why so few people take the time to put it into practice.
      Understanding the theory. Often, I see IT people doing things they know work, but without understanding why they work, even when it touches the core of their particular field. Of course, if that thing stops working, they're stuffed, and since they didn't have a questioning and inquisitive mindset to research when the pressure was off, they certainly don't have the mental skills and attitude to find out what they need when the heat is on.
      Learning how to learn. To my mind, what differentiates an experienced IT pro from those around him or her is not what they can remember, but their confidence (so long as it's justified) in their ability to learn on the fly when outside their comfort zone. You can only learn how to learn - or keep that skill polished - by constant practice, so don't limit yourself to obviously useful subjects.
      A specific one here; our lives revolve around keyboard and mouse, so how come so many IT professionals can't touch type? If you're proof-reading what you're typing on screen rather than watching your fingers on the keyboard, it's much easier to spot errors and so on as well as being quicker. Nor is touch typing difficult to learn.
      Basic mental skills. It's understandable that we who're so comfortable with computers should rely on them so much. However, I'm amazed at the number of people who are so totally reliant on spreadsheets and spell checkers that they can't spot obvious mistakes in what they type or what their code calculates. They've lost the "no, that just doesn't look right" skill, making sanity checking rather more difficult.

    You'll notice almost all of my points aren't technical per se. In particular, I see many of the "basics" that are lacking as being so low level that they occur even before someone touches a computer.

    Perfect... now I don't have to actually rant as much as I was going to :-D... you've hit almost all of the points that I'd hit. The one I'd really like to emphasize is the "Basic Mental Skills" like doing a little verification that the code actually works. I've seen thousands of bugs written up where a simple check with a calculator or knowing some simple "limits" would have prevented the bug. For example, if dividing two numbers to calculate a percentage has inputs of 2 and 5, should the answer ever be 0%? Another example is, if a database is set to "Read Only", do you really have to back it up every night? Simple stuff, right? But this is the type of simple stuff that I frequently see being missed by Developers and DBA's alike.

    Actually, I don't know if the two examples I gave are due to lack of "Basic Mental Skills" or just shear laziness. Sure... You got the task off your plate by forwarding code and QA (Quality Assurance) will pick up on the 0% problem but couldn't you just spend an extra minute or so to check your own work instead of just assuming you did it right? And how long does it take to check just one extra column of data to find which databases are in the "Read Only" mode before your code does a backup?

    I also very much appreciate the post where IceDread told of how many days of planning his group spent and then still got everything done in less time than the other groups. There are just too many people lacking the simple "Basic Mental Skills" to realize that each hour of upfront planning can greatly reduce the number of hours of actual development and can save 8 hours or more in rework time for each hour of time spent doing some decent planning (never mind the black eye the company gets if the code makes it out to the customers).

    Another thing I think people are missing is a little bit of dedication to the art responsible for providing them a livelihood. Do I think you should spend 6 days of development time to save 6 CPU minutes per year? Hell no! 😀 Do I think you should spend some time trying to figure out how to cut the CPU time in half on a 10 ms/row task that will be used everywhere in your system and will be used millions of times per day. Suprisingly... my answer is "No"... YOU SHOULD ALREADY KNOW HOW TO DO IT! 😉 In fact, it should take sub-millisecond times for each row and you should have written it correctly to begin with. And that's what I'm really talking about here. Spend a little time learning how to do what it is you're being paid to do... write good, fast, accurate code. :w00t:

    --Jeff Moden


    RBAR is pronounced "ree-bar" and is a "Modenism" for Row-By-Agonizing-Row.
    First step towards the paradigm shift of writing Set Based code:
    ________Stop thinking about what you want to do to a ROW... think, instead, of what you want to do to a COLUMN.

    Change is inevitable... Change for the better is not.


    Helpful Links:
    How to post code problems
    How to Post Performance Problems
    Create a Tally Function (fnTally)

  • majorbloodnock (9/23/2011)


      Understanding what it is you want to achieve. So many times, I'll see someone diving into detail before simplifying the problem so as to understand the fundamental requirements. It's not a purely IT skill, and it's not rocket science that the better you understand a problem the better your solution will end up solving it, so it baffles me why so few people take the time to put it into practice.

    Well said Major! I worked with a true IT professional a number of years back who wrote a very special program and his process was as you see it. Believe it or not he looked out the window for about three weeks and thought and reasoned the process. He wrote things down from time to time but wrote no code. Some wondered what he was doing, and the rumor was that he might be too old to perform the task and it should be reassigned. But he persisted in thinking about it day in and day out.

    One day he turned on the PC and wrote code for about 6 hours without interruption. He wrote it all from a logic map that was on a half sheet of paper, and a few notes. It took about 15 minutes for him to get a clean compile and install it on the mainframe ready to test.

    In three test cycles he had a table-driven process that generated an unlimited number of screens depending on variables passed in. After documenting it the total package took about a month of work. Three weeks thinking, a day writing, and 4 days documenting to give the rest of us a chance to understand what he had done.

    The task was scheduled to take 3 -4 months.

    Not all gray hairs are Dinosaurs!

  • Not doing needed research first, and coming to meetings with half-thought out ideas and goals. I see this so much this in this industry, it is not even funny. I have actually shut very noisy meetings down by simply bringing up the obvious that no one had really thought through. I have had people come up to me later and said "Travis, how in the world did you know that?" To which I simply replied "I did my homework first..:-D" Many times, people waste way too much time talking in conference rooms, when they should be researching... They spend way too much time talking when they should be listening. In the great words of Epictetus "We have two ears and one mouth so that we can listen twice as much as we speak. " Words to live by. 😎

    "Technology is a weird thing. It brings you great gifts with one hand, and it stabs you in the back with the other. ...:-D"

Viewing 5 posts - 31 through 34 (of 34 total)

You must be logged in to reply to this topic. Login to reply