Category: Editorial

  • Making Plans

    I write regularly about career topics, hoping that I can help many of you think about your career more, learn more, and move in a direction that’s important to you. I’ve had a great career, one I’ve enjoyed most of the time, and think that pressing myself to become a better professional in many ways has been a large part of that. However I haven’t always had a formal plan, and don’t really have any long term goals in any detail.

    I thought about this a bit in reading Kenneth Fisher’s interview of Tom LaRock. There’s a point where Ken asks Tom about his future plans and Tom paraphrases John Lennon to say he takes opportunities as they come and isn’t afraid to change directions in life.

    As important as I think it is to continue to learn, and to move your career forward actively, I don’t think you need to do it all the time. I don’t think it’s a constant, every day effort that you make. There are times when you’re busy with life, or busy with work, and you may not have the extra energy or desire to pick up a book or write some T-SQL. That’s fine. Relax and enjoy your life.

    Just don’t let those times stretch so far that your career stagnates. Make regular progress, not constant progress. Make plans, but live life as it passes. Make goals, but make them realistic, and pace yourself. Above all, don’t be afraid to change if that’s what’s right for you.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Where Do You End Up as a DBA?

    I saw this question pop up on the forums: Where do senior DBAs land finally? It’s an interesting question, and for people that are searching for the next challenge, I would guess that they’re interested in an answer. Here’s what I think:

    There is no landing, senior or not. There are only stops along the path of your career.

    As you gain experience, and talent, you will have both more, and fewer, choices. If you expect to constantly gain salary, you will find that harder and harder over time. That’s the nature of any business. The best artist/athlete/programmer/whatever will reach a point where they can’t necessarily raise the market price for their services. The more you want to get paid, the fewer people that will afford you.

    If you look at money as a measure, you will be disappointed at some time. Not that money isn’t important, but I recommend you keep things in perspective. Money is important, but as you earn more, I would hope that value would start to diminish.

    At the same time, the challenges and opportunities at a job may matter to you. If you always want a harder problem to solve, a more complex system to manage, you’ll find the same limitations at some point. Fewer and fewer extremely complex (or very large) databases exist. You have less choice if this is important to you.

    Some people are restless and want to look for new opportunities on a regular basis, no matter what their situation. If that’s you, I would think you should consider consulting, either with a company or by yourself. Which you choose probably depends on your tolerance for the non-technical parts of a business, as your own consulting business will have lots of non-technical work to manage.

    Some people value stability, and if you value that highly, you’ll sacrifice some challenge and excitement. However stability is very relative these days, and you need to keep that in mind. You always work for yourself and no job is guaranteed for the rest of your career.

    I have moved back and forth from consulting to FTE, and like both, but I tend to value the co-workers I have and environment more than other things. I have to enjoy going to work. I find the DBA/developer job to be pretty much the same in most places, but my co-workers make the difference.

    It’s good to investigate and consider other options, but don’t think of this as the game of Life, with a few choices and an ending point. There are many paths, many directions to go. Some routes may cross, but many do not. You choose the one that matters to you, but don’t be afraid to cross to another one if you find yourself wanting.

    Where do you think Senior DBAs end up?

    Steve Jones

    The Voice of the DBA Podcast

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

  • Your Tools

    I was watching a few developers present recently and they made extensive use of tools to make their coding go very quickly. At one point in the presentation, after having shown a very efficient coding session, one of the developers stopped to answer a question. The question was about how the presenter managed to write code so quickly with so few keystrokes. The answer was with Resharper, but I was surprised when the developer went on to say he had purchased the tool himself a few times at different jobs because it was so valuable in hits work.

    He noted that even if an employer wouldn’t pay for them, there are some tools that are really worth buying. They make your job easier, and so much less stressful, they’re worth the investment. He pointed out that mechanics often buy their own tools, chefs buy their own knives, why shouldn’t we buy a few tools ourselves?

    I know early in my career I never would have purchased any tools if my employer wouldn’t. However I’ve matured, and I realize that there are benefits from tools that go beyond what my employer receives. I think that if I were to move to a design role, I’d have to use a tool like ErWin, or at least Visio, to do the job. Even if I had to purchase it. If I were doing T-SQL development, I’d get a copy of SQL Prompt and SQL Compare to make my life easier. If I were tuning code, I’d be sure Plan Explorer was on my machine, and I’d be really grateful to SQL Sentry that it was free.

    I know that many companies don’t like to add extra tools to their systems, but I know I’d find a way to argue that these tools are really essential for an efficient IT worker. At least on developers’ and administrators’ workstations. Without them, not only are we working inefficiently, but we’re also working under more stress and frustration than we should.

    Steve Jones

     

    The Voice of the DBA Podcast

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

  • SQL Injection, Still?

    It seems as though SQL Injection issues are still around. Attacks from SQL Injection are on the uptick as we begin moving through 2015. As noted in that piece, the constraints put on software developers usually mean that testing and security are the first things to let go when time becomes short. That’s sad, and in some sense, I think this means that we aren’t teaching secure coding early enough to developers, and certainly not often enough.

    I ran across a piece from Kevin Kline that asks why this keeps happening. After all, as Kevin shows, much SQL Injection is easy to prevent. The coding patterns and tools we use are simple to write. There are lots of articles out there that show a variety of techniques you can cut and paste into your code. However there are two big problems that prevent us from eradicating SQL Injection: aging code and bad habits.

    There’s no shortage of code that comes from frameworks and application templates, not to mention naive or ignorant developers. Lots of this code is vulnerable to SQL Injection. Since so many of these existing applications work, there is no great pressure to go back and change them to be more secure. Since data theft may not even be noticed, there are plenty of companies (and technologists) that have no idea their systems are vulnerable.

    The other problem is bad habits. Far too many developers and DBAs have spent years writing insecure code. When they prototype, mock, or quickly knock out code, they often rely on their experience to get work done quickly. And they do this poorly if they aren’t writing in a pattern that prevents SQL Injection. They haven’t updated their templates, tools, or their knowledge in a way that ensures all their future code will be secure.

    Ultimately we as an industry need to take SQL Injection seriously and write better code. Whether you use an ORM, a framework, or anything other shortcut to build applications, if you don’t create secure software, you’re part of the problem.

    Steve Jones

    The Voice of the DBA Podcast

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