Voice of the DBA

Tag: career2

  • There Are Always Constraints

    Many of us have spent years learning about technology. I suspect that many of you might enjoy these pieces I write, but you visit SQLServerCentral for the same reason I started building it: to become better at your jobs. Many of you work regularly to improve your ability to make SQL Server perform as well as possible.

    I’m also sure many of you have had to deal with what you see as “bad decisions” from your management at some point. I’m sure many of you have felt that if we did something a little differently, or spent a bit more money (or time), we could have built a better application. That may be true, though I’ve found over the years that technologists sometimes don’t make better decisions than project managers. We often have different priorities, but also different views on what success means.

    There are always constraints involved with building systems. The most successful technologists I know may gripe about constraints, but it’s a passing comment. They don’t get bogged down in the limitations that are imposed on them. They move forward, deal with the constraint, and make things happen. They get the software working or the system running.

    Like many things in life that may irritate us, and potentially hold us back, the limitations will always exist. We need to accept the lack of staff, money, time, or even technology and do the best with what’s available. It’s fine to disagree and complain, but don’t let that hold you back from making the best of the reality that you work within.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Presenting Data

    Many of us that develop or manage database systems are concerned with the actual bits and bytes that compromise data. However our clients and customers are more interested in the information, in gaining knowledge from the numbers, strings, and dates that are kept in our database tables.

    I really think that one of those things that can truly allow a developer or DBA to show their employer they are valuable to the organization. Employees prove this when they can retrieve information in a way that clients find valuable. Not that we, as the technical people value, but in the ways that clients find valuable.

    This doesn’t mean you need to learn PowerBI or PowerPivot or any other Power tools, but that you learn how to present the data you work with in the best way you can. Whether that’s in an SSRS report, an Excel worksheet you email around, or a complex visualization, all of these formats have one thing in common: a query. One of the best things you can do as a developer or DBA is ensure you can write efficient queries that assemble data from a variety of tables in different formats. Queries that retrieve data that can answer a question or reveal a pattern.

    Learning how to build a fancy visualization is great, but be flexible. If you get the opportunity, work with a new technology and develop some comfort, take it. However make sure that above everything else you can get the data sets to the end user. Clients can always use their own tools, but the efficiency and performance they experience will often come down to your query writing skills.

    Make sure you are constantly improving those skills.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Jump In

    The SQL Server community is amazing. We help, share, bond, and care for each other in a way that is very rare for a large, disparate set of technical professionals. I see and hear validation of this constantly from people that participate in their first SQL Saturday and are amazed by the experience.

    I think one of the amazing things about the #SQLFamily is that we do jump in and help each other. I rarely see the RTFM answers to questions, or ganging up by multiple people to pick on someone’s ignorance. In fact, I see the opposite. Most often the SQL community calls out and refuses to tolerate unprofessional behavior.

    This seems to be the prevailing view of so many in the community, and I’m not surprised to see John Morehouse call for even more people to jump in and help out. I certainly see plenty of people offering to support or mentor others that are new to writing or speaking, and I think we can do even more.

    All of you can share your knowledge. Whether through speaking, writing, even just providing more comments and thoughts on what others do. Many of you have lots of experience and thoughts that can help your colleagues get better at their jobs. Whether inside of your company, at events, user groups, or just with a note posted to a random SQL Server blog on the internet. Jump in, be polite and professional, and make someone else a better SQL Server professional.

    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. feed

     

  • Why Can’t We Code?

    Today’s editorial was originally published on June 8, 2011. It is being re-run because Steve is on vacation.

    I think that most of the developers or data professionals out there have been through a variety of types of interviews in their careers. You might have had technical interviews that asked you to write code, or maybe you’ve been quizzed on SQL Server trivia or asked to explain methods and properties. Maybe you’ve had interviews with managers that had you define a few database terms. Perhaps you’ve just had someone ask you the ten common interview questions without requiring you to demonstrate any technical knowledge.

    No matter what you’ve experienced, I think that many people would agree that the hiring process needs work. It does a poor job of actually predicting if the new employee can produce quality code or manage servers. Why is that?

    Many companies have really tried to solve this. From the famous “How would you move Mt. Fuji?” questions at Microsoft to the common CS type questions at Google. Joel Spolsky has his own guerilla guide, which I assume has worked well for him, though on a much smaller scale. I think, however, that for the most part no one has come up with a good way to solve this issue.

    A friend sent me this piece recently: Why the New Guy Can’t Code. It’s a little heavy handed, but there was one quote in there that I thought made sense: “don’t interview anyone who hasn’t accomplished anything. Ever.” It’s so easy to set up your own website, design a database on your personal machine, even put an app out for sale, that there’s no excuse not to make some effort to accomplish something. Craig Farrall talked about building something in Looking for Work in SQL Server, as did Brandie Tarvin in Changing Career Gears. It’s also one of the things I talk about at the Modern Resume: show people what you’ve done.

    I don’t know that we’ll ever find a fool proof way to hire great employees, but hiring people that have proven themselves in the past, and can point to something they’ve done, is good start.

    Steve Jones