

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.<p>In terms of software development, I&#x27;m fairly proficient, but DBA is not my strong suit, but I&#x27;m picking it up quickly.<p>So far, I&#x27;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&#x27;t have any sort of mentor or senior to guide me, I&#x27;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!

------
matt_s
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!

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

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

