Event Modeling

When was your last breakthrough about software development? I think I can resume mine in 4 steps:
1- Writing test is not optional to handle complex system
2- Good architecture is not optional to write test
3- Most programs are built with a CRUD approach, which isn’t easy to maintain in complex systems
4- Event-driven architecture may help to avoid this CRUD approach, mainly because Events can be domain concepts that we share with the business.

That’s why, coming from the DDD world I’m so interested in CQRS/ES and functional programming to handle complex systems. I’ve seen a few times already how the combination of DDD strategic patterns to handle contexts, CQRS/ES implementation and Event Storming for exploration of the problem space are efficient. It allows to get a very deep understanding of the problem, and a very robust way to implement the solution, all relying on the power of events.

Recently I’ve seen a few tweets about this “new” stuff: Event Modeling. And a few tweets later, I had the chance to organize an Event Modeling workshop in Lyon with Adam and Greg, that I had the pleasure to attend. Let me share some feedback here.

Event Modeling vs Event Storming

There is a very detailed post about what’s Event Modeling by the author Adam Dymitruk, thus I will rather give a short explanation assuming that you already know about Event Storming.
Both methods are starting in the same way: you want to “storm” events by asking business people to tell the story of their domain.
Then, you try to order the events in time to show that you can describe a business flow from start to end quite exhaustively.
From that point Event Storming (at least in the way I’m used to practice it) focus on the emergence of commands, aggregates and bounded contexts.
Event Modeling in the other hand will then focus on User Interface (UI). The goal is to add UIs to show the progression of a screen through the business flow. You will often duplicate the same screen, and just change some values to represent in which way the UIs are impacted by the events. Note that you can add different lanes to represent the UIs for different users impacted by the same events.
At the same time, some lanes can be added for the events. Some events are about inventory. Some are about payment… Yes, it’s just another way to let your bounded contexts emerge. And a very powerful one I think, because it makes clear that UI most of the time gathered data from many contexts.

Event Modeling keeps Events order

Practicing Event Modeling removes some Event Storming frustration for me.
I have facilitated many Events Storming in many organisations since 3 years now, and I often have the same feedback that losing the temporal relationship of events (when going from Event Streams to Aggregate) is a shame, because we loose meaningful information. I usually agree but answered that this relationship wasn’t “lost”, and that we could always take pictures to keep it somewhere.
Event Modeling just keep this relationship by default, and I think it’s a good idea in the end, because time matters when speaking about events (actually they’re just two sides of the same coin).

Event Modeling also focus on UI

I also observed during my Event Storming session that adding some UI sketch might help a lot to remove ambiguity.
One of the steps in Event Modeling is actually to draw all meaningful UIs for different users. It makes sense because it helps business people to have a better understanding of the “link” between domain events and the software they will use in the end. I think it helps them to translate from problem space to solution space if you will. Also, as already explain, it shows that UIs most of the time gather data from several contexts.

A different view of bounded contexts

The step of drawing contexts around aggregates like in Event Storming doesn’t exist. Instead the contexts emerge in even a better way I think: by putting events stream in different lanes depending on the things they are doing for the business.
Is it more about payment? Or inventory? Or security? We easily feel that all events do not lie in the same streams. And each stream of events might in the end represent a different bounded context.

A CQRS cycle keeping track of time

Last but not least: Event Modeling results in a “true” representation of a CQRS/ES system. We know the classical circular view in a CQRS system: View -> Command -> Event -> Model.
What does this circular system look like in time? Waves of View -> Command -> Event -> Model -> View -> Command -> Event -> Model … and so on.
In the end, using this Event Model as a blueprint for the software we are building makes sense, because it doesn’t miss any component that matters for business. We have the domain events and we have the UIs, and all the transition leading from one UI to another following the pattern View -> Command -> Event -> Model .

Finally, a silver bullet ?

I’m not an expert of Event Modeling, and like anything new I probably miss some disadvantages of this method due to my feeling that it removes many problems I met in my current way of working.
But I’ll try to use it very soon, because I see lots of potential in this approach.
I can see how it helps me to be closer to the solution space, with still something making sense for the business.
Something I already feel harder though might be to know how to represent aggregates with it. Actually this is probably due to the author view: he doesn’t really care about context or aggregate; but rather about streams. An event stream is a “logical” stream of events… Ie either a context or an aggregate depending on the context I guess^^

Anyway, I will try it and let you know how things are going 😊

 

Writing code isn’t the bottleneck

What is the birthdate of the last framework you’re working with? Why have you chosen it? Did you choose it?
I feel more and more puzzled by the state of our industry, and how we’re used to deal with the fact that we suck at building software. I think a part of it might be due to a feeling that the problem is how fast we can build software. Spoiler alert: writing code isn’t the bottleneck.

Why frameworks exist?

They usually promise you to avoid writing tons of “boiler plate” code. This code that has absolutely no value to your business, but still is not optional to make your system work in production.
In other words, frameworks are here to “increase” your productivity by gaining time to write code that matters for your business.
What frameworks usually forget to tell you is that the time you’ll get by avoiding boiler plate code will mostly be used to understand and configure the framework. No pain no gain, right?

A pact with the devil.

But the worst part of it is not that it will take you time to configure. It’s that you are now highly dependent of a framework. It matters because frameworks are opinionated. They are here to solve problems, but the way they solve them might not be exactly what you need on your project. And to be fair, I’ve seen this many times: in the end you’ll burn 95% of your energy trying to make the business fit your framework, instead of building a software fitting your business.

Do you want to understand problems or solutions?

And let me add this important point: you should never use a framework if you don’t understand all the problems it’s solving. By building your expertise over a framework, you are building your expertise on a solution. And if you do not understand the problems, you are an imposter, because bringing a solution is not enough to be a software professional. You have to understand and challenge the problems.

Writing code isn’t the bottleneck.

Believe it or not, writing code is cheap. The cost is in maintenance and communication. Thus all efforts made in order to deliver features faster are false friends when they increase the burden in maintenance and/or communication. The real challenge is to keep the code easy to change.

Writing code isn’t the bottleneck.

 

The Design of Everyday Things

Do you know a job hard to explain, hard to do and usually underestimate? Of course, I’m talking about the job of designer 😊
What do I know about it? Almost nothing, like anybody after reading a book. This book is the bible in this area: the design of everyday things, by Don Norman. Let me share with you a short feedback about it.

The design of everyday software?

As Scott said, like for any topic, “When you’re outside an area of expertise looking in, it can often seem monolithic and uniform, but when you’re an insider you quickly realize that there are many different subcommunities, each with different specialties and different approaches.”
I tend to oversimplify the job of designers, mainly because I lack knowledge about it. And this book helped me to understand something really important: building Software is Design, and we have tons of things to learn from their practices. And to be fair, people like Johan Martinsson and Alex Bolboaca have already talk and share a lot about this.
Basically, you can replace almost everywhere in the book “Designer” by “Developer,” and it still makes sense.

It resonates a lot with my daily work

This book is well written and a pleasure to read. It starts by talking about psychology, then about the fallacy of accusing the user before accusing the design. In other words, “Read The Fucking Manual” is not an acceptable answer, because who read the manual? People that are not able to use your product the first time, and still are forced to use it. When was the last time that you read the user manual from your phone or any online application, you’re using?
The assumption that a good design can remove the very risk of errors is absolutely powerful, both in design and software.
The end of the book talks about the (hard) collaboration with the marketing to build a product, and I’m sure it would remind you many anecdotes as well!

Go read it

This book is a reference in the design world but should be as much a reference in the software world. If you haven’t done it already, you can add it on your list of books to read!

 

What if programming was a social activity?

It is well known today that building software is a really personal experience. Old studies have proven that the best software engineers don’t like people. According to M. Cannon and Dallas K. Perry, they dislike people activities involving close personal interaction. Hopefully it totally makes sense doesn’t it? Just to have fun, let’s imagine what would happen if this fundamental assumption of the IT industry was wrong.

A wrong culture might have emerged

Women are usually better in terms of soft skills like empathy and humility. If programming was a social activity, the initial bias in favor of men with the stereotype of the coder geek playing Dungeon and Dragons in his basement would have created a totally wrong culture. With more women involved, we may talk much more about people, ethics and other unproductive stuff. But we avoided this nightmare, most discussions are about the last Framework shipped by any big companies, which is much more productive and keep our industry sanity safe. 

Evaluating individual performance would be a nonsense

The second problem would be in terms of management. How the hell could you know which one of your employees deserve the best paycheck if what they produce is a global teamwork? And probably more important: how would you know who to punish in case of failure? In such a case, the whole management principle from Taylorism and Fordism would need to be changed.
Also that would highly discredit the 10x engineer fact! If you have a 10x engineer as part of your first few engineers, you increase the odds of your start-up success significantly. Because building a startup is mostly about coding something in your basement or in your student’s room, not at all about experimenting fast and understanding people.

Working in group would be a common approach

Can you imagine that? Two people behind the same screen at the same time? Do we need two people to drive a car? Or even a train? Of course not.
And what if they work with more than 2 people? All the brilliant people working on the same thing, at the same time, in the same space, and on the same computer?
That would mean that building software might be harder than flying a plane or doing some surgery? Let’s be serious, telling a machine what to do cannot be as complex as these disciplines, which require a high level of study and a long-life practice to be mastered.

The IT industry would be a perpetual crisis

I think the best argument is that most software project would have been a failure during the last 70 years if software programming was a social activity. Most projects would have been over time, or over budget, or even not release at all even though they cost lots of money.
If that was the case we would already have heard about it and fix it right?

What if programming was a social activity?

Anyways, I think I’ve demonstrated why programming cannot reasonably be a social activity.
Of course, if developers were responsible for critical infrastructure, or if they could code decision about human life, maybe that would make sense?

Ho?… Wait…

 

The systemic failure of the IT industry

Let me tell you a story.
This is a story about a brand new software project, using last technologies and mobile devices, a really important project for BigCorp. They want to use this new product as a vitrine to show how good they are to create mobile applications.

The gold rush

BigCorp invests a lot on this project, quickly a team of 15 people was created. 1 project manager, 1 assistant project manager, 1 scrum master, 3 business analysts, 3 testers 1 architect and 5 developers.
Everybody wants to be in, the global mood was very good, all the requirements were clear, this will be the best project we’ve ever seen.

Sprinting to reality

After 3 weeks it was time for the first release… And the first deadline was missed. Less than half of the expected User Story were produced, and the code was really brittle.
During the retrospective (where project managers and business analysts were missing because they are busy) it was decided to do less automating testing and less refactoring, because it was obviously a lot of time invest in unproductive stuff. We need to deliver more User Stories.

Wall ahead

The project is now 1 year old. Half of the team was replaced. One of the business analysts was fired because he “screwed” up a demo to the company board. The mood is no longer that good. The requirements were not clear enough after all, it’s even hard to know who the users of the system are. The technology is no longer shiny because 2 new frameworks have been created during the year and seem much cooler.
The software is still really brittle, which leads to even less refactoring because “we don’t want to break it”. New attempt to add unit tests were made, but it “costs” too much, this is obviously “not possible for us to do unit testing”. Retrospectives were stopped, because who can afford one unproductive day?

And yet another awful legacy

The project is now 5 years old. No one from the initial team is still working on the project. The team is only 1 developer now, half-time. We ask her to “maintain and fix bugs” that users will find. The code is a nightmare to work with. We have no idea of what is done, and how it’s done.
It creates lots of frustration for the developer, and for the user.

Failure = lesson learned?

Not really, it’s just a normal software project in BigCorp. It’s actually so common that most people in BigCorp think that software projects are always going this way. From developers to the top management, no one is shocked anymore, this is how software project works.

What can we learn from BigCorp?

Software of big companies and governments are usually pretty bad. Because the product is just a mirror of the system that produces it. A system with lots of hierarchy, politics, arbitrary deadline and silos. A system with no idea of the level of communication and collaboration required to achieve great software. A system where the customer does not really exist, because the company is too big to care about them. A system that erases the creativity required for good software.

Most companies have systemic errors. They produce bad software, no matter how skillful the employees are, because the system pushes them in bad habits and make them believe that this is the only way to go.

This explains why it’s so hard to create good software. It’s not only about technical practices and principles, this is also a lot about the system in which this software is produced.

PS: Thanks to Anthony Cassaigne, and on the recommendation of Woody Zuill, I finally read the paper “Nobody Ever Gets Credit for Fixing Problems that Never Happened”. I highly recommand it, many echoes with this article !

 

The violence of software programming

I have no doubt than many jobs are complicated, but I’m convinced that software development is also a really violent one. Mostly because it does not seem violent at all at first sight. But let’s dig a bit in our world to have a better understanding of this “geek job”.

The constant learner

Every seasoned programmer will tell you how important it is to keep your skills sharp. Technologies are running really fast, you have to learn almost daily in order to improve.
Universities are many years late. As a young graduate, you might learn some programming languages, but you will have no clues about how hard building software is. Writing the code is just the emergent part of the iceberg.
In terms of personal investment, this is comparable to what good physicians must do. We need to read many books, to attend conferences, to listen to podcasts, to do regular training…
Everybody acknowledges how hard it is to be a physician, very few acknowledge that being a software developer might require the same kind of learning habits.

The developer paradox

Of course, being hard does not mean it sucks. But most universities and companies explain to us that we can’t stay “developer”. As if it was something to be ashamed of. We need to “evolve” (which often means we need to become manager and fill Excel sheets instead of delivering software). If you don’t take this opportunity to “evolve”, you might stay at the same low salary, which creates a violent paradox.
You must work a lot in order to be good, and you don’t earn much. Basically, you’re considered as one of the lowest roles in hierarchy, even though you’re developing the software that makes the company earn money. This lack of alignment between what you give to the company and what you get as feedback might be so hard that it could lead to burnout. In better case it might just lead to disengagement, either as an old developer or as a new manager. In “best” cases, it leads to deep questioning about your job and how you want to practice it.

Extreme Programming

I once tweeted that XP should not use extreme, because doing good software might not be considered as something extreme. But I think I was wrong, these are extremely violent practices.
Test Driven Development will reveal how bad your architecture and coding habits are. Unit testing will demonstrate how bad you are at predicting software behavior. Pair Programming will show you daily the gap between you and your co-worker. It forces you to reveal how weak you are, because sometimes you don’t remember some simple syntax or shortcuts.
If you can push software each day in production, it will accelerate the feedback loop of unhappy users. If you use mob programming, any malfunction in your team will lead every mob session as a painful disaster of people arguing for ages instead of coding.
These practices are extreme, because following them daily require a deep level of mastery, an egoless approach of your job and a strong ability to communicate at the same time. Three skills that are not common on the same person. Even less common is to find them on each member of a team.

Fighting the violence

How can we be happy as a software developer then?
In theory it’s easy: we want to reduce the developer paradox. In other words, we want to work in places where our job is understood.
In such places, salaries might be higher, but it’s mostly a state of mind. In such places we encourage constant learning, either by helping you to attend conferences or by buying any book you feel useful for your job. We might give you some time at work to practice and learn. In such places we don’t push you to become manager, because we understand the value of seasoned developers. In such places your co-workers will make you feel safe, safe to show that you don’t know everything, safe to fail. In such places nobody will show you how better or higher in hierarchy they are, because they have understood that building software is such a hard thing, that only great team can achieve it. In a great team, everybody feels proud to work with awesome teammates.

If you are working in a place where you can feel this experience, this is great, and your duty is to help more developers to achieve it. Otherwise, do yourself a favor, leave your job and find a better one. The world is full of great companies having a hard time to find good developers.

 

When business does indeed sucks

In a recent article I explained why I think we should all be Domain Driven.
I get some interesting feedbacks on the “business sucks” syndrome.

Indeed in this previous article my point was to make technical teams aware of the necessity for business to change in order to constantly fit its market as much as possible. But sometimes business does indeed suck.
Let’s take a few examples I’ve met in 10 years as a software developer.

The never-ending prototype

One of the most common business error I’ve met is the fast hacked prototype that goes into production, and then evolve in a maintenance nightmare because you know… It works, why should we rewrite it?
To be fair, this is one of the hardest things to do when you start a new business. The first step is to look for a market fit. This can take years, and you must be very fast to test your hypotheses. You are sending many prototypes in production, and most of them will only live for a few months. At this step this is perfectly fine.
Of course the problem arises when, finally, you find your market fit. The growth is here, more and more customers are using the prototype. This is when courageous entrepreneurs should throw all the technical stuff, and write it from scratch with more money and knowledge. More money because growth means that we can get money, more knowledge because many technical limitation from the prototype will be clear, and a more robust product can be built from this knowledge. As Francesco Cesarini would say: “A programmer will fully understand a problem only when he fixed it at least once”.
What happens instead is that the money is used to growth even faster, the prototype has to scale even if it’s not done for it, and the technical team has to deal with many domain and technical problems that should have been avoided.
Here starts the famous “we don’t have time for tests, we have to deliver”.

Head in the sand policy

This error concerns mainly big corporation. But I’m sure you already were as surprise as me to see how fast politic can become important even in small companies.
The company is big enough to have a few layers of management and different services. Because the top managements want to keep control of the company, he’s requesting the famous KPIs. Each service has different KPI, and quickly enough, most employees understand that they can earn more money by targeting the KPIs than by trying to achieve the best possible product for their customers.
Worse, KPIs might be highly destructive when the KPI from a service leads to more burden for another service.
For example, if one of the KPI for the support team is to take as many call as possible, they will quickly classify lots of tickets as critical bugs to be managed by the technical team. Just because it’s faster than trying to understand what happens to the user.
As a result the technical team might have a more work and the global delivering flow of the company will be slower.
Each service prefer to keep their head in the sand rather than trying to collaborate with other ones.

Enterprise Standards

Another widely spread error is the standardisation spree. Usually in the name of costs hunting (even if it’s more about power and control, because in the end it often cost more than local auto organization), the company imposes some methods, tools and/or architectures, without knowing if it makes sense for a given context.
For instance a policy will enforce all the teams to work with SCRUM. Or they will impose a common integration platform for the whole company.
It often happens when management confuses practices (SCRUM, Unit tests, continuous integration…) with principles (being more agile, code quality, fast feedback…).
Many consultants actually increase this confusion and deliver what they (think to) know instead of what the company need in its context.

So should we be domain driven when they suck?

I think my point in the original article is still valid. In the end the problems I described here is just that sometimes, the business itself is not Domain Driven. In the sense that they are looking for immediate profit or power and control instead of caring about the domain.
Thus we should all be Domain Driven, especially the business part of the company. And writing it like that is a bit depressing, but yeah, quite often the business part of the company does not really care about the domain itself.
In this case, we should help them to be more Domain Driven, or just leave them and go work in more healthy environment 😊

 

Dry should not be technical

Do you know the “I talk about it so often that I believe I already wrote a blog post about it” effect? It happens when you talk about something so often that you are sure to have a blog post somewhere to explain it more deeply 😉
It happens to me recently about DRY (Don’t Repeat Yourself). In a twitter conversation where I once more had to explain why DRY should not be technical. I’ve looked for my blog post about it. Just to find that it doesn’t exist yet… Thus, here it is.

DRY ?

According to Wikipedia, DRY is a principle of software development aimed at reducing repetition of software patterns, replacing it with abstractions or using data normalization to avoid redundancy.
One of the main arguments for avoiding redundancy is to improve software maintenance. It seems great right? If you have to modify the code in two places instead of one when you want to change a behavior, you increase the risk of error.

Coupling ?

According to Wikipedia, coupling is a measure of how closely connected two routines or modules are.
Low coupling is often a sign of a well-structured computer system and a good design, and when combined with high cohesion, supports the general goals of high readability and maintainability.

The main issue with DRY when apply dumbly is that it increases coupling (which is a code bad smell). Because, sharing the same code between two things create a coupling between them. Too many developers consider that two identic lines of code in the system must be merged and shared into one, because we want to be DRY.
The key to have a smart refactoring in order to be DRY is to care about cohesion.

Cohesion ?

According to Wikipedia, cohesion refers to the degree to which the elements inside a module belong together. In one sense, it is a measure of the strength of relationship between the methods and data of a class and some unifying purpose or concept served by that class. In another sense, it is a measure of the strength of relationship between the class’s methods and data themselves.

If we share code between two modules with low cohesion, the result is a dramatic decrease in maintainability. We take the risk to break the second module, each time we want to change something in this shared code for the first module.

DRY Should not be technical

An easy way to avoid this pitfall is to consider the business concept of what you want to share.
If the business concept is the same for the two modules, you can share it with less risks, because it should evolve for the same reason in the two places.
If it’s just a technical concept, sharing it may be dangerous, because both modules will probably need different updates depending on their use cases.

Of course it happens because, no matter if you know/want it, you’re Domain Driven. It means that your module will evolve because of business requirements. Low cohesion means the two modules have different business purposes, then will evolve very differently. And we don’t want to share something between two things that evolve very differently.

Let me recap

  • To be efficient, DRY must be combined with high cohesion (and few people remember that)
  • An easy way to detect cohesion is to care about the business goal of each module

I do believe it’s one of the first good practice easy to apply that can radically change your code maintainability day after day.

 

We’re all Domain Driven

Believe it nor not, one of the main reasons why software exists is to help companies to make money. These companies earn money because they have a business. Usually they sell something to customers, in order to solve a problem for them.

A software developer that doesn’t care about the business is missing an important point. It creates a mismatch between the business and the software. This mismatch makes the system harder to maintain, because even if we don’t want it, we’re all domain driven.

The burden to maintain this system lies on the IT team. In other words, denying the domain aspects of the software is a way to shoot yourself in the foot.

How to recognize this mismatch

When this mismatch happens, there are many patterns that emerge.

One of them is the “business sucks” syndrome. You can recognize it when the IT team is always complaining with arguments like “they don’t know what they want!”, or “they always change their mind”, and even “they sell something that doesn’t exist!”.

Of course they sell something that doesn’t exist, otherwise how would you know what to build?
Of course they change their mind, because they are constantly testing and adapting to customers.
Of course they don’t know what they want, precisely because it doesn’t exist yet, and it’s not trivial to know what’s possible to do with software.

Let me raise a warning though, selling something that doesn’t exist is totally legitimate from a business perspective. But stressing someone else because a business man took unrealistic commitment with a customer is not.

It’s the business job to sell stuff that doesn’t exist, and then to handle customers expectations until it’s delivered. It shows why it’s a team work. Without the production team, the business man has only dreams to sell. Without a business man, a production team has no one to sell the product. The sweet spot is to sell something that doesn’t exist, but that can be done quickly. In other words, something that “almost exist”.

How to handle this mismatch

The solution is to let the business drive your software. To let your domain drive your design. Good news, there is a bunch of literature about Domain Driven Design!

It can be resumed by: organize your code, then your teams, then your company around the business, and you will improve software maintainability and customer satisfaction.

It seems trivial, but it isn’t. Trying to know at every line of code which business purpose it serves is hard. Trying to know at every meeting which business purpose it serves is hard. Trying to know if the company has a structure that serves the business is hard.

It’s even harder because as the business evolve, the whole structure (company, teams, software) should evolve as well.

To be fair it’s so hard that I don’t think any company can achieve it. But trying to constantly improve following the principles of Domain Driven Design is good enough to be far better than the average.

 

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.

Discipline

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.

Love

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.