The power of habit


“I’m not a great programmer; I’m just a good programmer with great habits.”

You have probably already heard this famous quote by Kent Beck. It is one of the most insightful quotes I heard in my career, because it carries hope.
Hope that you, me, anybody can become great by relying on habits. And this is great news become you were not born with habits. You rather develop them in response to an ecosystem, and you are more or less aware of them.
It is a common falsehood to convince ourselves that we develop habits in response to what we deeply are, in our soul, mind and body. But it’s exactly the other way around, we are in the end defined by our routines.
You’re not a drug addict because it was written in the stone that you will live as a junkie. You became a junkie because you relied on (bad) “having fun” habits for so long that, at some point, you lost control.
You’re not an average developer because you’re not smart enough. You became an average developer because you relied on (bad) coding habits for so long that you cannot even think about another way to work in this industry. Which leads to remark like “X is a great idea, but it doesn’t work in practice”. Where X is any good practices of software developers like unit testing, pairing or continuous deployment.

In other words, anybody can radically change its own life by changing its habits. This is exactly the topic of the last book I would like to share with you: the power of habit.

Great stories

Charles Duhigg is the author of this book, and he is such a good writer. I rarely had this much pleasure while reading a non-fictional book. The topic is the power of habit, why we do what we do and how to change it, but the writer uses storytelling to share with us his findings on the subject.
This book will improve your knowledge about the human brain, behavior and psychology, and provide awesome anecdotes about it. Stories about how a man with brains’ damages had an almost normal life despite a total amnesia, about how the coach Tony Dungy turns The Buccaneers football team from one of the worst to one of the best of all time, or about how commercial successes likes Pepsodent or Hey Yah were built in the background, all of them relying on the power of habit.

The book is organized around scientific findings, described through great stories, to make it popular science, and it is a delight to read.

Great advices

If you are not already convinced that habits are powerful, you will probably change your mind after reading a few of these stories and thinking a bit about your own life.
But the best part is that once you are aware of it, you have a chance to change the bad ones, and to improve the good ones. And the book also contains practical advices on how to do it.
In other words, this is a great tool to help change your life, and that is why I’m happy to share it with you.
It is, by far, the most impactful book on my daily life I have read for a while.

Sharing my good habits

Since more than 10 years now, I regularly teach myself some routines trying to get better. These habits now define me more than what I can say or write I believe. Here are some of them from the most to the less impactful:

  • Learn (by training, reading, watching videos and attending conferences, there is nothing you cannot learn)
  • Teach (through blog, book, training or anything, as soon as you learn something interesting, just share it, it will teach you even more)
  • Daily Exercise (physical training, it can be hard fitness or just a gentle walk, the point is to empty your mind and care about your body)
  • Stay focus (pomodoro helps me a lot for that)
  • Log your daily work (you probably already do daily stand up? Have you tried to write your plan and what you have accomplished every day? I barely do it for a year now, and find it to be essential already)

What about you? Which habits were the most impactful in your career and life?

 

3 bad coding habits of most software developers

And trust me, when I say “most developers” I include myself as I am now, or as I was a few years ago. 
Let’s talks together about the most productivity killer habits most of us share. I’ll discuss them from the less to the most common with my current experience. 

2 hours of manual testing can save 2 minutes of automated testing 

Unit testing is more and more widespread, but of course the game now is to explain why, in your team/context, you “can’t really do this”. 
A few of the usual excuses we tell others (and ourselves) are: 
– This is just a little project 
– The team is not trained/ready for this 
– We do not have time to write tests because we need to deliver features 
– Unit tests are worthless, we prefer end to end tests 
But 2 hours of manual testing can save 2 minutes of automated testing. Unless you won’t need to test your feature more than once or twice, writing an automated unit test will most of the time worth it (especially if you write it before, hence keep a testable architecture) .
Honestly, what would your customers say if you tell them that you don’t test everything at each release? Or worst, that most of the cost of the development process is actually manual testing of the software? 
Trust me I fought this idea long enough and was looking for many alternatives. As many beginners, my first contact with this method was something like “why the hell would you ever need this if you know how to code?” 
But in 10 years, I still haven’t found anything better than unit testing to deliver quality software and to speed up feature delivery in the mid and long term. 

2 days of Pull Request can save 2 hours of pair programming

I know the first point about unit testing is probably consensual enough, at least by the reader of this blog. And I know that this point about Pull Request will trigger much more discussion. 
My point is that, most of the time, Pull Request is a (bad) way to implement collaboration in the team. Probably one of the worst way to do it because: 
– It is asynchronous and necessitates lots of context switching both for the author and the validators 
– It slows done the flow of feature delivery as a Pull Request can stay for days in the review stage 
– It implies a relationship where the validator judge the job of someone else, and often feel necessary to add comments just to show that she took the time to seriously read the Pull Request (and sometimes it’s a true hierarchy relationship, when only architects or tech leads are authorized to validate Pull Requests) 
Yes, 2 days of Pull Request review can save you 2 hours of pair programming. Plus pair programming will improve the common code ownership, spread good habits, coding tips and domain knowledge in your team much faster. 
Should we avoid Pull Request then? No but use it only when it is strictly impossible to do the work directly in pair or mob. I hear you: “But my manager will kill me, 2 people to do the same tasks is pure madness!”. 
A first step to feel the benefits of what I describe here is to ask for synchronous reviews with the author. It will be much faster to validate it, because it’s easier to understand what our coworker means with her voice than with her code only.

2 weeks of coding can save 2 days of Event Storming

If I had only one thing to tell to younger me, that would be “Not Silverlight!”. More seriously that would be “being able to quickly understand any domain context and the human relationship involved in them will make you a much better developer than mastering any of the shiny tools around”. 
Don’t misinterpret me, methods and technology matters, but the challenge is to find the one fitting your context. Whereas most of the time we just impose our technical knowledge (ie habits) to the business (which is why most software are just CRUD built on relational database with the last fancy framework if you ask me). 
The thing is, we don’t care how good domain experts and/or the company are. The most critical point in software development is how well the developer will understand the domain. 
The best method I know so far to share business knowledge is known as Event Storming. It’s basically a meeting between technical people and domain expert to talk about how the company earns money. 
I know, business people are “really busy” and it’s very hard to get them for a few hours talking with you. The question though is, can they afford throwing away weeks of coding (or worse: keeping bad code and trying to fix it for the life of the software), when people will realize that the software doesn’t fit their needs? A few days of Event Storming, even with the whole team, is really cheap compared to the usage and maintenance of a bad software. And like for pair programming, it improves the feeling of common ownership of the software, more people feel involved in the process of creating the right tool for the company. 

Why are these methods still unusual? 

First of all, I would say that they are more and more common, but of course it’s still far from the usual way of working. I think it’s mainly due to the following points.

Line of business software are so complicated that nobody can control them. A corollary is that this level of complexity should be managed by a team, with proper tools. But we usually ignore this fact, due to our ego or just by habit.
All these methods have midterm return on investment, and are thus hard to evaluate. It doesn’t fit well in a company with a Taylorist state of mind and management, which is still the majority.

But as soon as you accept the complexity of software development and keep an egoless approach, these methods suddenly seem absolutely normal, as a way to avoid time wasting. 

 

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

 

Migrating Database from ClearDB to MySQL for WordPress in Azure

You know this feeling when something that should take an hour finally take a day? That’s what happens to me when I tried to move my database from ClearDb (because it’s no longer included in the MSDN subscription). I wanted to use the free MySQL in App instance instead, and I wasn’t able to find a simple and complete guide for that. Hopefully this one will avoid some pain to some people.

About ClearDb and MySQL in App

ClearDb is a Saas service for MySql database. They used to host the WordPress azure app service. But now we have to pay for it as it’s no longer included in the MSDN subscription. An alternative is to use the free MySQL in App database provides by azure with app services. Beware that this Database is normally for testing purpose, they are not recommended for production. But for a WordPress site hosting a blog like mine, I think we should be fine.

Let’s save everything

The first action to do is to save your website (Just in case :)):
YourApp -> Settings -> Backup

The second action to do is to save your Data from ClearDb. The easiest way I found was to activate MySQL In App:
YourApp -> Settings -> MySQL In App

Click on “activate”. Then you would be able to click on “manage” in the upper left corner. It will open your php MyAdmin UI for your web app. You normally have (at least) two server available in the server list in the upper left corner. One is for your ClearDb database, the other one is for the localDb from your MySql In App.

You can select the ClearDb server, select your WordPress database, and use the export button to get a sql script from your DB schema and Data.
Now you can select the MySQL In App server (localhost), and use the existing localDb, then import the sql script that you get from the ClearDb database.

Reroute WordPress to the new Database

Last but not least, you need to change the wp-config file from the WordPress site to use the new MySqlApp database.
Go to https://[yourwebsite].scm.azurewebsites.net/ to see your Kudu UI. Using the Debug console, you will find your wp-config file in: D:\home\site\wwwroot.
You need to change the following values:

define('DB_NAME', ‘localdb’);
define('DB_USER', ‘azure’);
define('DB_PASSWORD', 'password’);
define('DB_HOST', ‘127.0.0.1:port’);

To know the value for the connection you can check the ConnectionString for the My SQL App in D:\home\data\mysql\MYSQLCONNSTR_localdb.txt
It should looks like this:
Database=localdb;Data Source=127.0.0.1:port;User Id=azure;Password=password
Just extract your database name, user id, data source (host) and password.
Note that you need to precise the port for the host.

Cleanup

You can now remove the ClearDb connection string from the app service:
Settings -> application settings, connection strings
And of course stop your potential ClearDb subscription!

Hope it helps.

 

 

 

 

 

 

 

Breaking people

An interesting discussion including  Yannick Grenzinger, Romeu Moura and Daniel Gonçalves has recently happened on Twitter. Thanks mates for the respectful and enlightening exchange.

It started from this:

The first objection was from Yannick Grenzinger:

Which, as  Daniel Gonçalves noticed, resonates a lot with an older tweet from Nicole Rauch:

I think the matter deserves a blog post to explain my position. Not because it’s the right position, but rather because we all have different experiences, with interesting things to share. I kind of agree with Nicole, and still I think we can survive it, if we stop trying to fix the system.

What’s breaking people?

The first step is to agree on what it means to “break people”. I was once, when I started my career.
We feel broken when we lost interest in what we are doing. When we stop trying to improve, because it seems excessively hard. We know that something better could be done. But we feel that whatever we can do will not have any meaningful impact. First, we lost our motivation, then our discipline, and finally our values.
Because what we can do doesn’t matter, it doesn’t matter either way if we don’t write a unit test for this code, or if we don’t take the time to refactor it. It doesn’t matter if the build is broken or if there isn’t any automatic build. It doesn’t matter if we ship bad software for unhappy users. That’s because of the corporation, not because of us. They want us to ship too fast. They want us to write crappy code. They recruit only juniors. They don’t care about code quality and good software. They don’t want to hear about pair programming. They just consider the IT as a cost centre. If they don’t want to change and see the world like us, there’s nothing we can do.

The global local impact

I’m a firm believer that you don’t change the world by imposing your view. You change the world by acting locally and leading by example. That’s exactly how I understand Gandhi’s mantra “You must be the change you want to see in the world”.
When I do consulting for a company, no matter how big it is, I start by acting locally. Of course, it would be easier to act globally. It would be easier if the whole company, at all levels, will follow the agile principles at once. But it never happens to me. And who am I to know the correct way of working for the whole company? I don’t know. What I know is how to write software efficiently. What I know is that it doesn’t belong to any managers to choose if we must write unit tests, or if we should use a build server and do code reviews.
Whatever the context is, I can keep my discipline and my values, which are mandatories to stay motivated.

But the system will break you!

Fair enough, that could happen, but at one condition. Only if I fail to recognize the moment when the “system” is creeping into my local safe area. I did this mistake once, and it won’t happen again.
Since then, when I do recognize this moment, I do whatever is possible to protect the safe area. The last possible solution is to abandon it and let it collapse.
Is it a big deal? Absolutely not. Our team could fail, our product could be shitty in the end, our company could re-create a command and control culture, but I (and the people convinced by my example) will be safe. Because we will leave and find another place where the culture is less corrupted, where it will be possible to manage a full project, at least locally, with our discipline and values.

So you’re just a coward?

I always clearly explain how I work during interviews. My behaviour will never be a surprise, as I clearly state that some practices are not optional for me to work.
Anybody who has already quit a gig or a job know how hard it is. Like every other passionate people, I have strong feelings about my job. And it takes lots of courage to admit that we’re no longer in the capacity to protect our local safe zone. It’s a failure. It is the proof that we couldn’t change enough people around us. But it doesn’t mean that we must abandon our discipline and values. It just means that we must abandon this toxic context, to find a better one.

How do you change anything if you left when it’s hard?

As it happens, lots of companies are looking hard for competent developers, with strong skills, discipline and values. It explains why, in 10 years of professional software development, I only need once to quit such a toxic environment. Since, I’ve always found some places where my discipline and values are much welcome.
I didn’t change any system so far, but I’ve done more important things. I’ve influenced the way of working of several people, in such a way that broken systems were no longer able to break them.

Changing things is not as important as changing people. From the latter, the first will happen.

 

 

 

Diverse IT

Here is another privileged white guy who stand up to talk about diversity. Let me explain why.

Google memo, Uncle Bob and the SoftwareCraftsmanship community

If you didn’t follow this thread, you can have few information here. The thing to understand is that it’s a big matter. There are lots of anger, misconception and bad explanations, between smart people. I would like to testify as the average privileged developer why I ignored this matter for so long, and what I decided to do to care about that. Because as Martin Fowler says, “you can’t choose if you hurt someone, but you can choose if you care”.

A long ignorance

I am a passionate developer, and I do respect competent people. I really don’t care if they are higher in hierarchy, if they are men, women, black, white, gay, if they believe in any god(s), if they have lots of experience or if they are juniors, if they drink alcohol, if they eat meat, if they wear suits or t-shirts… I just do care about how competent and passionate (the two are generally connected) they are.
And because of that, I believed that I had the good behaviour. I deal with everybody in the same way, that’s fair isn’t it?

A spark of light

But then I meet different people and attend to different conferences, especially in the Software Craftsmanship community, where I learn so much about this topic. And thanks to them I realized two important mistakes I’ve done: assuming that equality is enough, and assuming that I’m not legitimate to talk about it.

 

 The equality inequality

Treating everyone equally is great. But it’s unfair at the same time. If you were a woman in the twentieth century and won a Nobel’s prize, are you equal or better than other Nobel’s scientifics? From a pure cognitive perspective, you are probably equally smart. But to achieve the same scientifics result in this male world, you probably must fight much more. You must fight for your rights, to be recognized by your pair, much more than an average white man.
The same thing happens in IT today. We must acknowledge for example that to be equally recognized in our field, women need to work harder than men.

 

The legitimacy paradox

Because I didn’t feel legitimate on this topic, I didn’t talk about it. But because I never spoke about that, people like me might think they should not care about it either. Worse, it’s always the same legitimate people who talk about it. But what if they would like to talk about TDD or CQRS/ES instead?

What to do?

First, we have to be careful in our talks, especially in public presentation. Be careful about genders, when we use guys, he, craftsman and so on for instance… Of course, it is the same thing when we write blog posts and when we use twitter.

Every day at work, we can watch our jokes and behaviour. Watch other jokes and behaviours as well, learn to identify when someone is hurt, and let her (or him) know that you care and you will do your best to avoid that it happens again. And when we hurt someone (because everyone can make mistakes), we should just apologize. No need to look for excuses, just apologize. Uncle Bob unfortunately gives us a good example of what not to do recently.

As I already said, it’s important to speak about this, at work, in conferences and everywhere, especially if we are part of the privileged guyz.

It’s far from enough to fix the problem, but it’s a start, and at least, it shows that we care.

 

 

Thanks to the awesome Franzi who specialy helped me to grow up on this topic.