Tag: misc

I started using computers a long time ago, and in the PC world, we were often limited to an 8 character name and a 3 character extension. Unix and MacOS allowed longer names, and many of us in DOS and Windows were jealous. Eventually Windows evolved, allowing long names, spaces, and really quite a bit of latitude in what you want to name a file. For example, try this and see what happens on your SQL Server:

BACKUP DATABASE Sandbox TO DISK = 'Sandbox.thisisafullbackupthatIusetostartarestore'

However, the three character extension still dominates, and many applications still use this. Microsoft has started to get away from this, as we have .docx, .xlsx, etc. Other vendors and software systems have started to expand names slightly. I was reading about the SQL Server Diagnostics Preview and noticed that the engineers will take a dump file (.dmp) as well as a mini dump (.mdmp) and a filtered dump (.hdmp).

Now I know developers are lazy, and they don’t like to type, but in these days of auto-completion and other tools, why are we limiting ourselves. Why wouldn’t we use .minidump or .filtereddump as descriptive way of identifying the file? If we are no longer bound, why not include a better extension? I can’t imagine that the filesystem for many tools would be stressed by longer names.

I’m assuming that people still feel bound to using the shortest set of letters that they think are unique, but with the growth of software applications from many, many sources, why not just be more descriptive? Would you want to see better filenames? I know I would.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.7MB) podcast or subscribe to the feed at iTunes and Libsyn.

Today is July 4, Independence Day in the US, more commonly known as the Fourth of July. This is the day that the United States declared it self a separate nation from the British Empire. For most of my life, this has been a day of celebration with kids, or as a kid. A time when we cook outside, watch fireworks, and have an enjoyable day away from work. The last decade or so I’ve also re-read the Declaration of Independence, as a way of remembering the history of my country.

As I was preparing for this year’s holiday, it struck me that so often inside of companies we find groups and departments that almost separate themselves from others. We get silos and habits of working that are distinct, often because they feel that trying to work within the constraints of others’ requirements is too stifling or non-productive. Unlike the U.S .Declaration of Independence, I’m not sure that most of the people that work separately could list a defined set of reasons why they work by themselves.

As I talk about and promote DevOps, the one fundamental action needed for success is communication. Disparate groups need to work together, from architecture to development to business analysts to QA to operations. Every person needs to provide help and feedback to other groups, being willing to modifty the ways in which they work to smooth the out the entire process.

In other words, we need to work together.

I hope that as you move forward in building software for your company, you learn to work with others, finding ways to smooth out the process to deliver valuable features and functions to your customers.

And if you’re in the US, have a great Fourth of July.

Steve Jones

Somehow across the course of my career, I’ve morphed from a strictly technical guy to a publisher and teacher that also gets to do some technical work. I never expected this, though perhaps I should have. Despite my disdain for writing in formal schooling, I learned early on to always document and log what I did. In fact, a few times my notes and tracking ended up ensuring that we weren’t chastised too harshly for our actions. Perhaps if even kept some people from being fired. I’m not sure, as I think it’s hard to get fired, but having some reasoning and documentation can provide some insurance against the boss getting too upset.

In my career, I’ve had to send out status items at different times, with various purposes. As with many of you, I’ve often had to document my time and efforts for my manager. I’ve been a part of teams that adopted the stand-up practice of sharing your workload with others. I’ve had to summarize the work of my team for a director or VP above me. Some of those efforts felt valuable, but often it seemed I was going through the motions and wasting valuable time on something that was more of a cover sheet on a TPS report than anything else.

There was a post on publishing an engineering weekly newsletter that reminded me of the various status reports I’ve built. While I haven’t had a weekly engineering letter, I have been in companies where a weekly or monthly newsletter was sent out. In fact, at one of my first jobs, we got a physical copy of monthly company newsletter delivered to our mail cubbies (anyone remember those?). While people would grumble about the contents or disbelieve them, I also noticed that many of them actually read the newsletter. I think it’s natural for people to want to be informed about the company, even if they are skeptical about the data.

The idea of publishing a weekly newsletter for your staff makes sense. It’s a good way to keep people on the same page, especially as your organization grows larger than a single team. I wouldn’t expect everyone to read every part of each issue, but that’s OK. They’ll get something out of it. This is also a good way for someone to fill time during a short break, see who’s out of the office, having a birthday, or changed positions. I think it’s also a good reminder for items like on-call or project releases. Even if I don’t have time to read it right away, finding information in a central place can be a hassle, and a quick search of email would let me check the person to call this week after hours.

Including technical content is always good, and allowing someone to peruse articles or new concepts on their own time, maybe even encouraging more learning subtlely, could improve the quality and morale of your staff. Of course, if you are an open, exciting company that employees enjoy, this works well. If management is oppressive and overbearing, then publishing a newsletter isn’t going to fix your culture. You’ve got other problems to fix first.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.