I like Paul Mooney, because Paul actually takes action.
While other people are sitting around talking about doing things with their life, Paul is actually out there makings things happen.
Paul purchased my “How to Market Yourself as a Software Developer” course, but he didn't just read the books and watch the videos, he took action.
In fact, he went as far as to talk to some of the popular round-up bloggers like Alvin Ashcraft and Chris Alcock and got his blog mentioned in their posts.
After that, he reached out to the hosts of .NET Rocks and got on the podcast.
Once I heard about this, I had to get the story from Paul, so I did this video interview with him and asked him to write about it here as well.
Q: Who are you?
I’m the host of insidethecpu.com, a blog focusing on performance-optimisation and security. I design performance optimised frameworks, such as JSON#. I designed the latest defence mechanism against CSRF attacks, the Encrypted Token Pattern, and ARMOR, its .NET implementation.
Q: Why did you set up a blog?
I wanted to publish my work to a wider audience for critical review. Following John’s advice, I decided to establish insidethecpu.com and post regularly, to make my tools available to a wider audience, and to receive valuable technical and design feedback.
Q: What steps did you take to establish insidethecpu.com?
I bought John’s How to Market yourself as a Software Developer, and followed his advice to-the-letter! I have found the most critical elements to be consistency, and focusing on your niche.
Q: What kind of traffic do you manage, and how do you retain interest?
I started blogging consistently in January 2015, when I received roughly 50 – 100 hits per day. Now I receive 1,000 – 2,500 hits per day. The key to retaining interest is to consistently blog at regular intervals, while keeping your posts relevant and professional. Try to stay within the remit of your niche to keep your brand consistent, and ensure that passion comes across in your posts – there’s not much point in posting irrelevant, or stale material.
Q: You’ve interviewed on simpleprogrammer.com and dotnetrocks.com. How did that come about?
Well, I began by reaching out to various roll-up blogs, such as Alvin Ashcraft’s Morning Dew, and Chris Alcock’s The Morning Brew. They’re nice guys, and will include your RSS-feed if you’re consistent and interesting. I’d recommend starting out here, and posting on reddit. The majority of my traffic comes from reddit. In particular, C# and Java subreddits. Whatever your niche is, there’s a subreddit for it. Once I gained traction, I reached out to Chris at .NET Rocks, among others, who very kindly invited me to talk. As John points out; remember – these guys need to record every week, if not more frequently. Approaching them directly saves them time!
Q: Any other advice?
If nothing else, I can’t stress the importance of consistency, and sticking to your niche.
Q: Wait a minute; you’re a performance guy, but you run TDD and OOD tutorials!
Absolutely! Following on from my last point; if you really want to drive traffic, then you need a hook. Mine is a tutorial series that I run on Test Driven and Object Oriented Design in C# and Java. I argue that both of these practices lend themselves well to writing performance-optimised code, and therefore fall within the remit of my brand, if loosely! Though, as John points out, be wary of boxing yourself in with your hook.
Q: Anything else to add?
Try to keep things interesting. Include images in every post (nobody wants to endure endless walls of text), be a bit quirky (long as that doesn’t conflict with your brand), and have fun. Remember, if you have fun writing, it will come across to your readers.
Q: Any books you'd recommend?
I recommend this book: Design Patterns: Elements of Reusable Object-Oriented Software.
It teaches the fundamental concepts of software architecture and how they should be applied. I recommend immediately reading this book afterwards: Refactoring to Patterns.
It teaches how these concepts should not be applied, and how to tell when you've over-engineered something.