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.
Four Things Our Developers Wished They Had Known On Their First Day
As part of our onboarding process at Quick Left, we meet with recent hires after 30 days and ask them several questions about their experience so far. One of the questions that gets some of the most interesting reponses is: "What advice would you give yourself on your first day?"
After six years in business, we've asked this question quite a few times. We recently took some time to read back and analyze the responses we've gotten. When we looked closely, some trends started to emerge. Interested in finding out what it takes to be a software consultant? Read on to find out the top four pieces of advice our devs wished they had gotten on their first day.
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!