We did not forget how to code

In a recent article, David Haney asks if we have forgotten how to program. I think not, rather we evolved.

We evolved from writing technical not so useful code to writing specifications.

Don’t misunderstand, when I am talking about specifications, I am talking about code. I am talking about coding crystal clear specifications even a computer can understand.crystalClearHow can we write “good” code?

Good code has two characteristics: it is useful for the business and usable for the developers. (usable in the meaning of Alexandru Bolboaca  and Johan Martinsson , for more information please refer to Alexandru’s book currently in writing, or Johan’s blog).

To write useful code, we need continuous domain knowledge crunching and refining. We want to avoid  technical stuff producing no direct value for the business.

To write usable code, we want to write code with clear abstractions, and easy navigate around these abstractions. We also want to replace/modify some code without pain.

From a business point of view, unless they are in a really specific context, they don’t need to know how to pad left. They don’t need to explain it either, because it’s obvious.

From a programmer’s perspective, we also rarely navigate in such an obvious low level of abstraction.designRewrite everything?

In most modern languages, these obvious and technically common operations are part of the core framework. Even if we know how to code them, even if it is quick to code, we don’t want to, because it creates no value for the business, and no usability for the developers. It does not make our code better.

 It’s dangerous to say « We should not depend on other libraries, we should rewrite what we need! » Where do we put the bar for « rewriting? »  Should we stop using NPM? JQuery? What about .NET and Java?    rewriteIt’s not the user’s fault, it’s the design’s fault.

That’s a core rule from UX translated to usable software design. We should always keep it in mind when trying to understand a problem.

The lesson from this “left pad” story is not that we should re-write everything to depend on nothing, but that NPM’s design allows a library to be deleted, or worse, to be changed.  

Imagine if Microsoft decides to change the behaviour of something widely used like String.Concat ? (or String.PadLeft if you lack imagination)

Asking every .NET developer to write these themselves is not the solution, even if writing a concatenation function is easy.

It’s unsustainable, a whole ecosystem cannot be built on an unstable foundation. If we want an ecosystem to evolve, we need a rock solid foundation.

This story shows how immutability is fundamental when thousands of users are depending on us.  

This kind of dependency, when hiding obvious stuff, is not necessarily bad. It’s more like solid roots allowing us to grow up.goodBadUglyDependency: the good, the bad and the ugly

The difference between bad dependencies (big frameworks) and good dependencies (little libraries) may be tricky. The key is: if the hidden part seems obvious to us and adds no value to our business, then it’s a good dependency. Otherwise we should prefer to rewrite it in complex contexts, because we will quickly be limited by what we don’t understand in our framework anyway.

This story should teach us that building an ecosystem is hard, and requires immutable, solid foundations. Please don’t re-write everything.

Let’s evolve together.


As usual, thanks to my kind reviewers: Brian Gibson, Jean Helou and Jérôme Avoustin

About hiring the best

A few years ago, three co-workers and I decided to work on the concept « hack your job ». We were convinced there was something wrong with recruitment and set out to find a technical solution. We wanted to find a better way to match great developers unable to find interesting jobs with great companies unable to find interesting developers. We concluded this problem required a human solution. Today, I would like to share a potential human solution to improve the recruitment process.


Disclaimer (edit)

I had some feedback accusing me to try to find a generic solution to hiring. As explained in conclusion, I don’t. My context is a start-up context with highly passionate and motivates people. I don’t claim the proposition I do here is generic, I don’t even claim it’s a good solution, I just assert this is how I would personally try to find great co-workers in my start-up.

I could even write a general disclaimer, I don’t try to teach anything to anybody in any blog article, I just give my feelings and experience.


What’s wrong with recruitment

I think the root cause is our mental bias for judgement. We believe ourselves to be good judges. We actually do it instinctively, anytime we met new people. Fact is: We are very bad at it. Humans are complex creatures. We can’t understand them within a few hours. It is known as the sampling bias. We believe a sample of time with someone will be enough to know if she is a fit for the job.


Military recruitment 

Daniel Kahneman is the psychologist who wrote Thinking Fast and Slow. In his book, he describes this error very well, because he did it himself. He worked on a team in the army to evaluate new soldiers. Their task was to determine if the soldiers would be good leaders (thus candidates for officer training) or not. They worked really hard to create a comprehensive series of psychologic and physical exercises to determine the soldier’s leadership skills. Tests were run over several days, the team’s confidence in the results they produced was high.

However, after a few years, the feedback they received was disappointing. Few soldiers they recommended for officer training were considered good leaders in the end. And many less recommended soldiers reveal themselves as good leaders.


Software recruitment  

Jeff Atwood recently wrote an excellent article on the topic. For him, software recruitment is wrong. I strongly agree and will reiterate many of the arguments and solutions from this article, adding my personal understanding and experience.

I see two general approaches to interviews:

Either we conduct an easy and short interview where how a candidate “looks” has a larger role than what they are able to do (not on purpose, but this is how our instincts work).

Or we conduct very long and complex interviews, often in several steps, lead by technical gurus. In this kind of interview, we believe we’re looking for talented people, but actually end up selecting technical clones of the gurus leading the interviews.

I’m not sure which one is the worst. With the first kind, chance is a big factor, but at least we may add diversity in our team. Maybe we won’t hire the best technically, but we will more likely find the disruptive employee with the ability to challenge our work. With the second kind, we will find people fitting our technical needs, while rejecting, more diverse candidates who just did not perform as well during the interview.


Hard interviews do not produce great candidates 

They produce great CV writers able to perform well under pressure. Are we hiring engineers for their writing skills? Do we plan to let them work under pressure ? Under pressure we can’t see the big picture, we can’t challenge and improve ourselves. We sense and react to whatever comes next. It’s not a professional behavior.

Removing pressure is the main goal of what I do almost everyday as a software developer. Unit testing, decoupling, context analysis…Whatever I do, I do to improve and manage my work in my context. Understanding our context and mastering the code we produce reduces the pressure we have to support.


How to find great candidates?

A software engineer writes code, with a team to solve business problems. An interview should be exactly that. Instead of simulating stuff, perform a selection based on the developer’s passion, as advised by Sandro Mancuso in his book. Can you find her on Twitter? On GitHub? Can you see some code she wrote? Is she active in local user groups? Any blogs? StackOverflow profile? None of that? Nevermind, take a coffee with her and find clues of her passion. Does she code at night? Any side project? How does she feel about new technologies? Does she realize we developers are changing the world?

As soon as you think you found someone passionate, find a way to work with that person for a few weeks. Jeff Atwood suggests asking them to work at night, or on weekend, or take vacation (if someone does that, it’s a clear sign of passion), and of course, pay them. Consider them as part of the company during this period, so they can really show you how they behave as software engineer. At the end, decide together if they are a good fit or not. You must especially hire them if they are better than you.


How to find great companies?

Be the candidate we want to work with. Recruiters cannot take the whole responsibility for bad hiring processes, candidates must adapt their behaviors too. An interview  is a two way process. The company learns about you and you learn about the company.

Show your enthusiasm, give some feedback to recruiters if you think their processes or mails are not that good. Show some respect and passion. Show your interest to understand their problems and how they plan to solve it. Be a Professional, always raise the bar. You can’t wait for the perfect company if you don’t try to be the perfect co-worker.


Hacking the interview

It is certainly not a perfect recruitment process, it is not meant to be. You still have bias, but by increasing the time sampling, you reduce the overall judgement bias and luck factor.

Fighting our biases, as candidate and as recruiters, is one of the hardest and most useful things we can do to improve our hiring process.


Thanks Brian Gibson , Clement BouillierAlin Dicu  and William Huart for the reviews and feedback.

Let’s be people centric

DDD, like agile and software craftsmanship, is very hard to teach.

We can explain concepts, describe patterns and practices, show some good habits. Still we can’t easily teach them, they are too large. The cognitive load is too heavy.

The consequence is that we usually focus on a subset of practices, and claim this is the essence of the principle. This is why some people believe DDD is tactical patterns, software craftsmanship is TDD and agile is SCRUM. It also explains why frameworks or simple patterns like micro services are over used.

I find this dangerous and believe it’s important to understand what these hard topics have in common. If we understand what is intrinsically hard in them, we may learn how to teach them in a more efficient way.information

It’s not about answers

It’s about questions. The three topics do not bring magic answers to our problem. They usually bring more questions. These questions allow us to evolve, to improve ourselves, and to dutifully accomplish our jobs.

They require being mature to accept that every answer we find will lead to more questions. They require courage and perseverance, but it’s worth it, because improving our habits will improve our professional life.darrell-fraser-quote-there-are-many-questions-but-no-answers

It’s not about a generic solution

It’s about context specific situations. There is a single answer to these three questions: What should we do to be craftsmen? What should we do to be agile? What should we do to be great DDD practitioners?

The answer: It depends.

What is our context? Do we work in a multinational or a startup? On a web or desktop application? In the finance or healthcare industry? The combination of all the specificities of our jobs is our context. For each context, different implementations are required.

What makes sense in one context is not necessary what makes sense in others. Every single architectural pattern coming out of Silicon Valley is not necessary a must have for your next project.


It’s not about technical stuff

It’s about people. The deep roots of DDD, software craftsmanship and agile are about people. Unfortunately, we mostly apply technical practices hoping to solve people problems, but fixing people is really hard.

Instead we should concentrate on understanding how they communicate and their particular business needs that are crucial to helping them create value.business conversations

Should we stop talking about it because it’s easily misinterpreted?

Of course not, but we should be aware of this problem when we are trying to communicate these subjects. I heard more great advice from Liz Keogh at DDD Europe 2016 that we could apply here: “Don’t strive only for the ‘whys’, put some ‘whos’ inside.” When speaking of practices, don’t forget about the team, about the context, and about why we think they make sense or not for us.

This is how we could be more effective transmitting passion on these subjects. By speaking about what it brings to us in our daily work, others may apply it, if they recognize a piece of their own context in ours.

It took me seven years to realize that I shouldn’t be an evangelist trying to push what I think are good practices. Instead I should have contextualized for others habits that improved my professional work.


Let’s be people centric

Let’s stop being technical monkeys always defending what we know as the only viable solution.

Let’s improve our communication about deep topics like DDD, software craftsmanship and agile.

Let’s be people centric.


Great Thanks to Brian Gibson for helping me to improve my English writing.

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.

Why I no longer recommend that book (update 22/10/2019)

Because John has a really toxic behavior in the past few days.
As a public person you do have some responsibilities, the first of it is to lead by example.
Attacking people online is certainly not an example. 

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