Voice of the DBA

Category: Editorial

  • Promoting Engineers

    CS career paths
    Do we have enough of a career path for technical people? I’m not sure we do in many companies.

    Never, ever promote your best salesperson.

    That’s the advice that Scott Horowitz got from his father. He talks a little about how this relates to technical people who find themselves looking at management to further their careers, or are sometimes even get promoted just because they’re the strongest technical employee in a group. Mr. Horowitz sees the transition as one that rarely works well, though he has some good advice on how you can increase the likelihood of success.

    In my career I’ve moved to management a few times and back again to a technical role, though never at the same company. I am sure it would be a strange move to be in charge and then move back to a contributing employee, but I do know some other people that have done it successfully in their careers. I have enjoyed both roles, and at different times in my career, the different role has fit me better.

    Many companies struggle with their technical people as they advance in their careers. Few companies think ahead and build dual career tracks in both the technical and managerial areas for their staff. As a result, many technical people find their career stalled in a company and may look to leave for another position. Setting aside a technical track that allows an employee to advance as a strong technical worker, and continue to grow their challenges and salary seems like a no-brainer, but it’s something rarely implemented outside of technology-oriented companies.

    Perhaps senior technical people can’t continue to add the same value as a manager or director in an organization. There are definitely lots of technical people that have a lot of seniority in a company, but do not necessarily bring a lot of additional value for all their experience. However some do, and those are often the people that a company should not let go. If they continue to grow their knowledge, and add more value, there ought to be a career advancement track for them in the technical area.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Being Responsible for Code

    I read this great account of how Facebook releases new code, and found it to be very interesting. Apparently the entire FB site compiles to a single 1.5GB binary at this time. That in and of itself is interesting, but their deployment strategy caught my eye as well. They use bittorrent to deploy the large file to all their servers. Very creative and interesting look at things from one of the largest web sites in the world.

    The process is interesting, but one of the comments caught my eye. It includes a quote from the article:

    developers must be held responsible
    I’m sure many DBAs wish developers were held responsible for issues.

    I know there’s no shortage of developers that make mistakes and don’t want to have responsibility for the code they release. I like the idea of tracking these metrics, and letting people’s actual performance being a part of their evaluation each year. Not trusting the manager’s memory, or the recent complaints from co-workers, but actually looking at the relative mistakes being made. This leaves out scale, but I’m not sure the scale of the mistake is as important as the frequency.

    However this is a double edged sword. Some people will perform worse if you place them under this pressure and may find it too stressful an environment. If you don’t have the same pressures as a company like Facebook, you might end up driving away good employees that could fit in elsewhere.

    My recommendation would be that you hold people accountable for their work and use metrics like this to actually track that back to specific incidents, but that you use this as only a portion of someone’s evaluation. Track other measures available that help you determine if a particular worker is contributing value to your company outside of the bugs they might have in their code.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • A Lifetime of Software

    old programmer
    I hope I’m still working with technology at this age.

    I’ve been working with computers and software for most of my life, but it’s been a career for a couple of decades now. I don’t do as much technical work as I used to, mostly testing and experimenting, but my job is related to SQL Server and software, and I anticipate that’s what I’ll be doing for the next two decades.

    However that’s not necessarily the plan for everyone that works in the technology business. I know plenty of people that would like to move into management, or even move into some other career field if they can afford to do so. In the responses to many editorials in the past, I read that quite a few people think the technology business isn’t a great choice and wouldn’t encourage their children to enter this field.

    I disagree, and think that this business has been very good to me, overall I’ve enjoyed it, and I think it would make a good career  for any of my kids. However this Friday I wanted to ask the rest of you what you think.

    Do you expect to work in the technology field until you retire?

    I know many of you will change your focus in technology, perhaps moving to develop from DBA, vice versa, or moving into another field. I know most of you will change companies before you retire, but I’m curious about whether you think you will remain a technology worker for the rest of the time you work.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Security Outside the Database

    SQL Injection on nametag
    SQL Injection shouldn’t be this easy

    It’s 2012.

    We’ve known about SQL Injection for years, we’ve known about the issues with high privilege admin accounts for decades, and poor configuration has been an issue ever since we first started networking two computing devices together. Yet these supposedly well known issues are still problems for databases in many companies.

    We have a lot of work to do in the database with regards to security. Auditing, tracking, configuring security, these are all challenges, and while SQL Server is getting better with the enhancements they have in SQL Server 2012, there is still work to do on the platform. I do think that Microsoft needs some help and guidance from us here as well, as we implement new features, find problems with using, scaling, or just understanding them, and I hope you will try out the new features and then submit feedback on Connect and write about your experiences.

    However the security implemented in the database is often circumvented by poor practices outside the database. There’s little  excuse for developers not to understand SQL Injection and code around it. There’s no excuse for frameworks and sample code to show code that allows SQL Injection. As far as privileged accounts go, that’s a bit of laziness on the part of admins. The modern OSs go a good job of allowing you to elevate from a non-privileged account. So even if you want to be lazy and give more access to developers or non-admins, give them an audited, second account that can be used to track activity. I’d prefer that we educate admins more and work closer with each other to ensure work gets done quickly, but maintaining a separation of duties, if for no other reason than to have a second pair of eyes examine changes for issues.

    As far as networking issues go, we have to demand more education from networking people. The days of connecting machines to a hub and worrying about IP addressing and the correct gateways are gone. Networking is much more complicated, and firewall administrators need to better understand their systems.

    Education is the key to making the systems work better, as it is in so many parts of life. Demand (if you can) or ask (if you can’t demand) that your fellow workers learn to work with their platforms better and improve the security throughout your entire system.

    Steve Jones

    The Voice of the DBA Podcasts

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