The grandiose IT ego

If you work in IT or work with IT then you probably know what the “grandiose IT ego” is.  Since it is a phrase used to describe something or someone technical then I guess we have to refer to it using an acronym (huge eye roll):  GITE (and I don’t mean a holiday house in France).

I rarely encounter the GITE but when I do it is something that ranks high on my list of unpleasant experiences that I would gladly trade instead for moments of crawling on my belly through deep muck in a scary jungle infested with disease, flesh-eating insects and cannibalistic tribes.

I write this post because a typical GITE made the news recently for doing something that a typical GITE does:  publicly mock people who ask “stupid” questions.  Not cool.

Unfortunately, I cannot offer sound advice on how to deal with GITE’s since my method is that of ignoring them on an epic level.  I am proud to say I am an Olympic champion in the arena of ignoring and, unless you are at this level, I do not recommend it because bottling up that kind of frustration could cause your head to pop off if you are not properly trained on how to internalize such things.

There is one thing I can do if you are a new IT up-and-comer.  I can offer a few tips on how to prevent becoming the dreaded GITE:

  • Your clients are paying you for an IT service for a reason.  They either do not have time to do the task themselves or they do not know how to do it.  In either case, they are going to ask you questions.  If some of these questions are questions you classify as silly, avoid mocking them for asking such questions.  This is the most important rule to carry with you in any field of study or business setting.  Mocking others quickly propels you into a spotlight of unflattering light that can be seen for miles.   Poking fun is something you do in private with your friends when you are letting off steam.  Keep it private and anonymous and remember this: you ask silly questions to, you just do not realize it.
  • Avoid the urge to lecture others on how they should be doing something.  Work on your delivery by offering suggestions or just appreciating others as they are instead of a scene like this:  hovering over someone’s shoulder as they drive and sighing and rolling your eyes as you tell them how slow they are and that they should be selecting Ctrl-C to copy text instead of selecting “edit” > “copy” from the top menu.  There are 1200 different ways to do anything on a computer, no one cares that you want to be the Overlord of Copy Commands.

 

Advertisements

Example of a list of Requirements for a Simple Application

This web page is an example of a simple application (it is a web form): http://mummey.com/contactus.aspx. This form allows a visitor to enter his or her email address, a message and click on a submit button. When the user submits the required data, the data is sent in email form to a general mail box at mummey.com. An application of this size and complexity will take a programmer about 15 minutes to write. A full hour if you throw in testing, handing off to the client for user testing, writing proper documentation and publishing to production. However, this estimate could go up to several hours if you wanted the programmer to create artwork.

If you wanted a simple application like the one listed above, your requirements to a programmer would translate to something like this:

  1. One form that displays 6 items (welcome verbiage, navigation of some kind, graphics, form fields of email address and comments and a submit button).  We will provide the images and descriptions of the items to the programmer.
  2. The visitor to the form should be able to enter their email address, a message and then submit the message via a submit button.
  3. When the visitor submits the form by clicking on a submit button, the visitor email address and the message the user entered will be submitted as an email to this email address: xxxxx@xxxxx.com.

Tips on How to Foster a Good IT Environment

I am one lucky gal. I’ve been a computer programmer for about 14 years now and my experience with working with men and women in IT has been wonderful (I know, life isn’t always peaches and puppies but this posting will focus on all of the wonderful things because there have always been more good than bad). This post will offer some insight into a few things that can be done to create an effective IT environment. These are things that have happened in IT groups I have been a part of and they really make a difference in the quality of an average IT day:

Each day as you travel to work, remind yourself of one thing: you are fortunate to have a job, just pick up any newspaper in any city in the world and you will see how worse off some people are. So no bad attitudes, walk in knowing that each day could end up being the best day of your life. If you know you cannot do this, and you’ve had a bad attitude for 20 years, it’s time you find a job where no interaction with living creatures is required. Maybe something like: go on a lone 30 year mission to mars, confine yourself to your garage to invent things, or learn animal taxidermy. Otherwise, read on!

Share what you know. If a newbie is on the way in, write up a short, one page document or email that describes who you are, what you do, what apps you support and how you can be reached for questions. This allows the newbie to reflect on you after you are briefly introduced (nervous people rarely remember names and if they have a document or email explaining who you are then they won’t forget you).

Document your application as soon as you send it to production for the first time. It can be short and sweet but is meant to help your coworkers when you are out of the office (and you when you have to update the application 10 years from now) so it needs to describe the application you just wrote (what it does, who the clients are, where the application resides, where the code is, what language the code is written in, any passwords and any database information if it relies on a database). Consider your documentation equally as important as the application itself.

Provide a quite space for uninterrupted thought. Plopping programmers down in cubes in the middle of the phones sales team isn’t going to work, there are too many people talking. Eventually many folks learn to drown out background noise but until this skill is mastered, money is lost. If you have no choice in location, then make sure employees have noise cancelling headsets or try out working from home a few days a week.

Provide clear direction to clients. They have their own job to do, don’t assume they know how IT works. Look at it like this: I am a computer programmer, if you put a tax form in front of me I go blind, I have no idea what to do. Same goes for clients, if they tell you they need an application built then give them some direction. Sit down and work with them face to face to hash out requirements, then give them a list of the basic application life cycle so they have an idea of what to expect and when.

Say thank you, everyone likes to hear it.

Avoid bashing someone else’s work in a group setting. By doing something like, you risk giving the impression of egotism, ignorance and paranoia to those on the receiving end. If you don’t like the way something is done, focus on a positive delivery by offering suggestions instead of demanding your ego be petted like a soft kitty on a rainy day.

Get your home life in order. Home is your only escape from an often brutal world. If your home life is not a safe, pleasant escape from the world, then it’s time to make a change – it won’t be easy but it’s the most important thing to do. Your home life needs to be solid before you can be happy doing anything outside of your home.

I need a programmer to write an application for me, where do I start?

Before finding a programmer, understand the basic application life cycle.  It is something like this:

  • Client comes up with a list of requirements (be as specific as possible).
  • Programmer is given requirements to study
  • Programmer gives estimate of time and cost of job based on requirements given
  • Programmer builds application
  • Client tests application and the programmer fixes any bugs in the application – this step loops until user agrees product is good. DANGER – it is in this step that scope creep can show its expensive head.  Scope creep is when a client at this point adds more requirements to the application, this is very easy to do because the client is excited about the project and the programmer is excited about the work and making the client happy.  If more requirements are thrown into the project at this point, the client needs to understand that the original estimate of cost and time no longer apply.  It is best to meet with programmer with a new set of requirements so the programmer can establish a new estimate of cost and time and if this new estimate exceeds the timeline of the client, then the application needs to be pushed to production as is with the original requirements and a new timeline/cost should be established for Phase II (new set of requirements) of the application with the programmer.
  • Programmer publishes the application to production.
  • Programmer delivers documentation in electronic form the client. Two forms of documentation are delivered: a user guide and a tech guide.  The user guide is a detailed step by step document of how a person would actually use the application (covering all of its features).  The tech guide is a detailed document containing the actual code of the application (or a link to where the actual code can be found), any passwords required of the application, detailed information regarding the database (if the application uses a database) and the language the application is written in.  The tech guide is to be given to any future programmers who may have to work on the application after the original programmer has won the lottery and moved to California:)
  • Client pays programmer.

Create a free website or blog at WordPress.com.

Up ↑