Tag: career

I wrote a post about Git recently since I’ve found far too many people who didn’t know Git well (or at all) and they seemed hesitant to experiment and learn.

Is this because of being too busy? Do we have so many people who are working in tech where “it’s just a job” and not because they enjoy technology? Or has management in too many places beaten people down to the point they don’t want to try things? Perhaps your coworkers are resistant to change (or lazy) and you don’t want to discuss new ideas with them.

In working with software and databases, I marvel at all the ways in which we can mold and change the system to match the creative ideas we come up with. I’m pleasantly surprised when someone solves the same problem I do, but in a very different way. Even using the same language/tools/frameworks, we can often come up with a variety of solutions that work well. I think we teach each other something when we compare disparate solutions.

When I was learning about computers, we were encouraged to experiment. Those who were willing to try things and learn from them were often more excited by the task, and I think these were often those who went on to successful careers. I’ve found the people who don’t like to experiment or try something new, even when there is no risk, are often limited in both their accomplishments and opportunities.

I don’t expect those who enjoy experimenting with technology to work more than others. I’d prefer that everyone have a balanced life that separates time at work from personal time, and limits the investment in your skills to a reasonable level. Live and enjoy your life outside of technology, but when you do work, make an effort to do your best work, while working to improve what “best” is for you.

Try something new this week. Solve a problem, use a new tool, read about new technology, and write a little code. It’s good for you.

Steve Jones

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

Redgate released the results of their State of Database Landscape recently, and I was part of a webinar where Beca Parker, Ryan Booz, and I discussed the results. As we were talking, one of the things that struck me was the high number of people who had picked skills as being a challenge for their organization. In a single environment, skillset requirements and training were the number one challenge, and it was listed as the number one obstacle to implementing a DevOps approach.

While this industry is full of self-taught individuals who have spent time learning new technologies and tools, it’s somewhat amazing that training continues to be an issue. Many organizations limit their training budgets and time allocated to employees while continuing to expand the number of technologies and platforms they use. This is one reason why I think changing database platforms to avoid licensing costs is unlikely to save you money anytime soon. Retraining staff and developing competence takes time. Perhaps this is also one reason why many companies look to the cloud, thinking that they can reduce the amount of upskilling needed by their staff if the cloud vendor manages the systems.

That might be true, but there is a lot of knowledge is still needed about how the underlying technologies work, especially if employees are to efficiently write code or make configuration changes in the system. The cloud can be more cost-effective, but it can easily be less cost-effective. Knowledgeable employees can make a difference.

I do see plenty of organizations subscribe to online learning, but often I find these courses good for basics, but not necessarily helpful for specific situations and just-in-time knowledge requirements for projects. There more custom training, or at least, group support, is needed to ensure that your staff is learning efficiently. Far too many people can’t handle open-ended training from an online platform and complete more than one course.

Training isn’t enough, as there also needs to be some practical application of new skills in your environment. Practicing katas as a group, coaching each other, and applying skills to actual projects while measuring results is important. It takes some commitment from both employees and organizations to get better. Far too often, I also see staff unmotivated to learn and grow, for a variety of reasons, but that’s a different problem that we have to work to solve together.

The world of technology in business is growing increasingly complex. We find more and more organizations adding technologies, especially new database platforms, and we lack skilled people to work with them. That’s a constant challenge, but one that creates opportunities for you if you find ways to improve yourself.

Steve Jones

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

I saw this on one of the syndicated SQL Server Central blogs: Job Description of a DBA. This is mostly a list of things, but it covers a lot of the general types of things that many of us expect a DBA to do. However, my question is whether you think this is a good description for a job opening. Would you ask someone to fill this list of things?

Maybe a better question is whether you could use this to evaluate candidates, and how would you go about asking questions or gauging a fit based on this. Perhaps you should ask yourself how you evaluate others and if there is a good way to rate them against a list of daily tasks.

To be fair, I know most job descriptions often include many “desires” along with “needs.” That can be maddening to many job seekers, as they don’t feel qualified. What I’ve found when building descriptions is that a wider variety of people provide input for what they would like in an employee than just the hiring manager. The hiring manager might weigh these items differently and accept someone who doesn’t know replication well, even though replication is used if the candidate is skilled at query tuning. I would say expert, but how do you judge that? Most of us would probably settle for someone who can improve queries even just a little bit.

When I interview people, I want to know a few things. One is can I get along with them, as well as the rest of the team. This isn’t to discount technical skills, but we need to be a team. If we can’t get along, and maybe more importantly, disagree civilly, it’s hard to work together. We do need to bond, though that doesn’t need to be over a drink or sporting event. However, we might need to share a meal, so I hope we can enjoy a conversation for an hour.

The other thing is that I need to see some effort and desire to succeed. I don’t need someone to be an expert, but I do need them to show an interest in helping our customers, whoever they are. Part of that is trying; part of that is getting to the end result. I see far too many people that don’t try to solve problems or care that there is someone waiting on a solution. I also see too many people unwilling to try and improve the environment, whether that’s a codebase or server configuration.  They might be good at their jobs, but I like to associate with people who want to make the world better. People who think forward, who ask questions, who under-promise and over-deliver.

I think the job description I linked above is a good one, fairly comprehensive in scope, but lacking in lots of details. The devil is often in the details, especially in how hard someone might work to complete these tasks, and if they would work to do so to meet their commitments, but also do so in a quality manner. And, of course, under pressure. Most of us know that things break, and when the thing is a database, a good DBA is invaluable in restoring service under pressure.

Steve Jones

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