My podcast is now online! Check it out!
I originally started my ‘blog to supplement my SQL Saturday presentations (among other things). I’ll admit that I wasn’t entirely sure what I was getting into with this endeavor, but one thing that was in the back of my mind what that my efforts might lead to bigger and better things. It’s still too early to know whether or not I’m near that goal (I’m not there yet), but I’m seeing signs that I might at least be heading in the right direction.
I previously mentioned that I was invited to record a podcast for SQL Data Partners. That podcast is scheduled to air tomorrow — when it does, I’ll post a link to it! (Update: my podcast is now online!) I was excited to do that podcast; recording it was a lot of fun (although there were a couple of things that I wish I’d said differently — that’s another article for another time), and it made me feel pretty good that I was being recognized for a skill that’s right in my wheelhouse.
I’m also seeing subtle indications that my skills are being recognized. In my current job, people are increasingly referring to me and asking me questions about documentation, writing, and communication-related issues. On the SQL Saturday circuit, I feel as though I’m treated as an equal among other speakers, despite the fact that I’m not necessarily an expert in SQL. I’ll admit that I’m somewhat humbled when I think about the fact that I’m sharing space with SQL MVPs. My presentations may focus on soft professional development (rather than hardcore technical) topics, but these people make me feel like a fellow professional and one of their peers — and that makes me feel pretty good!
There are many resources you can tap to get yourself going. I highly recommend an article by James Serra where he discusses how to advance your career by ‘blogging. I also suggest a SQL Saturday presentation by Mike Hays where he talks about creating a technical ‘blog. They are both excellent presenters, and I recommend attending their presentations if you have such an opportunity!
There are a number of ways to refine and practice your skill sets. Activities such as writing ‘blog articles, taking part in a user group, speaking about topics in your field, answering questions in an online forum, taking courses, and so on, provides a solid foundation for the skills you want to establish. It’ll take time, but if you make the time and effort to develop and enrich your skills, your efforts will eventually bear fruit.
A while back, I referred to Eugene Meidinger‘s SQL Saturday presentation about keeping up with technology. I came across his ‘blog article where he talks about exactly that. It’s a very good read, and he gives an excellent presentation.
Hope to see people there!
I had two appointments this past week. The first was one for my car to get my oil change and to make sure everything was in good working order (it was). A couple of days later, I had a dentist appointment. It was a routine cleaning (I also had a procedure done — one that I’d been putting off for a while). While the two appointments were for different reasons, they both served the same purpose: to perform maintenance.
Just about everything, especially anything mechanical, is going to break down over time. Maintenance ensures that things remain in good working order. But when we think about maintenance, we usually think about car repair, roadwork, furnaces, and water heaters.
I’m sure many people in tech industries consider periodic hardware and software maintenance. Hardware can break down. Drives crash occasionally. CPUs are upgraded to keep pace with emerging technology and to support software. Speaking of software, bug fixes are constantly made. There’s also the matter of security; virus software definitions are constantly updated, and operating system patches are distributed to ensure computers are safe.
But here’s another question: when was the last time you maintained your documentation? Does your documentation, which was written for, say, Version 1.0, reflect what is in Version 2.0?
The trouble with documentation, even the best-written documentation, is that it can become obsolete over time. Processes and systems change. Interfaces are redesigned. Steps become more efficient, or in some cases, even eliminated. Change happens. It’s one of the sure things in life. Documentation should also change as well. How often has your help desk received calls from frustrated customers saying things like, “your instructions say ‘press the red button,’ but there’s no red button on the interface!”
If your product changes — and it inevitably will — your instructions should change with it. It’s important that systems are maintained. Your documentation should be maintained as well.