Big Gaps

  • Comments posted to this topic are about the item Big Gaps

  • By far the biggest change I see is the inability of many to "let go of the mouse".

    This can mean opening a command prompt or even just letting something run longer than 30 seconds.:-)

  • I find it common that some see object orientated programing in java / c++ /c# as their home but do not want to touch sql and also the other way around. This I believe creates lack of understanding for the whole life of an IT product. I believe you must know both and have understanding for both of these worlds to succeed and bring good value to a company or else you are handicapped.

  • One of the things that I find missing these days is patience. It seems nobody takes the time out to think and plan out the code that they are going to write. They start writing the code, then the thoughts come up and from then on, it's patching up the code to meet the requirement. This results in patched up code being rolled out from the "assembly line", so to speak.

    The other thing is that most often employees are attracted to the buzzwords, and attempt to gain an expertise on them before exploring the basics. The person may not understand how a query is compiled, but yet wants to use high-end tools and become an expert in performance tuning. I always tell any trainees that work with us to always focus on the basics - the advanced stuff will come automatically.

    Thanks & Regards,
    Nakul Vachhrajani.
    http://nakulvachhrajani.com

    Follow me on
    Twitter: @sqltwins

  • The most basic thing I find missing is an understanding of binary, octal and hexidecimal.

  • Nakul Vachhrajani (9/23/2011)


    One of the things that I find missing these days is patience. It seems nobody takes the time out to think and plan out the code that they are going to write. They start writing the code, then the thoughts come up and from then on, it's patching up the code to meet the requirement. This results in patched up code being rolled out from the "assembly line", so to speak.

    The other thing is that most often employees are attracted to the buzzwords, and attempt to gain an expertise on them before exploring the basics. The person may not understand how a query is compiled, but yet wants to use high-end tools and become an expert in performance tuning. I always tell any trainees that work with us to always focus on the basics - the advanced stuff will come automatically.

    Oh I so agree!

    I even have the perfect example to verify patience and planing. While this was at the university, there were 4 groups of at least four people in each group. We had 2 weeks to complete an assignment. I was leading my group and we decided that we wanted to draw up how we wanted to build the application and while we might have been extreme in the planning part, we invested 7 days in planing but then we we had a very good picture about how to solve most issues and how the application were going to work and then it only took us two days to write the application. The other three groups started to program more or less directly and none of them finished before us, there was quite a margin to our favor. The other groups was in no way any less good than our group, in fact some would perhaps have considered some of the other groups having advantages because of previous knowledge.

    So yeah, planing is really key for success. However, most developers does not find it fun to plan, I however maintain that it's necessary at least to some degree.

  • I find that rushing in is a big problem when learning SQL. I've actually seen people take a jump in and just start messing about trying to make databases without reading any documentation, in the small hope that they can "just pick it up as they go along".

    Stop! Sit down, go to amazon and look up beginning sql. Choose a book on beginning sql, of which, might I recommend the Apress series, and when it arrives work through it. You won't be an expert at the end of it, but at least you'll know enough of the basics to have a starting knowledge.

    And before anyone tells me that they don't have time to sit down and work through it, just think of how much time your going to waste when it all goes wrong. Get the basics right, and the rest will come to you a lot easier.

  • There seems to be a lack of basic shell programming experience. This leads to developers looking for a complicated solution instead of a simple batch file or shell script.

  • As a developer, I think the single biggest lack that I see in many of my fellow IT professionals it that they have a mindset of becoming expert in a specific tool or programming language and think that that is the path to success.

    While I think that in-depth expertise in whatever your current field is, is a great idea, I think we all should remember that our primary function is an understanding of the process of problem solving and development, and that the IDE's and languages we use are just tools to accomplish that goal.

    If I can correctly articulate what the problem or goal is, and the steps needed to accomplish the solution, then the actual coding becomes a detail - the means to an end, and not the end in itself.

    Understanding what drives our host business (whether employer or client) is also paramount ... taking 8 hours to optimize the "perfect" code so that I save the company 6 minutes in CPU cycles over the next year may be "elegant" ... but does it make business sense when I'm being charged out at a few hundred Rand (or Dollars) an hour?

    After becoming an "expert" in Clipper, dBase IV 2.00, Pascal 7.02, Delphi, ... and spending an incredible amount of time and effort in learning techniques which impressed my colleagues but never actually changed the bottom line for my employer at the time, and found that each skillset become redundant as the world changed around me, I finally decided that what I needed to learn were not the tools and languages of my chosen career, but the techniques and mindset of problem-solving, whch remain a constant and make me valuable to my employer regardless of the actual tool used to acchieve that objective.

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

  • What caught my eye was that Miguel  de Icaza talks of reading books on the bus - glad it's not just me who uses the bus...

  • 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.

    Semper in excretia, suus solum profundum variat

  • I'm shocked at the number of IT people who class themselves as professionals who have never written a single line of code in their lives.

    No, you don't necessarily need to be 'a coder' to use a pointy-clicky windows server admin console, but until you've actually sat down and talked to your CPU (not literally, thats just silly) or peeked at a memory location you won't appreciate fully what your server/workstation is actually doing when you click this or that.

    ok, so powershell lets you query active directory, open an OU, do something with every object inside. Why are you surprised when it takes 30 minutes and kills the network when you try to update every instance of x to y? If you understand what the server is ACTUALLY doing you can anticipate such problems and think about it before you run it.

    People seem to forget that every tool, every utility, every api, every object and even things like the SQL engine itself is actually a program that was written and compiled by a human.

    It's like a builder building a wall. he knows he mixes sand, cement and plasticiser and uses it to stick bricks to eachother, but he may have no idea where the bricks come from or how sand is ground down or why the cement makes it go hard.

    modern IT (even programming in 4th gen languages like c#) is like mixing up some mortar and sticking bricks together, bricks other people made for you. If you take the bricks away from a builder and say go dig your own clay and bake it, 90+% of them would be incapable of doing their work. Likewise with a huge proportion of IT professionals, take away their 'bricks' their controls, their admin screens etc they wouldn't be able to do their jobs.

    I'm not saying I can write an O/S in machine code by hand, but if I've got a compiler and a means of putting text in a file and can produce stuff. albeit slowly.

    I believe IT pros should, as a matter of course, do stuff through the command line from time to time. why? because when RDP goes down and your clicky interface doesn't work, you can fix it without having to reboot a live server. Write a little program in C every now and then, even though a powershell script would be easier to write. why? to keep yourself in touch with what your machines are actually doing for you.

    thats my rant over 😉

    Ben

    ^ Thats me!

    ----------------------------------------
    01010111011010000110000101110100 01100001 0110001101101111011011010111000001101100011001010111010001100101 01110100011010010110110101100101 011101110110000101110011011101000110010101110010
    ----------------------------------------

  • Great post by Ben - I work in an IT department, but none of the manager have any IT experience, let alone written code.

  • I agree - in fact I would say a lack of of the KISS philosophy in general is a big problem.

  • Two things missing:

    1. Willingness to LISTEN to customer requirements - not give them what you think they need

    2. Willingness to spend a little extra time to come up with a more general design - anticipate likely changes to come and provide flexibility in design to allow them to fit later, even if we don't implement them now. Otherwise, you just end up "hacking" your own implementation. (Guess that could just be summed up as patience. 😉 )

    [font="Verdana"]Please don't go. The drones need you. They look up to you.[/font]
    Connect to me on LinkedIn

Viewing 15 posts - 1 through 15 (of 34 total)

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