Ask HN: First job in IT, what best practices should I get in to?

14 points by jdsfighter 12 years ago | 17 comments

I started a new job 2 weeks ago as a general purpose IT professional for an electrical contracting company. Although I am essentially the one man IT team, my responsibilities include essentially patching up their current MSSQL instance (20 horrendously designed databases created by someone who had zero knowledge of database design, no indexes, no pks, etc).Once I have finished patching up their current database, I am to completely redesign their back-end and front-end systems, moving them away from access front-ends, and migrating them to native applications and web services.

In terms of software development, I'm fairly proficient, but DBA is not my strong suit, but I'm picking it up quickly.

So far, I've been fixing little errors in the database here and there, creating backup jobs (there were not in place), and extensively documenting everything I can decipher. Because I don't have any sort of mentor or senior to guide me, I'm somewhat flying blind on this. What recommendations do you all have for me?

strick 12 years ago |

One best practice is to RESPECT the people who built the systems that are already in place. Think about it, they were able to achieve so much financial success that they were able to hire the best and brightest: YOU

So, respectfully implement the obvious stuff like version control, backups, etc and leave all of the 'can you believe how crappy this is' attitude at home. I'm extrapolating a bit from your 'horrendously designed' and 'zero knowledge' comments. Those people probably still work there, or are thought of fondly by the people who remain!

jdsfighter 12 years ago | |

Actually, the developer that designed the system was laid off over two years ago, and the database has since been maintained by one of the other managers at the location. Everyone at the company has stated how he was a hard worker, but didn't know the first thing about database design, and while he worked as best as he could with the knowledge he had, he still left them with a rather terrible setup.

I don't really blame him, it's as if I asked a chef to design me a rocket ship, it was simply something he didn't know, and instead relied on information gathered through quick google searches and tinkering.

strick 12 years ago | | |

OK. But still don't throw that former employee under the bus. Your attitude should always remain 'there is room for improvement' and not 'this sucks'.

One thing to keep in mind is that technology at almost every company you will ever work for will be held together with some combination of duct tape and bailing wire. I have seen tables with no normalization whatsoever that support tens of millions of dollars of revenue. They key factor with IT is that it needs to work. And since these things tend to grow organically, almost none of them are optimized.

diafygi 12 years ago |

I'd recommend starting out early with good password management. KeePass Professional Edition is what I use since it offers several huge advantages.

First, you only need to come up with one good password (the one for the actual password file). If you ever leave the job, you just have to give them that one password and they can access the rest.

Second, it makes it easy for you to have good passwords for your resources. Plus, each resource can have a different password, so it may help limit the spread of an attack.

Third, if the company hires more IT staff, you can just copy the password file, rename it, change the password, give it to the new person, and have them change the password again. Probably not the best solution for 5+ people, but works well enough in small groups.

Fourth, KeePass offers a portable installation, which you can stick in Dropbox, on a usb drive, or wherever (no internet access needed). This is really helpful when you need to type in the password to the firewall that just took down the internet to your network.

Fifth, it's open source and free!

mattbrewsbytes 12 years ago |

If there are key critical systems, you want to have some documented plans down to checklists of things to do if there is some sort of emergency. I work in BigCo and having redundancy is nearly mandatory for all of our critical stuff. That may not be affordable for a small business, although if you phrase it in a way that electrical engineers would understand (fail safe like a GFCI interrupt or breaker) they might buy into it for a critical system. Bad things happen and if you can get them back up and running ASAP (e.g. failover to redundant system) and then fix the broken system you'll have less headaches.

Setup version control and use it, it's like having a time machine if you mess something up and need to get back to a working state. Git is all the rage, but Subversion is simple to setup and run and understand. It's just you so having a distributed VCS isn't likely to reap any rewards.

Use an agile approach when delivering features/changes. Build an entire "vertical" of a change like say moving one app from MS Access to a Web UI completely (or whatever you're going to move it to). If you design and develop each layer, like db access, business objects, UI in serial fashion then it will be a longer time before end users can give you feedback. Get that feedback as early an often as possible.

Serow225 12 years ago |

Sounds like you're off to a good start! :) Getting everything backed up soon is important; if things were implemented marginally, you don't know how long it will run before something crashes or hardware dies. Without a backup, you could then be in a rough spot... Also make sure that you test out the recovery from backup. I think documenting as you go is a great step, and is an easy way to generate a regular status report to show your boss what you've accomplished. You might want to start looking into the hardware that the systems are running on; are they working reliably, is there any redundancy (RAID, multiple servers, etc) and/or spare parts available. Once things are stabilized, I would continue refactoring the databases without making any user-visible changes (besides the improved performance once indexes are added :) Good luck!

dwd 12 years ago | |

Second documenting your accomplishments; remember to phrase them to match your audience, so describing how it measurably benefited the company is better than just the dry description of what you did.

jdsfighter 12 years ago | |

Luckily I've used the backups to setup my testing environment so I know they're good! Can you recommend anything else I should start doing? Development journals? Version control system?

Serow225 12 years ago | | |

Another thing I just thought of is a health monitoring suite for your servers/network. Also starting to move towards virtualized servers makes dealing with both failed hardware and testing/rollout/rollback easier.

Serow225 12 years ago | | |

Are the servers on any sort of UPS to enable graceful shutdown if power goes out?

Serow225 12 years ago | | |

Definitely set up revision control ASAP.

contingencies 12 years ago |

The situation you describe is probably not that uncommon.

The habits I'd recommend are general enough that they'd apply everywhere: Documentation and testing of all kinds. An ingrained resistance to be tied to any one technology, platform or stack. Clear communication. A curious mind.

jdsfighter 12 years ago | |

I get to sit down with the branch manager sometime soon and go over everything he wants implemented or removed for the next version of the application so that should help. I try to be fairly communicative throughout the day as well.