Marc Schnau posted this on Google+ with the comment, “This should work properly with any language one is trying to learn. And not only while learning languages, Maybe this is valid for every kind of learning one will do.”
After watching this video, I think he’s completely correct. I know that the speaker in the video is correct with the idea of using shorter, intense sessions versus longer ones. One of my cousins is a personal trainer, and this is one of the methods he endorses with exercising, so the speaker is correct about it working with physical exercise of larger muscles. But Marc is right too–this applies to any kind of learning, not just with languages.
This video proved to be helpful to me, as there are events going on with my life that are leading me to try to figure out what I need to be learning next.
What do you think? Do you think this is hype, or do you think there’s some validity to this approach for learning anything, not just languages?
Sometimes, I think being a stunt person would be easier than being a technical communicator.
While plugging away at the big project I’m doing for work, a problem arose from how some features worked, and developers cluttered up the CMS architecture of the site I’m working on. When I tried to clean it up, the developers rolled out more content that either created duplicates, triplicates, and overwrote pages without my knowledge. This mucked up the whole thing even more, making it worse.
I ended up having a call with my manager explaining the situation, and showed him what happened. He was aware of some of it, and he knew I was trying to fix things, but he was unaware that the latest roll-out complicated the situation. After a good discussion, he came to the same conclusion that I did–it’d be easier to start from scratch with this section of the website than to try to clean it up. I took responsibility for my part of the mess, and was more than willing to put the time in that’s needed to get it right again.
In order to do this, we’ve had to work with the people in the global corporate office to help us wipe the slate clean on that section and resend the new information. Well, this turns out to be easier said than done, due to system issues and communication issues (we’re not sure, even with images demonstrating the issue, if we are explaining what we need correctly to non-native English speaking people, and we are having some trouble understanding their replys). It’s turning into a sordid mess that I didn’t mean to happen. Some of this is my fault, doing some things unknowingly, but it’s also Corporate’s fault for not staying organized with the information rolled out on the various servers and not informing me of these changes in a timely manner, as that’s what is complicating matters. My hands have not touched that section of the website for 2 days because I’m afraid of mucking up things even worse, and so I’m patiently waiting for the correct content to be rolled out so I can move forward.
In this type of instance, my experience has been that no matter what part I played, even a minor one, I needed to take the blame for the whole thing. I needed to fall on the knife for what’s happened, even if I’m actually the victim in this instance. I’m fortunate that my manager hasn’t viewed this as something that I needed to take the fall for, and he’s been incredibly supportive through this small ordeal. I am grateful to have him as a manager and it provides me with some relief. But in past positions, even if I was correct in the midst of something that had gone wrong, I’d have to take full responsibility even if full responsibility was not mine. I’m willing to take responsibility if it is truly and completely my fault. Yet, I’ve had many instances where it wasn’t my fault at all, or I played a minor role, and I’d still be blamed entirely. And it would be one thing if I was a manager taking the blame for someone under me, but I’m always the gal at the bottom of the totem pole! If I stood up for myself in the past, I’d be severely reprimanded, even though I was justified in standing up for myself. So, you can understand why I’ve developed a bit of a complex and learned to take the role of the scapegoat in these instances unwillingly yet necessarily.
It got me to thinking about technical communication and where technical communicators will be given the blame for something that’s gone wrong. Sometimes the blame is justified, and sometimes it isn’t. If a manual has incorrect information, is it the fault of the tech writer, or the SME who didn’t provide accurate information, or the editor? In my case, the developers were being sloppy. I was the one being responsible enough to realize there was a problem and clean it up, initially following their directions for the fix, and they made it more difficult adding a fix to my fix without communicating that they were going to make a fix on their part. So why am I feeling like I need to take responsibility for the problem I didn’t cause instead of taking responsibility for realizing the solution? Is that just me and the conditioning I’ve been put through over the years, or is that a common problem?
In my current situation, like I said, my manager has fully supported me, and he’s about to leave on vacation confident that everything will be fine, leaving it up to me to take care of things. This is a reversal of most experiences I’ve had, and it definitely bolsters my confidence that I do know what I’m doing, and I appreciate that I’m recognized for that.
Technical communications is not for the weak or faint of heart, for sure. There is no question about that. However, technical communicators are being encouraged, as a field, to assert themselves more to show that we do have the solutions and know what we are doing, and to play a greater role in communications. I’m sure you’ve heard the “Break down the silos!” battle cry by now. If that’s the case, how do we do that if we have introverts like me who have been pounded down enough times that they are fearful of losing their jobs for asserting themselves? Is that just me, or do others feel this, too?
Content Rules Inc. was kind enough to extend their invitation to have me blog for them again. This time, it’s on a subject that’s near and dear to their hearts as well as mine.
This article talks about my own personal experiences in trying to use standardized language. Whether you use standardized language in your personal or professional life, it’s something that one needs to keep in mind as a writer, especially when writing for a global audience, and even more so if you are writing for a digital format that is easily accessed through the Internet. It’s not easy to do, but it’s something that should be tucked in the back of every writer’s brain.
An ENIGMA coding machine, found at the Computer History Museum (photo credit: TechCommGeekMom)
Technical communicators truly do have skills that most others don’t have, and it’s a simple set of skills. We take for granted that we can display writing and documentation clearly.
What brought this to my attention most recently–as if I didn’t know this fact already–was dealing with emails from work. I was trying to interpret emails from several educated, fairly influential people from the company, and I didn’t have the faintest idea what they wanted because of unclear directions. Granted, it didn’t help that the email system that we are forced to use at the moment (Lotus Notes) is not exactly user-friendly when it comes to formatting content within an email. Even when I could wade through the quagmire of formatting fogginess, what was being requested of me was not completely clear, and I had to send emails back clarifying the requests.
Although we are often required to work on reducing the number of words used to relay our messages and act as translators of content, it shouldn’t be at the cost of miscommunication. Sometimes having more is less, because more detailed directions can provide less back-and-forth of emails, thus more efficiency in getting the work or task done. From a customer perspective, having accurate documentation–even if it’s long–can reduce call centers help requests significantly.
A great example of making sure that content–whether it’s an email or any other documentation–is efficient is when I worked at the Princeton University Press. The CMS I had to use was an in-house Frankenstein monster of an application, but it worked for better or worse. There was no printed documentation, so when I first started working for the company, I took lots of detailed notes to make sure I understood how to do tasks on the system. I left the company after a few months, but left my notes for my successor. About two years later, my successor left, and my former manager asked me back to fill in temporarily, since she knew my contract had ended, and my ramp-up time wouldn’t be the same as if a new person was coming in during the pinch of getting the new fall catalog posted online. Sure enough, the two-year-old notes were still at the desk, and I could still follow them clearly. (This was when I knew that techcomm was truly my calling!) This reduced the number of times I had to ask my manager to refresh my memory on how to do certain tasks. As a result, the fall catalog information went up quickly, and everyone was happy. Mind you, the documentation I had was pages and pages long–all handwritten, no less, but it was accurate enough that I didn’t need much help in re-learning the system. My second successor was able to use these notes as well, since they were so accurate.
As I said, we take for granted that we have the ability to write cogently and clearly since we all do it on a regular basis. It’d be nice if more people can get the basics of this skill down so that we technical communicators can do our jobs more efficiently. The fact that we can decipher and clarify messages better than anyone should put us in the same ranks of ENIGMA coders, in my mind!
Doc Brown and Marty McFly can’t believe the fabulous information they got at Adobe Day at the STC Summit 2014. (They already went, and said it was fantastic–not to be missed!)
With each big conference that I attend, I always look forward to Adobe Day, and Adobe Day at the 2014 STC Summit is no exception. You’ve probably read my past posts about Adobe Day from other conferences, so you know how rich in information they are. I’ve learned an enormous amount of information FOR FREE that would otherwise cost thousands of dollars from the leading experts in the field. It’s hard to find that anywhere else.
On Sunday morning, May 18th, 2014, Adobe is once again putting together a stellar group of technical communications luminaries to set our imaginations on fire! This year’s theme appears to be, “Vision 2020: The Demanding Job of a Technical Communicator.” Based on the descriptions of each speaker’s talk during this morning session, each will be providing advice and tools–free of any product promotion–that can help make our demanding jobs easier and more productive. I’ve heard all the speakers before in one way or another, and I can tell you that all of them are top rate. Most of them have spoken at previous Adobe Day events, and they are invited back time and time again because they have valuable information to share.
Kapil Verma of Adobe will be speaking about who he thinks are today’s technical communicators (hint: there’s more than one type!). Marcia Riefer Johnston will be talking about single-sourcing techniques she used to save her company USD$16,000! I’ve taken Marcia’s writing workshop and read her book, so I can tell you she have some marvelous tips. Kevin Siegel will be talking about how to combine something I love–e-learning–with technical documentation to make the documentation more dynamic and valuable! I’m looking forward to that. Bernard Aschwanden–the STC’s newly elected vice-president–will be speaking about using content strategy to help promote revenue growth. And last, but not least, a panel including all the speakers plus Tom Aldous of Acrolinx, moderated by Matt Sullivan, looks like it will be quite the lively talk.
Did I mention that breakfast, snacks, and lunch are included, too? And it’s FREE?
I know–you are saying, “Great! I want to go! I don’t want to miss out on this!” Great! But you do have to register so that Adobe knows you are coming! Make sure you register by 11:59 PM PDT on May 16th, because you don’t want to miss out!
TechCommGeekMom 
You must be logged in to post a comment.