Tag: career

  • Looking Back at 2010–Goal Review

    I had 8 goals for 2010, which I posted at the end of last year. That reminds me, I need to work on goals for 2011 Smile

    These were a variety of work, community, and professional goals that I set with, thinking that I would be able to achieve these in the year. As with many things, I was wrong and didn’t end up I the place that I expected. Some of this was due to my poor time management, some due to changing situations, and some due to a changing of my feelings towards the end result of these goals. Here are my final comments on the goals:

    1. Forums – My original goal was to post less, but keep 300 posts a month average. About 40-50 of those are set (editorials, handling issues), so it’s really a 200+ technical posting. I managed to make that average, with a wildly varying level per month.
    2. Blogging – I wanted to blog 5 times a week, each week, with at least 2 being technical. I think I made this, outside of vacations, and most weeks I did manage to get a couple technical posts. In some ways, I think this is an artificial goal that forced me to look for technical items, but it also resulted in some less than stellar posts. I think I need to re-examine what I am trying to accomplish here for 2011.
    3. Learn Reporting Services – Fail. I was hoping to devote 1-2 hours a week, a fairly small goal, to this. However besides getting this setup no 3 machines, building some basic reports, and fighting through non-domain security issues, I didn’t accomplish a lot here. Part of the issue is that I had no focus on “what” I wanted to do with SSRS and no work to produce. I think this was my learning goal for SQL Server, but it wasn’t well focused or developed. While I think these are good skills, and worth learning, it wasn’t a good choice for me. In short, a bad goal to pick, and one that was easy to let go as my life became busy.
    4. Attend one SQL Saturday – A huge success, and I actually attended 7, along with a couple other events. I spoke at:
      1. SQL Saturday #33 – Charlotte
      2. SQL Saturday #22 – Pensacola
      3. SQL Saturday #28 – Baton Rouge
      4. SQL Saturday  #52 – Colorado
      5. SQL Saturday #53 – Kansas City
      6. SQL Saturday #59 – New York City
    5. Write a book – I made progress here, devoting a few afternoons here and actually working on two separate items at the same time. However what ended up killing me here is no enough of a focused effort, enough times. If I had spent 15-20 days on this, it would be done. I think that I moved some of this time to speaking events, and building presentations.
    6. Build 2 new presentations – I actually built 3 this year. Two on basic SQL Server (one non-technical, one technical), and one on Common SQL Server Mistakes. I have another in progress that I want to get ready for 2011. Again, need to make focused time.
    7. Take all my vacation in 2010 – Close. I didn’t make it, and again, work is interfering with my ski-Thursdays this winter. However I did manage to get in 4 vacations this year: St Martin, Las Vegas, Winter Park, and Steamboat Springs. I’ll call this a success, assuming I can free up 3 days each month in Jan/Feb/Mar.
    8. Travel to one new city for work – Charlotte, Kansas City, Las Vegas, New York (for SSC) were new trips for me. It was good to me to visit with people outside of the areas I have tended to go (Seattle/Orlando) over the years.

    So was it a successful year? It’s hard to say. It certainly was a busy one, and that impacted some of my personal goals. I think that overall I did well, and some of my failings were a lack of a well-focused goal.

    In 2011, I want to look for goals that produce some result, and not arbitrary goals like blog every day. I am looking to better define a goal that will make my career grow, as well as contribute in a positive way to the community for SQL Server.

  • The Office

    The subheading for this article caught my eye. Sixty percent of workers think they can be productive outside of an office in a survey conducted of 2,600 IT professionals. Most of the these people also said that they tended to work extra hours each day outside of the office. The majority also said they would take a lower paying job if they could access the information they needed outside the office.

    That’s actually a smaller percentage that I expected would want to work away from an office,  though more than I expected would actually take less pay to do so. As least in America, it seems that people are very concerned with their salary, and reluctant to ever take a pay cut. I’m glad it seems that some people are starting to understand that value of their time to themselves and their families.

    It’s hard to work at the office, as Jason Fried said recently in a TED Talk. I haven’t worked in an office in some time, but I do remember a constant stream of interruptions. An hour of time without someone talking to you was rare, and I assume that the situation is similar with many knowledge workers today. We have people that we pay to think, and solve problems, but we don’t give them the time to actually work on those problems.

    Steve Jones

  • Strike Force

    Would you want to be part of an elite strike force inside your company? An IT team that can solve complex problems and save the day when there’s a crisis? Or even a large challenge facing your department?

    It sounds cool, and there’s a neat description of an “A-Team for IT” in this article, talking about the types of people that are needed. Overall I think this is a more a list of the ideal types of people that are important for almost any project, especially one that might involve significant investment from a company.

    This started me thinking about the type of person I have been in the technology world. I haven’t provided air support, or been the Über hacker or Fearless Leader that does something amazing. For the most part, I think I’ve been the infrastructure sherpa. Quietly working along, providing support where it’s needed, and just making sure things get done.

    That’s what I think most of us do on a daily basis. We grind away at work, building and fixing things that many people appreciate, but don’t stand out. We don’t get the spotlight, most people in the company aren’t aware of what we do, and that’s fine. Being part of a crisis or strike team sounds cool and exciting, but I think most of us would rather do a solid day’s work for an honest days pay and then go home and get on with out lives.

    Steve Jones

  • Call in the Experts

    Today we have a reprint of an editorial from Feb 1, 2006 as Steve is on vacation.

    Since my data center move last weekend the servers seemed a touch slow. Actually once I checked the mail server I noticed it was substantially slower. With my 100kbps connection on Sunday and Monday, everything seemed slow to me. I solved that DSL problem noting that the satellite receiver didn’t have a filter on it. Once I fixed that, the site was slow, but it was useable. I still wasn’t sure that it was me.

    But I got a few emails from people, so I called my network guy because I wanted him to check things. He said he’d be happy to meet me at lunch to check things since we didn’t have remote switch access (yet). We meet at lunch, me with a couple extra cables just in case. We log in and immediately see that there are tons of CRC errors coming from the switch to the firewall. He knows what it is: duplex mismatch. We open the cage, use a serial cable to connect, and see that the switch is set to 100 full and the firewall is auto. Apparently the negotiation when things don’t match drops to 10Mbps half duplex and can generate lots of CRC errors. We reset it and things are running quicker now.

    The point of this editorial isn’t so much that I’m an idiot about networking or that you should check your switches and NICs to be sure that they are set to match, but more that you should know what you don’t know.

    And quickly call someone in.

    It’s one thing to try to figure things out yourself, work through issues and learn on the go, but you should know the limits of your knowledge. In most areas I can quickly tell when I don’t know something and should just ask. But even in SQL Server I usually have a feel within an hour if I can solve the problem or I’m out of my league. And when I am, I call support or a consultant to help.

    Too often I see people beat on a problem for too long without calling in help. Sometimes they call too soon, but usually they work a problem too long because they are afraid to ask for help. Maybe they think they’ll look bad or the boss will wonder why he’s paying them. I don’t think it’s a knock against you to call for help periodically. I’ve been a DBA a long time and it hasn’t hurt me.

    In any case, knowing what you don’t know is a valuable skill. A skill I’d highly recommend you learn.