Okay, so they didn’t teach me everything, but close enough. So much so I thought I would share my journey from fledgling developer to a data architect.
What should I be?
I’m getting older. No, I didn’t say old. I said “older.” As in maturing. Something that comes with getting older is younger people asking me: “I really like computers — what should I do? What career path should I take?”
When I started college a handful of years ago, the answer was easy.
There were two primary degrees: computer science and computer information systems. If you wanted to be a “programmer” you went into computer science. For those who wanted to play with networking and hardware, it was computer information systems.
Now the choices are as diverse as a tropical rainforest ecosystem.
Some context: I have a bias toward all things data. That tends to be the bucket I have landed in, every place I have worked—whether I was hired for it or not.
As soon as people knew I had experience with databases, database design, analytics and so on, they quickly whisked me away to fill that gap. And that has always been fine with me. I love working with data. Not so much the “management” of it, but more the architecture and movement of it.
Given my bias, I start the conversation explaining that “databases are a good place to focus.”
The world of databases covers a wide gamut of technological subjects. From hardware, to security, to programming, databases cover it all. It is an excellent platform for your base jump into a career in technology (I’ll explain why in the next few posts).
Today I’ll cover security. Both kinds.
Security: The Warm Blanket Kind
I’ll get this out of the way first. If you have knowledge of databases, whether it is database development, administration, security, or architecture, you have career security. Data is not going anywhere. Sure, the tools may evolve, and businesses rise and fall, but the need for data will never go away.
Believe in incredibly accessible business?
Get the Gravity newsletter for FAQs, tools, and camaraderie.
When I go to conferences and seminars, there are always people trying to convince me to work for them. I’m not well known. I haven’t written any books (yet). All they hear is that I am a data [fill in the blank]. Opportunity abounds when you have experience with company gold.
(Side note, no extra charge: I’m really happy with where I work.)
Be good with data (and have integrity and good interview skills) and you are pretty much guaranteed to have a job. You have options. You can find the company that fits you.
Security: The Fort Knox kind
Although it isn’t the first thing typically taught, security always presents itself early in the process of working with databases, assuming you’re not working with something like an Access database.
Even so, Access is still used in production today (crazy, I know). But that’s another topic altogether. Matthew MacDonald already wrote about it: Microsoft Access: The Database Software That Won’t Die (thank you, Mr. Ozar, for sharing this gem in your December 16th weekly links).
A course worth its weight in whatever currency you paid should begin with setting up a database server. That means an almost immediate focus on security. Is the administrative user secure? Is my server accessible outside my machine, or outside an internal network? Can the world get to it?
Secure practice would include adding non-administrative users. You learn the joys of permission grants, doling out access with user accounts and roles. Who can alter the database? Who can add data? Who can only read from it?
Databases won’t make you an expert in security. However, working with them should raise an awareness of secure practices.
No matter what niche you fill in the world of technology, security should always be at the forefront of our minds. Working with databases early on can help instill this important value.
In posts to follow, I’ll cover more details on everything databases taught me, and why I think they’re a great technology learning and career opportunity. Topics will include:
- Getting your head in the clouds
- Design documentation – how good it is … if it’s good.
- People skills
- And anything else I come up with!
That’s all for now. See you soon.
Cole Kelley is Gravity’s data architect. He writes regularly about software development at his blog, Code Juicer. This post is gratefully cross-posted with his permission.