Category: Editorial

  • The Best Career Advice

    I don’t know that I have the best advice, but this month’s T-SQL Tuesday is asking for people to share what they think is the best advice they’ve been given or have for you. I wrote my own piece, where I noted that learning to say “No” was one of the best things I’ve ever done. Not that I say no to everything, but I do default to no, especially when someone asks for me to tackle something new.

    Actually, it’s slightly more nuanced than that. As I’ve gotten used to my workload, I will say yes to things, and certainly, I’m more likely to commit to one-off things. It’s the longer-term, larger things that I don’t want to agree to do unless I’m sure I can deliver.

    There are lots of other things people wrote. Deb said that you should trust your instincts and realize you can contribute, even if you’re new. Hugo notes the user is often right. Mala is more cautious with work and practices discretion. Rob got the advice to take it slow, learn his job, and figure out what he likes and doesn’t.

    There are lots of other advice, from Pragati telling you to get a mentor to Mikey saying you should find a job you love. If you check out the comments in the invitation above, you’ll see plenty more responses, many with interesting back stories and more details. If you only read through one set of T-SQL Tuesday responses, this might be the one to pick.

    I’m a big fan of actively managing your career. Make the decisions that move in the direction that matters to you. As noted in a few posts, we spend a lot of our lives at work. At times more than we spend with family, so be sure you have a career you enjoy.

    This takes work, but it’s an investment that can repay itself over many years. Both in financial rewards and less stress on a regular basis. Every job is a job some days, but when you enjoy your work, it doesn’t feel like work.

    Steve Jones

  • Highly Skilled

    The world of work has been changing quite a bit over the last few years. The pandemic appeared to be a boon to technology workers, both by allowing us to work remotely, but also taking advantage of our skills to deploy more technology throughout the world. At the same time, late 2022 and 2023 have seen many companies pull back and cut their staff, including technical staff. It seems that in mid-2023, we have both a demand for technology workers and a lot of people looking for technology jobs.

    A recent 2022 report on working in technology has some interesting insights. It is summarized at ZDNet, but you can see the original report here. The highlights from the report are that quite a few top performers left their jobs, recruitment doesn’t work well, and finding top talent is hard. These aren’t that surprising to many of us that actually write code or manage systems, but it is nice to see that founders and executives are reporting this (they were the ones surveyed in the report).

    For much of my career, I do think many executives have taken advantage of tech workers, pressing them to get more and more done with fewer resources. Even though many people were paid well (though not all), they may not have enjoyed their jobs. I’ve had a lot of great positions, but over the years, I’ve met a surprising number of people who wouldn’t recommend others follow them into their career choice.

    The pandemic made it easier for people to switch jobs since everyone was remote. That might not have benefitted lots of people, but it certainly helped top talent. If you’re one of those people, you likely got a better job, with better compensation, and hopefully, more interesting work to you.

    For others, we might still be looking for something new (or worried about the security of our current position). One of the main parts of the report talks about the problems with the traditional recruitment model. First, it takes too long, an average of 4 months to fill technical roles. There is pressure to speed that up, while also understanding that candidates will need some training and re-skilling or up-skilling to meet an organization’s particular needs. That would seem to be good for many candidates, but I think this report is biased to startups and newer organizations, not mature ones.

    I do think the impressions you make early are important. A candidate needs to ensure that they have technical skills. You should be able to solve problems but also think on your feet. Respond to the interviewer and showcase critical thinking. A developer should be able to answer general questions, like how to find duplicates in a table or sort data that is aggregated. You don’t need to solve all of Itzik’s query problems, but you ought to know some of them. I’d expect you to know the basics of this job. If you’re unsure, post a note on the forums and ask people what things they need to know to do their jobs.

    However, apart from the technical skills, you need good soft skills. A strong candidate will communicate well, display confidence, relate to the interview(ers), and build some rapport. They will look to ask questions that seek more information about what is asked, but without being confrontational or disagreeable. There’s a skill to debating a point rather than arguing with someone. The ability to get along with others and find synergy is important. When others think adding you to the team makes the entire team better, you stand a good chance of getting an offer.

    If you’re unsure of whether you present a good impression, get a few friends or co-workers to interview you and give you honest feedback. Maybe even ask a friend who hires people to mock interview for a position. Learning to present a better impression will go a long way toward increasing your chances of getting hired. Especially if firms are trying to make quicker decisions.

    Maybe the big change from the report is 80% of people surveyed say they are willing hire someone without a college degree. Whether they actually would to that, whether their HR or other policies allow this, and whether they convince existing employees to do this remains to be seen. However, many of us know that a college degree isn’t a good predictor of whether someone can do any job well. I hope future hiring trends confirm that.

    Steve Jones

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

  • Actively Choosing Compatibility

    SQL Server databases have had a compatibility level for a long time. This is a setting that enables the database to process code as if it were a particular version. The levels go from 80 (SQL Server 2000) to 160 (SQL Server 2022). Each time (almost) a new version of SQL Server has been released, there has been a new compatibility level.

    However, not all versions can support all compatibility levels. For example, my SQL 2022 instance can support levels back to 100 (SQL Server 2008). If I wanted to get a database to act like a version older than 2008, for example, 2005, I would need to install a SQL Server 2012 or older instance. There is a table of engine versions and supported compatibility levels on the ALTER DATABASE Docs page.

    When you create a new database, by default, it is at the current compatibility level. However, if you upgrade a database, the level might not change. There are some limits to which versions are supported, so an upgrade might change your database.

    An administrator might choose to keep an older level for compatibility purposes. Perhaps your code has an identifier that is now a keyword. Perhaps you expect some code to behave a certain way. However, not all changes are protected by the compatibility level. Most of the time, an administrator must manually change this, which is something that can slip through the cracks. If you don’t change this right away, likely it isn’t going to change.

    There was an interesting post from Brent Ozar recently that explained a bit about compatibility levels in a SQL Server database. I wonder how many people actually actively choose a level or they just accept the default level for that instance. Brent gives some advice in the post, and his recommendations vary a bit, depending on whether you are happy with the system or not. He also recommends measuring your system and then evaluating a change. Especially if this is a database for vendor software.

    I don’t think changing or updating this setting is a priority, but I also think that being aware of when your level doesn’t match the instance and documenting this is important. At some point, through many upgrades, you might find your level isn’t supported any longer. Then your database might have immediate issues. A good monitoring system can let you know when you have mismatches that can be evaluated when there is extra time to clean up or test changes to the system.

    Each version of SQL Server adds new features, like the changes for Intelligent Query Processing. In general, we want to take advantage of these if we can. However, not all workloads respond positively, so as Brent mentions, you need to test and evaluate your workload. Hopefully, you have a clear “things are better” or “things are worse” when changing levels. When you get some queries that perform better and some worse, then you have some choices to make. Often the default is “do nothing,” which may or may not be the best decision, but the devil you know is sometimes easier to deal with than the one you don’t know.

    That’s fine but consciously make that choice. Keep an eye on your system and don’t just accept defaults, whether those are from Microsoft or the ones you’ve left after an upgrade. Actively manage your systems to get the best performance you can for clients.

    Steve Jones

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

  • What’s Your Job?

    There are a lot of technology people looking for jobs these days, especially after all the layoffs that have occurred in 2023. At the same time, I have a number of friends and clients that are struggling to hire qualified people. They get lots of candidates, but they are dismayed at how little the candidates they interview seem to know, or at least how little candidates know in the areas that their organization has needs.

    Today, I want to help people get better at growing and managing their careers. Therefore I’m asking those of you that are employed to describe your job. Give us your title in the comments and then list 5-10 things that you’ve done lately. What types of queries have you written? What tasks did you complete with SQL Server or Azure SQL? Have you needed to research something to solve a problem? What knowledge or concepts helped you complete a task?

    The idea is to share some of the skills or concepts a person should have to grow their career. Hopefully, some people will then read descriptions and build skills from this list. They’ll try to accomplish the tasks you’ve had to finish, hopefully documenting or blogging about their work.

    As an example, I’ll give a few tech things I’ve seen lately from clients. These are practical things someone needed to finish, or something they asked someone else to do.

    I was working with a client and there was a need to find all the logins whose passwords were not set to expire. How can you do that?

    Another had a table had a lot of duplicate data, and all duplicates but the row with the latest date needed to be deleted. What does the DELETE statement look like? Caveat, what if I need to update all but the first row (newest) with a new value in some column to mark them as inactive?

    A client needed to get a list of all the servers from their central management server (CMS) and then extract that list as a CSV file. They were using this for some audit purposes.

    At another client, a developer needed to clone a git repository and then open the .sql files in Azure Data Studio. Can you show how to do this?

    A DBA wanted to decide whether you choose a clustered or non-clustered index for a table that contains sales information and is often queried for a few rows based on a date. Why would one index be better than the other?

    Don’t answer these questions, as this is homework for others. However, if you could share a list of things you would expect your new coworker to know or solve, that will help us raise the bar for what we expect from our colleagues.

    Steve Jones

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