Voice of the DBA

Category: Editorial

  • Give

    volunteerThere’s a lot more to life than just working to support yourself. Sometimes you need to do just that, but often we have more flexibility to enjoy and appreciate the world around us. We can take joy and pleasure in the experiences we have, the people we encounter, and the accomplishments we achieve. However there’s another part of life that I think is important for everyone, and that’s giving of yourself to help others.

    I believe that almost everyone should volunteer their time or resources and give back to society. We should all work to make this a better world for everyone. Whether this is through a church, a non-profit, your local community or some other way, we are all better off for the efforts. I also believe this isn’t something you do constantly throughout your life, though if please feel free to do so. Some of us will volunteer when we are young, some when we retire. The important thing is that when we are able to do so, we act.

    Giving of yourself helps others, and it can provide you with positive feelings. It can also be good for your career. This piece talks a bit about the traits of those people that give, and it seems they often find their own personal success grows. This is because the way they view themselves, their time, and their accomplishments, changes when they help others. Volunteering can reduce stress, and may help you enjoy your job more. That last item might be the most important reason of all.

    This is something you can learn to do, by making time to help others at work, or in your life. Please be sure to balance this with the rest of your life, but you might find that taking a little of your free time to help others ends up improving the quality of your life, well beyond the price you pay in accomplishing less yourself. However please volunteer because you want to, not because you want to look good or add an item to your resume. Give because you want to give.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • SQL in the City 2013

    sitc_e.jpg

    Last week was the opening of a new SQL in the City season for Red Gate Software. Once again, for the third year in a row, we had our first event of the year in London. We had a new venue, and only one day this year, but it was sold out completely, with well over 400 people commuting to the middle of London on a Friday morning. I was lucky enough to attend, though my name being listed next to 4 of the talks probably ensure I had an admission ;). This was one of the busier events for me, slightly compounded by the fact that I arrived in London about 20 hours before the event and left the next morning.

    It was quite a bit of fun see lots of familiar faces and meet a number of new ones. I had some interesting questions posed to me, and I think I was able to answer, or get someone else to answer all of them. Sometimes it’s more important to be able to do the latter, since SQL Server has grown in breadth and depth, as well as sheer numbers of versions to the point where no one can keep everything straight. We encourage networking at SQL in the City, as do many other events, and you should take advantage of the time to meet a few new people, and renew old acquaintances as well. You never know when you’ll need to ask someone a question, and a personal contact might get you an answer quicker.

    The event ran smooth (Thanks, Annabel and Carly), as they all have over the last few years. This year we tried something a little different, focusing the morning on development topics and the afternoon on administration items. I liked that split, and I liked the flow in the morning between three sessions that built on each other to tell a continuous story moving from development, to testing, to deployment. Deployment is an important topic of conversation at Red Gate these days, and we hope that you find it to be important in your organization as well.

    Our tour is a little shorter this year when it comes to the US, with three dates in the fall: Pasadena, Atlanta, and Charlotte. I know many of you were hoping we’d come to your city, and we might in the future. We are bringing smaller events, 40-50 person, half day seminars to a few SQL Saturdays later this year. If you’d like to have us come early to your location and speak at a SQL Saturday, let us know. It’s Grant and I doing most of the work, so we have a limited number of slots available, but feel free to voice your opinion to our Community group at Red Gate.

    We like these events, and love the chance to speak with the community and customers, and plan on continuing them for the foreseeable future. I expect that we’ll bring more events to locations outside the US, and I look forward to meeting more of you all around the world at a SQL in the City near you.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Better Technical Interviews

    Is the tech interview dead? An interesting case made in the article, and some links ideas on how to better interview and hire technical developers. I think some of the ideas are specific to developers, and while they can work, they don’t necessarily translate to other professions, like database people. Developers are tinkerers and while there are lots of projects they can tackle outside of work for fun, I don’t see a lot of database project type work for database administration.

    However I think the main problem with trying to recast technical interviews and ensure you have better success in hiring is that interviews aren’t good models of the real world. In trying to evaluate a person’s skills, and ensure the process is efficient enough to talk to 2, 3, or 10 people for each position, you have to sacrifice something. Usually you end up sacrificing the fidelity of the insight into how the person will perform.

    The idea of hiring someone for a side project is a good one, though not that scalable. However in many of the non-tech companies I’ve worked in, this would have easily have been possible. We didn’t hire new people that often, and having them spend a week on a project, maybe 20 hours of side time, would have worked well and been affordable. The constraints would actually have been finding time to assemble the side projects. We’re usually hiring because we can’t get our work done, and we would have struggled to find time to assemble a project.

    Ultimately I think that prep time is perhaps the best way to hire better. Spend time teaching a few of your managers or other employees how to evaluate someone, perhaps even by interviewing and evaluating existing team members. Learn what things have helped people fit in better, and what haven’t. What traits make sense in your environment. Maybe then you’d have a better chance of finding employees who would both fit in and be productive.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.

  • Great Engineering Culture

    engineer

    There are some nice quotes in this piece, and it’s an interesting talk to watch as well. The talk is aimed at people starting companies that are based on technology and how to build the culture from the beginning. However I’d argue these same techniques can change culture in an existing company as well. It takes time, and patience, but you can slowly transform your technology department one that people want to work in. More importantly, you can make it much more effective and efficient.

    Way too many managers don’t communicate effectively. They want to use the military techniques of command and control, broadcasting a message and assuming everyone will follow along. Instead it would be better if managers listened more to the opinions and ideas of their technologists, especially when it comes to technology issues. The management part of your job comes in when you help your staff mitigate problems, and help them understand the issues and constraints of the business. Giving someone real, logical, valid reasons for adhering to deadlines or requirements often works well. Most technology people are smart and respond much better to discussions and debates based on reason rather than edicts backed by fear or power.

    I love the section titled “Firing A**holes”. This quote is especially important: “Even if you have an engineer who is exceptional, but an asshole, you should fire them immediately. Your team will thank you for it afterwards. It only takes one asshole to destroy an entire team“. I completely agree. It doesn’t matter if someone is an average or even poor worker. If their attitude is corrosive, disruptive, and upsets people, move them on.

    I especially like the part about promotion. Most of us want ownership, responsibility, or as I’ve thought about it, autonomy. Most of us want to make decisions and have control over what we do. Give more responsibility as people do better and drive forward. When they don’t, remove some. That alone will probably help motivate and drive your people forward.

    Building great culture is hard. It isn’t something you set up and it will maintain itself, but rather something that you constantly work on, and tweak to make better. There will be regular arguments and minor disruptions, but if you have people actively managing and working to make the environment better for other technologists, you’ll get great things done.

    Steve Jones

    The Voice of the DBA Podcasts

    We publish three versions of the podcast each day for you to enjoy.