A blog article on blogging (celebrating one year of 'End of Line')

So, my blog turned 1 recently (on October 31, to be precise). As a present, I decided to devote it an entire article. I’ll talk about the principles behind starting it, what were the initial goals, analyze some numbers, and try to come up with an idea of what it might look like in the future. I’ll also share some of my thoughts and experiences on blogging and the writing process in general. 6

(I’ll explain what the numbers at the end of the paragraphs are later in the article) 2

The goal 2

Starting a blog was on my to-do list for a long time (like for a lot of programmers, I think). I didn’t really have a big set of topics ready to go – just some general conclusions about programming that I came to in the course of my career (a good example might be the “I like checked exceptions” article) that I wanted to share, and maybe get feedback on. I also wanted to address some issues I kept having recurring discussions on, so that next time the topic came up, instead of repeating myself, I could say, “Read this blog article” ;p. I did, however, have some specific technical objectives I wanted to achieve. 7

The first one was writing a custom application for this purpose, instead of using some ready-made blogging platform. The main reason for that was that I wanted to learn a completely new technology stack. I chose Ruby on Rails, as I heard a lot about that framework, and I was curious whether reality matched the hype. It was also as far from my day-to-day Java technologies as you can probably get, so it seemed like a good learning experience. 4

The second one was that I wanted to do all of the CSS myself, and starting from scratch – not using a framework like Bootstrap, and without the crutches of basing it on a preexisting template. I think styling (and design in general) is one of my biggest weaknesses as a developer, and so I really wanted to use starting a blog as an opportunity to improve in that area. 5

All of that meant that the process of getting the blog up and running took quite a bit longer than I would have liked. The resulting design, I’m sure you’ll agree, is also nothing to write home about. However, I don’t regret it one bit – and actually, I’ve already used some of my improved styling skills in a small contracting job, so I feel the time was well spent. 3

The journey 2

So, I finally managed to get the blog online. I didn’t really expect a lot of people would read it – probably my colleagues (if only out of courtesy to me), perhaps some diligent recruiter from LinkedIn, maybe my girlfriend if she felt particularly kind to me on that day (she’s not technical). I didn’t even bother with setting up Google Analytics, figuring staring at a bunch of zeros wasn’t really worth the trouble. 2

All of that changed when I linked to the “GitFlow considered harmful” article in this Reddit comment. Pretty soon, the article was posted to /r/proggit’s main page and Hacker News, where it climbed to the #1 spot and stayed there for several hours. My laziness with Analytics bit me hard – I got it working like 2 days later, and the traffic was still in multiple thousands of unique visits per day. I would love to know how much was it in the peak. 3

That was an awesome experience, and really motivated me to keep working on the blog. It’s one thing to put your ideas out there, but to have them be read and validated by so many people felt great. The GitFlow article (and the follow-up to it) remains to this day the most popular piece on the blog, by far. I just hope it wasn’t a one-shot deal, and some day another article will surpass it in the number of page hits (or, at least, get an entry in the ‘Comments’ section ;p). 2

The learnings 2

My original target was to publish one article per month. I’ve failed pretty miserably at the goal, managing only 9 in that first year – so, 75% of the plan. 5

My blogging hero is Steve Yegge (I think every blogger should have a blogging role-model – this way you have something to aspire to). In his classic “You Should Write Blogs” piece, he says something very interesting: that if he can’t write a blog entry in one sitting, he feels like he doesn’t have something concrete enough to say. That’s fascinating to me, because I can’t imagine finishing an article in one go. Even the simple “Bash initialization files” one took me, if I recall correctly, three evenings from start to publishing (I would estimate the total number of hours spent on it to be around 6). This just confirms something I was aware of already: that I’m very slow at writing articles. It also explains why I wasn’t able to meet the, let’s be honest – not too ambitious, goal of 12 articles in a year, although certainly working on Oxyjen and good old-fashioned laziness had something to do with it as well. 6

So, the question is: why is writing articles taking me so long? Some of the reasons are certainly quite involved, as I can trace them back to my school years – essay assignments were also always costing me a lot of time. I’d say it has a lot to do with the way I think. I generally don’t think in words, but rather in concepts. Which means I know, somewhat intuitively, what I want to convey in an article. However, when actually sitting down to write it, I need to translate that internal representation into English, making sure I don’t lose anything important in the process. That is a difficult thing to do! 3

Because of that difficulty, I do it iteratively. I’ll usually start with writing a paragraph (sometimes, although rarely, more than one), concentrating mainly on getting all of the ideas I want to communicate down, without worrying too much about style, flow etc. Then, I go back and edit the text until it reads well, has no grammatical errors (although I’m sure I miss some), doesn’t repeat the same vocabulary to close to each other etc. – polishing it, you could say. Sometimes, this “refactoring” alters the structure so much, the changes ripple out to the earlier parts, and they need to be edited as well. 4

Another thing I like to do is to periodically re-read the article as it’s forming (either from the beginning, or going back one or more paragraphs from the one I’m working on currently) . This way, I can look at the finished parts with a sort of fresh pair of eyes. This re-reading often results in changes, as things don’t flow as well as I thought they did, or the overall message of a fragment is different from what I planned, or I simply forgot to mention something I consider important. 5

The experiment 2

As you can see, this process includes a lot of re-reading and editing of already written text. And this is where we come to the numbers at the end of the paragraphs. As an experiment, for this article, I decided to write down how many times I changed each paragraph after it was written (I do it in “real time”, incrementing the counters after each edit). 4

The results are pretty telling – not a single paragraph made it through in it’s original form, and some of them were edited a pretty absurd amount of times (seven edits? Really?). When learning fast reading, one of the first things they teach you is that re-reading is a fundamental barrier to increasing your reading speed. It only makes sense that re-reading (and re-editing) slows you down when writing as well. I somehow doubt Steve Yegge edits each paragraph seven times when writing an article in one sitting. 3

If I want to produce more content (and spend less time doing it), this is something that I have to address. Jeff Atwood, another famous blogger, said that when he was starting, his goal was one article per week. This is a figure currently completely unattainable for me (unless I quit my job and become a full-time blogger – which he didn’t envision for himself when setting that goal). I think I’m faster then when I started the blog, but I still have a long way to go. 3

The future 2

They type of article being written is also a big factor in how fast I can produce it. The fastest are the ones which have a concrete goal in mind – both “Benchmarking Java 8 Streams” and “Follow-up to ‘GitFlow considered harmful’” were written in one day (not in one sitting though). Conversely, the one that took the longest – literally weeks – was “ORM Entities should be an implementation detail”. This is a topic that was on my mind for a long time – the problem was that I didn’t really have a plan on how to present it before starting to write the article. That meant that the structure for it was emerging at the same time I was doing the writing, and it actually went through several iterations before I settled on one. I was pretty happy with the final result, but it failed to generate any waves with the audience, so I guess something was (is?) still missing. 2

In the future, I want to focus on writing smaller, more concrete articles, in the vein of “Bash initialization files”, instead of the more general (and thus more time consuming and less useful) ones like “ORM Entities”. The good news is that I’m slowly making my way through my bucket-list of saved-up big Computer Science ideas (the recent “Testing with Doubles” was another one), and so doing it this way should become easier as time passes. 2

As for the goal for the second year of the blog, I won’t be too ambitious. Anything above twelve articles total (so more than one a month) I’ll consider a success. It would be fantastic to put out two per month, but realistically speaking, I don’t think I’m there yet. 2

The closing thoughts 2

In the end – was starting a blog worth it? To that, my answer is a definite ‘hell yeah’. Blogging is an awesome way to grow as a programmer. Even if nobody reads what you write, it adds structure to your knowledge, and forces you to deep-dive on things you previously had only a superficial understanding of. Putting things in writing also necessitates a certain level of clarity that you have to attain beforehand. And if somebody does stumble upon your work, the feeling of achievement on hearing their feedback is AWESOME. 4

I honestly believe writing and coding have more in common than it might appear at first glance. I heartily recommend blogging to any software developer looking to expand his comfort zone a little bit. 2