Voice of the DBA

Tag: career

  • Gigging for a Career

    There are some people that like working for an organization, sacrificing some compensation and flexibility for stability and security. Others enjoy the chance to experience constantly changing environments and a rich variety of projects at the expense of regularly searching for new work. Neither is necessarily better or worse than the other, and these aren’t polar opposites. In the real world, each includes some of the advantages and disadvantages of the other.

    For many of us that work with data, we realize there are some advantages to understanding the business meanings and implications of the information derived from data. Indeed, those that tend to work with the same types of data become fluent and comfortable manipulating and discussing how analysis, transformation, and more relate to that type of data. This leads me to think that someone that works for a company or stays within a particular industry might be preferred as a data professional for organizations in that space. Maybe this is someone that an organization wants to hire and retain over time.

    I ran across a piece that discusses the Gig Economy from the perspective of data professionals. Their view is that many data professionals would rather work on interesting projects, and analyze data that is interesting to them, rather than being stuck with a single organization. Certainly from the organization’s view, having very skilled professionals available for project work means less costs in training, benefits, hiring, etc. While the cost per day might be high, there is no need for an ongoing, or at least not a constant, commitment.

    I do think that many of the changes in technology have made it possible for talented workers to find plenty to keep them busy and earn a very good living. However, there’s a cost in spending time looking for projects on a regular basis. It takes not only time, but mental strength and a desire to be a bit of a salesperson and marketing professional. Some people may find long term clients that call them over and over, which isn’t that different from working for an organization unless you can interleave a number of clients together on a regular basis. However, most people that work at “gigs” are regularly spending time looking for work.

    I would postulate that most of us prefer some amount of security and stability, preferring to work for an organization for a period of time. While we may change jobs at times, it’s often at a lower pace than those that might prefer to work in the Gig Economy

    Steve Jones

    The Voice of the DBA Podcast

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

  • Teaching Quickly

    I’m a constant learner. I try to regularly experiment and try new things at work and in the rest of my life. For work, sometimes this means working outside of the other hours and commitments I have to get better at manipulating data. Sometimes I go deep and sometimes I just want the general gist of how to solve a problem I’m having. Time constraints come into play at times because there’s never enough. Even with limited time, I do want to understand the reasons why things work, or why I should make a choice for some function/method/framework/pattern/etc.

    I’ve been working with R a bit this summer, trying to learn a bit more. I’ve tried tryr.codeschool.com as a guided tour, but sometimes it doesn’t help me understand enough of the details. Even as I experiment, I’m going through the motions. I purchased R in a Nutshell, and just got Stephanie Locke’s Working with R. I’m hoping these books will give me a more thorough grounding in R.

    As I’m learning, I always want to ensure I understand the implications of how I may write scripts. What do my choices mean for quality, performance, etc. Sometimes trying to understand why slows me down, and I don’t get much done. That’s fine, and maybe that’s for the better. However, I don’t want to learn slowly by going through all the pain that someone else went through. I want to know how someone would write code today, and why they do so.

    I ran across this post on learning the hard way. It discusses the way some people try to teach others, and I’ve been through some of this as I’ve tried to learn various technologies. The teacher sometimes wants to assume I am going through their pain and can sympathize, but often I’m learning something new for the first time. I’m sure I’ve been guilty of this as well, perhaps trying to level set or show an old (or poor) practice to emphasize why it’s better to write code in a new way.

    The thing is that my time is precious, and I shouldn’t have to work through the mess of the way things used to work to build good habits today. What’s new to someone might not be new to all, and certainly at some point, all code isn’t new anymore. I’d rather teachers, and me, sometimes focus on giving us good habits today. Teach us the right way now, and spend time on error handling, testing, or other good habits. Certainly there are cases where we need to know about the changes to systems, but explain this is an upgrade section. And then tell me what’s different, don’t wax nostalgic on the way you once were forced to find innovative solutions.

    Steve Jones

    The Voice of the DBA Podcast

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

  • Get-DbaPowerShell

    When I first saw PowerShell, at TechEd 2006 (ish) and I was enamored. This was a much better environment than VBScript for working in a shell. Then I realized I needed -eq, -gt, etc. and was less excited. These language elements felt like a step back. Then I tried to build a restore script for SQL Server databases early on and was much less excited.

    Across the years, I’ve played with various tasks in PoSh as opposed to T-SQL or simple command scripts in various languages, and I find myself going back and forth. PoSh is very useful in some ways, more cumbersome in others, and I still am not sure exactly how I feel about it as a go-to tool. I am coming around to use more PoSh because of the dbatools project, and I find myself considering PoSh instead of T-SQL, especially when I think I may want to work across instances and string together commands.

    I was quite excited recently by T-SQL Tuesday #94, hosted by Rob Sewell. The topic was PoSh, and quite a few people participated, as you can see from the Get-PostRoundup. There are some creative uses of PoSh, such as importing Excel data, administering SSRS, turning Azure VMs off, cleaning up orphaned files, and more. Personally, once you start to use Azure more, PoSh makes the portal seem cumbersome and slow, and I find that for recurring tasks, it’s a much better tool.

    Recently I saw the DBAfromtheCold write a short piece on why you should learn PoSh. It’s a good look at some of the tasks that are easy through PowerShell. Some of these could be done in T-SQL, some with other scripts, but PoSh certainly is a possibility and an easy way to manage some of the tasks you might need to do at scale.

    I don’t think PoSh is the best way to do everything. In fact, I often still lean on T-SQL for many admin things, especially if I already have a connection open in SSMS. However, as I learn more about PoSh and how to use it, I can make those judgment calls about when it’s a better fit. That knowledge helps me become a more capable and stronger data professional, because I have choices about how to work with systems, and I have some knowledge or basis for the decisions I make.

    I advocate continuing to learn throughout your career, and certainly including PoSh as a topic if you work on the Microsoft platforms.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Flash DBA

    The job as a DBA is the job. That’s been my view for a long time, which is why I am always concerned about the staff when I interview. The people I work with make the job good or bad. I can always handle the job, which is often very similar in many organizations. I might do more tuning in one place, or more infrastructure management in another, write more reports than the last gig, but the skills and techniques are very similar in many positions.

    I have also found at some, maybe many, companies there isn’t always a full time need for a DBA, or architect, modeler, etc. Instead, there are periodic ongoing needs for those skills. At one position, I was negotiating a deal to only be employed 3 days a week, planning on spending the other two at another company consulting. I was about ready to implement my plan when the first company lost funding and went out of business. Since then, most companies haven’t entertained the idea, even when there wasn’t necessarily a full time need for a DBA position.

    I thought back to that job when I read this piece on flash organizations, where the idea is to bring people together for a project or (relatively) short period of time to do some work. I have seen similar project teams in larger organizations, but those teams are limited to the talent within the company. A Flash team would bring contractors together for a project, perhaps with employees. Certainly consultants or contractors are sometimes used today, but they often aren’t seen as part of the “team”, or at least, they aren’t treated that way. That disparate treatment often means that there aren’t necessarily shared goals or the same focus among everyone in the team.

    If you’d asked me to consider flash teams a decade ago, I wouldn’t have thought that we had the management maturity to accept outside help for many types of work. However, the advent of cloud services (and more adoption than I would have thought), along with the use of pull requests and agile development services have me wondering if this might not be the type of things we see more often, especially for software. I could even see this for specialized skills, such as data science and ML model training.

    I do think that this type of work is harder for data professionals to walk into, since intimate knowledge of the meaning of data fields and their relationships is important. Coming up to speed on the way a business uses data can be easy when you start,but there are often edge cases and the complex ways in which business people often use data takes more time. I would expect time spent as a flash data professional would be front loaded in trying to gain an understanding of the environment. However, perhaps that would mean that there would be better documentation for future projects. Maybe even an ER diagram or two that actually matched the database system.

    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.