Log in

No account? Create an account
Job situation update - John [entries|archive|friends|userinfo]

[ userinfo | livejournal userinfo ]
[ archive | journal archive ]

Job situation update [Oct. 19th, 2003|10:00 pm]
Because I wanted to give updates to folks who had posted or e-mailed congratulations, I figured to post this to the newsgroups where I'd made announcements (and also in my livejournal). Feel free to skip this; it just seemed like a good compromise between sending out a form letter, and not having time to give anyone any meaningful amount of information.

Well it has been an interesting week since I last showed up here. As most of you may know, I was offered a job the Friday before last, as a Windows system administrator and database administrator.

Now, I have already planned to go down to visit Pat last weekend, because she had tickets to Cirque du Soleil, but this gave me the opportunity to make it a celebration weekend, as well as an activity weekend.

First I had to drive down there, and I was late getting out, because the interview was Friday afternoon.

(The interview itself was rather interesting; it consisted of putting together a Lego model of the international space station. It was part of a teamwork project, you see, to make sure that the Linux administrator they hoped to hire, and I, could work together. They were already satisfied with our technical skills, or, our ability to gain technical skills that we needed.)

Anyway, I arrived there late, and Pat and I celebrated with champagne, and oatmeal chocolate chip cookies. (And, there were other lover-like celebrations, but I see no reason to go into "too much information" mode.) The next day, there was a fair amount of post job hunt recovery, and then of course, the trip to Cirque du Soleil. We followed our trip to the circus with dinner at a barbecue restaurant named, if I recall correctly, "Busters"… that was a damn good restaurant, let me tell you. They do only one thing, slow cooked meat with barbecue sauces, but they do it *really* well.

Sunday went by relatively quickly, finally culminating in a night of watching Buffy, and eating popcorn... a nice, relaxing end to the weekend.

Monday was spent getting ready to drive home, and driving home, and trying to relax for my first day of work. I had to go to the doctor to get a prescription, and I managed to do that before she closed, and I needed to get my car registered, and was able to do that online. So, I didn't have anything else that I had to do, but somehow I still felt busy until it was time for bed.

Now, I already had an agreement with my boss, that I did not have to be in at eight, which was a relief, because I'm always panicked about Seattle traffic patterns. Unfortunately, my boss didn't have plans to be in at eight, or nine for that matter. This wasn't a big deal, because I had promised myself that I would not panic no matter what went wrong, and ended up spending the morning learning a bit about the network that we still have the inside the office building. (They have just recently moved a good bit of the network to a co-location site.) When my boss came in, he was able to find out about the computer components that he had ordered for the two new people he had hoped were starting that day (the Linux administrator had chosen not to accept his offer), and my next job was building two machines, and installing Windows 2000.

Anyone who knows me really well knows that I am not very lucky when it comes to building computers; I have had a lot of things go wrong, and sometimes, there doesn't seem to be any rhyme or reason for what went wrong. However, my most recent computer building had gone relatively well, with only one semi-inexplicable problem arising. This time, everything went about as close to perfect as I could expect. Maybe it was just that I was being more careful, maybe it was that I was using entirely new equipment, or maybe it was simply a good omen for the job. In any case, in what is, for me, record time, I had two working, relatively high-powered computers at my disposal.

That, along with other bits of software installation took up most of the first day, at least, the first day at work. The day wasn't over yet.

You see, I needed a new chair; the chair that they have given me was really not appropriate for long-term seated work, and, worse, it squeaked whenever I swiveled. I realized about halfway through the day that the squeak was going to drive me absolutely batshit before long. Well, my boss and I found the proper chair for me in an Office Depot catalog, but it would take several days for an office order to come in, so he handed me one of the company Office Depot cards, and told me pick one up on my way home.

So, the next day, I started off building my second piece of office equipment... although this was a much easier build, let me tell you! I spent most of the rest of the day I installing an evaluation copy of SQL Server, and starting to drill myself on T-SQL statements ("SQL" stands for structured query language, and, it's essentially a programming language specially built for databases. T-SQL is Microsoft's implementation of SQL). It's an interesting thing, because I know that I know a good bit about SQL Server, but all the studying in the world can't quite prepare you for your first live experiences.

There was a lot that I knew how to do, but I realized it was going to take time before I was truly proficient. I could do things, but it took me two to three times as long as it would take anyone else, because I've really didn't have enough practice doing "real things" on a live SQL Server. Still, by the end of the day, I was quickly gaining confidence. I also realized I had a lot of work ahead of me... I have enough background knowledge to know what questions to ask (the hard part of learning something new is that period of time when you don't know what questions to ask, so you won't even know when you have found the answer), but it's somewhat disconcerting to realize just how many questions I have to ask.

For example, I found that I busy table has what's referred to as a "trigger", and the comments nearby say that it is to prevent null values in a certain column. Now, it's pretty hard to study database design for very long, without finding out that you never use a trigger to prevent a null value. You use what's called a "constraint". A constraint is exactly what it sounds like; it prevents certain values from being put into a table - for example, null values. A trigger is a piece of code that gets run every single time a certain action occurs. Maybe it's obvious to you, maybe it's not, but constraint is much more efficient in just about every way that you can imagine. However, it's not impossible for a person to want to use a trigger in that type of situation,*if*a trigger is supposed to do something else, in addition to preventing null values. Mind you, I can't think of a good example, but I am sure that it is possible.

So, I need to find out what's going on with that trigger, and find out whether the comment needs to be changed, or find out if we can get rid of the trigger, without breaking something else.

Now, that's just one thing that I found that I have questions about, that someone in my position should be asking questions about. And, I found that when my second day of work... well before the time when I would be normally going through the database, looking for things like that… this is both a good sign (that I’m catching things like this) and a bad one (there are so many things I’ll need to investigate that they just pop up before I’m really looking at them).

The next day got very interesting; I was connecting to our production database, and I was looking around at things, and one of the first things I did was check out the database maintenance plan. (There is actually a maintenance tool known as "database maintenance plan" in Microsoft's SQL Server; this wasn't a document I had to look up, it was a set of software settings indicating when certain tasks would happen automatically.)

Well, when I checked the history, it turned out that there was a problem with the database; in fact, the problem had been occurring for four days. It turns out that the problem was one that is an almost known issue; if you search Google long enough, you may find a mention of it. However, there is a false lead... there is another problem that appears similar that Microsoft fixed in service pack one (SQL Server is up to service pack three now).

Anyway, I didn't find the final solution that day, but my boss and I talked about how to fix it, and I decided that his suggestion was worthwhile, because it would be relatively quick, and I was sure it would fix the problem. So, that is what we did at the end of the day, and the next day, I checked to make sure that our fix was still holding. Well, it wasn't... so I had to find a more permanent fix.

I searched USENET, and I finally did find a fix that I think is closer to permanent, though it certainly isn't the best solution. It's more of a workaround, and it requires diligent monitoring, however, all databases require diligent monitoring, so I don't think this is a problem. Still, it would have been better to find a solution that was permanent, so that we could at least put this particular problem to bed forever.

Along the way, I noticed that our databases were not well-designed, because they were set up in a way that would require them to grow. Now, when files have to grow, there's a chance they will get fragmented, which slows down disk reads, and, each time they grow, it takes up a large amount of processor and disk time. So, I went my boss with that information, and came up with a plan to expand the databases to prevent these problems. I think that this, and my solution to the earlier problem, convinced him that he made an excellent choice in hiring me. And, to tell you the truth, from looking around at the company, I'm inclined to agree with him. I think that I fit in here (well, "there" - I'm at home), and I think they need someone like me. I think that if I'm careful, I can do a great deal of good for this company, and, incidentally, for myself.

The biggest problem I had with my job at WorldCom was that I was never doing anything real; here, I'm gaining experience incredibly quickly. The next time I have to hunt for a job, I'll have a much more impressive resume, and a lot more reason to be confident in interviews.

But, if I play my cards right, I think I can teach people a lot of ways to make things more efficient on the servers. The hardest thing is going to be finding the right tone; because I have my MCDBA, my boss wants me to play doctor. That is, I will give the prescription, and they will take my word as the expert's opinion. I think that I have to do that, but I want to find a way to do my prescribing in a way that convinces people that this is what they wanted all along.

I'm confident that I can do this, but I am a little bit nervous, because I know that a single misstep can make things difficult, though usually only for a single person or two. So, I decided that at first, I am going to play visiting doctor, and find out how people do things before making any suggestions.

In any case, the new job is going fantastically well, at least as far as I'm concerned. I really feel good about things, and I expect things to keep going well in the future. I had an idea of what my perfect job would have been when I started my job hunt, but I think I was wrong… I think *this* is my perfect job, at least for now.

[User Picture]From: 98
2003-10-20 04:02 am (UTC)
Glad to hear that you are off to such a good start!

As for the puzzling trigger, I once had to work with a database generated by Visio from an ERD diagram. That program always added a trigger in addition to a specified constraint. The only reason my colleagues and I could think of was that the error message resulting from violating the constraint was terse and geek-speaky while the message that Visio had the trigger print was more verbose and user-friendly. Since the trigger triggered before the constraint check the user would get a nicer message at the cost of performance you mention.
(Reply) (Thread)
[User Picture]From: ms_interpret
2003-10-20 09:50 am (UTC)
Oh, I'm so glad to hear it's going well! Congratulations!
(Reply) (Thread)
[User Picture]From: persimmon
2003-10-20 09:50 am (UTC)
I'm just so pleased for you - not only a good job, but one that *fits*. It's much better to work where your talents and abilities can grow and benefit the company as well as yourself.

(Reply) (Thread)
From: kightp
2003-10-20 10:15 am (UTC)
We followed our trip to the circus with dinner at a barbecue restaurant named, if I recall correctly, "Busters"…

Yup. Buster's Texas Style Barbecue, in Tigard, to be precise.

Thanks for posting this, by the way; it goes into details that sometimes go over my head in our phone conversations; I seem to be able to grasp some of the technical stuff better when it's written down. And I love knowing what you're up to at work (partly because it all seems so much more interesting than what I'm usually up to at work).

Here's hoping the second week goes as well, and all the weeks beyond...

(Reply) (Thread)
[User Picture]From: calpatine
2003-10-20 11:19 am (UTC)
(Reply) (Thread)
[User Picture]From: eleccham
2003-10-20 12:58 pm (UTC)
Congratulations, indeed! A job in which both the company and you come out ahead (besides your paycheck, I mean) is by far the best kind. Mine has definitely done that for me, except pretty recently, when things have gotten hairy... and I find myself sincerely hoping that it will calm down and revert to more how it was.
(Reply) (Thread)
[User Picture]From: lutonianbill
2003-10-20 02:26 pm (UTC)

I know the feeling about "finding the right tone": both from being the theoretical expert but a total newbie on a particular real system, and from being the expert on the real system with newbie theoretical experts to cope with. Asking questions is always the best way to progress. "The general advice is this, so why are you doing it that way?" lets the newcomer show some knowledge but willingnes to learn: and will often be met with "because we didn't know any better". Or "we've done it this way for years, but don't really know why" lets the established staff benefit from new ideas.

BTW, MS T-SQL isn't really that difficult: I learnt it several generations ago when it was still pretty much the same as Sybase T-SQL, but coped with maintaining some recently after an eight-year gap! It's just got wordier, really. As has PL/SQL, my current bane. If you know enough to optimise it, great: if not, sometimes just being able to explain what it does in business terms is improvement enough. There's very few developers or DBAs known for documentation skills!
(Reply) (Thread)