Voice of the DBA

Tag: career

  • What Do You Want to Learn?

    There are lots of resources for learning: articles at SQL Server Central, blogs, user groups, SQL Saturday and other events, conferences, and more. In most of those cases, the editor, author, or speaker is deciding what they want to write about. If you want to learn something different, you need to go search out that information. You can certainly request topics from others, but they may or may not listen to you.

    At least not as an individual.

    Steve Rezhener put together a survey for what topics you’d like to learn about. A few others, including myself, gave him feedback and he’s published this for people to use. It was intended for SQL Saturday organizers and speakers, but it can work well for anyone producing information. I’ve created some shortlinks at SQL Saturday that you can use to take the survey and see the results.

    This is open-ended, and none of the items are required. It’s long, but just answer the items you care about. While it does ask for places you’d attend events, you can answer or leave this blank. I love surveys like this one, since I can pick and choose and don’t have to answer every question.

    I plan on analyzing this data every month or so and publishing a report, which helps me decide what to request or publish here, but also which topics I might speak on in the future or what I might plan a SQL Saturday around. I would love to see more niche events, especially virtual ones. If some of you out there want to be an MVP, run a virtual event on your niche topic. Ping me and I’ll help you get going.

    The results of a survey like this might also help you decide where you should drive your career. If a lot of people are interested in something, likely it’s relevant to their jobs. Perhaps you ought to follow the crowd a bit if you aren’t sure what things might bring opportunities for you in the future.

    If you’d like to see more topics or different choices, drop Steve a note and I’m sure he can add to the form.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Poor Database Design Realities

    One of the interesting things that I see at Redgate Software is how idealistic our developers and engineers can be. They often build our database DevOps products with the idea that customers will use well-designed databases. The systems will have primary keys, foreign keys, defaults, constraints, indexes, and more. Developers will use coding standards, and naming conventions, and will understand what data is stored in tables. Not in every case, but often.

    After all, that’s how we build software at Redgate, as teams, sharing information, publishing documentation for others, and following best practices.

    It’s cute and endearing, and unfortunately, not often true. In most cases, I find databases built by developers, accidental DBAs, or even experienced DBAs to be full of inconsistencies, lacking constraints and keys, and even duplicating some indexes and forgetting others. I often joke during one of my presentations that the main thing people should learn is to add primary keys to their tables. However, I’m not really joking.

    During a recent design session on our masking technologies, there was a discussion on masking data in tables without PKs, which is a challenge. We’re working on it, and also on being able to mask PKs themselves, as some people use the PII data as a PK. This could be a tax ID of some sort, but could also be an email address.

    When one of our account executives (Rob Boswell) heard that we were enhancing our capabilities with regards to PKs, he joked that we will soon be “primary key agnostic.”  It was a great line, and in one sense it’s true. In another, it’s sad that we need to design tooling around such poor practices.

    The reality of the world is there is a lot of bad design, bad architecture, and bad code out there. I applaud those who work to improve things in their environment, am saddened by those who don’t (either improve code or their skills), and frustrated by management not supporting efforts to be better. At the very least they should support efforts to teach your staff to code things right the first time, which helps improve future code. The next best thing is to refactor and improve older code, which can help you spend less in the cloud, or run longer with the resources you have on-premises.

    The reality is the reality we are in, but that doesn’t always need to be our future reality. We can change the future, each of us, by learning to write better code and improve how we approach our work tomorrow.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Life in a Startup

    I have worked for a few startup companies, including SQL Server Central. Each has been a different experience, and I learned a lot at each stop. However, I’m not sure I’d want to go through that process again at my age. I was thinking about the challenges and the excitement of being at a startup while reading about the founding of Reddit. The post doesn’t go a lot into the technical details or the working life, but it is an interesting read from a VC investor.

    I also found this post on Choosing Startup Life, which talks about what the author thinks about before trying to start a company. He compares this with life in a Big Tech company, which relates to lots of companies, in technology or not. The main differences are lower salaries, less infrastructure, lots of work, and upside in a startup. Big companies have higher salaries and more perks, less stress and responsibility, and not a lot of context-switching. In general, that’s been true in my experience, though in bigger companies that didn’t think they were software companies, I sometimes could end up with a lot of context-switching.

    When you work in a startup, I hope you have some passion or belief in what the company is building. I think that’s what drives a lot of Kickstarter/Indiegogo projects. Someone wants to start a business to do x and they believe in x. It’s important to do that since you are likely to need to work extra hours. Startups often are cash-strapped, so they don’t have a lot of services and infrastructure and depend on employees to work above and beyond their main job. They also are in a hurry to get cash, so they want to complete their work sooner, which means more hours per week. Not all are like this, and once there is some investment capital, hours can ease a bit, but investors want their return, so this isn’t a slow-paced, relaxed atmosphere.

    There isn’t a lot of security. I’ve had startups fail under me where we didn’t have enough money to make payroll. I’ve had them sold in an instant with the new owner deciding to drastically change the employment status for many people. At the same time, I’ve had some jobs that result in unexpected windfalls of money. I haven’t had a company go public yet, but perhaps that will happen at some point.

    I think about being in a startup like being in my first apartment in college. Nothing is provided, I don’t even know what I’m missing until I look for it, I keep long hours there, and everyone is responsible for everything. There are also a lot of arguments over who should/needs to/ought to do what.

    Is it worth it? I think that the chances of a startup becoming a success can vary. It is important to understand valuations if you are trading away hours of your life on a gamble you’ll make money. Keep an eye on the number of shares offered and the potential value they would have to reach to make a difference in your life. For that matter, make sure you know what a pile of money means for your life. USD$100,000 sounds like a lot if you got a check tomorrow, but how much would that change your life?

    If you decide to create a company and take outside investment, make sure you really understand finances.

    Startups are exciting, but make sure you like the people working around you. You’ll spend a lot of time with them, and if you don’t enjoy their company, you won’t enjoy your job. Startup life isn’t for everyone, but it can be an exciting chapter in your life.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • The Costs and Rewards of Speaking

    Most of the people I know who speak at a SQL Saturday or user group aren’t paid for their efforts. At many of the community events, the speakers are volunteering their time. Many are also paying for their own way to those events not located in their area. A few, such as me, might get a company to cover their travel expenses, but often this doesn’t include time. If I attend a SQL Saturday, I still have a bunch of work on M-F that needs to be done. No comp time for these events. That being said, I’m happy to donate some time and money to community events.

    Some speakers build and teach full-day sessions, usually called pre-conference sessions, for which they are paid. There can be competition at large events like the PASS Data Community Summit and SQL Bits to get a session since the payment can be rewarding. I’ve seen some speakers make USD$1k or so, which can cover travel expenses, and others make over USD$10k, which is a nice payday.

    Most of us don’t want to teach a full day of sessions, usually because it’s a lot of work to build a day of training. It’s also very nerve-wracking to try and teach people who have paid you. A lot of speakers don’t really want to deal with that stress. I’ve done it, and it is hard work. I don’t deliver pre-cons at events because I get expenses covered at lots of events and prefer not to compete with others who might want to earn some money while growing their careers.

    However, lots of people want to share their knowledge and teach others something useful. It’s been amazing to me how many people have stepped up to submit sessions and present them at events all over the world. I’ve been lucky and honored to meet many of these volunteers and call them friends.

    When Andy, Brian, and I started SQL Saturday, we weren’t sure there would be enough speakers to run 10 events in a year in 10 cities. At the time, the PASS Summit and a few other conferences were the only places to speak outside of user groups and we weren’t sure there would actually be enough people in a community willing to speak to run a conference. We also weren’t sure that many people would travel outside their home area to speak.

    I’m thrilled we were wrong. So many people have volunteered their time and energy to build a session and then deliver it at user groups and local events that there are often more speakers than spaces available for them. I’m also glad that so many of you attend and support local events.

    Speaking can be intimidating, but I know many of you can do it. It’s scary, and it’s something I never thought I’d do when I left university. It is a lot of work, it interrupts your free time, and it doesn’t pay you any hard currency after a session. However, it’s also thrilling to help others, exciting to have them listen to you, it hones your communication skills, and it is impressive to employers. On balance, I’d say that even delivering a presentation at your local user group is a profitable endeavor and a memorable experience.

    I hope we continue to see more of you willing to deliver a session for your peers, share some of your knowledge. I also hope that we see more of you stepping up to help organize a SQL Saturday or another local event in your community.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.