In this three part series, we're exploring what it takes to break into the technical blogging space. In the first part, we looked at initial steps you can take when preparing to write. In the second part, we explored how to to get into a good writing flow during the actual writing itself. In this, the third and final part of this series, we'll talk about one more aspect of how to write a technical blog post: getting as many people to read it as possible.
In this three part series, we're looking at some of the best ways to get into a good flow as a technical blogger. In the first part, we talked about some initial steps you can take to get psyched up when figuring out how to write a technical blog post. In this, the second part of of the series, we'll talk about how to do the actual writing itself. We'll explore some effective structures you can use to organize your posts, thoughts about the creative process of writing, and how to make sure your content is as good as it can be.
Content is king. Bill Gates predicted it in 1996. Much of the money made online today is in content. In the tech world, where languages and frameworks are here today and gone tomorrow, this is doubly true. Developers, managers, and CEOs of technical companies spend an enormous amount of time understanding their chosen tools, the next hot thing, and how to stay relevant.
It's no wonder so many startups host blogs on their sites. Blogs drive traffic to your site, increase your visibility, and elevate your brand in the tech world. So how can you get a piece of the action?
In this three part series, we'll explore some strategies you can use to generate ideas, produce clearly written blog posts, and effectively promote your work on the internet. In this, the first part of of the series, we'll talk about how to get started as a technical writer: overcoming mental resistance, generating ideas, and starting with your audience in mind.
The tech world moves fast. It's not uncommon for a startup to scale from two people in a coworking space to a team of thirty or more in a matter of months. Just as often, the team shrinks again due to sudden market changes or errant developers moving on to the next big thing.
When you're getting ready to rebuild, it can be hard to know where to begin. There are so many things to do, from marketing, to onboarding a new team, to deciding what to build next.
In part one of this series, we talked about some of things you can do on the technical side to get your dev team up and running with a minimum of fuss.
In this, the second and final part of this series, we'll focus on how to prioritize your best features. We'll look at how to decide what you should get rid of and what you should pull out into its own codebase. Then we'll tackle the question: what to build next?
Remember the glory days? Your company had it all! New signups every day. Coverage on the hottest blogs. Money was rolling in hand over fist. All thanks to your hot app. You and your goons really nailed it when you followed an MVP process and built just the thing the market was looking for.
But then something happened. You shifted focus to integrating with another company's API. Or you lost your entire developer team. Slowly, kudzu vines covered over what was once a glorious app. The technology you used to build grew outdated. Bugs accumulated, but there was no time to fix them. You shed a single tear when you thought back to the glory days.
Finally, a new day dawned! You got a funding round! You've just hired a new team of developers. They start next week. You can't wait to get them slinging code. But are you ready? Starting a new team on an old app isn't as easy as handing them laptops and saying "clone down the repo". In this post, the first of a two-part series, we'll take a look at some advice you can use when ramping up developers on code in a legacy application. When we're through, you'll be ready to let the good times roll again!
- ← Previous
- Next →