Voice of the DBA

Tag: career

  • The Salary Range

    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.

  • Testing Coders

    Interviewing someone is hard. In fact, I’m not sure many of us really know how to do it well. Looking at the past hires in most companies I’ve known, I find that all too often the success of hires in developing software is a bit of a hit and miss effort. Some hires do well, and some don’t quite perform as expected. Why is that? Wouldn’t you expect that we could adequately test someone’s skills as a developer? After all, we know what kinds of code we expect people to write. Shouldn’t there be some sort of test that you could have someone complete, even across a few hours, that would allow them to show what they can produce?

    I ran across an interesting post from Ore Eini that looks at a way of interviewing people by asking them to improve code. Rather than a take home test, or having someone develop code from scratch, Ore gives them a file and some code, then asks them to make it faster. The interviewee has around an hour (mentioned in the comments), but this is a test of whether or not someone understands how to read and write code well.

    Perhaps there’s a good way to do this in the SQL world as well. Can we take a loop or a complex join and have a user rewrite a query to be more efficient? Some of the changes in T-SQL in recent versions (especially 2012) can dramatically change the way you write code. Perhaps a candidate should be tested to see if they actually know how to avoid Grant’s seven sins? I bet more than a few people would want to know if candidates would remove, or at least question, the use of NOLOCK.

    There are many reasons why a candidate might interview well and then not perform as expected on a day to day basis. Life changes, we have outside distractions that might affect us at work. During the workday, we may struggle to get along with co-workers. Our managers might not bring out the best, or even the good, in us. Perhaps we are asked to perform tasks that weren’t covered in an interview and are outside our area of expertise. Perhaps we just don’t try as hard after we’ve achieved our goal of getting he job.

    There isn’t going to be any magic, guaranteed way of ensuring we hire people that will always perform up to their abilities. That doesn’t mean we should give up. I would really like to see us continue to try new techniques, share ideas, and most of all, continue to inspire and motivate others to learn more about their craft and constantly improve their skills.

    By the way, if you’re interested in the code side of things, Ore discusses some basic improvements and then more efficiency changes. One interesting thing, moving away from Linq dramatically lowered the memory allocations and working set size. Is this a big deal? It really depends on the way in which your application is structured, but this is an optimization that might be worth doing early and often with a little developer training on how to better write queries.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Learn to Earn

    Could you double or triple your salary by learning more technology skills? Sure, and here’s a great story about someone learning PowerShell and dramatically increasing their earnings. This is a good read, looking at the journey of someone through their career and how they credit learning PowerShell for the changes in salary.

    When I read this, I don’t view this as PowerShell being the reason that Mr. Duffney increased his salary. Instead, I think the takeaway is that professional learning and regular skill development, focus across time, and producing results for an employer as being the primary reasons for raises. I think that the right part of the salary curve in the post, which has a steeper slope, is also likely due as much to speaking and giving back as it is to solving problems. The other lesson in this piece is that Mr. Duffney is constantly gaining skills, and looking to move forward in his career.

    The world of technology is ever changing, with new platforms, additional features and changing paradigms constantly appearing. I’m sure many of you have experience with management that becomes excited by the latest buzzword or hot topic in the media, expecting that each of us can quickly build a proof of concept. Perhaps you’ve dealt with a boss that assumes we could buy a product or build a tool that easily solves some problem because they read about some other company in a publication having success.

    Tackling a new project or technology is a challenge, but we can learn to ease the way for ourselves. We should be constantly learning something, anything that exercises our minds. One of the best talks on the topic I’ve seen is from Andy Warren, and I’d encourage you to check it out. Andy talks about directing your learning in an area that can help you. That may sound daunting, but I think that building the habit of regularly learning something is important in this business. We never know where our career may take us, and being accustomed to the idea of picking up some new technology and using it for a task is a skill you should practice and develop. The more often you try to improve your skills, the more comfortable you will be with the idea of tackling some new technology. In the first piece linked, we see that Mr. Duffney had a plan to become a CCNA, but over time that plan morphed into something else, as did the focus of his learning.

    I certainly have been able to raise my salary by learning more about databases. This usually comes about not just from learning, but from applying that learning to my job, showing my employer (and potential future employers) that I provide lots of value for my salary. Using new skills in a valuable way is the method by which I’ve most often been able to translate learning into a raise.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Pressure to Compromise Ethics

    There have always been those that seek to defraud, deceive or mislead their customers. In order to do this, someone inside an organization has always been willing to pressure employees to compromise their ethics and morals. Construction companies may use substandard materials or ignore standards for construction. Financial companies falsify performance records of products. Medical professionals may order unnecessary tests to charge more. Perhaps one of the common areas many people feel cheated is with used vehicles, where there are numerous stories of deceit from companies and individuals. I’ve had my own experiences with cars to support this.

    It may be no surprise to you this is also happening in the digital world, which seem fundamentally more disturbing to me. After all, software is constantly changing in a way that many other industries don’t. We can fundamentally rewrite the rules under which systems work by deploying new code, something many of us do on a regular basis. What’s more, we have rules and regulations that fundamentally prevent us from disclosing how the systems work, limitations that don’t allow for anyone to easily audit or evaluate what the programming might be doing.

    This is different than a car, where we can examine the components and test them, or have a third party perform this for us. It’s different than health, where we can solicit second opinions. Even construction has inspections from independent groups that can verify some specification is met. However, none of that exists for software. In fact, our industry resists remotely attempting to implement any sort of ethics by limiting access to source code.

    There’s an article that lists some of the issues developers have encountered. It also talks about teaching ethics as a way to reduce the impact, which is a good idea. But without any sort of accountability or transparency into the actual code, I’m not sure ethics will help much. There are always people that need a job, and may be willing to write code that continues to provide a paycheck because they aren’t sure they can get another job. I know most of us would like to think we wouldn’t succumb to pressure, but it can be hard to be sure what you’d do until you are confronted with a particular situation.

    I do think this is a problem that will grow, and become more pervasive in the digital world, precisely because no one really knows what software is doing under the covers, and it’s hard to even determine what might be happening if you could access the source code. After all, can you be sure that code you get is actually what is running? You can, but not easily.

    What I’d like to see is some sort of framework that allows us to specify the behaviors of our software, along with the data movement and handling so that end users would have an understanding of how the software should work. Maybe some automated way of producing a “contract” based on the code. Then we could resolve disputes without ever needing to examine the source.

    Steve Jones

    The Voice of the DBA Podcast

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