Tag: career

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.

We published the results of our 2016 Salary Survey today, which has some interesting numbers in it. I haven’t done a lot of analysis of the data, but it seems as though the averages are higher than I expected for SQL Server professionals. That’s good news, and it’s one of the reasons I switched from being a developer to a DBA. Our DBA back in 1990 made more than every other programmer in a larger Fortune 500 company. Since I enjoyed database work, I moved in that direction and never looked back.

I also ran across this interesting post on programmer earnings on Quora, and found some of the answers interesting. There are people showing the entry level salaries being high at large tech companies like Google and Facebook. I’m sure that happens, but those salaries often skew what most of us might see when we start in this field. I think non-tech companies that are trying to fit developers in with other entry level jobs (sales, marketing, operational positions in their industry, etc.) don’t view programmers as special. I would guess that the technology pay is better, but still below US$50k/yr in most places.

While I think in the US there isn’t necessarily a cap around US$100k/yr as there used to be for most of my career, I do think that it’s still hard to make more than this for most people. The average programmer is just that, average. Without being driven to develop strong skills, make a different in their organization (and learn how to do this), and stand out substantially from everyone else, management often doesn’t want to substantially increase their labor cost. They won’t want to pay more for a developer without a good reason.

All the number are useless if you become a freelance consultant. That’s easy to do in this field, though finding work is a challenge. As is the demands on freelancers outside of the technical work. On your own, you need to manage accounting, sales, marketing, and more, which are not necessarily the work that most people enjoy. In my view, if you become a freelancer, you earn that extra money with the hassles of running your own business (it’s not uncommon for freelancers to easily make over US$100k with successful ones going to US$200-300k/yr).

Many of us know people that love programming computers, and don’t worry too much about salary. Most of us would like to earn more, for a variety of reasons, but few of us actually work to earn more. There’s a good quote in the article: ” Because some folks never ask for raises and never leave a company. They built up experience, but didn’t leverage it, so their compensation never rises.” I’ve found that to be true. Far too many people never learn how to increase their salary, whether by changing jobs, becoming more valuable, or even just asking for more money in a way that is likely to be successful. We usually just take what’s offered.

Money isn’t everything. I think that working in technology strictly for money is a bad idea. There are downsides to this work (sedentary, stressful, complex and ever changing), but I also know that many people have enough of a talent to get by and have other interests in life. If that’s the case, and you want a job you can do for most of your life and earn a decent living, this isn’t a bad field. There are plenty of answers from people that recommend you don’t pursue programming if you don’t enjoy it, but I think that it can be hard to find employment in an area you really enjoy and also make ends meet. Certainly if you are starting a career, I recommend you try to find work in an area you enjoy. Build a budget that suits your earnings, and find some satisfaction and enjoyment in your career and life outside of work. Once you have a family or other responsibilities, it can become hard to make a drastic change in your career path and you may find yourself stuck working at a job you don’t enjoy.

There is one answer that struck me. The final line of that one says: “A bottom tier developer should probably stop being a developer.” This is a place I’d disagree. Almost every industry has no shortage of people that aren’t that talented at their craft. I know poor plumbers, electricians, doctors, lawyers, retail workers, and yes, programmers. Some of them may lose employment regularly and struggle to find jobs. If that’s the case, and it is a problem in your life, then perhaps you should look for other work. However, if you have a job, then why stop? Every team I’ve worked in or managed has a need for a variety of work. Some hard, some mundane. Some easy, some complex, but in all cases, it’s good that we have a spectrum of talents on the team. There is always some work that is better suited to less talented employees, whether they are electricians or programmers. There is also work that can only be done effectively (or efficiently) by the most talented.

If someone is willing to pay you, and you’re willing to do the work, then that’s the definition of a job you can do. Why stop, especially in this business, if you have employment that suits your situation? There’s nothing wrong with going to a place of employment every day, and doing a day’s work for a day’s pay, even if you don’t do it as well as others.

Steve Jones

The Voice of the DBA Podcast

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