Consistent code infrastructure

“Any fool can write code that a computer can understand. Good programmers write code that humans can understand.”

— Martin Fowler

I’m currently working on a project in which I’m trying to deconstruct a database. In doing so, I’ve come across a number of things about it that, in the scope of databases, appall me. Who the hell creates a relational database with no defined primary or foreign key constraints??? And this thing is in a production environment, no less! While that’s a big part of my frustration, that’s another rant for another time. For this article, I want to focus on something else.

A big part of my task — and my frustration — is trying to figure out what the data columns are and how they’re being used in the application. I did come across a table that contains data as to what primary keys are defined (I have no idea why whomever built this thing didn’t actually create the primary keys), and I’m spending a lot of time trying to figure out how these tables relate to each other. As I already mentioned, there are no foreign key relationships defined. So a lot of my time is being spent trying to figure that out.

This is where my frustration — and the purpose of this article — kicks in. Whomever built this structure used names like “DataCounter,” “CrossReferenceCounter,” and so on, to define their “primary keys.” (I put it in quotes, because, like I said, they’re not actually there. And who uses the word “counter” to define them?) What I’m finding is that the corresponding foreign key isn’t exactly the same. For example, while the entity table uses ” DataCounter” for its “primary key,” other tables reference it using ” DataIDCounter.”

This might not seem like a big deal, but when you’re trying to figure out how to map large numbers of data tables and columns, you start questioning whether or not the relationships are correct. And I came across several others whose naming conventions are even worse.

Some of you might be saying, “that’s not a big deal. What’s your problem?” Well, trying writing an ad hoc query where you type in what you think is the column name, and it turns out to be something completely different. You end up wasting your time going back to look it up and trying to figure out what it is.

I remember a previous job in which I was looking at a piece of JavaScript code that contained two nested loops. You would think that the increment counter would use words that would make some sense, right? Wrong. Whomever programmed it named the variables “dog” and “cat.”

Explain to me how that is helpful to somebody trying to troubleshoot or edit the code.

In my previous life as a developer, I would write what I referred to as “open-ended code” — that is, I wrote it with the idea that it would likely be rewritten somewhere down the line. I wanted to make it easy for me (or someone else) to go back and edit or change the code, if necessary. I like to think that other developers have this same mindset, but, all too often, I come across examples like this that tell me that that is not the case.

If you’re a developer — whether it’s for an application, website, database, network, or whatever — keep your naming conventions and infrastructure consistent and meaningful. You will save another developer or support analyst a great deal of grief, frustration, and time.

Expect the Unexpected with DiRT

Steve‘s article reminded me about the first time I gave my Disaster Documents presentation at a SQL Saturday.

At the end of my presentation, one attendee started an argument with me. He kept saying that paper was dead, everything was online, and there was no reason to keep hardcopy documents. I argued, what if you can’t get to your online documentation?

Not surprisingly, he gave me a poor evaluation.

The bottom line is this: even documentation needs a backup. Other than, say, getting lost in a fire, paper documents can’t break. At a minimum, have hardcopy documents that instruct how to get minimal services back up and running, and back up other recovery documentation so you can recover it later.

Voice of the DBA

Disaster recovery is one of the core tasks that many DBAs think about on a regular basis. Ensuring that we can get our data back online, available, accessible, and intact is important. More than a few DBAs that haven’t been able to recover systems, find themselves seeking new employment.

That’s not to say that most DBAs perform perfectly under pressure. Plenty make mistakes, and there may be times when they can’t recover all data. There does seem to be a correlation between how often DBAs practice recovery skills and how well they perform in an actual emergency. I know that at a few companies, we scheduled regular disaster tests, though often with simulated recovery of a systems that didn’t expect to actually take over a workload. Arguably not a good test, but better than nothing.

Google takes things a step further. They have annual, company wide, multi-day DiRT (Disaster Recovery…

View original post 359 more words

Don’t tell me how to build the clock! Just tell me what time it is!

I felt a need to reblog this article, because this still continues to be an ongoing frustration. I’m reminded of this every time someone (the same person to whom I refer in my original article) feels a need to explain everything in his status update.

Why do people, especially technologists, insist on including every last detail about what they’re doing?

People don’t want detail! They just want the high level overview!

Why don’t these people understand that?

Welcome to Ray Kim's 'blog

This article’s title comes from something that a former manager used to tell me all the time — often enough that he seemed very fond of saying it. Nevertheless, it’s an important message. This is not the first time I’ve written about this issue, but it’s something that occurs all too frequently. It is a problem in technical and business communication, and the issue is something that bears repeating.

I was reminded of this during our daily status update meeting this morning. The gist of this regularly scheduled meeting is that everyone has a short time — usually no more than a minute, if that — to provide a brief update of what they have going on. The key word here is brief.

One person proceeded to go into detail about some of the projects he had going (he has a tendency to do so). He’s been pretty good…

View original post 475 more words

Want to learn something new? Get off your butt, and go get it!

A few weeks ago, Monica Rathbun wrote a ‘blog article about pursuing education or learning opportunities. It had been shared and retweeted a number of times by a number of people. I had meant to do the same, but it came out right around the same time that my father-in-law passed away, so the timing was inconvenient for me. After a few weeks of dealing with family issues, not to mention a week away at PASS Summit, my life has settled back into a state of semi-normalcy, so now I can go back to boring all of you with ‘blog articles and posting things I find interesting.

Additionally, Steve Jones came out with an article this morning about the benefits of conferences. Conferences are a great source of learning and networking. Some, such as SQL Saturday, are even free. If you ever have an opportunity to attend a conference or a seminar, I recommend it highly.

People, all too often, make excuses as to why they don’t learn anything new. Monica’s article lists out many of those excuses, and goes on to say why they are all invalid. She goes on to list resources you can use to further your education. It isn’t just about getting a degree or a certificate credential; it’s also about attending conferences and user groups, reading ‘blogs and articles, talking to people and networking, going to your local library, and getting involved with activities. Go read Monica’s article; it’s a great read.

I’ll make another suggestion: consider starting your own ‘blog. One of the best ways to learn about a topic is writing about it, even (and especially) if it’s a topic you don’t know. Writing about something you don’t know is a challenge, and it can sometimes be uncomfortable. But you won’t get anywhere unless you step out of your comfort zone.

Education is important, and we are always learning. Don’t use lack of money or lack of time as an excuse not to learn. There are many learning resources out there that you can do on your own time and require little or no money. If you’re seriously interested in learning about some topic, take the initiative and go get it. Otherwise, you run the risk of remaining in the same routine rut for the rest of your life.

Why candidates fail the job interview

At the moment, my work group is looking to hire a couple of new Oracle DBAs. My colleague, who is doing the interviewing, regaled us with stories about the people he interviewed. He extended at least one offer; whether or not the candidate accepts remains to be seen.

His stories reminded me of a SQL Saturday presentation by my friend, Thomas Grohser, entitled “Why candidates fail the job interview in the first minute.” The link sends you to a YouTube video of the session he did for the professional development virtual group. I haven’t yet looked at the video, but I have attended his session live and in-person at previous SQL Saturdays. If you are able to spare an hour, take a look at Thomas’ presentation. He gives a very good presentation, as he always does.

I have a few thoughts that, hopefully, will help you if you’re looking to go to a job interview. Again, I didn’t watch the video, so I’m not sure whether or not Thomas covered these points in his virtual presentation, but he did touch on them whenever I attended his live presentations, and I thought they were worth pointing out.

  • If you do NOT ask any questions, consider your interview blown. I overheard my colleague mention that he asked one of his candidates, “do you have any questions,” and he responded with, “Nope!”

    In the back of my mind, I said to myself, “he just disqualified himself. Please tell me you’re not extending him an offer.”

    Seriously. It is absolutely critical that you ask questions at an interview. If you do NOT ask any questions, then you just failed the interview.

    A candidate who asks questions indicates that (s)he is interested in the position and the organization. Keep in mind that you’re interviewing the company just as much as the company is interviewing you. Interviewing is a two-way street. You need to make sure that the position is the right fit for you.

    If you don’t ask questions, it’s an indication that you aren’t interested. Worse, it also signals that you aren’t taking the interview seriously. Why would a company want to hire you if you’re not serious about the interview?

    Bottom line: never, EVER, NOT ask questions at an interview!!!
  • It’s important to ask the right questions. Make sure that, when you do ask questions, ask the right ones. You should frame your questions in such a way that it shows you’re interested in the company.

    You shouldn’t ask questions about salary, benefits, etc. unless the interviewer brings it up. The company doesn’t want an employee who is self-centered. Instead, ask questions that show that you want to be a team player. A common one that I’ve asked when I’ve interviewed is, “what are the organization’s biggest challenges, and what can I do to help you out?”

    Whenever I’ve interviewed, I’ve always prepared at least two or three questions (sometimes more, depending on the interview) to ask in advance. I’ll ask questions about their system environment and their competition. I’ve even asked questions about their workplace dynamic — a question as simple as, “what do you guys like to do for lunch?” can sometimes be revealing about their workplace atmosphere.

    I highly recommend books titled Best Questions to Ask On Your Interview (I’ve seen these books in various titles — 200 Best Questions, 300, etc.). Get them from Amazon, check them out from your local library, or whatever works for you.
  • It’s okay not to know everything. I recently saw a Facebook post from a friend of mine who interviewed a candidate who didn’t know about what (s)he was being asked, and said so. My friend commented that it was refreshing that a candidate just admitted that (s)he didn’t know the answer, rather than try to BS his or her way through the interview.

    We’re human. We don’t have unlimited data storage that we can query on a whim. As such, you’re not going to know the answer to every interview question thrown at you.

    One of the worst things you can do is try to BS your way through every question thrown at you. More often than not, a good interviewer who knows what (s)he’s doing will see through it. That will not reflect well on you during an interview.

    Thomas admits that he will ask the candidate questions that either don’t have a correct answer or have ambiguous answers. (The question itself might even be ambiguous.) He isn’t looking to see if you know the facts; rather, he is looking to see how you answer the question. Answering “here’s how I would find the answer” or “I don’t know, but this is what I think” is often enough to satisfactorily answer the question.
  • Respect the interview. Make sure you’re showered, cleaned up, and properly dressed. Make sure you show up on time (even better, show up early — fifteen to thirty minutes early should suffice). Come prepared. If you’re late or unable to show up, contact them immediately and let them know. Say “please” and “thank you.” Use a firm handshake.

    In short, respect the interview. Not doing so conveys a message that you’re not taking it seriously, which causes the interviewer to question whether or not you really want the job. If you don’t take the interview seriously, chances are that the job offer will go to the candidate who does.

Hopefully, these tips will help you nail the interview. They might not guarantee that you’ll land the position, but they’ll definitely increase your chances of doing so.

Good luck at your interview.

Soft Skills: Controlling your career

I came across this article on SSC by David Poole titled “Soft Skills: Controlling your career.” It spoke to me in a big way, as it pretty much sums up my career in a nutshell. It’s a good read, and I encourage you to go click the link.

I’ve said before that I’ve made an entire career out of adapting to my environment. Soft skills are the key to being able to adapt.

All of my SQL Saturday presentations revolve around soft skills. I’ve been asked before about why I speak at SQL Saturday, when my talks don’t talk about data topics. The fact is, soft skills are important. You can know everything there is to know about data storage systems, recursive structures, or nuclear physics, but often, soft skills are ultimately what sets you apart.

Lots of user groups to choose from

Yesterday, I received a Meetup email (I get them regularly) regarding an AWS group (that I didn’t even know existed). I, personally, don’t deal directly with AWS, but my organization does use it extensively. There is an AWS user group meeting coming up this week. I sent the announcement to my coworkers; I figured that a number of them might be interested in it.

It made me think about the plethora of user groups that are out there. I write primarily about the SQL user group with which I’m involved, but I’m also involved with a UX user group and a .NET user group. I’m also involved with a number of extracurricular activities (that, for the purposes of this discussion, I count as user groups); I play with a large symphonic concert band, I have my CrossFit gym, and this Fall, I will be music-directing a show production that’s scheduled to be on stage in December!

I will confess that I have yet to attend a .NET user group event, and there are a number of other groups that interest me. What keeps me from attending them is lack of time. It seems like there is an endless number of user groups out there, but there’s only one of me, and there’s only 24 hours in a day and seven days in a week.

I’ve written about the benefits of user groups before. It’s a great source of learning, it often doesn’t cost anything to be involved, you support a cause that is special and specific to you, and it’s an opportunity to network and make new friends. (I should also mention that it’s a great excuse to get out of the house!)

And you never know where involvement with a user group might lead!

So if you’re looking to meet people and learn new things, go out and find yourself a user group. I have no doubt that there’s one one there that suits you!