Below are just a few things I've come across in almost 19 years of working in IT. After a chat with a good friend who is considering breaking into It I thought it would be worth jotting them down.
1. Take time to document and keep a copy of the document.
Make sure you document issues you had, that part will be invaluable in the
future. When you document something make a note of software versions. You'll
often be surprised at differences in 'point' versions. These differences can be the key between something working and something going majorly wrong.
2. Never be the person who says 'yeah, I remember seeing
that error once' Document it. You'll need it some point. A well structured wiki
or notes system can cut future task time in half simply by recording known issues and fixes.
3. Never lie to clients be they internal or external. You
don't have to tell them everything but a direct answer to a direct question,
admitting when you are wrong and/or don't know something will win you points
for honesty, I also call it being professional.
4. Going the extra mile is good, often that extra mile
isn't staying until silly o'clock but providing some hand holding during a
major piece of work or just some notes on why you are changing the config of
something. Communication is vital.
5. Saying "its urgent" is often code speak for
"I didn't plan and am giving you this problem". If you already have
documentation on how to fix something flagged as urgent and you have the time
then go for it, this can be worth major brownie points.
6. Sometimes something really is urgent. A major trick is
knowing the difference between 'its urgent' because it really is and 'its
urgent' because they didn't plan and need it now. This comes with experience
and listening to people.
7. Weekend work, whilst unpleasant, can be made easier
with planning and pre-staging. All weekend work should have a back out
plan/rollback plan. Never be afraid to call for a rollback. You may not be
popular with project mangers but that's preferable to digging yourself into a
hole you can't get out of.
8. If you lack documentation for something (and at some
point you will) then make your own. It will have gaps but you'll have a
starting point to build on. See point 1
9. No matter who takes the minutes in a meeting make your
own. they don't have to be anything official but a few notes often go a long
way when, 6 months down the line, when someone asks about a point from that meeting/that client you'll have notes.
Something as simple as a
notebook that never leaves your side and has name, date, attendees, client and
actions as well as notes, diagrams, etc will be a major asset when you need it.
10. Prioritise. Most managers cant do it for you because
they don't have the tech skills to know how something works, if they demand
something be done asap, they are the boss so do as you are told.
11. Organise your email. As an IT person email is often
the key way people communicate and where all the alerts go. Organise it with
rules and alerts to keep on top of what is important and what is noise. Don't
be afraid to consign those management prep talk emails to noise, its better to
find a system problem than learn the latest internal buzz.
12. It's rare to
find someone in it who will share knowledge. If they are happy to share
knowledge make the time to learn as its always good to be able to take a step
back and see the big picture of something. Also, if you can talk to other
people, not just it people, using their own terms not only will they will be
more willing to listen to you but they are more likely to help you. Be ready to
share your own knowledge. It people who hoard knowledge are often scared of
being caught out. If you are caught out you've just learnt a valuable lesson,
accept it with good grace.
13. Listen. Be it to customers (internal and external),
other people, meetings or to a point, gossip. Gossip can and will tell you more
about what is going on in a company than regular status updates and from that,
you can infer the likely impact to systems under your control. Gossip is
sometimes the best measure of where to put your energies than anything else!
14. When you do a project for a non-IT person, other
company, users, etc they are trusting you with one of the most precious things
they have - their data.
Don't let them down. Listen to them, understand what it is they do with their data and explain to them, in plain English - with diagrams if required - just what it is you will do with it and why it'll be better. Over time this will gain you both trust and a reputation for being professional.
Don't let them down. Listen to them, understand what it is they do with their data and explain to them, in plain English - with diagrams if required - just what it is you will do with it and why it'll be better. Over time this will gain you both trust and a reputation for being professional.
15. Any backup is only as good as the restore procedure.
Any restore procedure that has not been tested in the last 12 months should be considered as just
words in a document that has no basis in reality. This goes double if
software/hardware has been upgraded.
Even if it's up to date, validate it. Its best to verify and understand the gaps before getting to the point where you need the restore and finding the gaps then or that a key step is missing.
Even if it's up to date, validate it. Its best to verify and understand the gaps before getting to the point where you need the restore and finding the gaps then or that a key step is missing.
16. Project plans are often just big task lists with no
meaning to the dates. Understand the real deadlines in a project and the reason
for those deadlines. When project managers start pushing you'll know the real
score - this is better when you understand the customer and their job - see
point 14.
17. At the end of a project do your own lessons learnt.
Too often lessons are not learnt from lessons learnt. Your own version should
highlight how to deal with certain blocks you encountered in a project especially
if they were blocks put up by colleagues, it'll help with future project work.
18. Avoid the following names: old, new, temp. They will
bite you and if a project is halted mid work for some reason when you go back
to it which areas are valid? the old ones? New ones? Temp ones? Meaningful
names will save headaches in future.
If you are saddled with someone else's poor naming
convention then document it - see point 2!
19. If possible, test changes to live data before doing
the change on live data. If its not possible make and test a backup. Saying "it'll be fine" is the IT version of "look at me!" Often with the
bone (data) shattering crunch at the end.
20. When you asked to estimate time for a piece of work
don't estimate time for just that piece of work. Add in things like
documentation, internal processes, liaison with others, interruptions and then
double it.
