Voice of the DBA

Tag: career

  • Choosing a Career

    This was a short week in the US with the Thanksgiving holiday. This is a time when many people in the US have a long holiday weekend and often get together with family for some time away from work. It’s also a tradition for many people to “give thanks” to the blessings and people in their life. It’s a good time to reflect and appreciate the things that go well for you.

    That doesn’t mean that many, or even most, of us aren’t looking to grow our careers. For some of us, that may mean moving into a new field. Is that a good decision? Will we like the day to day work? Those are tough questions, and while you might be enamored with some technology as a hobby, when you do the work every day, things aren’t always the same. I’ve certainly seen this with friends and colleagues that have dramatically changed the lives into a completely new field. What is fun a few hours a week may not be as interesting when it’s a 40-50 hour a week grind.

    At SQLServerCentral, we often see posts where a community member asks if they should learn x or y. Should they move into a new career, or what’s it like working as a person that does z? Those are good questions, and I ran across a nice blog post from Dev Nambi on what it’s like being a data scientist. If you’re interested in data science, this is a nice list of notes about his job, but even if you were thinking about becoming an HA specialist, or Power BI report writer, or something else, the post talks about things that make impressions with his job. I’d like to hear more about how others would answer some of these questions about their own work. I need to do some of this myself.

    There are also a few very good items that I wanted to highlight. First, Dev notes that you don’t learn everything in school and there is more to work than is learned in school. That being said, there are core concepts to understand. I think this is true in most fields. We need some good base knowledge, but there is more than that knowledge. We need to learn how to put concepts and requirements together, as well as continue to ask good probing questions about the task.

    The other item that is pointed out a few ways is teamwork. Communication skills, including body language and humor, are important. We are social creatures and while I think having a variety of skills, views, and ideas is important, we need to get along with each other. We need teamwork within an organization, but for our careers, we also need a team of people to help us. That’s our network. Those skills are important for all of us, no matter what the job.

    If you want to move into a new role and grow your career, you have options. You can use schooling, you can try to grow in your role, or you can learn things on your own and apply for new positions. They all work, but they all have some drawbacks as well. They also all require effort and motivation, so if you want to make a change, set some learning goals, and start working. Making strides in a direction will help you grow and get you closer to your goals.

    Steve Jones

  • The Data Scribe

    There’s an interesting piece in the New Yorker about technology in the medical field from Atul Gawande. It talks about the love hate relationship doctors have with medical systems, and ruminates a bit about whether these new systems are making medicine better or worse. I think Dr. Gawande is a very interesting individual, and whose Checklist Manifesto is a great look at improving processes.

    The article talks about the struggles of doctors with using various systems, but there is one interesting solution that some companies have tried: medical scribes. For these companies, rather than teach a doctor everything and have them do their own work and spend less time with a patient, the meetings are either recorded or witnessed by a scribe. The scribe handles the computer work, writing down observations, notes, orders, etc. The doctor later approves things, but this allows the doctor to focus more on patient care and get less caught up in technology.

    Years ago I worked in a company that had some extensive technology in some areas, but some older senior management. There were still secretaries that literally took dictation, handled schedules, and printed reports for the senior executives, who almost never used their computers. The might pull up some emails, but anything that required more than a few keystrokes was dictated to a secretary who wrote and sent the emails. At the time I thought this was wasteful, after all, couldn’t an executive type a few emails themselves?

    I thought of that experience while reading the other story about doctors. Certainly the executives could type emails, but not as well as others, and was that a good use of their time? Certainly today, with far too much communication being sent, I might argue executives ought to have less access to email, not more. Certainly upper level execs do have assistants, but is it really a good use of time for directors and managers to be dealing with many of our computer applications?

    What about report tools like Power BI and Tableau? Is that a good use of anyone’s time in finding data and assembling it into reports? The analysis is, but tracking down data, formatting it, and more feels like something that is a skill in and of itself.

    Perhaps we need data scribes in more industries. Not a single employee dedicated to one person, but a specialist in the gathering and cleaning of data, preparing it in tools that business people then use to perform their analysis, working for multiple people. Need more data? Ping your data scribe, someone that knows the structure, meaning, and location of data.

    Would you want that job? I know I’ve done this at times for people, finding the data they need and producing a report, often showing them how to do it themselves, but I wonder if that’s a good idea. With data changing, new sources appearing, stronger access controls and more, perhaps this is a role that more companies ought to embrace to ensure that those with experience analyzing data aren’t spending time fiddling with it.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Fundamentals

    Volleyball season is approaching. Practice started last week for the team that I’m coaching this year, and I’m excited. I look forward to teaching and competing with a new group of athletes each year. I’ll also look forward to a more regular schedule and a bit less traveling for a few months.

    In preparation for this season, I’ve been doing some learning, some reading and watching, trying to improve my abilities, something I’ve done for a few years. One of the books I completed recently was one on John Wooden and called Wooden: A Coaches Life. This was a look at his life, as player and coach, with some of the descriptions and principles that embodied his work as a college basketball coach.

    There were interesting stories and topics in the book, but one of the core items emphasized in the book was Coach Wooden’s emphasis on the fundamentals of the game. He stressed this with his players, asking them to work on the basics and perfect them more than on any complex plays or situations. I tend to focus on the basics when I coach as well, hoping to train players to be good at their jobs, trusting them to react to new situations.

    This feels like advice that is applicable to a data professional as well, especially in the era of new features and functions that continually expand on the capabilities of the Microsoft data platform. While graph structures and containers and Azure Data Factory and Big Data Clusters are amazing new technologies, there is still a need to have good, solid fundamental skills for a SQL Server system. We still expect anyone working in those areas knows how to backup a database, how to write good T-SQL, how to set security for objects, and more.

    If you want to specialize, that’s great. Perhaps you love BI or HA or some other aspect of working with the SQL Server data platform. Just keep in mind that the fundamentals are important, no matter what your job. You ought to be very competent at handling any of those tasks that we would teach a junior DBA in their first year on the job. Once you know those, you can move on to more specific items. If you don’t know those, be sure you include those as part of your learning along with more niche topics.

    Steve Jones

    The Voice of the DBA Podcast

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

  • T-SQL Tuesday #108

    tsqltuesdayIt’s that time of month, and this is a good topic as it relates to career learning. I’m a big fan of improving your career, so I like this topic. The invitation is from Mala, one of the people I look forward to seeing each year at various events.

    Non SQL Server Tech

    At heart, I’m something of a data person, though I dabble in various other technologies at times. This year, I made it a point to work on learning two new technologies, one of which was outside of SQL Server. Python was what I chose and I ended up spending some time on various Python courses for about 5 months. Then life and work got in the way.

    I still want to spend a bit more time on Python, but I also recognize that I need a new challenge, so I’m going to pick something else for 2019. For me, this will be CosmosDB.

    I think CosmosDB is a neat technology and has some really good things inside of it, but I really don’t know enough about it. I’ve had minor exposure to NoSQL structures, but not really enough to know how well I’d use them for a project.

    The Plan

    For 2019, or at least for the first quarter(ish), I want to port a database from SQL Server to CosmosDB and play with the differences. I have a few sample ones, but I’ve been compiling a database of some SQL Saturday data and want to use that as a test. I’ll work on moving the data to the different CosmosDB structures, likely a document structure and a graph structure, and gain some experience as to how these work.

    I hope to build a simple REST website that accesses these databases, which should also let me compare the differences for data access and note where one structure might work better than the other.

    I’ll set a reminder for the end of each month in 2019 (Jan-Apr) to evaluate where I am.