Tag: career

  • Pluralsight for Another Year

    One of the ways that I try to keep current and learn is through Pluralsight. I’m lucky to get a subscription as a Data Platform MVP, but I’m sure Redgate would pay for one if I didn’t.

    My subscription ran out last week, but the support staff at Pluralsight was kind enough to renew me in minutes. Amazing service and greatly appreciated.

    If you haven’t tried online learning, I’d give it a go. Pluralsight has some great courses, but there are other choices as well. No matter what you choose, making some regular time to learn something fun, or improve those skills you use every day is a great way to keep your career moving forward.

  • Practice Until You Don’t Get It Wrong

    I wrote recently about a bad first day for an intern. He/she was fired, without cause in my opinion, when a production database was damaged while following a document for developer setup. The situation felt like a mistake, and one that wasn’t necessarily the fault of the individual. To me, this was extremely poor handling of the situation from a CTO.

    In the discussion for the piece, someone pointed out that it might not just be a new employee that makes a mistake that causes downtime. Certainly an unexperienced employee could have caused the issue, but I know there are people with lots of time in a position that make similar mistakes. It could be that someone that has been there a long time followed a poorly documented procedure, or applied the procedure to the wrong situation.

    In sports and the performance arts, I’ve heard a saying that says: amateurs practice until they get it right, but professionals practice until they don’t get it wrong. It’s the difference between just gaining a skill that you complete and continuing your learning to ensure that the execution of that skill is ingrained into your being. You internally build the muscle memory and skill to complete a task correctly over and over with practice.

    In the database world, this might be the difference between someone that has restored a database (the amateur) and someone that regularly practices restores of not only full database backups, but differentials and logs, tail log backups, filegroup restores, and more (the professional). The former has a skill, but the latter is confident and likely to complete the skill in a variety of situations without error.

    Practice won’t prevent mistakes, especially under pressure, but lots of practice does help us learn how to perform better. We learn what options are available, what issues might arise, and which choices we should be making. Just as professional athletes and musicians can make mistakes, we can as well. However, those mistakes should be rare. We should get most things right as the product of numerous hours of working deeply in, and understanding, our craft.

    Steve Jones

    The Voice of the DBA Podcast

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

  • The Pressure to Perform

    I’ve worked as a technical person for most of career. I’ve often been responsible for building or managing systems, and ensuring they operated according to some set of requirements. If things didn’t work, I’d have to fix them, but often there wasn’t the threat of losing employment unless I was grossly incompetent. If I made a strong effort, I’d get other another chance, or maybe be shuffled to work on some other application or system.

    Throughout my career, I have worked with various salespeople in different companies. Either they were my customers/clients or they were just co-workers. However, they operated under a different mindset. Most salespeople are expected to make a certain amount of sales in a time period, and if they don’t, they may be let go. In fact, in quite a few companies, a salesperson couldn’t miss their target more than two time periods in a row without finding themselves out of a job.

    I realize that sales isn’t like the creative work that developers do, or the tedious work of managing systems, but what if we were treated like salespeople? Do you think you’d want to work in an environment where you had some quantifiable measurement, such as uptime for a quarter, plus tickets closed, and if you couldn’t meet the goals, you’d be let go from your DBA position?

    Imagine if you were a developer. You might have the demand that you meet the expectations for delivery and you are held accountable for estimates within some amount of variance. Perhaps as a developer there would be a requirement to complete xx amount of stories in some time period. I don’t this would work well. I think we’d try to make longer estimates and more granular stories to better define out work, but I’d also expect the business might press back and put more pressure on us.

    In plenty of organizations, there are these pressures. I certainly see developers working harder to get things done, not because of the threat of their job, but because many of us that choose technical work feel a sense of pride and responsibility in the work we do. We work long hours to meet deadlines, sometimes because we’re afraid not to, but usually we do want to complete our projects in the best way we can.

    I think we’d all be worse if we were treated like salespeople, and likely many of us would have more job changes. I also think our organizations would suffer more, with higher turnover and a lack of detailed institutional knowledge among those that build systems. Certainly some high performers might thrive, especially if we received large bonuses, like salespeople often do, but I also think we’d find shoddier work overall, with applications even more cobbled together with patches and prayers, with the hopes that our workload doesn’t overwhelm our systems.

    I know I wouldn’t like working in that type of environment, and why I’m not sure I’d ever want to go into any sales role.

    Steve Jones

     

  • In a basement, a long, long time ago… #tsql2sday

    It’s T-SQL Tuesday time and this is a good one. Read the invitation and proceed.

    Who Influenced Me?

    I’ve been working SQL Server for a long time. Since 1991, in fact, and had held 4 jobs as a DBA or developer by 1999. I was comfortable with the platform, and had actually published some articles in early 1999 for a small UK journal. My career was going well and I felt very comfortable with the platform (v6.5 in my company) at that time.

    As a developer, I knew T-SQL well, and was still learning things from reading articles, but there weren’t many SQL problems I couldn’t come up with some solution for. As a DBA, I knew the tricks to keeping a large, busy instance running, including the DR tricks to ensure my restores worked well on new hardware.

    I was lucky enough to get my company to fund a trip to the initial PASS Summit. I went, along with my wife and infant son, to visit Chicago. We went to Comiskey Park on the last ,day of the baseball season, braving chilly weather along with about 1,500 people to watch the White Sox. I’m not sure my wife has been to a game since…

    In any case, my main memory of that event was being the basement of some hotel in downtown Chicago. There were a few rooms in use, and we packed into see sessions on various topics. One was delivered by Kalen Delaney, @sqlqueen, who was perhaps the person I saw as an amazing speaker and teacher. I’d read her Inside SQL Server 7.0 book, anticipating an upgrade. I was delighted to see her speak, and perhaps more thrilled to shake her hand and get an answer to a question.

    That was quite a highlight in my career.

    Since then I’ve seen Kalen speak many time, and we’ve become friends. I’m always glad to get a hug and a few words with her, but each time, I remember that early, semi-awestruck time when I met her.

    She’s inspired me, both as a data professional and a teacher.

    If you ever get the chance to meet Kalen, take a moment or two with her. You won’t regret making the effort to introduce yourself and ask a question. I know I haven’t.