The Road Less Traveled

“Confronting and solving problems is a painful process which most of us attempt to avoid. And the very avoidance results in greater pain and inability to grow both mentally and spiritually”. Does it remember you something? Root cause analysis, Domain Driven Design and so many practices in IT are about solving the problems instead of fixing the consequences. Actually, I think it’s the difference between a young and an experienced developer. The young dev wants to hack a solution as fast as possible. The experienced dev will use this time to analyze the problem, because when it is done correctly, building the solution will be “trivial”.
The passionate thing about The Road Less Traveled by Scott Peck is that it’s a book written by a passionate psychiatrist, drawing heavily on his own professional experience. It’s all about human relationships, and the incredible number of lessons from this book we can directly apply in our software developer job should be a huge warning for people arguing that we must be technical monkey.


Seems familiar again? That’s the very first section of his book. Through different experiences he explained how discipline is important to grow as an adult, and how most of us stay children. Each time we refuse responsibilities, each time we look for the easy solution instead of a more permanent one, each time we take a direct gratification instead of investing in a delayed but greater one, we are acting like children. This book brings us this hard truth: being an adult is not fun, and nobody will help or prepare you to become one. But fleeing our responsibility results in pain. That’s why discipline is required to grow as an adult, even if it hurts.


This one is a bit far away from software development, but important for mind growing. In a nutshell, the author tries to define love: true genuine love. Not the one you think to know when you’re 16 years old and discover the opposite sex. True genuine love is the unconditional love we have for our children for instance. This kind of love does not require anything from the loved one, it does not have to be mutual. It’s just something you give to someone. This kind of love is hard, and usually not what we’re used dealing with. It excludes the myth of “love at first sight”, because genuine love requires a deep understanding and respect of the loved one. The author explains that this kind of love is the one that can stand for life.

Religion and Grace?

The two other sections use some words that make me very careful… Religion, Grace… I believed this psychiatrist was a scientific man? But the reading was still really pleasant. The author is not trying to convince you of anything (even if he personally believed in god, or at least in something bigger than us). Again, he drew on his experience to relate some stories were religion drive people crazy. And some stories were these same religions literally save people. And grace is about all these things that we observe but can’t explain. What’s the link with psychiatry and psychology? Well, to be happy you need to accept that you won’t understand the world.

Yet another must read

It will not be the book that will make you a better developer technically. But we can feel the passion of the author through chapters, and his feedback on human relationships are priceless. It helps me to realize how much the job of a software developer is driven by people’s relationships, more than by anything else.

I highly recommend it.



This book is the second-best seller by Jason Fried and David Heinemeier Hansson. I’ve already commented the first one. It was basically one of the most pleasant reading experience I had so far, in terms of presentation. Knowing that they have written a book about remote working, I had it in my reading list since a while. As a remote worker myself, I was sure to learn stuff, or at least to discover another pleasant book to read.

William Zinsser’s touch

Like for Rework, we feel the hard work in this book to write only essential things, in the most comprehensive way. From the writing style to the chapters patterns and the images to illustrate them, we feel that nothing was chosen by coincidence.
The result is again a delightful experience.


Thanks to this writing style, clear and concise, the chapters follow each other with lots of takeaways. Short and actionable things you can do tomorrow, either as an employee or as a company, if you want to use and promote remote working.
There are also many arguments about why remote working makes sense, from a human and economical perspective. Including counter arguments to explain the challenges that arise with remote working.

Favourites takeaways

– You can work remotely just a few days per week, or even per month, it doesn’t need to be all or nothing
– Just staying in front of a computer is not working, the work is what matters wherever you are
– A demotivated remote employee is also demotivated on site
– On site or at home, we need a routine to perform
– It’s all about trust in the end

Should you read it?

If you are a remote worker or a company working with remote workers, this book will definitely be helpful. This is also true if you are interested by remote working, but don’t know where to start.
If you want to learn how to write a book which is a pleasure to read, this is a must read as well.

Have a good read!


The Computer Boys Take Over

Does it already happen to you that a book is so good that you can’t stop read it? I’ve experienced it a few times. For H2G2, the Lord Of the Rings or the Dark Tower for example. But for the first time it happens with an IT book: The Computer Boys Take Over.

Why it resonates with me: the short story

What’s the Software Crisis? Is it old? Why do we have so few women in IT? Why our job is still not understood? Why are we often in conflict with middle management? These questions are very recurrent in our industry. I heard them a lot in many conferences and blog posts. This book provides answers, or at least good insights about the roots of these problems.

IT history

Did you learn about IT history at school? I didn’t, and that’s a shame. Learning about the first decades of our industry (roughly 1950-1980) is full of lessons. Many of us believe that our job is mature. It isn’t. Our job exists since less than one Human life, and the computer industry is undergoing a fast-paced evolution. Most of us didn’t even remember what happens ten years ago. It would be both pretentious and dangerous to suppose that our industry is mature. This book does describe the beginning of IT, and shows clearly that the software evolution hasn’t happened yet. The fundamentals problems we had 30 years ago (projects running over time and budget, low quality, unmanageable software employees, lack of resources…) are still relevant today. I would even argue that it’s more relevant today than 30 years ago, because of the explosion of personal soft devices.

The coders diversity

The book explains well how we (deliberately or not) build a male oriented industry. From the lack of consideration of the first developers (women programming the ENIAC) to the IBM PAT (Programmer Aptitude Test) ravages and the will to overcome the “lack of software developers”, we have all the keys to understand how and why women were not welcome for such a long time (of course we’re not the only industry to suffer this problem, which is not a reason for ignoring it).

The challenge for the management

Since I’ve started to work as a professional, I’ve always felt uncomfortable with middle management and huge hierarchies. I just feel like it’s a waste, and I can’t understand the fact that “Excel-Managers” do need to express their authority on me. And by the way, how can they have authority on me without understanding what I’m doing?  I read a lot of stuff about the “Y-generation” and experts trying to explain this fact. But this book also provides potential answers:  what if software does remove the need for middle management from the classical Taylorist understanding of work? That would definitely create tensions between the middle managers and the software developers. That would also explain why it’s important for these managers to keep developers in a code monkey position. “Please code, don’t think. We are here to think and manage, you are here to code and obey.”

The representation of developers

Another discussion that I often have with other passionate developers is the lack of representation of our job. Should we create a union? An association? Who could have the legitimacy for that? Another question that this book tackles. It explains that this was already asked a few decades ago. That’s what lead to the creation of the ACM (Association For Computing Machinery) and the IEEE (Institute of Electrical and Electronics Engineer). Most of us don’t know about them, and these associations have historical points of conflicts between the “pragmatic business programmers” and the “scientist software engineers”.

Software is hard to do

This book gave me many insights, and if you are a regular reader of this blog, you will probably recognize how it influences my recent thoughts about software. It helped me to have a deeper understanding of our industry, better than any other book before. Like always, I have now even more questions, which is the proof that this book is a must read for anybody with the will to understand the past in order to improve the future of the software industry.


PS: If you are wondering why such a great book has a title that may look sexist, please understand it is ironic. It highlights the fact that for many decades, these bunch of unmanageable weirdo nerds were referred as the “Computer Boys” (usually with a pejorative connotation).


Patterns of Enterprise Application Architecture

Patterns of Enterprise Application Architecture is one of the many interested books written by Martin Fowler. I have a lot of respect for Martin, mainly because he’s able to constantly challenge himself and improve his craft, since several decades. Here is what I like and dislike about this book.

A bit hard to read

Like Eric Evans, Martin Fowler has tons of interesting things to say. Unfortunately, both have a style hard to read. Mainly because it is dense in terms of content, but also because it is not concise. Let me be clear: I don’t pretend by any way to be a better writer than them. I just consider what they write as much interesting as it is hard to read.

Not totally up to date

Because the book was written around 2000, with many technical details, some of the patterns described are no longer relevants. Which is not that bad, because it gives an historical perspective. For instance, it was released when OOP was kind of marginal, and patterns like ORM were not widely spread. It is interesting to see what were the alternatives, and how OOP was perceived before to be mainstream.

A must read stay a must read

This book has greatly influenced our industry in the last decades. From this perspective it is still valuable, because it helps to understand what IT looks like in the 2000s, and how it evolves. The book contains also some seeds of the original ideas behind the emergence of Domain Driven Design, such as the Domain Model pattern. It allows to understand the original link between Domain Model and OOP, and thus the influence of OOP in the mythical blue book by Eric Evans.

 Thank you Martin for this book and what you do for IT since many years.





I discovered DHH during the « TDD is dead» trend with an ambiguous feeling. I highly value (smart) people with different opinions about testing, craftsmanship and software, but at first glance, DHH looks pretty bumptious to me.

Who’s this guy I’ve never heard of before who decides that one of my favourite development tool is dead?

TDD is dead?

First of all I listen to him and his arguments. I always knew TDD has limits, but rarely meet them. In a nutshell, he argues that TDD may hurts design. After some thoughts my feeling is that TDD does not fit well with invasive framework like Ruby on Rails. Does it make TDD or Rails dead? I don’t think so, they are great tools useful in given contexts.

DHH and I are not working in the same context. He’s more in the web fast app context, whereas I’m more in heavy line of business context (usually not even web). The good news is that his thoughts about my work’s style are less biased than people from my context.

Why I read it

I’ve a very simple way to select the books I read: the more I heard about it, the more it goes up in my reading list. I select rework in this way, without knowing DHH was one of the authors (the other one is Jason Fried).
It was a good surprise, and I definitely recognize his style, close of his blog. I also recognize William Zinsser’s influence, something we share. It is a really pleasant book to read.


The content is full of short take-away. I think I would gain more benefice if I read it a few years ago. Some advices sound clearly obvious now. Still I admit it wasn’t this obvious when I discovered the world of software and entrepreneurship in 2009.


Favourites take-away

–        Scaling is not mandatory
–        You need less than you think
–        Beware the workaholists
–        Go to sleep
–        Don’t confuse enthusiasm with priority
–        Pick a fight


Should you read it?

I think the book stay a must read, especially if you like the direct style of William Zinsser, and/or if you are both entrepreneur and software developer.

It helps me to know more about DHH’s universe.



Learning from the past

“As a principle objective, we must attempt to minimize the burden of documentation, the burden neither we nor our predecessors have been able to bear successfully”

“My first proposal is that each software organization must determine and proclaim that great designers* are as important to its success as great managers are, and that they can be expected to be similarly nurtured and rewarded”
* Understand designers as software engineers

“There is no single development, in either technology or management technique, which by itself promises even one order of magnitude improvement within a decade in productivity, in reliability, in simplicity”

“Adding manpower to a late software project, makes it later.”

“For the human makers of things, the incompletenesses and inconsistencies of our ideas become clear only during implementation.”

“The brain alone is intricate beyond mapping, powerful beyond imitation, rich in diversity, self-protecting, and self-renewing. The secret is that it is grown, not built. So it must be with our software systems.”

“testing is usually the most mis-scheduled part of programming.”


An echo from the past

All these quotes were written 50 years ago, in the excellent book: The Mythical Man Month.

Sometimes I think: “Waouh, we know this since more than 50 years, and we still have to fight for these practices in the companies I work for? Are we developer stupid people who don’t learn from the past? Don’t we try to improve our industry? Or maybe it’s just a French problem?”


An unexpected answer

Unexpectedly, the answer comes from a discussion with my grandmother.

A few weeks ago, I talked with her for the first time about world war two. How it was, where she lived, what she saw.
Even if I know the History, I was choked when she explained me how Jewish people were parked in hotels, and how Nazis come to take them with violence, in places I know very well.
She was 13 at that time, she told me how a soldier put a machine-gun on her chest, yelling at her in German, even though she didn’t talk German at all. The soldier believed my grandmother was a Jewish kid trying to run away from the Jewish hotel. Fortunately my great grandfather arrived just in time and was able to save her. She told me many other frightening things.

I realized that, if my grandmother was more nervous, or if this soldier was less calm, or if my great grandfather was longer to find his daughter, I may not be here to write this post. I am lucky, but how many people did not have this chance? How many lives were broken because of racism and hate?


Back from the Godwin point

My point is: developers are not stupid, but developers are people. And most people don’t read, or even wish to learn. Most people unconsciously look for confirmation biases (including myself), about how things should work.

The less we have knowledge, the more we think we know. We can solve it by staying open and learning more, until we accept we know nothing.


Repeat the past

Most people believe that the past is the past, and that today is totally different. Most people don’t talk about world war two with their grandparents.

This is why nationalist parties have more and more influences in Europe.
This is why U.K. leaves the U.E. despite the fact that U.E. was the best invention against hate, racism and war since many centuries.
This is why the most powerful country in the world can vote for a racist billionaire to make America “great again”.

This is why I have to explain the things we know since 50 years in our industry in every company I work for (but in perspective, it does not really matter after all).


Happy end

The good news is that it is easy to be “a good software engineer”: read, learn, go out of your comfort zone and always challenge yourself. Avoid people and methods who pretend to solve everything.

And to start learning about the History of software development, I highly recommend  The Mythical Man Month.



On Writing (Code) Well

Following an advice from Cyrille Martraire, I just finished reading On Writing Well: a non-fiction guide written 35 years ago. Reading this book helps me to realize there are lots of similarities between writing code and non-fiction.


The arrogant guy

“A simple style is the result of hard work and hard thinking. A muddled style reflects a muddled thinker or a person to arrogant, or too dumb, or too lazy to organize his thoughts.”
On Writing Well, William Zinsser

I like this quote because who has never met a codebase much more complicated that what it needs to be? I was one of these arrogant guys not so long ago.

I was proud to write code that none of my co-workers can understand. It took me a while to accept that my code was bad, and that I overcomplicated it in order to look smart. It took me a while to realize that I had a muddled style.


Another similarity is that it’s more about re-writing than about writing. No writers are able to produce a perfectly understandable story at the first shot. They have to write, and re-organize, and change, and remove things until it is clear enough to be shared.

Refactoring seems absolutely normal for a writer. But for a software engineer, we expect a perfect code at the first try.  We’d like to believe we are so smart that we can build a whole business process in our mind, and write it in an unambiguous way for a computer who doesn’t speak our natural language. But we can’t.


Decreasing the cognitive load

We need to decrease our cognitive load, to focus on the really tiny portion of the whole business process we want to manage. Being able to reason about our code is paramount to high quality. And we can’t reason about our code if our brain is full of things unrelated to the problem.

In the same way, non-fiction writers can’t write a good article if their brain is full of things unrelated to their topic.


I see one big difference between writers and coders though: feedback loop. When writing non-fiction, it’s hard to know if your content is good before releasing it.

As developers, we have a very quick feedback using automatic unit tests.

continious-feedbackThe developer/writer metaphor

The house building metaphor hurts a lot our industry.
I think a better metaphor would be that writing software is like writing a book.

It’s something to remind our managers next time they want to add writers to solve our deadline issues.

Writing software is like writing a book with several other people, during several months, if not years.


Patterns, Principles and Practices of DDD

Patterns, Principles, and Practices of Domain-Driven Design was written by Scott Milett and Nick Tune. It gives a holistic view of DDD, from strategic to tactical patterns, and provides many examples to explain the concepts.

This book was presented to me by Bruno Boucard in this way : « It’s a very complete and modern view on DDD, and very few people have read it .» I agree, and it’s a shame.


Why have so few people read it?

The more I read about DDD, the more I wonder if it is wise to explain all the DDD concepts, including examples, at once. It produces huge books (this one is 792 pages) contributing to the idea that DDD is complicated. It could discourage newcomers just by its size.

Also concepts and examples  do not deteriorate at the same rate.

Explanations about strategic and tactical patterns were quite the same as in the Blue Book. A few building blocks were added by the authors like Domain Events, but nothing really new emerges. It stays worthwhile to write about it, this content can stay up to date for many years.

DDD implementations on the other hand evolve a lot. The emergence of CQRS/ES and NoSql storage, the hexagonal architecture, and other practices have changed the way we implement DDD solutions in the last decade. These solutions did not exist in the Blue Book, and we can hope in 10 years it will be outdated by better alternatives.


But is it always good to have examples?

It is really hard to show examples, because DDD is contextual. It is courageous to show examples anyway, but I would not push them into production. I don’t blame the authors though, they wrote disclaimers explaining it is short examples for learning purpose.

My point is, it was interesting to write such a complete book, and I find it’s a shame it will be half outdated when we’ll find better way to implement DDD. Maybe it would have serve the authors to write better examples in a dedicated book, and keep another book to stay focus on concept explanations.


Why you should read it anyway?

It is still a must read to have a modern understanding of DDD. It covers everything from integrating bounded contexts to implementing an event sourced aggregate and much more.

If you’re already familiar with DDD, it will improve your knowledge. If not, it is a very good start, even if you don’t grab all the subtleties at first.



Another article kindly reviewed by Brian Gibson.


Soft Skills

I believe software development is a fantastic job. It’s always challenging, accessible to anyone, and generates good revenues. There are several books dealing with “how you can be a successful developer”, but very few give life advices. Soft Skills by John Sonmez is one of them.


Success ?

The book talks a lot about “success”, but unfortunately the author never defines what it means for him. I won’t speak for him, but for me success is the ability to choose if I want to work, and on what I work if I decide to do so.  

Soft Skills really helps me to be more successful, according to this definition.

Honestly I was sceptical at first. This guy is going to tell me what to eat and it’s supposed to make me a better programmer ? But I missed the point : It doesn’t explain how technically to be a better programmer, we have plenty of books for that. Instead it proposes a series of practical advices to improve your career, your finances, your body and even your spirit.


Career paths

For example, the author describes the main possible paths : Employee vs Freelance vs Startup, trying to show pros and cons in each case.

I found good advice for hacking the interview : the best way to get a job ? Don’t look for a job, make the job look for you. The point is : research the Company you want to work for, engage conversation with people working there (social networks are awesome). Be the guy they already know instead of the guy who needs a job.

I also enjoy (and applied almost immediately) the part explaining how to write a resume. Writing a good resume is not a required skill to be successful, but having a good resume is useful to have the job you like. Solve the problem by hiring a Professional CV writer, and save time for more interesting stuff.


Marketing yourself

As a freelancer, I was particularly interested in this chapter.

We often assume that if we’re good, success will follow. It does not work that way, you need to be good, and you need to be known for what you are good at.

I found useful advice about blogging for example. You wonder how to have a successful blog? The short answer is: write on it, consistently. You certainly won’t write a piece of art each time, but if you’re consistent you’ll build up an audience pretty quickly. And by writing a lot, you help yourself think, thus improve.



Our job requires us to always learn. Better find an effective way to do it. This chapter has advices on how to find a mentor, how to learn and how to teach by breaking your goal in small goals.

The author presents a method with different steps roughly from being a total beginner to teaching to other people. I haven’t tried it yet but I like the structured approach for learning about anything.



Again I quickly applied most advices in this chapter.

It includes using Pomodoros to manage my time. True multitasking : which means for example listening for a talk or a podcast during a run, or use my commute time to write blog article (MS Word on Smartphone is not that bad).

Another thing I directly applied from this book is setting objectives. My current weekly objectives are : at least one Pomodoro to answer a Stackoverflow question, and at least 4 Pomodoros to write blog articles.

I especially like the chapter explaining how much it costs you to passively watch stupid TV show.


Financial, fitness and spirit

Do you ever realize that you are virtually not free until you can choose to work or not? It was a bit of a shock for me, but I now think it’s quite true. If you want a decent life, you are forced to work. If you want to have the choice to work or not (and keep your lifestyle), you need to create passive incomes.

Even if you don’t want this choice, it’s good to realize that retirement is not the only path.

About fitness and spirit I won’t go too far, but the chapters are really worth it. Whether you are absolutely allergic to sport, or you already do gym every day, you will find useful stuff. You’ll better understand how calories work, and how your spirit can influence your behaviour.


Why I recommend that book

Because it’s not a magic formula. It’s really pragmatic and realist. A good summary could be: if you want to be a good developer, you need to have good professional habits. If you want to be a successful developer able to choose if and on what you want to work, you need to have good life habits.

It’s not easy, it requires hard work and this book may be really helpful to find these good habits.



Thanks to Jean Helou and John Sonmez for the review.
Special thanks to Christophe Fernandez for recommending me this book.


Thinking Fast And Slow as a developer

thinking fast and slow

In the excellent thinking fast and slow by Daniel Kanheman, the author proposes a representation of our mind with 2 systems:

–        System 1 is fast, but also prone to errors mainly due to biases
–        System 2 is slow, and can overcome some limitations of system 1, but we don’t like to use it

Think of driving. When you learn, you need a full focus and you can hardly have a discussion or listen to radio news when you drive (you use system 2). After a while, you can do it without thinking of it anymore, and you can easily discuss when you drive (you now use system 1).

An interesting thing occurs when you meet an unusual event (let’s say brutal stop of the car in front of you): you immediately stop to talk or to listen the radio. You now use your system 2 in order to manage the unexpected event.

We routinely use System 1. System 2 is involved when you learn something new, or to process complex thinking.

And if you wonder why Kanheman asserts we don’t like to use system 2, just try to calculate 21*17. You can do it, but you probably don’t want to, and you won’t do it just for pleasure. Even if you do it, it will be pretty slow.

What can we learn from this in software development?

BigThink_System_1_2Choose your battle

Technical skills (like mastering your IDE, TDD/BDD, a given language/Framework/Library, design pattern, SOLID…) should be practiced until they are fully integrated by system 1. You should be able to use them without thinking deeply about them. Ideally, if you master them very well, you can use your system 2 only to solve business problems, because all the technical stuff should be routinely managed by system 1. All the technical stuff is just the side effect, the goal is to solve a business problem.

But of course, we also need to learn/test new methods, language or libraries, or we will quickly be biased by our own knowledge. We’ll try to fix any business problem with the few technical things we master well. If all you have is a hammer, everything looks like a nail.

So we shouldn’t learn too much new things at once on a project, because the consequence will be less focus with system 2 on the actual business problem (or at least if we do, we should be aware of this limitation). If you learn TDD, do it in a language you master. If you learn a new language, don’t try to implement design patterns you never implement before. If you learn all this at once, do it on a pet project or in a coding dojo rather than for a customer that pay you to solve a business problem.

Choose your battle, you cannot win all of them at once.


How to teach TDD

Another thing we can learn from the system1/system 2 representation is: don’t be too rude when teaching TDD to a junior. First you should help him to master his IDE, language, libraries, patterns and good practices. Then he will be in better position to understand TDD. If you try to teach him everything at once, he will likely perform bad design and/or bad business decision. Not because he’s stupid, but because he’s already fully using system 2 to understand the TDD concepts he’s learning.

The interesting thing with TDD is that it actually challenges a bad design. But if your junior has no idea about what a good design is, he will just choose bad solution to solve what seems to him a pure “TDD problem”, not a design problem.


TDD rocks

Speaking of TDD, I was amazed to read this assertion in Kanheman’s book: “Whether professionals have a chance to develop intuitive expertise depends essentially on the quality and speed of feedback”.

In the book, he tries to explain the difference of expertise between financial experts and seasoned firemen. His point is: financial experts are pretty bad. Not because they are stupid, but because their job is to forecast, and we are terrible to do prediction. He performs several studies to demonstrate that traders “skills” are mainly due to chance.

But he was challenged by some other studies showing a true skill difference between seasoned firemen and novices. So Kanheman tries to understand these differences, and he concludes that the speed and quality of your feedback is essential to develop intuitive expertise. He explain it in a psychological way, because with a quick feedback your new knowledge challenges almost instantly your previous assumptions. It is not contestable because you clearly see the correlation between your thinking and the consequences. But when you have a very late feedback, or not at all, you missed that opportunity for improvement.

Prove immediately to someone that he’s wrong, and he could change his mind. Prove him the same thing some years later, and he might resist, or just refuse your argument. Ask to financial experts if they foresaw the 2008 financial crisis. Lots of them will answer they did, but only a few have actually spoken about it before it happened.

In software development I see exactly the same problem with architects that “don’t code anymore”. They are often reluctant to practice or spread TDD. Here again the power of TDD is to challenge your design in a very quick feedback loop. If it hurts, you can try to convince yourself that it’s because TDD is dead, or TDD sucks, or TDD doesn’t work in the real life. Truth is: your design sucks, that’s why it hurts.

To improve your expertise in software development, you have to find a way to obtain a quick feedback about design decision. That’s why TDD rocks.


Wish to read the book?

Of course there are much more than that to learn in this wonderful book, both for your professional and personal life, and not only for software developer. But I won’t spoil you anymore, if you have the chance, just read it.

And if you don’t want/can’t read it, at least remember:
– Choose your battle
– TDD rocks

It will definitely improve your developer’s life.


Thanks a lot to my reviewers: Johan Martinsson, Sebastian Larsson, Sébastien Rabiller, and Christophe Fernandez.
Thanks to Sandro Mancuso for recommending this book.