Tag: career

I wrote the Five Year Plan in mid 2013. In it, I noted there was a prediction that IT departments wouldn’t exist in 5 years, meaning in mid 2018. That’s a year and a half away. Is that a possibility?

I don’t think so. The more I work in the technology world, the more I see a need for humans to help manage the systems and data. The systems are complex, the small details of getting a platform up and running are varied and not standardized across any two companies, and I can’t envision a complete self-service world. As easy as the Azure or AWS consoles can be, the mindset of those platforms still expects a technical person to choose options and provision systems. After all, how many of your non-technical friends understand what geo-redundancy is?

It doesn’t seem that IT departments are really shrinking. As I look through various surveys, employment statistics and predictions, it seems that most all positions in IT are still growing and hiring. The outlook for the next few years is still good and the pay is still rising overall. What does that mean for all the DevOps, self service, and BYOD vendor support that hint at less jobs for many administrators?

I suspect that there are trends at some companies, where mundane, less skilled, easy-to-automate jobs are being replaced by automation. Some companies may even eliminate certain jobs, like the Database Administrator, but they don’t really eliminate people. Those individuals that can learn to handle other work, and become more efficient still keep their jobs, albeit with different titles. Some work may get handled by systems, but much of the work just gets distributed to other staff as a part of their jobs.

I’ve seen this in software development at companies that eliminated testers. Developers and operations staff start to become responsible for different aspects of testing. Each person spends a little time testing, in addition to their other work. Everyone ends up doing a little less of what they used to to, but a little more of something new. This also usually results in a larger development staff to cover the work the testers used to do. Often this means the department remains the same size, some testers become junior developers, and we’ve moved work around. The shared responsibility might actually improve overall quality since the impact of poor code gets noticed by more people.

I think this is what will happen with many operational IT staffs. Perhaps some companies will try to eliminate the IT department, but really just move the staff to different departments, changing the reporting structure, perhaps expand some of the responsibilities of people, but they’ll likely still have the same number of “IT staff”, even if they don’t call it that.

This doesn’t mean that each of us should count on gainful employment at our organization until we retire. Most of us should constantly get better at our jobs, and learn more about technology. I would recommend you learn new skills, but constantly and regularly practice and polish your old ones. Become better at your craft, even as you might choose to grow your career in new ways.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( MB) podcast or subscribe to the feed at iTunes and Libsyn.

I was helping someone recently clear up some confusion about the encryption structure of their TDE databases. This individual wasn’t sure about how the various keys were used, which ones needed to be backed up, and which keys needed to be restored. As this was an online discussion, anyone could read the posts and add their own thoughts. There was a point where one person chimed in that the process was really easy and anyone should be able to complete it.

I do think that working with TDE is easy, but I also think that its easy for me because I have experience and practice with the technology. There are nuances to undestanding how the piece fit together and what needs to happen in order to ensure your system operates smoothly during both deployment and in disaster recovery situations. Since mistakes can result in lost data, I understand why people might feel intimidated or nervous, but once they practice a few skills and gain knowledge, I find they get the confidence to proceed.

Their fear is often because of ignorance, which is understandable. All of us have things to learn, especially in technology where the rate of change is quite high. Before we learn something, or even while we’re trying to understand concepts, various tasks might seem quite difficult, or even complex. These might be simple tasks, such as restoring a certificate or sending a set of objects through a Powershell pipeline or writing a unit test.

Just because you can do something doesn’t mean everyone can. Just because one person finds a task easy doesn’t mean others won’t find it complex. The knowledge that each of us gathers over time isn’t consistent or easily mapped. We all learn different skills at different times, in varying orders and to fluctuating depths. One of the very frustrating things about technology is that there isn’t a defined path for a particular technology, or even job. Someone that begins working with SQL Server might learn T-SQL first, or backups, and not get to the user/role/GRANT security model for some time. Even then someone might easily add logins and users to roles, granting permissions, but being unaware of the difference between REVOKE and DENY, or be confused by the WITH GRANT option.

I am not excusing the inability of someone to be competent at their job, but I do think that ignorance deserves some understanding and tolerance. While you might be annoyed that someone doesn’t know how to take a COPY_ONLY backup, I would hope you would treat them as a colleague that needs to learn a new skill and not chastise them if this isn’t something they’ve every dealth with before. If they can’t learn this skill and make mistakes over and over, then that’s a different situation and perhaps they aren’t competent. We should understand ignorance once or twice, but after that the person might need to find a new job.

I see plenty of people that are constantly working to improve their skills and get better at their jobs. I also see plenty of people content to continue their career with the same level of knowledge they’ve had for a long time, unable or unwilling to change and produce better code or faster systems. I also see plenty of skilled individuals treat both groups of people with the same level of scorn, contempt, or shame. I saw a comment posted recently about how Linux supporters will often mock people using Windows and then deride the same people for asking questions when they switch to Linux. I would hope that our SQL community would treat others better than that.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.5MB) podcast or subscribe to the feed at iTunes and Libsyn.

I was reading a short piece from Mike Fal recently and it struck a chord with me. I started working with computers as a developer, really a hack programmer as a kid. Friends and I would build small games or hack existing ones to change things. Eventually I was paid to write code, and moved into data work because the pay was better. That was 25 years ago, and I haven’t regretted the change since. In fact, I’ve enjoyed working with data.

Even as I managed data, I always ended up writing some code. Not code, code, like an application that others could use to accomplish a task (though I have often done a touch of that), but rather code to help me as a DBA. I had code to check servers and record values. I had code to move backup files around and generate restore scripts. I had code that would build reports for other DBAs. Some of this code are queries, some are more complex scripts in PoSH (or older VBScript), some could be C# or some other language, but it’s all code. Fundamentally, the code isn’t much different from the code that application developers write and deploy to clients, web servers, or mobile devices.

There always seemed to be a separation between a DBA that could script something and a DBA limited to simple DML queries. The latter was much less efficient, less productive, less capable of managing a larger environment. As I look to the future, I’d say that that DBA or sysadmin that can’t write some code, that is mystified by the concepts of Puppet, Chef, or even unattended SQL installs, is less likely to find good paying, enjoyable, desirable employment. There will be exceptions and less capable people will find work, but given a choice, I think businesses will prefer to get the coding DBA.

Mike brings up great points in his piece, and despite my history as a developer, I’ve build bad habits over the years. I used to carry around a CD, then a flash drive with helpful DBA scripts on it. I didn’t always have a good test process. Part of this was the lack of good modern tools, part was laziness, but just like Mike, I’ve started to think of anything I do as an effective developer would. I make sure things get done, and I don’t try for 100% solutions. I try to get something working, find the problems and fix them, adjusting as I learn and the system changes. I try to build unit tests and ensure that as I change code, I’m not introducing silly bugs because I’m focusing on today’s issue while neglecting the requirements I had to meet last week.

Above all, I use version control. That should be a no-brainer for a DBA. We preach backups and restores all the time. Why should our code be any different? These days I’ve adopted git and I use it extensively. Whether on Github or VisualStudio.com, I’m ensure I’ve got my code backed up, and practice restoring regularly on other machines. I create repos as soon as I create a folder to work in, and commit regularly. I don’t revert often, but when I do, it’s nice to have that backup in my VCS.

Steve Jones

Last week I wrote some predictions for 2017, and plenty of you added your own thoughts. Overall, security is a concern for most people, with little hope things will improve. I certainly hope they do, but like most of you, I think expediency and profit will overwhelm any chance that organizations will make patching their systems a priority, much less improving their data security.

As the new year came and went, I ran across a great post from Buck Woody that’s a few years old. Inthe post, Buck notes that he likes to make goals in the new year with his family, not resolutions. That sounds like semantics, but I agree with Buck. There is power in making goals instead of open ended changes. Goals can help drive you, especially if they’re measurable and time boxed. Having someone else keep you accountable also helps.

This week, as we start a new year of our careers, I wanted to ask you what goals you might have. List a few and think about asking a friend, spouse, parent, child, someone else to help hold you accountable and check on your progress each month. If you have just a few goals, chances are that you will achieve some of them. Don’t forget, you can always add a few more later in the year if you finish everything.

Perhaps you want to learn something about a new technology. If that’s the case, make a specific goal. Don’t try to “learn Azure”, but instead think about “building a database to track my own movie reviews in Azure and use it for a year.” If you want to get better at a specific technology, like T-SQL, then think about challenging yourself with a specific set of problems, like the T-SQL challenge. Or complete something like the Advent of Code in T-SQL.

Set aside some time to improve your career and take a step forward. Data professionals working with SQL Server have no shortage of new features, subsystems, and solutions to practice with as our platform grows wide and deeper each year.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 3.5MB) podcast or subscribe to the feed at iTunes and Libsyn.