I spent over a decade as a software development engineer in test (SDET) before I formally changed my job discipline to that of programming writer and then content developer. Many friends and family have asked or guessed why I made this change and most of the guesses tend to land in the “something easier than testing” bucket but that’s not the case at all. I actually moved from test to content because I discovered my knack for organizing data and information into a coherent flow fed a brand new passion for teaching, especially for teaching about processes and technology to those new to it.

In my daily work life, I’ve always been a writer in one way or another. I would be the person who would write out test processes, or would help design test architectures. I wrote and taught several internal classes when I decided I could do a better job than the current versions being offered. Then, in the midst of the first real push toward software security and security testing, after I had sat yet another junior tester down and explained the what SQL injection was, I told my husband that I should just write a book on security testing. He challenged me to do it and the idea took hold in the guise of a dare. I’ve always had problems resisting a dare. I wrote that book and sold it, despite the prevailing theory in the industry there was no market at all for books on testing. It sold and still sells a bit.

I count that book, Testing Code Security, as the major turning point in my decision to change job disciplines and it taught me several things:
• I learned that I really did love teaching others what I knew and did. I loved researching things I didn’t know as much about and putting that information together as well. Heck, I had to love it to spend nearly 5 full months working on this book every night at home, after dinner and after my youngest son was in bed.
• I learned that writing an instructional book is a huge amount of gathering and organizing raw data, developing a structure and a fair number of false starts before a good balance is struck and the subject matter flows into a coherent whole. It wasn’t as easy as I thought it would be, honestly.
• I learned that, while I loved testing, I loved the ability to talk directly to my users in the instructions I wrote and to feel like I’m trying to solve their problems even more.

Above all, I realized that my prior ideas of what a technical writer was and what the job entailed were incorrect, at least in my industry. It was much more about teaching and finding ways to get concepts and information across than it ever was about word choices, writing tone or any cute turns of phrase. Illustrations needed to be functional more than just add color or flair. The technical details MUST be correct and the user must be able to understand them or nothing else really matters.

In my new role as a programming writer, supporting all currently shipping Windows Embedded products, I take as my prime directive to be a teacher first.