Voice of the DBA

Author: way0utwest

  • Is Software Engineering Dead?

    Software Engineering
    Are textbooks like this obsolete?

    Is Software Engineering dead? It’s a premise that’s in this article from Bloomberg. It calls the job a career dead end where job prospects decline after one reaches 35 years of age. I think that’s a naive view of the industry, despite the quotes from Craig Barrett and Mark Zuckerberg. While the best of the best might peak in their careers at the same age as many athletes, that doesn’t imply that the career choice is a poor one.

    There’s a discussion on Slashdot as well, and I was struck by a few of the comments, which seem to suggest that if you are still just a “software engineer” at age 40, you aren’t very good at your job. It seems that some people seem to think that everyone in this business is constantly looking to move to a new job and advance into management or they aren’t successful . I saw analogies with other industries thinking that same thing, that experienced people would not still be doing the same job after 20 years.

    That seems crazy to me. So many people in various industries continue to improve at their jobs, and do the same work for decades. Carpenters, doctors, accountants, all continue to improve their skills over time, and while some may more into management or open their own firms, many will continue to do their same jobs until they retire. And they’ll enjoy their careers.

    I don’t deny that ageism exists, and that older programmers often can’t, or won’t, work as many hours as younger ones, but that doesn’t mean they aren’t worth their salaries. Good, experienced programmers produce better code, with fewer bugs. Once managers learn that working more hours doesn’t equal better code, or even more code, the entire industry will start producing better applications.

    Steve Jones

    The Voice of the DBA Podcasts

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

  • Time for Your Career

    Pro XMl book
    Trying to learn some XML, and work on my skills.

    When I was at SQL Saturday #131 recently, I attended Will Sisney’s (@HanSQL | blog) talk titled “6 Steps to a Stellar Performance Review”. It was a very interesting session and I agree with most of the advice that Will presented. A lot of it feels like common sense, much like my Branding presentation, but it’s helpful to have someone talk you through the ideas and get you organized. I’d recommend you attend this session if you get the chance to do so and vote for it if Will submits for the PASS Summit.

    However there was one thing in the session that struck me. One of the steps is for you to take control of your own training and make an active effort to learn more about your craft, tracking your time and efforts to present to your boss. Will says that he spends an hour a day on professional development, which sounds like a lot at first glance, but it’s only 12.5% more than a 40 hour work week.

    Who works 40 hours in this business? Lots of people, though I’m not sure it’s the majority. However I do know that there are people that don’t focus and work just on their projects for that 40-50 hours they spend at the office, so an hour a day isn’t unreasonable. I’ve had more than a few bosses that were willing to give me 2-4 hours a week to spend on learning something, if I could show them it was time well spent.

    How much time could you spend on professional development every week?

    I am asking what you could realistically fit into your schedule now, without large sacrifices by your family or the rest of your life. Could you spare an hour a week? Two? Five? Andy Warren talks about needing 100 hours to learn a new skill and feel comfortable with it. You won’t be an expert, but you would be able to work with the technology and have an idea on how to learn more. Four hours a week would get you 100 hours this year. Could you spare that?

    Steve Jones

    The Voice of the DBA Podcasts

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

  • The Difference Between Change Tracking and Change Data Capture

    Change Tracking (CT) and Change Data Capture (CDC) were both added to SQL Server in 2008. At first it seems like these two items ought to be synonyms, but they’re separate features. They are similar, but there are some differences, and you might choose to use them in different situations.

    Change Tracking (CT)

    CT is not as well known as CDC, and I see it talked about less. This is really a feature that allows the net changes made to data to be easily returned from a query. This only lets you know that a particular row has changed since your last query. You have no idea

    • how many times it’s changed
    • the various change values over time

    The queries you run will return a table that lets you know which rows have changed since the last check, and then let you know the type of DML change. You need to join this table with the source table to actually get the data.

    This is really useful for those applications that cache data and periodically query to update their caches. Lots of .NET frameworks allow this, and it’s a great way to limit the load on your database server.

    Change Data Capture (CDC)

    CDC is more well known, and seemed like a great tool when I first saw it, but like many useful enhancements, there is a bit of complexity that you have to work through in order to understand and use this feature.

    CDC is a little more complex to implement, and it creates a bit more data in your database. You get a change table that is a copy of your table, along with a few additional columns that contain metadata. For each DML operation, you get a row(s) added to the change table. Inserts get one row (new data). Deletes get one row (old data) and updates get two rows (old and new data).

    This gives you lots of history and information about your table, but it’s a lot of data. The amount can grow quickly in a busy database, so you need to be sure that you extract the information you need and prune the change tables periodically.

    Which One?

    Which feature should you use? Is CT better than  CDC? They work differently, and they capture different amounts of data. There’s an entry in BOL that compares them, and you should understand the differences. However you really need to spend time working with both to make a decision about which one meets your needs.

    Pick a table or two, enable one, test with some workload changes, then evaluate. Then repeat with the other. You might find that you need to use CT in some places, and CDC in others, depending on the downstream processing of the data.

  • Teambuilding and Bonding

    old manual printer
    The roller that printed my etching.

    It’s a joy for me to go to work. Of course, I have the advantage of working at home, a 50ft commute, and working with my wife, someone whose company I enjoy. In all of the places I’ve worked over the years, it’s been refreshing to go to work with people with whom I get along, and distressing to go see those I don’t like. In places where I have a preponderance of the latter type of people, the job is a grind that wears me out. I only keep going until I can find another place of employment.

    Recently I was in Cambridge, UK for a meeting with my group at Red Gate Software. I go over once or twice a year and spend a few days with my department and a few days in the office. This time one of the days I was planning on being in the office was a “day out” for our part of the company. Twenty-some people took a bus to another town where we etched a picture and printed it during the first half of the day, and then toured the GainsBorough house and museum in the afternoon.

    It wasn’t quite the trip I had in mind, and I was tempted to try and skip the trip and return home a day early, but I went along. It turned out to be a fun day, and I had the chance to meet new people in the company, and get to know others that I had met before. In some ways it reminded me of previous jobs where we had excursions to movies, baseball games, miniature golf, and even cookouts. All those events, often during work hours, were nice breaks from work.

    However they also made the job more enjoyable. I got to know co-workers better and bond with them in a way that never happens in the office. I established common rapport with people, getting closer to people I liked, and often finding that I wasn’t so different from others that I didn’t get along with. These events made the job better, even when we were all back to our normal routines.

    It seems that fewer and fewer companies actually bother to set up team-building, even at the department level. It also seems that many people would rather skip these events, and take a day off rather than spending time with co-workers in a social setting. I felt that way on this trip, but I also realized that sharing those common experiences is valuable, and can help promote synergies among a team of people that result in better work in the future.

    Steve Jones

    The Voice of the DBA Podcasts

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