This is part three of a series on writing a technical article. The advice might apply to non-technical articles, but I’m focusing specifically with my examples on technical pieces. Other parts are listed at the end of this article.
One of the ways to really enhance your brand and show that you are a knowledgeable and motivated employee is to write some type of article that is published in a well known publication. These days it’s hard to find places to publish in print since there are fewer of them every month and competition is fierce. There are, however, more and more places where you can publish on the Internet, and that is almost as respected.
When you blog, which is something I recommend that all technical people do, you make the decision of what to write. You decide what the content is, what a completed article is, and you’re putting your voice out there. You are also allowing someone else to judge the work before it is published.
That simple act, which often includes some basic editing, allows someone else to independently check your writing. Some places may or may not test your code, some may or may not give you opinions on your ideas, but most should copy edit your work. This ensures that it's readable and others can understand it.
When choosing a place to publish, there are a few things you might want to consider.
First you want to identify where you can possibly publish an article. These days most publishers have some web presence, though there are a few places that only produce printed materials.
Some recommendations of places for SQL Server articles:
SQLServerCentral - I'd be happy to help you get published here. We do try to help new writers, and we are less strict about what we'd publish. Our daily newsletter goes out to hundreds of thousands of people and there are a lot of SQL Server critics that will examine your work. We don't pay a lot, but offer exposure. You need a thick skin, and you need to check your work. We don't test code, but you'll do a light copy edit and give you an opinion on your idea.
Simple Talk - The sister site to SQLServerCentral, also owned by Red Gate Software. Simple Talk is more of a journal, and tries for more serious writing about SQL Server. They pay more money than us, though with less exposure. They will also subject your work to a more rigorous edit, and that means a lot more work. However they are always looking for material. I wouldn't suggest Simple Talk for your first article, but if you have some experience writing, send them something.
MSSQLTips - A site that puts out daily, short tips about how to better understand something in SQL Server. Greg and Jeremy, who run the site, are friends of mine, and they're good people to work with. They are always looking for shorter pieces, but they need to be well written, and they offer a chance to write. A good place to work on shorter tips.
SQL Team - Bill Graziano, who is a VP of PASS, owns this site. It is one of the oldest SQL Server sites on the Internet, and contains a lot of information. I don't see new articles up there too often, but I am sure that Bill would like to publish more. I'd submit something to this site if you have an interest.
Database Journal - This used to be Swynk, and one of the best SQL Server sites on the Internet. I wrote there before starting SQLServerCentral. They are owned by a large corporation and tend to publish a few articles a week. I don't see a place to find out how to write for them, or even contact them. It seems they have relatively few authors writing for them, but feel free to try to write there.
SQL Server Magazine - The only real publication for SQL Server in print. They have been out a long time, and I was proud to publish an article with them years ago. Print publication is more serious in that you can't easily take things back if there are problems. You need to be sure that you test well, and they will subject your work to a few edits. When I published my article it took almost 8 months from submission to publication. If you are interested, check out their editorial calendar and look for something 8 or 9 months out and match your topic up with their schedule.
SQL Server Performance - This site was started by Brad McGehee who now works for Red Gate along with me. He sold the site and since then it seems to have less content being published. There is still a write for us page, and I am sure they will help you get published. A lot of people still go to this site because of their large archives, so you can get some good exposure.
SSWUG - When Swynk was sold, Stephen Wynkop started SSWUG. It is a pay site where you must subscribe to read the content. They also run a virtual conference and allow speakers to present with video recordings as well. They offer you the chance to reach people in a different way.
Some publishers prefer an abstract to be submitted first. Others, like SQLServerCentral, will take the full article and provide you feedback. We have an automated process to submit something, and we'll review it in a couple weeks and get you feedback.
If you want to submit somewhere else, please feel free to do so and contact those places for information about how to do so.
The rest of the series on how to write a technical article.
A few simple tips that I've learned over the years. Keep these in mind as you write your next article.
That and Which - It's amazing how often I correct this in writing, and it was something I learned early on. If you use "that" in a sentence, you don't need a comma. If you use "which", you do. A few samples:
There are a few other rules here as well. That should be used for essential clauses, meaning the are necessary in the way things are worded. If you have non-essential clauses, like descriptive information, use "which."
If you use "that" in one sentence, or earlier in the paragraph, you can switch over and use "which" for the sake of better flow.
Its vs. it's - I still mess this one up at times, but here is an easy way to read your sentences and avoid mistakes. Replace "its" with "it is" when reading. If it makes sense, you're supposed to be using the contraction "it's" and not "its." If it doesn't make sense, as in it's possessive, then stick with "its."
Capitalization - Surprisingly this is more difficult than it seems. Proper nouns and names are capitalized, and of course, the first word in a sentence. Outside of that, don't capitalize random words. So SQL Server is the proper name of a product, but "the database server" is a generic. Don't capitalize "Database Server," which is something I see often. The same thing applies for groups, even if you think they're specific. I realize you are talking about your "development team" or your "manager", but unless you call them out by name, or you are using the title of the group, they aren't capitalized.
If you've got questions, post them in a comment and I'll try to answer them. I'd also recommend that if you want to write, pick up a style guide. Microsoft has published a technical one and the Chicago Manual of Style is always a good book to keep around.
The best advice I can give you is to have someone else look over your article. I realize that I don't always do that for my editorials, and some of that is because of the time pressures and crunches I get under to get things done, but for technical articles, I'd be sure that you have a friend read it.
Today is the first day that I've really had any significant time on the computer over vacation. That probably sounds like it should be the rule, and it does tend to be, but this is the first time in a long time that I've let go of SQLServerCentral for a week and allowed others to be responsible for editorials, scheduling newsletters, everything! Typically I've done some work beforehand to be prepared.
Being busy with my nephews and family has kept me going, and it's been great wandering around the northern DC/southern Maryland area. I've had the chance to catch up with my brother, Mom, and other family. Only with my son being gone to a leadership conference, and my daughter sleeping in, do I have time to write a little bit.
And I've missed it. Not the work, but the writing. Perhaps I'm more done as a technology guy than I realized.
It's late, it's been a busy day, so why bother to spend 10 or 15 minutes at night jotting things down?
For me there are a few reasons, but the main one is that it's cathartic. I can unwind a little, let go of things, and sometimes think more clearly. When I was doing more authoring, a little writing after work helped to cement some ideas in my head, and many times gave me something to ponder or work on overnight or throughout the next day.
Taking a few minutes to write usually just makes me feel better, and better understand what's happened in my day.
What’s the cost of e-books? It’s an interesting question that I have always wondered. I found this account of the cost of books, and it makes sense to me. I think this is about what I expect.
It is somewhat confirmed by this section on CoolerBooks: What aren’t ebooks cheaper? However Coolerbooks, which is selling another eReader (in color) called the Cool-er Reader, isn’t giving a huge discount. Wicked Prey, the new John Sandford novel, sells for $22.36 from Cooler books (in ebook form). If you had their e-reader, you’d get 25% off, or it would cost $16.77. That’s the cost from Amazon for the hardcover.
The Kindle edition is $9.99.
I know Amazon takes a loss on some books, but if they can offer the hardcover for $16, can’t Coolerbooks to better? After all, it’s without the paper cost, which isn’t much, call it $3, but that adds up. It seems to me that perhaps Coolerbooks, who says they’ll never sell at a loss, isn’t necessarily disclosing what level of profit they want.
By my reckoning, the publisher's cost of the book is about $10. So Amazon is at cost, but I'd think that other retailers could sell books in the $12-15 range and make a profit. If not, then perhaps they're not doing a good job.
I was annoyed recently with Amazon offering a book I wanted to buy, brand new from an author, for $14. I wrote them and they responded saying the publisher sets the price. I wrote the author, and got a response back saying Amazon was playing games. Of course the publisher sets the price. At $29.99!!
This was a best selling author, fairly successful, and I heard that he has no input into the price of the book. Based on some reading I've been doing of author blogs, this seems right, but it also seems that no one wants to really talk about it. I think they are concerned about their relationships with publishers, and perhaps they are happy with the arrangement.
I don't know if I'll ever get anything published, but I am tempted to just find a good editor and go it alone. I might not make any money, but I would like to have the control to charge what I think are fair prices.
This is part two of a series on writing a technical article. The advice might apply to non-technical articles, but I’m focusing specifically with my examples on technical pieces. Other parts are listed at the end of this article.
I've been asked often about where I get ideas from. The answer, for me, is everywhere. Every conversation, email, article, almost everything that happens in my life triggers thoughts and ideas, and as a writer, I tend to think about how I would write about things.
That took years of practice, and constant writing to develop that skill, but I've heard similar things from people that don't write daily like I do. However I do have a few ideas and thoughts.
First, anything that you do in your job can be an article. Any problem you solve, any solution you implement, they can be an article. No matter what you're working on, I can likely find a way to write it into a technical article.
Second, remember that you are teaching someone about the technology. You want to consider how you would mentor someone else about this technique. If it's anything non-trivial for a layman in your area, it can be written about.
I tend to focus more on beginner articles, and I think that's a good place for new writers to consider. Different publishers will be looking for different levels of content at any time, and they'll often let you know if your article doesn't meet their needs.
As an example, here are a few things that I've seen happen in my environments and then written about:
Some of these are beginner, some of them are more experienced, but the topic doesn't matter. Different publishers will have different criteria for what they will publish. They will let you know, and you can work on your article based on where you will publish. SQLServerCentral will publish almost anything while MSDN will be very choosy about which topics they release.
Any problem that you have solved is likely something that plenty of other people have not. And the longer you worked on it, the less information you found on it, the more likely it's a good candidate.
The one thing I caution people against is writing general overviews. Too many people write these, and they often don't add information or knowledge to the world. We each have our own voice, but overviews are so generic that you likely won't reach different people with yours. Instead focus on a specific area and give details. Your readership will appreciate it.
This is part one of a series on writing a technical article. The advice might apply to non-technical articles, but I’m focusing specifically with my examples on technical pieces. Other parts are listed at the end of this article.
I deal with a lot of first time authors, people that are working in a technical field and want to publish some type of article to share their knowledge or work. And I see all sorts of quality of articles from highly polished and ready to release to drafts that aren't as good a quality as my ten year old might write.
Even allowing for the language differences from around the globe (I get submissions from many countries), the quality of writing is appalling at times, and even when it's not poorly written, it's often not well structured.
The first thing that I'd really suggest for people is to pick a topic, or theme, for your article. Think about what you want to write about and then write an abstract or at least a topic sentence.
As you write, you should be able to go back to your topic sentence or your theme at any point, at any paragraph, and you should be supporting that theme. You can diverge in your writing to make a point, or give an example, but your writing should almost always be supporting your theme. If it isn't, you're off track.
Too often I find technical writers worrying about losing people, worried about covering their bases, and so they try to spell out every detail, or they include lots of background about lightly related subjects, or they want to be sure that someone implementing this technique understands everything needed for the entire infrastructure.
Don't do that.
Focus on your small topic. If you are teaching someone about encrypting data in SQL Server or in an ASP.NET web page, don't tell us about configuring IIS or creating server certificates in SQL Server. If that's needed, mention it, but don't go into details. Point people to another article, or just the vendor documentation. Or Google if you must. But write about the one small piece of technology you have chosen and leave other parts for another article.
Write about what you are teaching us, and assume people have some base level of knowledge. That might be a beginner in a topic, or an advanced used, but no matter which level you write for, you can still focus on your one area.
One thing I usually tell people is that a good technical article tends to be in the 2-5 page range (perhaps longer if you have lots of images or code), but beyond that you might want to consider splitting it into two parts.
Everything above is general advice for trying to determine what goes into the article, but how do you structure it? The "default" advice, the advice that I think everyone should follow until they're established and comfortable writing articles that someone else publishes, is this:
Or in other words, have an introduction, a detailed middle section, and then a conclusion. This is standard essay advice that most people get in grammar and high school, and it still applies for articles. Blogs can be different, but for an article, follow this advice.
The introduction should have your theme or topic sentence, and then some details that explain what you're showing, and perhaps some back story about how you discovered this, or how it fits into a common situation.
The details should be just that. Walk the user through your code, your settings, explaining things. You ought to be able to give the article to a non-technical, or low-technical user and they should be able to follow along. They might not understand, but they should be able to follow things.
I tend to advise people to show snippets of code and then explain them as they go rather then show a huge section of code at the beginning or end, but it can work either way. You can even make the code a download and reference sections or line numbers. If a technical person can't load code into an editor, they probably shouldn't be reading your article anyway.
For the conclusion, it feels silly, but summarize what you've said. Restating the theme does two things. One it reinforces things for the person reading. They'll agree that you've shown something and it will stick with them. Of course if you haven't done a good job, hopefully there's a feedback mechanism for you to find that out. The other thing is that in writing that conclusion, you should go back and think about what you've written up to that point. Does your conclusion really summarize things?
The conclusion for me also tends to include a teaser to another article, a way for the reader to move on, or perhaps a quick note about what (specifically) this technique has done for me.
I was listening to Colin Cowherd and the Herd one morning and he was talking about the Los Angeles Dodgers and Manny Rodriguez. At first I wasn’t sure I agreed with him that the Dodgers should spend $25million to sign him. Is he worth it? Does he make a difference?
Then Colin stepped back and started talking about branding, and that got me interested. Twenty years ago the big stories in sports included the Yankees and Dodgers. I’d agree with that as the history from Jackie Robinson through Bob Gibson, Sandy Koufax, Tommy Lasorda, I remember hearing about them in the 80s, seeing them on Sportcenter regularly, and knowing that the Dodgers mattered in sports. They actually seemed to be more people around the country supporting the boys in “Dodger Blue” than even the Cubs.
However I agree that’s changed. Nowadays the Dodgers don’t make as big a splash, and they’re not featured in highlights that often. The exception was last year when Manny was traded over there and hit home runs. All of a sudden they caught my attention slightly more.
That’s branding.
Colin brought up an interesting point. ESPN shows highlights and lead stories, which are often a minute or two long. If you could get yourself, or your tem into those leads, the A blocks, you are building a good brand. Buying a 30 sec ad for the season would cost millions. I’m not sure if it would be the $25mm Colin mentioned, but it would be something. If you could get Manny to advertise you more, as a side effect of his signing, in addition to more seats, (likely) more TV coverage of games, and apparel, he really could pay for himself.
As much as I hate to admit it, he might be the top name in baseball.
So what does this have to do with your brand? How can the individual DBA benefit here?
You have a brand as well, and it be used to promote yourself. You won’t get a $25mm contract, but you can leverage yourself in other ways. In the grand scheme of the world, Manny is small. Just as in the scheme of DBAs, most of us are pretty small.
You can get more exposure, grow your brand, and get a level of networking with one simple thing:
Write an article.
It can be intimidating, and it’s work. But it’s an investment in your career that is worth making. I don’t want to exclusively promote my site, SQLServerCentral, but I will say that you’ll likely get the most exposure (500k+ newsletters sent out) for your work with the least effort. I’m an easy editor, and we don’t require huge amounts of research. However there are plenty of other places (SQL Team, Database Journal, MSSQLTips, etc.) that you can write for in the database space. In other technologies, I’m sure you have favorite sites that you visit.
The thing to keep in mind is that this effort, your first article, is going to showcase your brand. Spend some time on it, get friends to review it, and teach the world something. It doesn’t have to be earth-shattering or amazingly innovative. However it should be in your area of expertise, whether that’s writing SQL, managing security, grooming a dog, or training a horse. Write something well that shows:
And then make sure it’s on your resume. I bet it gets mentioned in your next interview.
I’m a little frantic this morning trying to get caught up on work, lots of stuff piled up, Tia leaving, kids had to get to school, etc. I need to run as well, which I was hoping to do early, but I might need to leave until before karate.
I have a ton of articles to edit, which isn’t my favorite thing to do. A number piled up before my trip to the UK, and I didn’t dent the load that much in the week between that trip and vacation. I’m not looking forward to going through them, and that will take me 30-60 minutes just to sort out.
Adding in another log to the fire is that the kids are off on Fri and Mon. We’re thinking of going skiing in Aspen, but that means mucho work for me this week and Tia’s going to be gone until Wed. Not something that makes me really productive. It’s quiet, but too quiet and I struggle to get things done efficiently.
On a final note, my neighbors are out of town, so I get to take care of tonight:
I write on a daily basis, and while I don't find it hard to come up with things to say, it is hard to write something great every day. Actually it's probably hard to write something great ever.
I try and I think there are some great things I've written, but in trying to get something done every day, I find it hard to write something that will stick with people. Something that is inspirational and touches people. And it's not just me. I find it hard to find anything out there in the hundreds of pieces I read each week.
I Ride
I found this one from an unlikely source: my wife. I read her blog regularly, mostly to just keep in touch with how she's doing with horses. Typically she writes about how she's doing this or that with the horses, how the ride went, etc. It's one way that I learn more about her and see what she's doing in life. Most of the time when I follow her writing I think it's more for her clients and people working with horses than anything.
However when I read this post, I had to stop and read it again. I could feel the passion and it really meant something. It really touched me a bit, not because it's my wife, or because I like horses (I don't), but because the intensity of someone's emotion came through.
It's the type of passage I wish I could write more often.
When I first got my new laptop, I thought it was very cool. It included a fingerprint reader below the mouse pad. I was excited to start getting myself set up and using that to log in.
But then I started thinking. What if someone hacks my laptop with a trojan of some sort and copies my digital fingerprint? That's the type of information that it might make some sense to steal at some point and keep around. Why I'm not sure, but what if they could use it somehow? What if they could send my fingerprint somewhere to some system that mattered? That's not something I can change, unlike a passcode or a smartcard.
My concern in the editorial was mostly a trust issue, and I hope that came across.
Why did I write this? I got challenged by Andy Warren to write a bit about why I wrote something. I complained to him that he has some "mechanical" posts on this blog that just mention he wrote something with some questions, and don't really blog about why he wrote something. He challenged me to write about why I wrote something, so here I am.
With a large election year in the US (President + all the other races), I've been more interested than in some other years in the election process. I think it's an exciting time in the US with the chance to have a minority or a woman in the White House, something that has never happened before. Over the last couple months I've debated issues with friends, family, the kids have been interested and that's a good thing.
I love my country and I am grateful for the opportunities that it gives me. And I think that I shuld give something back, at least at times. It's important to me to vote every election, and I'm proud to do so. Two years ago when we had a fairly minor race, I took my daughter (then 5) with me to vote before she went to school. She liked it and I had made plans to do it again this year, including my 9 year old as well this time.
As we've talked about the election with the kids, told them how it works, etc., I've been trying to instill in them the importance of respecting your rights and responsibilities in this country, and participating in how things work. I want them to feel pride as well as responsibility to the country and it's gotten me thinking that I should participate more.
That's really the inspiration for this editorial. I didn't want it to be a political piece, or even a patriotic one, but more that the ability, and perhaps responsibility, to participate in those things that affect your life, or go on around you, whether that's work or home or anything else, is something that I hope you feel.
You can't do everything, but you can make a difference. Pick and choose according to what you can do, where your moral compass sits, or what is important to you, but help out when you can and pay it forward whenever you can. I think it's important and I think it comes back to benefit you at some point in life.
Only a small one, but I appreciate every one I get. Not often that I get to leave the site or shirk a few duties.
Today Phil Factor contributed an editorial for the newsletter. It was supposed to run yesterday, but for some reason it didn't get to me on Friday, so I scrambled Sun night to get the one done I had started last week. Not sure where things broke down, but I wasn't thrilled Sunday night. When it arrived Monday, I decided to run it and delay my need to get another one out there.
Hopefully I'll get a few more as ski season approaches :)
Late in getting this one out there, but it's interesting to see people's responses. Especially to my story.
As a kid we hear stories that we can do anything if we work hard enough. 35 years later, bum shoulder, bad joints, I realize that talent affects a lot of what we do as well. My dreams of playing sports or music likely wouldn't come true no matter how much I practiced because of the lack of talent. I can accept that, I'm not invincible, and never was.
But that doesn't mean I can't work hard or shouldn't. Physically I've felt a lot better in the last year than I have in the previous 3 or 4. I'm working my body harder and smarter and that's making me wealthier in that aspect of my life.
As far as in business, I've got a couple businesses going (JumpstartTV and End to End Training) and if one of them makes me a bunch of $$, great, if not, they're still doing well. I'll continue with my day job here at SQLServerCentral and I'm likely to always work. Be nice not to have to, but I'm not sure what I'd do with myself if I didn't have to work.
I've had a bunch of writings based on finances over the last couple weeks, and I've tried to spread them out so as not to overwhlem or bore people. Some people don't care and others are so deep they probably think I'm not looking at it enough. And this isn't a financial site.
In any case, my wife and I have talked about it, and we've been watching things. I haven't been too worried since we have a lot of time, but I've talked with friends about it, and they are of mixed opinions. It was during one of these conversations that got me wondering about the tech world and the impact. So I was curious how many people think they affected, are are really affected. If you carry consumer debt, then it might be an issue, or if you have an ARM on your house.
I'm actually wondering what most of my audience thinks about it from people in my field, people that work for a living and are somewhat counting on fund managers and companies to take care of them.
