5 Years of Blogging About Software

5 years ago, I started blogging. I started really casually, my posts were personal reminders and notes rather than real well thought of articles. Nevertheless, it did me great good :

  • I’ve been invited to talk at meetups
  • I’ve had the joy of seeing some articles being tweeted many times
  • I received interesting job offers from all over the world

6 months ago, after reading Soft Skills: The software developer’s life manual, I set up the practice of writing at least one article per week, and here is my (very encouraging) graph of sessions since then:

Excuses Why Not To Blog

Here is a collection of the (bad) excuses you’ll often hear people say for not blogging :

I don’t know how to write …

Blogging regularly is actually a pretty good way to improve your writing skills. As usual, the key is to fake it until you make it.

I’m not into this social media stuff …

You don’t need to share anything personal on your software blog. In the end, your blog is a professional tool.

I don’t have anything interesting to say …

They are others in the same situation as you who would like to see more posts about the kind of uninteresting things you just discovered. Wouldn’t you have liked someone to have written the newby article about « how to do XXX » you just spent 3 days to crack ?

I don’t have the time …

Make it ! Time is never found, it is made. In the end, it’s just a matter of prioritization.

Obviously, there are other totally valid reasons why not to blog, but I’ll assume you’re able to recognize those.

Why Would You Blog ?

On the other side, if you jump into blogging, you can expect a lot of returns :

  • First thing is that you’ll obviously gain more visibility. I’ve got readers from all over the world, and my articles are sometimes re-tweeted many times.
  • You’ll improve your writing skills. Writing skills turn out to be unexpectedly important for software writers !
  • In order to lay down your ideas about something, you’ll need to dig a bit more into. It is said to be the last step to learning.
  • It can act as a personal documentation. I tend to use mine as a how-to notepad on which I can refer later on.
  • If you have a day job, you can re-post your articles there. I might gain extra visibility and expose the company to new ideas.

How to start

Once you’ve decided that you want to blog, starting should not be an issue.

Pick a platform

There are a lot of blogging platforms out there. For programmers, I would recommend a few though :

Platform Pros Cons
Octopress free, Open Source, Github hosting, static HTML generation, markdown & Git based, made for programmers Theming can be rocky
Medium free, no setup, good looking, simple to use It’s a private company, so it could close some day ! postero.us did so some day (I remember, I was there …)
Posthaven created by the founders of postero.us, sustainable, guarantees to keep it live for ever, can post by email ! nothing special for programmers, 5$ / month
Logdown looks like a hosted version of Octopress, without the hassle ! 50$/year

Then, it’s up to you !

Start with how-to articles

When I started my blog, it was mostly has a personal how-to reference. It allowed me to come back to it and find out how I did something last time. I thought that if it was important to me, it must be important to others as-well !

Blog regularly

Blogging every week made a huge difference to me. My traffic went from eratic to steadily increasing. I am currently observing a 11% traffic increase per month. This means that it nearly quadruples every year : I’m not going to stop now !

Integrate with the web

This boils down to social networks and analytics. Obviously, you’ll want to use Google Analytics to see how people are reading your content. I’m using the venerable Feedburner to automatically post my new articles on twitter. There’s an option to use your post categories as hashtags, be sure that works, it brings a lot of traffic.

The Size of Code

The CFO’s debt is visible in his balance sheet. The CTO’s technical debt is invisible. What about making it visible ?

Developers have an intuitive sense of the technical debt in some parts of the system. But few have an accurate estimation of its full extent. Even the size of a code base is difficult to grasp. In the same way, the size of the code is just a number. But the fact are there : between 10 000 and 10 000 000 lines of code, the rules aren’t the same, but it’s only invisible data on hard drives …

Showing It

If we had a device or a trick to show to non-developers the size of the source code, people might start to feel the embarrassment of working in a bloated code base. Unfortunately, for the moment, the only ideas I had are somehow unrealistic, albeit funny !

First Idea : Printouts

Suppose we printed all the source code every Monday, and then keep it around for everyone to feel its size. We could leave it in the middle of the place, or in the CTO’s office, so that he’d actually be hindered by the space loss. The larger the code, the bigger the troubles.

It’s possible to print 50 lines on a sheet of paper, that’s 100 on both sides. That’s 50 000 in a pack of 500 pages. And eventually, 200 000 in this kind of standard case :

Keeping these printouts in sync with the real cost would make the thing even more painful realistic. Imagine all the printings costs, and moving around cases of paper every day … ;)

Second Idea : Inflatable Device

What about an inflatable device linked to SonarQube (or any other code metrics tracking system) ? It could grow as new code is written. We could make it as large as we want : 1m3 for every 10K lines of Code, making the whole office a difficult place to walk around. Try to figure out how to work with this thing in the office :

Third Idea : Sand

For maximum pain, let’s use real sand instead of an inflatable device ! Imagine the mess with some sand lying around in the office. If the only way to clean up the mess was to clean up the code, surely everyone would take the issue seriously !

Final Word

Obviously, these are jokes, but I guess there’s a real need there. If we managed to make non developers feel the size and cost of the code base, it would be easier to agree on priorities.

Legacy Code Coverall Day

Some days, coding feels like speleology or mining … Dealing with weird and undocumented old logic can even some time be damaging to the mind ! I think we should go to work wearing the adequate protection !

OK, maybe we cannot start to go to work wearing a coverall everyday, but let’s say very 21st of June is now legacy code day, the day when every developer maintaining legacy code comes to work dressed like that !

Obviously, that’s a joke, but it could attract the attention of other non-coding people on the state of their codebase and amount of their technical debt.

Anti Ugly-Code Glasses

I think I found a way to fix the dirty code problem once and for all …

In The Hitchhiker’s Guide to the Galaxy Zaphod Beeblebrox has some anti panic glasses. They feature some special danger detection mechanism that turns them opaque black to save their bearer from panicking.

(It turns out that Zaphod has two heads …)

In 2016, it’s shocking that some many hours are lost by poor developers reading ugly code.

Let’s build anti ugly-code glasses ! We’d just need an IDE or editor plugin, connect it to Sonar in order to get the quality of the current file, and if too bad, shut the glasses black !

Finally the killer feature for augmented reality glasses !

How to Keep Up With Software Technologies

Since I started to program professionally 15 years ago, a lot of things have changes. A lot of technologies appeared and became mainstream while others fell out of fashion.

As software developers, it is really challenging to stay fit and productive in new technologies. I cannot obviously say that I am an expert in all new technologies, but I can say that I can get up to speed in a pretty short time in nearly all.

If there is a single reason for that I strongly believe it is because “I studied my classics” !

How does it work

At the same time I started to program all day long for my living, I also started to read a lot of programming books on my spare time. This allowed me to learn at night and practice at day, setting everything in my brain.

This might come as a surprise, but I never read a lot of books about the technologies I was using. I’d rather study fundamental programming books. These contain a lot of transportable knowledge, unlike in most books about a particular technology.

I believe this is a pretty good use of time since it made me a better programmer and also greatly reduced the time I need to master most new technologies. I can now easily relate them to some more general concept I learned before.

For example, I never read a book about UI. By the time I had to do some UI programming, I had absolutely no issue getting up to speed on the topic. I had already seen quite some UI code examples in other books, I knew that most UI frameworks are built from a set of Object Oriented patterns. Coming from a different perspective, I was even able to suggest improvements to the code that UI experts had not thought of.

That’s not to say that I never read books about a particular technology, sometimes, that’s just what you need to start something new. But when I do, I usually find them quite easy to read and digest. And I tend to skip things I intuitively understand and use them as cookbooks containing recipes for particular problems rather than end to end walk-through.

My books

The Pragmatic Programmer: From Journeyman to Master

As a young programmer this book made me understand that my job was not only about writing code, but about building maintainable systems. It provided me with tools to do so, 10 years later, I can still remember “The power of plain text”. This is also the book that made me have a first look into Ruby :).

Refactoring: Improving the Design of Existing Code

Here is the theory behind all automated IDE refactorings. Reading this book had a profound influence on my coding style. The examples made me understand the difference between readable and unreadable code … It’s also the foundation for any kind of incremental design and architecture. That’s the book that got me started with TDD.

Domain-Driven Design: Tackling Complexity in the Heart of Software

This book teaches good object oriented programming. Some say it is tough to read, but it’s definitely worth doing so. Among other things, it explains how to use functional programming concept in your object oriented project, by separating Value Objects and Entities for example.

The C Programming Language

With around 250 pages, it’s pretty difficult to find a programming book with a greater value/page ratio. This one will teach you all there is to learn about C, and help you understand everything that was built on top of C (and that’s quite a lot …)

Structure and Interpretation of Computer Programs

Compared to C, Lisp is at the other side of the language spectrum. Learning C and Lisp gives the ability to put nearly anything in contrast to these 2 languages. Lisp is dynamic, functional and meta. It can be morphed into nearly anything and SICP teaches how to do so. There’s a Lisp practice that is invaluable to any programmer : use your language to express your problem as simply as possible. SICP teaches that.

Programming Erlang: Software for a Concurrent World

Neither the C book nor SICP deals with distribution and concurrency. That’s what this book does. I had never programmed distributed systems before reading this book. After I read it, I learned how to code for distribution in a maintainable way. The lessons taught by Erlang are applicable in many languages.

Not the best books

I did not and will never read all programming books available. There might be newer books that treat the same subjects better, but these books are the ones that taught me the most about our craft. My point is that learning fundamentals and things far away from our daily technologies will teach us more.

Software Is Like Writing and Revising a Giant Book

With time, I discovered a way of explaining the subtleties of my developer job to my uninformed relatives and friends.

Sharing what your developer job is about with others can be very frustrating. Some people think you are “Just playing around with computers” as if it was not serious work. Others think that it is an extremely Cartesian and solitary activity with no place for communication or creativity. Trying to explain the diversity and richness of a developer’s work is often a disappointing experience.

The book metaphor

I explain to people that writing software is not unlike writing a huge book. A book long many millions of lines. I explain that the challenge is to maintain the whole story of the book coherent. I stress how difficult this is given that no one can take the time to read the full book, that the authors come and go, and that the book is under constant heavy revision.

Details of our work

The metaphor is quite valid and even holds about more subtle aspects of our work. Here is a summary of the last discussion I had about the book metaphor :

  • (Him) Do you have some ‘gatekeepers’ for different sections of the story to make sure that these parts remain coherent ?
  • (Me) That’s what we would call strong code ownership, this was the norm 20 years ago, but that the industry is moving to more collective code ownership, in order to decrease the bus factor.
  • (Him) What is the bus factor ?
  • (Me) The number of person who need to be hit by a bus to block your development progress
  • (Him) I see, that’s kind of funny. But then, does that mean that any developer can change any part of the code ? Isn’t that dangerous ?
  • (Me) Sure that would be difficult, that’s not really how we do it. We make a lot of efforts to split the big story in many smaller independent ones as much as possible. This way, teams specialize on different ‘chapters’ and work collectively within it.
  • (Him) I see
  • (Me) And if you need to change something in another ‘chapter’ you should ask the guys who know it better to help you.
  • (Him) That makes sense. And what happens if two developers want to modify the same part of the story at the same time
  • (Me) That can happen. People might even want to modify the story in conflicting ways ! We’ve got tools, processes and best practices to minimize this. If nothing is done, we’ll get what we call a ‘merge conflict’.
  • (Him) Ho … I wouldn’t have guessed, but it seems collaboration is really important in your work, isn’t it ?
  • (Me) Sure it is !

We are software writers

All this reminds me of DHH’s talk about writing software :

How I Fixed the Unknown Language Pygments Error in Octopress

Last time I tried to insert a code snippet in my Octopress blog, I was hurt by the following error :

vagrant@ae4a04cebb73:/vagrant$ bundle exec rake generate
## Generating Site with Jekyll
unchanged sass/screen.scss
Configuration from /vagrant/_config.yml
Building site: source -> public
/vagrant/plugins/pygments_code.rb:27:in `rescue in pygments': Pygments can't parse unknown language: ruby. (RuntimeError)
  from /vagrant/plugins/pygments_code.rb:24:in `pygments'
  from /vagrant/plugins/pygments_code.rb:14:in `highlight'
  from /vagrant/plugins/backtick_code_block.rb:37:in `block in render_code_block'
  from /vagrant/plugins/backtick_code_block.rb:13:in `gsub'
  from /vagrant/plugins/backtick_code_block.rb:13:in `render_code_block'
  from /vagrant/plugins/octopress_filters.rb:12:in `pre_filter'
  from /vagrant/plugins/octopress_filters.rb:28:in `pre_render'
  from /vagrant/plugins/post_filters.rb:112:in `block in pre_render'
  from /vagrant/plugins/post_filters.rb:111:in `each'
  from /vagrant/plugins/post_filters.rb:111:in `pre_render'
  from /vagrant/plugins/post_filters.rb:166:in `do_layout'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/lib/jekyll/post.rb:195:in `render'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/lib/jekyll/site.rb:200:in `block in render'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/lib/jekyll/site.rb:199:in `each'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/lib/jekyll/site.rb:199:in `render'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/lib/jekyll/site.rb:41:in `process'
  from /vagrant/vendor/bundle/gems/jekyll-0.12.1/bin/jekyll:264:in `<top (required)>'
  from /vagrant/vendor/bundle/bin/jekyll:22:in `load'
  from /vagrant/vendor/bundle/bin/jekyll:22:in `<main>'

I had been switching to Docker in Vagrant to host my Octopress installation, but that did not seem related …

Plan A : Upgrade Octopress

It turned out it was related to my migration to Vagrant and Docker.xs This kind of nasty error often comes from obsolete environment. Internet confirmed confirmed it :

  • Ubuntu now uses Python3 instead of Python2
  • Octopress2 uses an old version of Pygments
  • That version of Pygments requires Python2

I thought that I did not want to play this game against open source libs, so I set out to update. Octopress 3 has been released. It’s not yet documented yet, and there is no official upgrade guide, but some guys have done it :

I tried it … but I stopped before the end. It’s kind of working, but fundamental features like category archives required too much Jekylling for me at the time. And themes are still an issue … I mean, stock theme uses a clean and simple gem based update workflow, but most other themes rely on a tricky git clone-merge update workflow.

Plan B : Find a hosted blog engine for hackers

I found quite a few options :

  • Medium Looks cool, but there is no simple migration tool, and I’ve been burned by postero.us shutting down, I want to keep control on my content
  • Posthaven Having loved postero.us, this one seems cool, It’s just I’m not sure the guys are keeping the motivation to increase their feature list with their current business model
  • Ghost Looked great, but too expensive for me (19$ per month)
  • Codrspace This is a special blogging platform for coders, but it seems it has not been updated for a long time
  • LogDown This also is a special blogging platform for hackers. It seemed great and had everything I was looking for … I was ready to spend the 50$ per year for it as it could save me a lot of hassle. Unfortunately, I could not find a way to forward the categories of a post as Twitter hashtags as I’ve been doing with Octopress and Feedburner

In the end, I was rather disappointed by the alternatives, even though I was ready to pay for them.

Plan C : Fix the error in Octopress 2

Eventually, the fix was rather easy. People had fixed it by patching mentos.py file in the pygments.rb gem to run Python 2 instead of the stock Python. That’s not great because it means that I’d have to redo the patch every time I updated my gems, or rebuilt my workspace. Here is what I added to my Vagrantfile instead :

sudo apt-get -y install python2.7
sudo ln -sf /usr/bin/python2.7 /usr/bin/python

Here is the commit on my Github repo.


I’m sticking with Octopress2 for the moment. Maybe I’ll re-try to migrate to Octopress3 later on, when an official migration tool or guide is available. Meanwhile, I’m still dreaming of my perfect blogging platform :

  • Open source
  • Static HTML generation
  • Self or SAAS hosted
  • Great integration with social media and the web
  • Easy to maintain
  • Plugable themes

I’m looking for my next side project at the moment, that could be a useful one ! Anyone interested ?

Real Developers Ship

If you are a developer and you are not shipping, you’re in the danger zone. I believe it’s mostly your fault, and it’s time to act.

Nothing new

It’s been told before. Famous blogs have said the same thing :

What does it really mean ?

If you are not shipping, are you really developing something ? Maybe it’s more some kind of research project, or maybe you are just there for learning ? Real Developers know what they are in for.

If you are not shipping because the quality is too bad, that’s because you’ve been developing poor quality software … Real developers write quality software. (BTW, shipping bug fixes is not shipping)

If you are not shipping because you don’t have yet enough features, that’s because your MVP is not small enough (despite the current Skateboard metaphor, this is not an MVP). So Real developers follow lean (startup) principles.

If you are not shipping because it’s much work, that’s because you did not automate delivery. Real developers use continuous delivery.

If you are not shipping because someone else said so, maybe it’s time to convince her. Real developers know how to deal with people.

If you are not shipping because you are in a shitty environment … Real developers work on their skills to be able to quit when needed.

Shipping above all else

My point is that every developer or organization containing developers should put shipping value as their absolute priority, and things should get a lot simpler.

Pair Programming, From Pain Zone to Skill Zone

We’re doing pair programming almost all the the time in our team. A few weeks ago, we went to Devoxx Paris, and 2 team mates used pair programming at a hands on session : they finished way before the others and had the time to take a 30 minute break. Pair programming delivers more … when it works.

Flavors of Pair Programming

Throughout our experience, we have identified some situations where it does or does not work :

Pain Zone Skill Zone
Wandering buddies Mates
Expert / Novice Mentor & Apprentice

The Pain Zone

Pair programming can be painful. It can feel like a waste of time or extremely frustrating. Here are the typical situations and how to fix them.

The Wandering Buddies

That’s what you’d get if you asked to newcomers straight out of school to pair program on existing source code on day 1. They’d be dabbling here and there, without going anywhere. Each one would try to get the keyboard to try his way, but in the end, no general direction would be followed.

The cure in this case (as often) is to stop and think. At least one in the pair needs to lean how to pair program. It’s not difficult, that’s just :

  • Discuss and agree on a general plan first
  • Keep a todo list
  • Track your advancement on your todo list while you don’t have the keyboard
  • Stop and discuss from time to time

By starting that, the pair will quickly move into the ‘mates’ state.

The Export / The Novice

That’s when a ‘lone wolf kind of’ expert pairs with a junior. The expert picks the keyboard, dashes through the tasks, doesn’t make sure his pair follows (which usually means it does not).

Regular pair programming means a change in job responsibilities for such expert programmers. If they were expert doers before, they should now become expert mentors or coaches. That’s quite a difference. To them, it means that their goal must be to make his pair finish the task … It can be very frustrating at first. Nevertheless, the overall skill level in teams doing that increases so fast that’s it’s very fulfilling for the team as a whole.

The Skill Zone

The is where we want to be. When it happens, pair programming feels productive, interesting and fulfilling. Contrary to what is often thought, this can happen whatever the skill levels of the 2 programmers.

The Mates

The programmers have equivalent skills on the subject at hand. They organized in a way that they are both learning from each other. By having to verbalize what and why they are doing things, by challenging each others assumptions and by sometimes doing differently than what they’d alone.

The Mentor & The Apprentice

Other times, there can be a real difference in skills for what the pair is attempting to do. In this situation, the goal of the most knowledgeable is to train his pair, who’s goal is to learn. The task becomes some kind of exercise on which to practice.

During a typical pairing session, a pair might switch many times between mentor and mates states. Each one in the pair might assume the mentor’s role for different aspect of the work. At the end of the day, everyone should feel as if they had learned and accomplished good work.

Last Word of Caution

Pair programming is exhausting. Don’t expect to be able to do 40 hours of pair programming per week. After 6 hours in a day, one usually starts to get a lot less efficient.

Both juniors and experienced programmers also need some time by their own, to experiment things by themselves or to complete a simple task without having worry about explaining everything.

These are the reasons why XP stresses having a sustainable pace and leaving space for Slack time

5 Books About Data Driven Lean Software Development

In french, we say “Le cordonnier est toujours le plus mal chaussé” which I found an English equivalent in “the shoemaker’s son always goes barefoot”. I believe this is nowhere more true than in the software industry !

“Software is eating the world” they say. Software is now able to do things that only humans used to be. So why the hell are we driving our projects as if we were a horde of amateur hitch hikers ?

What does it mean to be data driven ?

Being data driven would allow us to answer questions such as :

  • How much is the feature we delivered last week contributing to the bottom line ?
  • How much is the feature we are currently developing expected to contribute to the bottom line ?
  • What are the estimated cost and value of increasing our test coverage of 1% ?
  • What are the estimated interests and nominal amounts of our current technical debt ?
  • Which is the most valuable : improving our build system or building this new feature ?

Most projects I’ve worked in have absolutely no clue about the answers to these questions. The decision is left to experts, to the one with most influence, or simply to the developer, who can do how he thinks is best …

The books

Hopefully, some people are thinking differently, they believe it is possible to quantify all this, they even explain how !

Running Lean: Iterate from Plan A to a Plan That Works by Ash Maurya

Details a very practical guide about the lean startup process, which is a very good starting point to any kind of lean software development.

Kanban: Successful Evolutionary Change for Your Technology Business by David J. Anderson

This book explains with real world examples how to use Kanban board to control your work queues and improve your flow of work, a real basic for any lean product development.

The Principles of Product Development Flow: Second Generation Lean Product Development by Donald G. Reinertsen

This book is rather theoretical, but it links all subjects together : lean startup, risk management, Kanban, and economics. I guess it’s a must read on the subject.

How to Measure Anything: Finding the Value of Intangibles in Business by Douglas W. Hubbard

If the flow book gives a big picture view of what you want, this one explains how you can actually measure all the aspects of your product development in $ value.

Waltzing With Bears: Managing Risk on Software Projects by Tom DeMarco and Timothy Lister

Although this book is getting old, and is a bit outdated when compared to agile development practices, it provides real world examples of how scientific measurement can be applied to software product development.

An opportunity

Reading these books was a real eye opener for me. The software development world is plagued with cargo cult and supposed best practices. We follow advises, but most often without verifying if they actually work ! I believe that by applying the techniques in these books, we could create standard ways to measure the values of productivity, technical debt, quality, testing …

I see real opportunities to avoid a lot of useless argument between proponents of A and B, but also to communicate better with all stakeholders and finally, to reduce stress for all of us.