Jonathan Boccara's blog

The Dailies: how to efficiently teach C++ at work

Published April 4, 2017 - 0 Comments

If there is one thing that we, as developers, all have in common, it is our desire to learn.

We like to get better at our language, or maybe take on a new one. We are avid of code design techniques, we want to know about the best practices to apply, we are passionate about the latest features that come out and let us write ever better code. We like to make experiments, or read about those that others do, be there successes or failures. We are starving for blogs, books, videos, conferences and every source of knowledge that is available to us.

The problem with learning

Unfortunately, there is a major obstacle on our sacred path to learning: we just don’t have the time. Working days are so busy, and so is private life.

So I took the time (but not too much!) to think about how to learn a lot of things when one doesn’t have the time.

I realized that there are times when we learn things while we weren’t expecting it. For instance it’s quite common to learn an interesting insight while informally sharing a coffee break with a colleague. You know these people in companies that know so many things? You certainly have a couple of them around you, don’t you? Or you may even be one of them (and you’re not aware of it yet).

It seems to me that this knowledge is kind of wasted. During such informal moments, why is it just a handful of developers that could have access to the insight? Why not every other developer of the company?

To tap into this vast bank of knowledge that we possess, collectively as all the employees constituting a company, I came up with a new format of presentations, to keep learning besides of corporate training: the Dailies.

The Dailies

The Dailies are a presentation format that are made to transfer a substantial amount of knowledge within a company, with a minimal investment in time of the working day.

It consists in:

  • giving a presentation once a day, and at the same time every day. On the (not-so-) long term, it accumulates into an impressive mass of knowledge. Also, leaving 24 hours between every episode leaves time to assimilate, and potentially come back with questions.
  • the presentation lasts for 10 minutes. This is the key. Every one has 10 minutes to spare during this day. This is the time you would invest into trivial things such as a coffee break, making a phone call or waiting for a lengthy build. Moreover, in 10 minutes you don’t really have time to get bored, and this makes it easier to follow and retain the contents of a presentation.
  • it’s internal: by people of company, for people of the company. This way you don’t need to worry about getting a budget for an external trainer, nor about scheduling sessions with him. We keep agile. The other advantage of an internal training is that it increases the chances that it will tackle the real problems faced by the people of the company.
  • you don’t have to move: presentations are given right in your office space! The team that hosts a Daily just has to spin their chairs, listen to the presentation, and get back to work right when it’s finished.
  • it’s filmed and uploaded, so that everyone can see it again or share it. We also make transcripts of the presentations. The transcripts look like blog posts, and we share them too.
  • the presentations are structured into monthly sessions. the presenter of a Daily gives his or her talks in the same office space for a month or less, and then gives them again to another interested office space the following month. For example, Team A hosts Daily C++ in January, then Team B hosts it in February. At the same time in February, Team C is hosting Daily Java and Team A is hosting Daily Functional Programming.

This is how I teach C++ in my company: the Daily C++.

I realize that the concept of daily talks is already applied in some companies. But what I think makes the Dailies special is their structure and rules, that focus on being as easy as possible to follow for the audience. Such a structure allowed other Dailies to spring up. For example, here is François giving his Daily Java:

Daily Java dailies

Since we started, a bit more than a year ago, several other Dailies have spawed at Murex. On the top of C++ and Java, we now have Daily Functional Programming, UI, Bitcoin, and Automatic Differentiation. And others are in preparation, such as Daily Clean Code.

Given this experience, I genuinely think that Dailies are realistic to put in place in software development companies. This is why I want to share the concept with you (and I am presenting it this year to Devoxx, the major development conference in Paris). I am convinced that you can benefit from it, the same way that we are at Murex.

What it takes to make a Daily

At this point you may find the concept kind of cool, and would be prepared to attend a Daily. But, if you’re like most people, you are not even thinking yet about animating one yourself.

Like most developers, you may think that you don’t know how to speak in front of people. And this may well be true. Let me tell you that the first time I did it, I did’t look like Steve Jobs (and I still don’t). But this is seeing the situation the wrong way up. It is by presenting that you become a good presenter. And Dailies give the most intensive practice to presenting that you can get. I’ve seen people make impressive progresses in a short period of time with this amount of practice. Can you imagine how you would be, a year from now, after having spoken dozen and dozen of times in front of other developers? I promise, presenting is not that hard, and it gets a lot better with practice.

Next, you may think that you don’t have that much to share. But let me unveil an incredible truth about yourself: you do. Whatever your experience in the field of software development, you know things that would be of interest to others. Can’t you think of some things that you’ve learned recently, that you found useful, or simply interesting?

Also, the more you teach, the more you have to teach. It is a bit surprising because you would think that you’d dry up once you said all you know. But in fact when you synthesize what you know into a presentation, you often realize that there are aspects of your topic that were more complex than they initially looked. And this makes for sub-topics and new talks.

Moreover, the Dailies make you travel in your company, since you give local presentations in various office spaces. This way you get to meet a lot of people, that will ask you interesting questions and share their experience with you. And this often brings up new points, worthy of talk themselves.

Finally, the question that I get asked most about Dailies is how much time does it take to prepare? From my experience, it depends on two things:

  • how well you know the subject before starting. If you have to conduct research and experiments to build the contents of you talk, then the sky is the limit. But if you know it fairly well, I found that it only takes a few minutes to structure your 10 minutes intervention.
  • what level of details you choose for your transcript. Writing is definitely the part that takes the most time. It may take two hours to properly write down all the contents of a 10 minutes talk. I strongly advise that you leave some trace of your talk, so that people can get back to it later, but the way you do it is really up to you. You can even just film the session and upload the video.

Dailies are a practical way to share the enormous amount of knowledge that lies in the various people constituting a company, without even requiring a budget. They allow us to get better at our jobs, and more motivated by these shots of knowledge that we receive every day.

If you’re doing a Daily, take a picture and post it on Twitter! You can use #DevDailies.

You have all it takes to launch your own Daily. Why don’t you go and make the most of everyone’s coffee breaks?

Share this post! Facebooktwittergoogle_pluslinkedin    Don't want to miss out ? Follow:   twitterlinkedinrss

Receive regular updates to make your code more expressive.