Tag: career

This editorial was originally published on Aug 19, 2013. It is being re-run as Steve is away at the Data Platform Summit.

When you work with a vendor, you may report bugs, issues, or strange behaviors in software. These area facts, and are valuable pieces of information that vendors do care about. When you exclaim that a particular bug or missing feature is critical, you’re stating an opinion. The importance or priority you place on an item is not necessarily the same priority the vendor places on the item.

We see this every day in our work, as clients and customers send us issues with our applications and systems. We triage the items and may or may not fix them in the order the customer would like them fixed. Our management may set priorities that we don’t agree with. It’s a complex interaction that involves many factors, all of which are weighed differently by different people.

However the end user (client, customer, etc.) often doesn’t understand why the priorities are different and why can’t we just see how badly an item needs to be fixed? I see this all the time, though from the end user perspective. I use lots of software, and I find lots of issues and failings, especially in SQL Server. My priorities aren’t Microsoft’s priorities, and I accept that. I provide them with an opinion of what I think, not a vote. If they don’t agree with my opinion, or choose to work on other priorities, I don’t think they aren’t listening to me. I think they disagree with my opinion.

Like it or not, politics is important here. The art of influence is important, and while an individual opinion doesn’t matter, lots of opinions can have influence. Again, however, these are opinions and influences, not votes. We can convince Microsoft to change direction at times, or work on certain issues, but it takes participation and rational, reasonable debate, not childish exaggerated complaints and insults. We want to influence and convince, not upset and anger.

Steve Jones

This editorial was originally published on Jul 22, 2013. It is being re-run as Steve is on vacation.

I wrote recently about tech interviews and hiring, and even on an interesting interviewing technique for senior people. However we need to hire more than just senior people. We need to hire junior people, and intermediate people. Those roles are important for both growing the experience of your staff, and not getting caught with a “” as a bottleneck or single point of failure. No, that’s not Brent Ozar, though someone with his talent might be the single point of failure in many organizations.

Not everyone can be a superstar-expert-architect that decides how the system is built. Not all architects should spend time coding basic insert/update/delete code or adding clustered indexes to tables. We need a variety of talent levels that can get complete different types of tasks. There is tedious administrative work, supporting roles, necessary, though unexciting work like reviewing security, logs, audits, and more. While you can automate much of this busy work, there are still tasks that we must assign to people.

There’s another consideration as well in hiring that all too often people overlook. Hiring too many people that are too similar, who may think alike, who may view problems the same way can lead to an environment that doesn’t grow and expand, that loses it’s creativity over time. There’s a great quote that says “Where all men think alike, no one thinks very much” (Walter Lippmann). It’s important to have a diversity of opinions, and when you hire new people, you should consider this. You want talented people, and people that get along, but not necessarily all thinking about problems in the same way.

The world is a richer place for the diversity we have, and varying opinions, thoughts and ideas. We don’t all get along, but many of us can work together with mutual respect, considering each others’ viewpoints as we work to build solutions to the problems we face.

Steve Jones

This editorial was originally published on July 1, 2013. It is being re-run as Steve is on vacation.

Hiring good people is hard, though in some cases it might not matter as much as others. If I am hiring entry level developers or DBAs, I have a lot of candidates, I’m not investing a lot, and I shouldn’t be too concerned if I have to let someone go and find a new employee. Given the fact that the people are often unproven in this case by definition (they’re junior levels), I should be prepared as a manager to make more mistakes at this level.

However at the senior level, hiring needs to be done more carefully. The high costs, the limited number of candidates, the responsibilities I give senior people, along with the trust I need to bestow upon them means that I can’t afford to make the same percentage of mistakes at the senior level. Most importantly, I don’t want to hire expert beginners instead of experts at this level.

I ran across a post on a way to hire senior developers that I thought was very interesting. In particular, I was struck by the analogy of hiring a guitar player. For the most part, I’d agree that if I wanted an experienced guitar player, I’d want the expert, not the expert beginner. If for no other reason than I don’t want to argue with an employee that does things my way, including making the same mistakes I’d make, and then explaining to me this is how I had specified things to be. I want a senior people to warn me, and influence me to do better.

I’m not sure how I’d devise a similar level of test for a senior level DBA, though I do like the idea of giving them some scenario or simulation that has flaws or problems and seeing if they’d correct them, point them out, or leave them in place as they moved on to “play” the scenario. I’m sure there’s a way to do this, and a balance between how to evaluate the responses.

Ultimately I want senior people to fix things, make them better, and provide a smooth path to increase quality. I want them to point out flaws, and warn me about issues. If I insist on making poor choices, I want their support, but if they can influence me to do better, I’d prefer they did. That’s one mark of a senior person.

Steve Jones

This post was originally published on Apr 23, 2013. It is being re-run as Steve is on vacation.

I ran across an article on ways to accelerate your career and for the most part I think these are good ideas and suggestions. Networking, finding a mentor, and more will help you no matter what business or field you are working. Some of the advice is geared towards those people looking to climb the corporate ladder and move into management, which is not necessarily what many of us want. If that’s the case, ignore those items. There was one item, however, that I thought was particularly interesting for data professionals.

The seventh item on the list notes that you should spend 10-15% of your time working on a project that’s outside of the scope of your job or team. That might sound crazy, and even dangerous, but it’s a good idea if your boss isn’t opposed to it. Having knowledge about the way your business works, the way they use data, or solve a problem, could be valuable in your existing job. You might notice a pattern or way in which you could improve either your job or someone else’s. Over time, helping in a variety of departments builds friendships, increases your networking, and might show your boss you deserve a raise.

Many of us end up working with data as a widget. The job of a developer or DBA is writing code or managing data, and sometimes don’t often think much about the actual industry in which we are working. Gaining deeper knowledge of the way your particular business works means you can better understand why you are asked to solve a particular problem. That knowledge can lead to a better solution. It might also make your job just a little more interesting.

For the typical US worker, that’s 4-6 hours a week. For the IT person, that might be a little more time, but I think it’s worth the investment. I wouldn’t be overly driven in this area, and if I were working on extra projects at work, I’d eliminate (or cut down) on the time I was spending learning new technologies. Life requires balance, and if you tackle something new in one area, make sure you know what you can give up.