A few years ago I started blogging and I try to keep doing it weekly or bi-weekly. Why? What’s the point? Why spend time on this? What do you gain?

Spread your way of coding — inspire

Everyone of us has its own taste and list of acceptable hacks. By blogging, I make sure that in Arkency, and in other companies that I somehow influence, my way of coding is known and propagated by other developers.

Think about Uncle Bob, Martin Fowler, and Michael Feathers or Sandi Metz. They influence thousands (if not millions) of developers around the world. You might not always agree with them, but they truly believe in how they try to change the community of developers. By writing and speaking about the code they show others what kind of code they value and what steps to follow to reach it.

In every programming community, there are smaller groups built around certain ideas and techniques.

In Ruby you can follow DHH and classic Rails-way, but there are also alternative libraries and approaches such as dry-rb, roda, hanami, rails_event_store. All invented by some developers who have different taste, different needs. The more they are used, the easier it is for them to consult or operate in some projects and enjoy programming. As you probably already feel that programming in a paradigm you don’t like can be frustrating.

In JavaScript/Frontend community there are many ways to deliver nice apps. You can use React, Angular, Vue, Ember and much more. How do you make sure that the one you enjoy more keeps being chosen? By spreading the word and showing other developers how to solve most common problems with it. By contributing. Articles, books, and tutorials are equally important for adoption as code quality or number of features a library/tool has.

But even if you choose (say…) React, there are still many technologies around. Do you use Redux, Mobix, or something else? Do you use immutable.js? But wait, you can also go with ClojureScript and Reagent.

The point is. By blogging about your choices, their pros, and showing the code you like, you influence others in your team and in the whole world to write code similar to what you like.

And I mentioned very high-level decisions like libraries, frameworks, and languages, but it can come down to much smaller aspects such as longer vs shorter methods, a number of arguments, named parameters, inheritance vs composition.

For me, it is always very satisfying when another developer from Arkency, working on a different project, links to my blog post in a commit message as a way to explain where someone can read more about the technique or rationale behind a certain change.

Tell about interesting books and techniques — inform

There are so many books, resources, courses that we, developers can spend time on. If I say that I enjoy 99 Bottles of OOP by Sandi, it means that I checked and vouched for it. Instead of spending time myself showing others how to TDD and refactor step-by-step, I can just point out to this lovely book.

The more developers know and read, the smarter they are, the easier the job is for everyone in our industry.

I believe programming is hard. The tempo of changes and tools evolution is enormous. Everyone wants to stay updated. On the other hand, there is a lot of fad and many concepts are just re-iteration of something invented years ago. Some topics are very complex and there is a lot of misinformation (for example recent hot discussion about exactly once delivery).

For example in http://blog.arkency.com/2014/11/dont-forget-about-eager-load-when-extending-autoload/ I explained how adding

config.autoload_paths += %W( #{config.root}/app/services )
config.autoload_paths += %W( #{config.root}/app/presenters )

is unnecessary in Ruby on Rails. I have seen this repeated dozen of times in other blog posts or stack overflow answers.

Show your unique path — be an example

Every one of us is on a long journey to mastery. First in one language, one framework, then often in other languages (we always believe another language out there is better and is gonna solve our problems).

You might be thinking that you are a junior, who just started and there are millions of better devs out there. But your point of view and your way of expressing can be unique. There is a bigger chance you will connect with people from the same country, same age, same sex, etc. Yes, you can inspire thousands of people not like you, but you have a higher chance of reaching those similar to you than I have. That’s why there is space for everyone in blogging.

People with very little experience can much better show how they struggled with certain topics, what was hard for them and where are the traps and non-obvious parts compared to experienced programmers. Don’t follow into the trap that what you write about is obvious. For many developers out there it is not.

Document progress and expertise — prove

The reality of our daily work is that usually we program closed applications and we can’t present the code just like that. Even though many of us dream about doing open source, we often don’t. In such case how can we document what we learned, how can we present our experience and the expertise we gained? Even if we do our best, not always (I would even say very rarely) the projects that we work on succeed (financially or otherwise). So it is rather hard to build a portfolio of successful projects that you were part of. The success depends on whole teams, marketing, managing, market fit and much more circumstances. How do we prove we learned something useful and that we are better programmers than last year or two years ago?

If you blog from time to time, bi-weekly, you can show what kind of challenges you faced, how you decided to attack them, which techniques and tools you used and which you avoided. After one year you have 25 topics where you provided others with useful insights and show how you approach problems.

If you need to change team or company, you can now point tech leads and recruiters to your blog.

Learn expressing ideas and writing — get better

This is one of the surprising effects. By writing more you learn how to better express yourself and your ideas. I’ve met some nice, good programmers who seemed to have interesting points about app architecture but they could not articulate them in a way other developers or management would easily understand and grasp. Many programmers claim that writing articles help them also write a better code.

P.S.

We will be soon releasing a 90 minute video from Blogging for busy programmers workshop. It’s all about how to blog and not spend hours of time on it. Subscribe http://eepurl.com/cVc_-n and we will tell you when it becomes available.