DEV Community: Ben Roux

Untold Benefits of a Software Blog

Ben Roux — Fri, 06 Jan 2017 16:35:03 +0000

This post originally appeared on Ascent.

Starting a software blog can feel out of reach to most. Without readers our time will be wasted, right?

Wrong.

Thousands of dollars. That is what blogging about software will make you, even if no human being ever reads your blog. Not hogwash. At first, readers may seem like the "goal" of blogging, but they are actually a natural result of it. Along the way will be plenty of other personal benefits, including better jobs.

Deeply understand your own opinions

Whoever said, "you do not really understand something unless you can explain it to your grandmother" never tried detailing their opinions to a text file.

The first thing you will notice when writing about software is just how incomplete our thoughts are. We are conceptual creatures and we think in abstract about software. Intuitively, we fill in those blanks in our mind.

In many ways our feelings about software are like dreams: they make sense when you are actively involved, but when you try to transcribe them, you notice holes everywhere. That is not to say they are unrealistic or contradictory. Just... incomplete.

Blogging forces you to take the time to fill in these blanks. Filling in the blanks forces you to think critically about your own opinions. The result of these activities is a far deeper understanding about topics you previously considered yourself informed enough to write about. This manifests externally, too. You will find yourself speaking with more perspective and confidence about topics even tangentially related to your blog posts.

Learn to communicate empathetically

There are two ways to communicate an opinion: from your point of view or from the point of view of the person you are communicating with. The first is easy but useless. Remember those college professors who were clearly brilliant yet no one could understand them? They were not teaching from the point of view of their students. As a result, their brilliance was lost on their audience.

As domain experts in our own right, we should be afraid of this. We are not protected by some software tenure. People take the time reading blogs to learn new ideas, expand their perspectives and keep up to date with the ebbs and flows of technology. Learning to communicate your ideas effectively to any audience is a crucial part of making your opinions approachable. It also makes you a better communicator.

My spoken communication skills have improved since I started blogging. Not because I have learned to "dumb things down". You learn to pay attention to which details are applicable and which are not. You learn to explain concepts from the mindset of the audience. It changes how coworkers and even clients perceive your command of the topics.

Build your credentials

One thing I assumed about bloggers is that they know their shit. I mean, they must. They have a blog with hundreds of posts. That doesn't just... happen.

But it does just... happen. And people who blog a bunch do know their shit. Cause and effect plays a role here, though.

People don't start blogging because they passed a test and got a membership card allowing them to do so. Bloggers appear to know their shit so well because they have benefitted from the above points. The more you blog the more you fill in the gaps in your understanding and become at communicating.

Armed with better understanding and communication skills, client relations improve. You are more valuable asset to your team. Interviews seem to get easier. Being able to point people in the direction of your blog skips a lot of the credential questions that so often plague tech interviews. Better understanding, more valuable employee. More valuable, better job. Better job, more pay. It's a beautiful thing.

Starting a blog

To the uninitiated, blogging feels like a nonstarter because you will have no readers. Little do people know, readers are the motivational fuel the drives the blog. They are the gas in the car, not the destination we are driving to.

I will do another post on the steps to getting readers and setting up a blog. To those eager (good for you!), I will point you to Ghost and some free themes for it. It is free, open sourced, runs on Markdown, and has excellent documentation for getting it up an running.

In fact, I have liked Ghost so much that i've even started installing it for clients who need blogging platforms.

I suppose that is another benefit to blogging. They just keep on coming.

tl;dr: Blogging has valuable lessons long before you get your first readers or ad revenues. These are some of the most important ones.

Side Projects - Avoiding Failures to Launch

Ben Roux — Wed, 28 Dec 2016 22:07:11 +0000

This post originally appeared on Ascent

The story is a familiar one.

An excellent idea, simple but valuable. A fresh codebase, like a world of possibilities. A side project is born. A weekend of delivered pizza and whirlwind coding lays the foundation of something wonderful. But then the novelty fades. Productivity slows. Eventually, between work and family, progress all but halts. Momentum is lost. But then you have a new idea. This is the one. The cycle repeats.

Momentum is everything to side projects. Keeping it can be hard. The trick is two fold: avoid things that lower momentum and keep your scope small enough that it completes before momentum runs out.

I have built many side projects. Most have never launched. But for each failure to launch, at least one of the mistakes in this article is the cause. Over the years, i've learned what to avoid.

My newest endeavor, detextion.io, was built atop these lessons and has grown to be my most successful project. Its success is due in large part to not repeating my past mistakes. I hope that they can help others avoid the same traps I spent years discovering the hard was.

Pick a familiar stack

Easily the biggest roadblock to launching a side project is starting with a stack you are not familiar with. While side projects are the correct place to play with new techs, projects you intend to actually launch are not. When you start a side project, ask yourself if this project is for experimentation or launching. If you pick launching, pick a stack you know. Period.

The reason for this hard and fast rule is all about momentum. Nothing kills momentum quite like those moments when you think to yourself "how do I do this? it would take me 2 lines in...". Don't fall into that trap. I firmly believe every time you have to google a code question, you are a little less likely to complete that side project.

Release before you write code

As soon as you pick your stack and initialize it, release it. Yes. Seriously.

Momentum is rarely as strong as when you are starting a project. This means it is a great time to get this necessary evil out of the way. The last thing you want is to have to start a release process 3 weeks into a project only to find you have production specific issues. Don't play that game.

Pick where you want to release to and get that out of the way early. Wait too long and it just isn't going to happen. Just as we selected a familiar stack, this is also a good time to select a hosting environment you are familiar with. If heroku has treated you well in the past, go with that. If you host your own server, bully to you and host it there. Wherever you choose, release it about as soon as you initialize a project and database.

Build a buy button

Not adding buy buttons to my projects is the single biggest failure of my professional career. While many of these points are about avoiding momentum losses, adding a buy button is a huge momentum boost.

Integrate Stripe. It will require a EIN Number. It takes all of 5 minutes to get it via an online form. A rare example of government efficiency. A beacon of hope in a swamp of... I digress.

The day you are able to run a test checkout and see the revenue graph jump up is a great day. The mere possibility of earning money from a site you build is a powerful driver that is too often ignored. Do not deny yourself this boost.

Furthermore, side projects need not be charity labor. Your time is worth more than you are being paid in your normal job. That said, your side projects ought to at least have the capability of collecting money.

So build a buy button. I'd argue you should build it before even adding the core feature(s) of your site.

Embrace moments of genius

I find coders go through waves of productivity. We tend to associate those waves with moments of inspiration. A more accurate statement would be that our thought process shifts over time those inspiring moments are when it shifts to the mode we are trying to work in.

There are 4 distinct types on thinking in building a project:

Feature building (Problem solving)
Styling and copy writing (Creative presentation)
Validations and bug fixes (Mundane tasks)
Manual testing (Critical thinking)

When you are working on a side project, you do so in short bursts. Learn to recognize where you are mentally when you start a work session. When you do, allow yourself to work in your current area of genius.

Not only will the regular context swaps keep you from feeling like things are dragging on but it is also a more efficient use of your time.

Clearly describe your product

When you have one of those early creative moments, start off by writing down some basic descriptions of your product. What problem does it solve? Who is it for? Why is it a joy to use?

Reason being, side projects, practically by definition, rely more on first impressions and self-service than traditional sales efforts. To facilitate this, you will need a marketing page that clearly and concisely presents your product.

I place emphasis on "concisely" because it is a challenge. This is why I suggest writing these blocks of text early, even if they are presented with a single line of CSS.

If you have some draft copy written, you will find yourself returning to it as your own understanding of the project grows. These revisions often involve little effort but pay big rewards in the final product. But it isn't possible without an early draft of your marketing copy, so scribble some ideas down early.

And just like above, ignore the CSS until you are inspired. Trying to style the font page to a side product when you aren't feeling particularly artsy is a great way to frustrate yourself to hell and back.

Get feedback

Ok, real talk for a moment. We wranglers of the 1's and 0's tend to suck at this. We are either too introverted or weary or overly confident to ask for real feedback about our projects. But if there is one thing I have learned, it is that there should be no ego when building products.

The fact of the matter is every product is wrong until it is solving problems for a lot of people. Until then it is either missing the mark or isn't done yet or isn't being shown to the right people.

Once you have a working version of your project it is time to find out what is wrong with it. Start with friends and coworkers. Move on to prospective customers. Make people sign up and read your marketing. Ask them to be ruthless in their answers to you. While praise is encouraging, our product doesn't get any better because we are sitting atop our high horse. Critiques are what we need now.

Personally, I list out everyone's feedback in bullet points. Trends will emerge. People will be confused about a feature or label. People will wonder what some sentence on your marketing pages means. They will get stuck. These stumbling points should be your highest priority changes. You are better off having an under-featured product people understand than a fully featured one that confuses them.

Ship it

Finally, ship it.

In truth this is the single most important step. Everything else here is a way to achieve this end. So did you skip some of the above? Who cares. Ship it. Do you still have a list of features you would like to add but don't absolutely need? Ship it. Are there some style issues on IE9 that one person you asked for advice from told you about? Ship it.

As developers we have this strange illusion surrounding our personal projects. We feel that releasing imperfect projects would diminish our reputation, or some such nonsense. Let go of those inhibitions.

The sense of accomplishment that comes with releasing a side project to the world is one worth experiencing. The lessons you learn along the way about scope, refinement, feature cutting and product presentation are invaluable to companies you are and will work for.

The old adage is that invention is 10% inspiration and 90% perspiration. Many developers will have the inspiration about a great product. Few take the steps to see that idea to fruition and reap the benefits that come from it. But they are real and worth it.

So take your idea and get it rolling. Build some of this momentum we have been talking about. The finish line could be only weeks away.

tl;dr: Side projects are notoriously hard to finish. These are the best ways to complete and launch them.