Remote

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.

Content

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.

 

 

 

Rework

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.

Content

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.”

would-in-the-past 

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?”

quote-those-who-do-not-remember-the-past-are-condemned-to-repeat-it-george-santayana-162594

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?

imagesq1bg3pxm

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.

learn-icon

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).

 happyending_dark_x2

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.

41ebnx45bbl-_sx329_bo1204203200_

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.

arroganceRewriting

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.

the-essence-of-writing-is-rewriting

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.

shutterstock_178355147-300x200Feedback

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.

millett_patterns_principles_and_practices_of_domain_driven_design

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.

domain_driven_design

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.

wooden_fence_png_by_camelfobia-d5kka26

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.

softSkills

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.

success

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.

3paths

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.

personal-social-media-branding

Learning

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.

learning

Productivity

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.

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.

bodymindspirit

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.

Pick-your-battles3

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.

ed5

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.

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.

 

The Passionate Programmer: Creating a Remarkable Career in Software Development

This a book full of good advices: “The Passionate Programmer: Creating a Remarkable Career in Software Development”

Chad Fowler (former Jazzman), gives a lot of little simple advices. Concrete examples that you can do daily to create a remarkable career. This is clearly a book for passionate programmer, but you could guess that from the title.

I personally do not agree with every proposed solution, but most of them are interesting enough. My main problem is that if you follow every advice in the book, you have to be single and forget all other activities but IT.

Still, if you pick the most pertinent advices for you, there are a lot of “good professional practices”. Here are the most pertinent for me:

– Find a mentor to improve

– Learn to teach what you learn

– Keep being up to date with your favorite’s technologies

– Do not put all your eggs in one basket (learn different languages)

– Understand the domain you are working for (DDD is in the place…)

– Invest some times in differents User groups and Meetups (JUG/MUG/Mix-it and so on)

– And the most important: learn to say no

In conclusion, this is an excellent book. Easy and quick to read. Of course you need to nuance some advices. I think it is not very hard to be successful if you work 18h per day 7 day on 7. Work is only a part of the life, even if you find it important. The difficulty is to be successful enough and keep a social interesting life.

Anyway this is the kind of reading that gives you the good ideas you always feel, but you do not know how to put it in practice. The experience of a successful programmer and how he manage to do it is always interesting.

 

 
IP Blocking Protection is enabled by IP Address Blocker from LionScripts.com.