I’ll be live on the PASS TV broadcast on Wednesday, Nov 7, at 11:40am PST. The Professional Development group asked me to do a short (15 minute) talk, and I’ve put together a set of quick blogging tips with a few slides.
If you’re not at the PASS Summit, you can watch this. If you are, I’m sure the recording will be available later.
This editorial was originally released on Nov 30, 2007. It is being republished as Steve is traveling to the PASS Summit.
Microsoft got in on a deal to Nigeria that Mandriva Linux negotiated with the government there. The story almost sounds like a bad email: the provider of a “free” product complaining that another company gave their product away for free? So does that mean that in a free market where the cost is the same ($0), that Windows is superior?
There’s some other editorial on that topic, but in this case, what was interesting is that the CEO of Mandriva fired off an open letter to Microsoft, which you can read here. The tone of the letter was a little whiny, and it didn’t seem as though Mr. Bancilhon really thought through what he was writing.
It’s Friday, and with the holidays approaching, I thought this would make a good poll.
In the old days, back when I was younger, if you wanted to fire off a letter, you had to write it and then mail it, usually ensuring some type of delay. Often you had at least one night to think about what you’d written before you dropped it in a mailbox.
There are plenty of people that still recommend that you delay sending an emotional email for at least a day. I know quite a few people that rethink their position before sending, often saving the email to a drafts folder for ten minutes, an hour, some delay to give themselves a break between writing and proofing.
I’m actually pretty bad. As I’m sure many of you have noticed, typos slip through the editorials from time to time, often because I’m in a rush. My self-proofing skills aren’t the greatest, and I tend to make mistakes more often than I’d like.
However I’ve also learned that delays can be good things. I’ve often incorporated a delay in restoring a secondary log-shipped database to give me the chance to recover from an accidental deletion of data. Delaying the send of a potentially inflammatory email allows me the time to cool down and can prevent me from making a big mistake.
Email is quick and a great tool, but it shouldn’t be abused. Take the time to be sure that the message you’re sending is the one that you want received.
Steve Jones
The podcast feeds are now available at sqlservercentral.podshow.com to get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
The RSS Feed: 
or now on iTunes! 
Today’s podcast features music by Everyday Jones. No relation, but I stumbled on to them and really like the music. Support this great duo at www.everydayjones.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.
This editorial was originally published on Nov 26, 2007. It is being republished as Steve is at DevConnections.
These days it seems that the demand for IT workers is still growing, but there is no shortage of companies still looking to lay people off or get rid of employees that aren’t performing up to some standard.
I saw an interesting article on how to better ensure IT job security and wanted to comment on a few of the items listed from the DBA perspective. I think that different groups of IT workers have different tendencies, but DBAs often are in a very strange position in a company and they need to ensure that their contributions are recognized as well as their work is valued and understood.
I remember in the dot-com boom days when “quirky” IT workers were tolerated and even valued. The strange people wearing flip flops and t-shirts could perform wonders with computers and their eccentricities were tolerated. Often when they were just competent at their jobs and no one really understood just how much or little they actually could do with systems.
The world has changed and expectations for most of our systems are higher than they were a decade ago. Management is more realistic in their view of their business, with most of our employers not expecting to get bought out by some large corporation and retire. Our job is to provide stability and long terms strategic value to our companies.
As a DBA, you have a varied job. You’re in charge of data, need to technically manage the systems, but also work with business users to ensure their data is properly qualified, the meta data is understood (even if not explicitly written down) and you can help them ensure data quality and recognize the importance of the information that is being stored in databases.
This means that you need to better fit into the business as well as providing value. You should respect the dress codes and other habits of the rest of the company. You also need to learn to communicate effectively with others. Don’t talk down to someone with technical acronyms and descriptions and make sure that you are trying to solve the business problems, not fit the solution into come cool piece of technology.
By trying to better fit in, you become an asset to the business as a whole. People should feel comfortable asking for your help and appreciate the work you do.
And they’re likely to keep you around for the long term.
Steve Jones
The podcast feeds are now available at sqlservercentral.podshow.comto get better bandwidth and maybe a little more exposure :). Comments are definitely appreciated and wanted, and you can get feeds from there.
Today’s podcast features music by Joe Sibol. If you like it, check out his stuff on iTunes or at www.joesibol.com.
I really appreciate and value feedback on the podcasts. Let us know what you like, don’t like, or even send in ideas for the show. If you’d like to comment, post something here. The boss will be sure to read it.
In my career, I’ve worked in a variety of environments and positions. I’ve been a developer, and a production DBA, sometimes at the same time. Many of us aren’t working in environments where we are strictly performing one job. We often flex our work to meet the needs of our organizations, doing whatever is needed to get the job done.
However many of us spend most of our time either producing software or supporting it, sometimes separated from the other side by internal rules or even regulatory requirements. Those of us that are successful usually learn to make friends with the people doing the other kind of job and these relationships allow us to bend rules and regulations to get things done quickly. That can be a good thing, but it often doesn’t really give us any appreciation for the job that others do on a regular basis.
In a few large companies I’ve worked in, management felt it was important that the developers or engineers spent some time in the operations area. People would rotate out of their area for a month and spend time working in another area, gaining skills that might allow them to provide support in an emergency, but more as a way of helping them understand the impact of their work and how they might go back to their job with a new perspective in the future. The ultimate goal was for design and development to proceed more efficiently and at a higher quality level. It worked well at times, but often failed if the developer didn’t embrace the temporary assignment with a positive attitude.
I’ve rarely seen administrators sent to work with development groups. Usually an administrator has to have an interest in development and is interested in making a career change. However I think that there is value from giving administrators some exposure to the development process. They might realize how complex and tedious it can be, how seemingly obvious problems slip through, and perhaps most important, they might learn how to better troubleshoot issues in production systems.
Steve Jones
We publish three versions of the podcast each day for you to enjoy.
