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

[jdsfighter]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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.

[jdsfighter]

They are very set in their ways when it comes to their severs, they wont even implement Active Domain services... So virtualization may be out of the question for now.

[Serow225]

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

[jdsfighter]

Yes, the company I work for is an electrical contracting company, and specifically the branch that I'm working for is based inside a massive data center. So power wise, everything is golden.

[Serow225]

Definitely set up revision control ASAP.

[jdsfighter]

Any recommendations on the best, I have minor experience with SVN, and I've only used GIT for github related stuff. Everything here is windows based, everything. So I was even considering going with TFS, but I also have been thinking about using git out of its simplicity and robustness. Especially since I may be working from multiple computers.

[Serow225]

Well the term 'best' is touchy, but for your use case I'd suggest trying SVN using something like VisualSVN Server and TortoiseSVN for the client(s). Simple to set up, understand and use.

[contingencies]

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]

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.