Hi, I'm Jonathan Boccara. I am a senior software engineer in a tech company and I blog on Fluent C++ about writing clean code. Ask Me Anything!

Jonathan Boccara
Feb 11, 2018


I'm Jonathan Boccara. My job consists of writing and maintaining code in a large C++ codebase in a software company (Murex).

What I strive for is writing expressive code, that is, code where you understand the intent of the person that wrote it. I think this is the most important characterstic of a piece of code to survive over time.

There are plenty of ways to make code expressive, and I blog extensively about them on Fluent C++.

Ask me anything on:

  • writing expressive code
  • writing expressive code specifically in C++
  • keeping your spirits up when facing not expressive code

...and I'll do my best to answer! :)

joboc says:

This AMA will end Feb 18, 2018 11AM EST

Comments are locked

Conversation (90)

In three easy steps and under a minute you could be hosting your own AMA. Join our passionate community of AMA hosts and schedule your own AMA today.

Let's get started!

Do they teach C++ in school? What’s the best college course to get for those who want to learn about this?

Feb 18, 12:03AM EST0

You mentioned you never worked as a freelancer; would you consider doing so in the future?

Feb 17, 10:09PM EST0

What separates a great programmer from a good programmer?

Feb 16, 5:29PM EST0

Do you choose the clients you work with? Is there a particular niche you're most comfortable with?

Feb 14, 5:53AM EST0

I personally don't, because I work for a fairly large sofware company, that has their clients. But I'd imagine that some developers, in particular freelancers and consultants, must have more flexibility in choosing their clients. Although I hear freelancers that tell me that sometimes clients are too scarce to be picky.

Last edited @ Feb 16, 9:58AM EST.
Feb 15, 3:31PM EST0

Do you think a functional programming style enables you to write more expressive code than an imperative style?

Feb 14, 5:20AM EST0

I think that functional programming style allows to write more expressive code than an imperative style when it comes to code that performs computation. And by computation, I don't only mean maths, I also mean all the logic of a program (generating objects, comparing collections, ...).Functional programming style has the big advantage of guaranteeing side effects on objects. This makes the code easier to understand, hence more expressive, because you don't have to perform those side effects mentally to follow along.

However, I think that to perform operations, imperative style is more straightforward. By performing operations in include side effecs on the outside of the application, such as producing an output of the program (writing in a file, a DB, a UI), but I also include side effects on objects in code. For example, you have an object that is built by several functions:X myObject;changeThisToTheObject(myObject);activateThatInTheObject(myObject);in particular if various contexts would call various combinations of those funcitons.Those side effects are local to one variable, I find they are OK to follow, and they have the advantage of being straight to the point.

Now there are other coding styles as well. I've attended a talk of Anjana Vakil where she classifies programming paradigms in 4 categories: imperative, object, functional and declarative.

Take the object oriented style for example. Is object better than imperative or functional? Is it optimal that all the codeline consists in object exclusively?

It's funny how the periods of computer science history have had different views over those paradigms. In an (excellent) article of James Noble called Argument and Results, the author calls routines "protocols" and says that "a program's protocols are the glue that binds its objects together". It was written in 1997, when the world was object-centric.

Today, the Haskell language which is purely functional and has no notion of objects is increasingly growing in popularity. So much so that some universities I know ask of their students to hand in some of their assignments in Haskell. This is another extreme where the way of thinking revolves around functions.

So which one of object or functional is better?

I've had the opportunity to chat with Michael Feathers about this. His view on the topic sounded very sensible to me: a good design is to structure the code with objects, but to implement the methods of the objects by following the functional programming style.

Also, on the other way round, I think that objects can be used inside of reasonably functional code for two purposes:- lumping several functions into one entity (the object) that you can pass around in code. Even is this object has no mutable state or no state at all.- encapsulating a local state that would otherwise spill over into your calling code (such as mutable curried object, on which I'm preparing on article).

Now how about declarative style?

By declarative I mean code where you merely state your intentions of the desired behaviour rather than how to how to implement the desired behaviour. At this stage this seems very attractive to me, but technically hard to achieve in a lot of cases. One way is to design a declarative interface to which you can state your intentions, and an implementation behind which contains the nuts and cogs. But both parts represent some challenge.

This is a wide topic, very opinionated, and I'd love to hear more opinions on it. Yours would be welcome :)

Feb 15, 1:04PM EST0

Do coders get paid a lot of money? Is it better to get hired by a company or to just work as a freelancer money-wise?

Feb 13, 11:50PM EST0

Salaries can vary greatly. Typically it depends on the sector. The video games industry has the reputation of being tough and having not very attractive wages. On the other hands, some companies, like Think-Cell, openly display attractive salaries for their employees.

As for freelancer VS employee, I'm afraid I couldn't tell as I have never worked as a freelancer.

Feb 14, 12:47PM EST0

Does a coder’s job ever get boring especially since you deal with a whole lot of codes (obviously)?

Feb 12, 8:22PM EST0

Not necessarily. Coding is something developers choose typically because they love it. A lot of them also do some in their spare time.

It's been over 6 years (not counting the time where it used to be just a hobby) I've done coding pretty much every day and I still love it! :)

Feb 13, 5:00PM EST0

In layman’s terms or in ways a totally clueless person can understand, what does C++ coding mean?

Feb 12, 7:58PM EST0

Hi Pimark,

Imagine that you're sitting in front of a piece of sofware, say Microsoft Excel or Microsoft Word. You, as a human, do things on the computer, such as clicking with your mouse on buttons, and typings letters on your keyboard.

While doing this, you can see the piece of sofware reacting to your actions. How does the software know what to do when you click somewhere or type something?

To do this, programmers write instructions for the software. Something like "if the user clicks on the little button with a B on it, then write in bold the following letters that they will type".

The programmer needs a way to express those instructions in the software. The problem is that a computer only works with electricity flowing through its components, and you can't talk to it to give it instructions.

Here comes the code. The code is a way to express instructions to the computer, that is not plain English like the sentence I've written above, nor pure instructions about flowing electricity. It's something in between. It is written with basic words in a very structured way. And the computer has a mapping from those words to electricity.

Those words consistute a language. And, just like for communicating between humans there are many different languages, in software engineering there is also plenty of languages to express instructions to a computer. C++ is one of them.

Last edited @ Feb 13, 5:24AM EST.
Feb 13, 5:24AM EST0

What’s the most difficult or challenging part about your job?

Feb 12, 10:08AM EST0

Meetings? haha

More seriously, I think the most difficult part is when I need to make a fix on a piece of code that has been written long ago and that has badly evolved. In this case it is hard to be sure the additional fix I'm making is not in fact adding the general mess of this piece of code, and that it won't break anything.

Feb 13, 5:05PM EST0

Hi, i love C++ coding , but i dont know how it's working , on live projects

i am Asp.Net developer ( Intermediate) ,

so i would like to more about C++ coding and also would like to learn !!

Feb 11, 11:01PM EST0

Hi Nizam,

If you want to see what the language looks like, I hear that LearnCpp.com is a good reference.

Now if you want to know more about how C++ projects look like in real projects, I suggest you have informal conversations with C++ developers. And the place where you can meet them face to face is at meetups! If by any chance you're in Paris, we can chat about C++ in real projects and I'll be glad to answer your questions. Otherwise you can walk up to pretty much anyone at the food break in a meetup of your city and ask them any question about their daily life!

If you have a more specific question about C++ on real projects, you're welcome can ask it to me here, but for this general feeling you want to get, the most efficient is probably a face to face casual chat with C++ developers.

Feb 12, 1:17PM EST0

cuz of most of awesome softwares and games are all writtern in C++, just curious about it , yeah i am interested ,

i am not in paris , i live , Bangalore, India

Feb 12, 2:02PM EST0

I dont understand perfect forwarding. Any reference or help is appreciated. 

Feb 11, 2:31PM EST0

Hi Madhusudan,

I suggest you have a look at this article. It explains lvalues, rvalues and their references, and conludes with perfect forwarding in template code.

Hope that helps.

Last edited @ Feb 11, 3:32PM EST.
Feb 11, 3:32PM EST0

What is « expressive code »?

Feb 11, 12:39PM EST0

Hi Edith,

By expressive code, I mean code that tells something to its reader, code that is written and structured in such a way that it is fast and effortless to understand it.

Hope that makes sense.

Feb 11, 12:53PM EST1

In your large code base, how is the code logically separated to prevent small changes in especially header files causing a full recompile? Some ways I can think of to do this in C++ are forward declarations and pimpl classes. What other ways do you know of?

Feb 11, 10:48AM EST1

Yes forward declaration is the most direct, pimpl takes over in some cases but has its drawbacks.

Apart from that, I can think of template explicit instantiation, to avoid putting the body of template functions in headers (if you're not sure what I mean by template explicit instantiation, have a look at the section called "Explicit instantiation" in this article)

Other than that, a simple guideline is not to fit too many classes into a header file, to avoid recompiling the clients of another interface that shares the header but that you didn't modify.

Last edited @ Feb 11, 10:58AM EST.
Feb 11, 10:57AM EST1

At what age, you started writing the code? What is the ideal age to start according to you?

Feb 11, 9:59AM EST0

Hey Keith,

I must have written my first line of code when I was 13. But it's just because I hadn't been exposed to programming before, and I wish I had encountered programming earlier. I suppose that a kid of 10 or 12 must be able to understand?

That said, I was exposed to creativity before that, because my parents made me pick a musical instrument when I was 6 or something, and I'm very grateful to them for this. I think that giving kids a hobby when they're very young, like 5 ot 6 is a good thing for them, because it shows them that there is something else that school in life, stimulates their creativity, and gives them the desire to focus on stuff. This mindset fits well with programming I think, even it the code itself comes only a few years later.

Last edited @ Feb 11, 10:09AM EST.
Feb 11, 10:06AM EST1

How competitive is the coding field today? Is it difficult to get jobs? What are the best paid coding jobs?

Feb 11, 9:44AM EST0

I can only speak for the C++ market in Paris because that's where I am, and it is clearly in favor of applicants. There is much more demand than good profiles, so if you have good skills, there is no reason why you wouldn't find a job (and if you're interested by a C++ job in Paris, get in touch with me).

As for salaries, I have little info apart those in Murex where I work for, and the opinions on Glassdoor concur to say that they pay good salaries. That said, I'm sure that other places can give you a good pay as well, and for that you can look up specific companies on open websites such as Glassdoor to see where they stand.

Feb 11, 9:59AM EST2

How to go about learning C++ when you are coming from languages like Java/C# ? advise ? tips ?

Last edited @ Feb 11, 9:10AM EST.
Feb 11, 9:08AM EST1

Hi Vishy,

I'd say focus on the specific concepts of C++, in order to get into its mindset. This is how you will write idiomatic code and make the most out of the language.

Here are examples of such concepts that would be beneficial to get familiar with:

-RAII (check Fluent C++ on Tuesday where I will release an in-depth article about RAII). This is important to master because it illustrates well how C++ deals with memory.

- smart pointers, that go hand in hand with RAII, and save the trouble of managing dynamically allocated memory.

-The STL: this is the part of the standard library that deals with collections.

- When you're feeling comfortable with the language, have a look at templates. From what I hear of generics in Java, they have little in common.

- Exception safety. This also goes hand in hand with RAII but it's a little more advanced. So check this when you're already confortable with the language too.

Also, I suggest that you read the classical books of Scott Meyers, at the very least Effective C++. This book is not difficult but allows you to know what you're doing when coding in C++.

Feb 11, 9:24AM EST2

What is the best way to create/destroy a template class which may work well for different data structures? 

Feb 11, 8:40AM EST1

For performance it is more efficient to create data structures that are stored contiguously, for cache-friendliness (see the answer I gave to Mwangi on the question "how often do you find yourself using std::list in place of something like a vector container").

For an array (like std::vector) it goes without saying. But the thing is, this can also apply to more complex data structures.

Take maps or sets for example. They are typically represented as trees intenally. But you can get almost the same interface by representing them as a sorted vector. And this brings the performance advantage of contiguous data structures. For more about the performance of flatmaps, you can refer to Björn Fahller's article Performance of flat maps.

I hope this answers your question. If it doesn't, please let me know in another question.

Feb 11, 8:56AM EST1

How do you keep yourself motivated?

With big c++ codebase, the job is more often than not to fix issues. There's very few new development and it is often the backbone that makes everything else work, so you never really see the "end" of a project.

Feb 11, 8:24AM EST1

Hi Sebastien!

Here are a few things that keep me motivated:

- I try to learn continuously, even from bad code when I encounter it. For more about that, see the section 3) of answer to Babou's question "What are the important traits of a good code writer?" on this AMA.

- I don't mind fixing bugs, I see them as puzzles. Also, bugs give you the opportunity to explore an application and codeline, on a restricted scope.Also, in my team we have a target to fix a certain number of bugs by unit of time (N bugs by week, or N bugs every two weeks). And this makes it look like a reachable objective which is very motivating. A bit like gamification. Over time, this makes us fix a lot of bugs without it seeming too daunting.

- Not seeing the end of a development can be demotivating indeed. Chunking it up in small sub-development, tasks that could be as small as a day or half a day, also make it seem less daunting. And with this, you get the satisfaction of feeling you're making progress.

- I interact with people. I do blogging, dailies, I get involved in meetups. Interacting with people makes you realize that everyone has the same problems, and you're far from being in the worst situation. It gives you an opportunity to learn and help other developers, which is a different sort of motivation.

- I explore code techniques whenever I can. Even when making a fix for a bug, I try to decide what the ideal code would look like and then think it could be implemented. Even rewriting an if statement in an innovating way to make it clear is a good satisfaction (about this, I'm preparing an article specifically about declarative if statements to let you know more technically what I mean by that).

- I love coding. I've had the good (or bad?) luck of working in another domain than programming before, and now this makes me realize how beautiful a job where everything revolves around code is. When you like programming, that is :) I consider us developers lucky because there aren't so many people that choose a job by passion like we generally do.

- finally, here is my take about the attitude we should have about legacy code. It has helped me a lot.

Hope this helps!

Feb 11, 8:47AM EST1

Hello how often do you find yourself using std::list in place of something like a vector container and under which circumstances have you found list to be a better container. Thank you

Feb 11, 8:14AM EST0

Hello there,

I haven't found a use case where std::list was more appropriate than std::vector.

Initially, I thought that given that std::list had a complexity in O(1) for append and insert while vectors have a complexity of O(n) for both operations, std::list would be the default option for container.

But this is wrong, because there is another factor that determines performance: cache access. std::vector has a contiuous storage (the C++ standard guarantees that) so when traversing a vector, we don't reach out far into memory to get the next element, and that next element is likely to be in the cache line that was loaded when starting the traversal.

Whereas with a list, the next element may be anywhere in memory, and is likely to cause a cache miss.

So std::list are slower than std::vector. I learned that watching Chandler Carruth's talk Efficiency with Algorithms, Performance with Data Structures.

And since std::list and std::vector have nearly the same interface, I always use std::vector rather than std::list.

In fact, I always use std::vector for storing data when there is no addional constraint (if you need elements to be unique, or sorted for example, then you need something like std::set), except when storing booleans, because std::vector<bool> has issues (see Effective STL item 18) so I use std::deque<bool>.

Feb 11, 8:26AM EST1

What is your personally favourite project of all you worked on so far?

Feb 11, 7:14AM EST0

I've enjoyed nearly all the projects I've worked on so far, be there at work or in my personal time, but if I had to pick one, that would probably be the NamedType library.

This library implements strong typing in C++, and I believe that strong typing makes a difference when it comes to writing expressive code. It was a fun experience as it made me experiment with modern C++ and with a very concrete purpose in mind.

Other libraries I enojoyed working on include smart output iterators in C++, and expanding the algorithms on sets. This was fascinating.

Feb 11, 8:03AM EST1

What is your educational qualification in C++? Do you think education alone helps in coding or is it best to just go ahead and practice?

Feb 10, 6:04PM EST0

The educational qualification in C++ that I received at engineering school consists in 6 months of a 2-hour weekly course plus homework. It's really not much.

I got my experience on the job, but I tried not limit myself to the tasks I was given at work. I tried to spend a fair amount of my spare time reading C++ books, and trying to apply at work what I had learnt. When I got comfortable enough, I started to give trainings in C++ at work in the format of dailies, which allowed me to go further.

So I'd say yes, just go ahead and practice. But don't just practice, learn at the same time and use your job to apply and enrich this learning, and to make it resonate with your teammates.

Last edited @ Feb 10, 6:26PM EST.
Feb 10, 6:26PM EST1

What about CSS? You get a lot of templates and all sort of code generators that come up with really messed up CSS should that be expressive as well?

Feb 10, 4:45PM EST0

I don't have any practice of CSS so can't give a specific answer for this language. That said, to determine if the code should be expressive as well, the question comes down to: are the templates or generated code going to be read by a human? Even more, are they liable to be modified by a human? If the answer to any of those 2 questions is yes, then I think they should be made expressive.

Last edited @ Feb 10, 5:15PM EST.
Feb 10, 5:05PM EST1

What is the most valuable tip you would like to give the beginners? What mistakes you could have avoided if you could go back in time?

Feb 10, 1:50PM EST0

Hi Alfred,

There are several pieces of advice I would give to beginners or to my former self, but if I had to pick one, it would be about starting on the right foot about your attitude concerning existing code.

If you are to be a professinal programmer, you are going to collaborate with others, and work with existing code. And some of it is going to be bad code.

Starting from this point you have two approaches: the rational approach and the primal approach.

The primal one consists in despising the piece of code and the person who wrote it, thinking they're trying to get in your way to understand the code, that you'd have done such a better job, that maybe you ought to be working somewhere else.

The rational one is to recognize that the code is there, and you have to deal with it. Plus, maybe it was hard to write and its difficulties don't show at first glance, and rewriting it would be a challenge. Also, code written a long time ago did not benefit from the best practices that we discovered since then, so had we wrote it at the same time we may have not done better. Plus this code being run in production, it has helped make money to your company, and even perhaps grant you a job today.

The primal approach, as its name suggests is the one we're naturally enclined to take, as humans. But it's not the right one, because it leads us to moaning about the code without real purpose, the code doesn't get better, and it makes us live a crappy professional life.

The rational approach leads you to do the best you can with the code, be productive, and only make constructive complaints if any at all, in the purpose of improving the code.

The thing is, a beginner has to choose their side. Because once you're used to an approach it's hard to change habits and switch to the other one. So to a beginner, I say: adopt the right approach. Pick the rational one and stick to it.

Other than that, people starting out typically have a huge appetite for learning things. It's great and you need to make the most of it. For that, you need to settle for some goals to aim for in order not to learn stuff haphazardly and waste your energy. Some examples of goals: I want to be proficient in the [X] language. Or I want to be proficient with the Linux command line. Or I want to be good a class design. There can be a lot of goals. My point is don't lose yourself by learning a little of maching learning, and then taking up quantum computing, and dropping it for lambda calculus, then doing the first 2 sections of a course on C#, and so on. Focus your efforts in order to build up real skills that you can use and sell later.

Now about a mistake I could have avoided if I could go back in time: learn continuously! At some point in my career I moved apartments. It changed my routine, and during about a year I didn't have any book or course, or any time in the day where I would learn things. If I had put that year to use, I would be much further than I am now.

The thing is, there is a lot to learn in our field of programming. Probably more than is doable in a lifetime. So we should never stop. Learning something everyday is ideal, but if that is not realistic, try at least to learn something every week, or couple of times a week. This builds up over time to give you a deep knowlegde. Never stop to learn for a long period of time.

Finally, get involved. At least, attend the meetups of your domains in your area. This will give you opportunities to chat with more experienced developers in a friendly atmosphere, ask questions, get clarifications, and discover new areas you would not have come across on your own.

Last edited @ Feb 10, 5:09PM EST.
Feb 10, 4:57PM EST1

The "primal approach" is a trap far too easy to fall into. Usually if you can do some refactorings to leave the codebase in a better shape than you found it you not only fix most of the issues you had with it but you might cause a good impression.

Feb 11, 8:43AM EST0

Do you think everyone should know at least a bit of coding nowadays? Why?

Feb 10, 8:37AM EST0

I don't think so, because there are so many jobs that don't require any coding skill at all. When I think about the people I know that are not developers, virtually none of them needs coding skills in their job. Isn't it the same for the people around you that are not developers?

Conversely, I know people that are not interested in coding whatsoever, and would hate having to do this as homework.

But I know that kids learn coding at school now. So school systems seem to have a different opinion. I suppose they think jobs may change in the future perhaps?

Last edited @ Feb 10, 3:59PM EST.
Feb 10, 3:57PM EST1

Did you want to be a programmer as a kid?

Feb 10, 7:31AM EST0

As a kid I loved playing around with computers but I didn't know programming. As a teenager, my cousin showed me a text game he had programmed on his calculator. I was blown away. But I didn't get how the thing could work. I remember asking him dozens of times what this concept of "variable" was again because I just couldn't get it.

Finally I got it. Then my cousins taught me a little of Q-Basic, you know that old thing where the code in the editor was on a blue background? Then I moved on to Visual Basic where I was making games and small applications. And then to VBA for Excel. I loved programming, but I didn't think of making it my job. That was just a hobby.

Then I stopped being a teen and started begin a student, I got a serious job at EY working in corporate finance. I hated it and craved for something more technical. So I went for a programming job. This is how I decided to officially become a programmer, and also where I got my feet and then the rest of my body wet with C++ :)

Last edited @ Feb 11, 4:05AM EST.
Feb 10, 3:18PM EST1

Hi Jonathan ,

I'm interested in desktop software development and little bit web development and security , so which programming language will suite for me for a good start and with a good scope?

Feb 9, 9:05PM EST0

I hear that Python is  good language to start with, and is very polyvalent. But that's only what I hear and I don't have practice in this language so you should ask around for a confirmation!

Feb 10, 3:07PM EST1

Hey Jonathan, 

I really like your blog, you always try to keep the post (C++ concepts) simple and easy to understand. I want know whether is it possible for you to do some review of C++ open source projects and explain some of the concepts you alredy explained in the blog, like how expressive the code should be and how we can make it better?



Feb 9, 6:05PM EST0

Absolutely! I'd love to look at code and search how to make it more expressive. You can send me an email at jonathan@fluentcpp.com to share the piece of code that you're thinking at.

And thanks for the kinds word about the blog :)

Feb 10, 3:04PM EST1

Python or PHP? Why?

Feb 9, 11:38AM EST0

I don't have enough experience in either language to give an insightful opinion here. Sorry!

Feb 10, 3:02PM EST1

Is life and coding similar in some ways, what parallels can you draw? Are there things you learnt with programming that you apply to daily life?

Feb 9, 6:13AM EST1

Yes, if some principles are so transverse as to apply to coding in general, I think they can even go beyond than coding.Here are the coding principles that I try to also apply in daily life:

1) Clean code first, performance next. To make a piece of software run faster, we don't act upon intuition. Instead we start by writing the clearest code we can, and if the application happens to be slow we profile it, that is to say measure how much time is spent in every component (e.g. every function). This profiling gives an objective view of where time is spent in the application. We can then target a small part of the code that takes a lot of time. This the most efficient way I know of to make an application faster.I think that other things than software can be sped up this way. For example, I have reduced my morning preparation time with this method. I've profiled it by keeping a stopwatch near me and measuring how much time every step was taking (shower, getting dressed, and so on). Then I looked at the results and tried to do something about the one or two things that were taking up the most time. And now I get ready much faster in the morning!

2) YAGNI, or You Ain't Gonna Need It. This means that we should not code things that we don't need now, just in case we could need in the future. Like in an interface for example, we should always develop minimal interfaces, that allow to do exactly what we need at the time and no more. Indeed, it is hard to guess what a client will need in the future only based on what we develop now. Adding functionalities just in case is adding complexity for sure, that may well serve nothing in the end.In that same spirit, I try not to keep objects just in case. When I moved I threw away a lot of things, and I tried not to keep stuff just in case I may need it in the future. Because most of the time that stuff takes up space, creates disorder in our house and in our minds, and we never end up using it. There is this theory that 99% of the "just-in-case" items, we can in fact get them again in less 20 minutes and for less than 20 dollars if ever we do need them, and even that happens very rarely. I like this theory very much.

3) Modularity. To keep a system sane and under control, you need to decouple components from each other. Said differently you need modularity to manage complexity, and if components have too much access to each other, in particular in non read-only, your system becomes unmanageable. And there are components at every levels: function should be decoupled from each other, classes should be decoupled from each other, and modules too. I think that it translates to daily life very much. There are entities at various scales: a person, a household, an employee, a team. And there are things that should only be dealt internally. It's counter-productive to judge how much sleep a person should get, or how a household we don't live in deal with their finances. Similarly we shouldn't micro-manage employees, and teams are better off with some flexibility in organizing themselves.

4) Analyse twice, debug once. I know a doctor who complains that some of her patients come to her to ask for a prescription for a test: "doctor, my chest hurts, prescribe me a scanner please". Apparently this is the wrong way to treat a patient. A better way is to interrogate the patient ("do you smoke, do you exercise"), then make a hypothesis (no idea what that would be here since I'm not a doctor :) ), and then select one of the numerous tests that exists in order to confirm that hypothesis. And then give the patient the appropriate treatment.It really reminded me of the fastest method to fix a bug: look at the application, play around of the test case, formulate a hypothesis of what is wrong and ONLY THEN, open up the debugger to test that hypothesis. And when it is confirmed, make a fix. If you start by debugging the region of code of the buggy functionality, you can spend hours trudging through lines of code until finding anything wrong - or collapsing of boredom.

5) Conventions. When designing a component, it is important that you respect some conventions to make it easier for its user to discover it. Take the example of containers. In C++, the standard containers all share some methods names and some design characteristics, and your custom containers should abide by the same conventions (I'm preparing an article on the convention in C++ for containers for Fluent C++). This way, someone who knows the standard library (and all developers should know their standard libraries in my opinion) have a head start on how to use your custom containers. On this, the comparisons with everyday life are countless. Just look around you and see that all traffic lights, taxis, phones, TV remote controls, and so on abide by some conventions to make it easier for us to use them.

Thanks a lot for asking this question. It allowed me to put together these aspects of coding and my life and put them in a light I had never considered. Thanks a lot.

Last edited @ Feb 11, 6:08AM EST.
Feb 10, 3:01PM EST1

What are the best ways to market one’s coding skills?

Feb 9, 3:13AM EST1

The idea is to get your skills out there. Out there can be online, or in front of people.


From what I gather, one of the best ways to market your coding skills online is to hold a blog. I know it makes a difference for me when I interview people that have a blog - even before I had one! About that, I recomend John Sonmez's advice about building a blog. (By the way if you don't want to start a blog, but still want to write something about expressive code it in front of people, you can submit it to Fluent C++ as a guest writer.)

Other than that a YouTube channel can give you some online exposure, as well as giving an online course for example on Pluralsight.

Physical exposure

Attend and then talk at meetups and user groups. If you live in a big city there is probably a meetup on your language not far from you. And meetups are typically easy to talk at, because the organizers are trying to get people of the community involved.

In Paris, I regularly attend the C++ meetup and the Software Crafters meetups, which I recommend. Not only to meet people, but also to learn about programming.

Finally, attend and speak at conferences. This will also give you online exposure because most of them are available on Youtube a little after the event, but the bar is higher than at local meetups to get accepted as a speaker.

Last edited @ Feb 9, 8:01AM EST.
Feb 9, 7:58AM EST1

Isn’t there some software like Dreamweaver that can completely solve the expressive code issue by automating all that? If not - is there a market for such a thing?

Feb 8, 8:06PM EST1

Hello Andia,

So if understand well, that would consist in describing how a program behaves without interacting too much with the code, just like Dreamweaver lets you build a website without touching the HTML too much?

I'm not aware of such a software. But that could be the standard way to do things in the future, just like today we look back to the days everyone programmed in assembly and had classes of bugs that are extinct today!

Feb 9, 7:48AM EST1

When you say « where you understand the intent of the person that wrote it » does that mean the other programmers that pick the code can read it well or you mean the end user can understand the intent? Do you think end users really care about the code? Don’t they just want to see things work and don’t really look under the hood?

Feb 8, 4:55PM EST1

Hey Jessie,When I say "where you understand the intent of the person that wrote it", I do mean the other programmers that pick up the code and read it, and not end-users.And like you, I think that users just want to see things work. But I think that they care very much about the quality of the code. They just don't know they do.

Indeed, when we think about it, the main (sole?) purpose of coding an application is for it to be useful to users. Period. But the thing is, code quality and expressiveness is a way to reach that end.

For example, one thing that users hate is regressions. If the codebase is unclear, you're not sure exactly how to add an new feature and what its impacts would be and you have more chance of introducing a bug. In this case without an army of tests, regressions leak through.

But even with tests, if you don't master the codebase because some unexpressive code won't tell you its intent, you can't follow along the direction that was thought of when the code was written, and the new layers added participate to a growing mess. It becomes harder to add new features, and their delivery takes time. Which is not good for users either.

Another things that gets on the nerves of users is a slow application. If an application is slow, you profile it to check where the performance bottlenecks are. If the code is a mess, those bottlenecks could be diffuse in the codeline and those are the hardest to fix. If the code has a clear structure and good encapsulation, there is a higher chance that the bottleneck is located somewhere where you can make a local fix.

Finally, this is an indirect effect, but bad code can be frustrating, and over time it can lead developers to leave a company. This increase in turnover means training new developers, which takes a lot of time, and makes it that much harder to delivers features to users on time.

Feb 9, 7:42AM EST1

Why did you pick C++? What other programming languages are you a fan of? Are there some you actively avoid and why?

Feb 8, 2:48PM EST1

I started with C++ because that's the language we use at Murex. But what motivates me to get deeper in it is that it is such a rich language, with multiple paradigms and a flexible syntax.

I've learned some Haskell to get my feet wet with functional programming, which I enjoyed a lot. I've also tried Lisp to discover its world. And I have a little practice of Java too.

There isn't any language that I'm actively trying to avoid. If anything, I'm actively trying to avoid actively trying to avoid a language, if that makes sense :) What I mean to say is that I don't want to be religious about technology or languages.

All the mainstream languages have become mainstream for a reason. I think we should explore as many languages as reasonably possible, because all have some strengths. Combining those expriences gives a broader view on programming itself, which can then be applied in any language.

Last edited @ Feb 9, 7:22AM EST.
Feb 9, 7:19AM EST1

Thank you for your blogs and videos. I live in Paris too so can I meet you in real life :) ?

Feb 8, 10:59AM EST0

That would be nice!

Why don't you come to the next meetup of Software Crafters? I'll be there. It's a nice place for a casual chat about programming and all things, with food and beers offered :)

Last edited @ Feb 9, 7:13AM EST.
Feb 9, 7:12AM EST1

What is the IDE that you use in your videos ?

Feb 8, 10:58AM EST1

I use XCode for the videos on the Fluent C++ channel.

Feb 9, 7:11AM EST1

Where are you from ?

Feb 8, 10:56AM EST1

I'm from Paris, and spent a bit of time in the UK, hence my accent.

Feb 9, 7:10AM EST0

Say one programmer has worked out a way to structure their code and make it expressive, how can that translate to someone else grasping it? Are there some common rules and protocol across languages?

Feb 8, 6:14AM EST1

If I understand well your question, you are talking about a protocol to spread a new way to structure code to other programmers, so that everyone agrees on it and understand what it means. If I got your questions wrong, don't hesitate to let me know in another question.

I'm not aware of a standard protocol. However, there are ways to communicate your new techniques to other developers.

The first one is if your technique speaks for itself. For example if you extend an existing feature of your language by following the same conventions, your new component should make sense to people familiar with those conventions.

For example in C++, the standard function called "iota" takes a collection function and fills with incremented values (1, 2, 3, 4...), and in C++ the standard functions ending with "_n" take the beginning of a collection and a number N, and operate on the first N elements of the collection. If you create a function called "iota_n", everyone should understand that it fills the first elements of a collection with incremented values.

Now if you come up with a new structure, a new way of doing things, I think the best way is to lay it out in front of people and explain what purpose it serves. For this, the most adapted channel I think is writing a blog post, at least for a first exposure. It allows to get your ideas out there quickly, and also to receive some feedback from people that are interested in the same topic as you.

If you have worked out a technique to structure code to make it more expressive and would like more exposure for it, you're welcome to submit a guest post on Fluent C++ :)

Last edited @ Feb 11, 3:59AM EST.
Feb 11, 3:57AM EST1

Why set_new_handler is not often seen in the code?

Feb 7, 11:05PM EST1

For those who are not familiar with C++'s set_new_handler, it allows to specify a new_handler function, that the compiler calls when the systems runs out of memory to allocate new objects (with dynamic allocation).

I think it is rarely seen because:

1) there aren't so many options to continue a program when you run out of memory. One consists in deallocating a big chunk that the application had allocated at the beginning and can do without, but I can't imagine this situation happening often.

2) It is a very low-level function (in terms of levels of abstraction), and is not at the same level of abstraction as the application code that most people work on, so even if it is there, it should be encapsulated in a technical layer.

Last edited @ Feb 9, 7:08AM EST.
Feb 9, 7:06AM EST1

Would you recommend some logic in naming variables? Length, methodology of naming etc? And obviously longer and more descriptive names are probably better but over pages and pages does that not add too much to the overall time to type it all?

Feb 7, 7:08PM EST1

Ah you've touched upon a central subject, Edith!

Yes there is some logic in naming variables, and for naming everything else in code for that matter (function, classes, etc). And it is crucial to get naming right because this is perhaps the easiest way to convey your intentions in code.

First off, some names are illegal. The keywords of the language for example (like "if", etc.). But some languages have specific rules for naming. For C++ I summarized they have to do with underscores.

Next like you said, long names sound like a better idea than very short or abbreviated names, but with them, code can get too verbose.

Fortunately, there are ways to shorten long names while still keeping them expressive:- some abbreviations are OK: for example those that a user of the application understands, or those that all developers are supposed to understand, like BFS and DFS for example. Even if some developers don't know them yet (like me a few years ago), they are part of the common vocabulary of developers that your are allowed to use. And every one should level up to this common vocabulary in my opinion.

- if you see an 'And' in a name, it suggest thats it represents or does two things. Split it up and you have divided the length of the name by 2.

- get rid of the redundant information. Like in the function:void saveEmployee(Employee const&)you can shorten its name to void save(Employee const&)

- get rid of negations in names: isNotValid -> !isValid. This takes away 3 letters, and even better, saves some headaches when trying to turn around the meaning of a name in your head when reading code.

Going a little further than the topic of name length, the major guideline I recommend for finding the right name is to respect its level of abstraction.

Last edited @ Feb 9, 7:00AM EST.
Feb 8, 4:40PM EST1

What are the mistakes most programmers make when annotating their code?

Feb 7, 5:16PM EST0

By annotating I'm assuming that you're thinking of comments. If it's not what you had in mind, feel free to let me know in another question.

So, what are bad comments?

If I had to sum it up in two sentences, I would say: Imagine what you would need to tell to someone who is reading your code, if you were sitting next to them. This is what you put in comments. The rest is bad comments.

So for example, if a comment merely repeats what the code already says, it's just noise and it's a bad comment. Plus it risks of getting out of sync with the code and lead readers off to a wrong track, which is worse than no comment.

Now if a comment explains what the code does because the code is not clear, then in my opinion it's bad code but a good comment, because it would be useful info to tell someone sitting next to you and reading the code.

But when the code gets fixed the comment becomes redundant, hence a bad comment.

Now if you want my position about good comments, here it is.

Last edited @ Feb 8, 4:35PM EST.
Feb 8, 4:34PM EST1

Are you looking to start your own software codebase company in the future?

Feb 7, 2:39PM EST0

Hi Rabeca, I'm not sure what you mean by software codebase company? In any case, starting a company is not is my next plans but it's an exciting option for the future!

Last edited @ Feb 8, 4:17PM EST.
Feb 8, 1:46PM EST1

What does it take to maintain a code in a large company?

Feb 7, 12:38PM EST0

Be prepared to work with code that someone else wrote! This is true pretty much wherever you work, but large companies have large codebases, where multiple strates of times and people contributed.

But it's ok, as you can learn from that code, whether it is good or bad ( for more about learning from bad code see my answer section 3) to Babou's question "What are the important traits of a good code writer?")

Anyway, the characterstic you want for your code is to be expressive, that is that you can understand the intent of the person who wrote it. This is particularly true for the codebases in large companies, because so many people are going to read your code. Some of them will be young developers in a few years!

For more about writing expressive code, you may want to check out Fluent C++.

Also, since the code is vast, it's a good investment to implement the usage of tools that check or refactor the code automatically (like the clang tools in C++)

What is important too is learning to find your way around a codebase. For this I have 5 tips:

1) Start from 1 class or 1 function or even 1 line of code that you perfectly understand because it maps with a simple aspect of the application. From there, you can probably figure out the surrounding code. And you can work your way from there to master a region of the codebase.

2) Sit with someone who knows the code (maybe your manager) and make them show you call stacks that are representative of use cases of the application. This will show you the layers of the code.

3) Pick an input or output of the application, for instance something you see in the UI. Then look for how this is represented in the codebase.

4) Make a refactoring that decouples several components. Even small ones like functions or classes. This will make you identify componets (and improve the code at the same time). You may use guidance from your manager about what needs to be decoupled.

5) Find a padded-room function: a large or complex function but that has no dependency on other functions. It will help you get familiar with the coding style and patterns of the codebase, but you won't get lost as it only goes so far

Last edited @ Feb 8, 1:40PM EST.
Feb 8, 1:40PM EST1

What are the best and the worst codes you have written so far?

Feb 7, 12:37PM EST0

Why do some good code writers fail today? Is there any particular reason?

Feb 7, 12:11PM EST0

Hello Farayola,

I'm not 100% sure what type of failure you have in mind, however there is one case I've seen happening a lot where skilled developers didn't produce the optimal code: sometimes you don't see the simplest solution at first.

It happens that you start out coding the simplest solution that you can think of, invest time and effort in it, and at some point someone comes up with a simpler solution to solve the same problem.

In that case the more complex solution typically has some advantages over the simple one on advanced cases, but the simple one fits better for like 90% of use cases.

The complex solution may have been very well designed, but can be replaced by the simple one.

When this happens, the best thing to do is identify the trade-offs between the 2 solutions and keep the simpler one where the advanced cases are not needed.

If it was another type of failure that you had in mind, feel free to let me know in another question :)

Last edited @ Feb 8, 4:20PM EST.
Feb 8, 1:21PM EST1

What are the important traits of a good code writer?

Feb 7, 11:12AM EST2

Hi there Babou,

Here are several traits a good writer could use in my opinion:- building up knowledge- having the mindset of an explorer- being rational with the code

1) Building up knowledge

First about your language. Good code is understandable by other developers of the same language, and must therefore follow its idioms and conventions. To get that knowledge (at least in C++) you can read the classical books of how to use the language proficiently (Meyers and Sutter in C++).

Still about the language, as a good code writer you need to take the time to explore the standard library of your language. It will prevent your from reinventing the wheel, and will give you more sense of what is idiomatic in your language. You can go through the language documentation, or other resources that explain how to be proficient with the standard library (for C++, check out the STL Learning Resource)

Next, a good code writer needs to learn design and architecture principles. How to distribute responsibilites across classes, how modules interact together, etc. There are the related sections in Code Complete that are worth reading about it, and the GOF Design Patterns. If someone has other resources to point to on this topic, I'd be glad to hear them :)

Why is knowledge so important? Building up knowledge is building up a toolboox you can use to solve problems in code. The more tools you have, the more chance you have to have one that matches a problem, and the more nuanced and precise your intention can be when writing code.

2) An explorer mindset

A good writer needs to explore new horizons. Learning a new language or a new framework gives you another perspective about how to write code in general. And the more different from what you normally use, the better! Even if you don't use this new language in production, more often that not you can reuse some of its ideas while coding in your own language.

But even without going as far as another language, you can explore writing code in your main language. Next time you need to implement something, think about how the ideal code would look like. Have no boundaries in your imagination! Write even code that is syntaxically incorrect, but that looks good to you. And then, find a way to emulate this as close as possible with real code in your language. You'll be surprised at how often you can get pretty close. But for that, you need to know your language well, as said in 1).

Work on side projects. A pet project at home is a good place to try out wild things without the risk and constraints of the production code of your company. Then you come back to work with new insights, that you can apply in a more organized way in your production code.

3) Be rational about your code

Building knowledge and exploring new horizons gives you a theoretical background that is fundamental, but can sometimes constrast with the reality of the code you're working on.

A lot of people feel they are working on "bad code" (to stay polite) and are discouraged that they don't learn anything with it, and they only learn in their books or side projects.

But bad code is there, and, like Rome, you can't refactor it in one day. Instead, a good code writer embraces bad code. It sounds surprising, but what this means is that to write good code, you need to seize every opportunity to learn in that direction, and bad code is one of those opportunities.

How to learn from bad code? For example, next time you encounter a piece of code you don't like, make the effort to pinpoint what exactly the problem is in it. Sometimes it's harder that it looks. Once it took me 2 days to figure out exactly what I didn't like in an interface. But the reward is that you know what to pay attention to when you write your own code (in my case it was: don't make a function parameter that reflects an aspect of the function implementation and not its interface) More about learning from bad code here.

Other difficulties with going back to real code after your book or side project is writing code that looks understandable to other developers. See the answer I gave to Nickie's question "How will you make sure that you have written a good code?" on this page about that.

Thanks for asking this great question :)

Last edited @ Feb 8, 4:18PM EST.
Feb 8, 8:19AM EST1
How will you make sure that you have written a good code?
Feb 7, 10:49AM EST1

Hey Nickie, great question.

First it must seem like good code to you, the author. An indication of that is whether you'd be proud to check it in and excited to show it in code review.

But that is not enough: your code must also be clear to others. For this reason, you must be very open during code reviews. If someone don't find your code clear enough, don't explain it to them. Indeed, if this particular person understands it thanks to an extra oral explanation, the next person who reads the code will have a hard time too. Instead, listen to what makes it difficult for them to understand it, fix it and re-submit it to them until they find it understandable.

But even that may not be enough: one particular person may find your code clear and another won't. So if you want to have a more objective opinion, submit it to several people. I find that sharing it with people with different levels of experience gives a good sample.

One thing about submitting your code to a junior dev: if they don't understand your code because you've used a language feature or pattern they don't know, it's ok not to change the code and explain it to them instead. Because language features and patterns are the common vocabulary of code that everyone should know.

However you can't submit every piece of code you check in to the whole word. It is for every team to decide but 2 people of the team should be enough in my opinion.

Other than that, you can run a static analyzer on your code (such as clang in C++) to detect more faults. And naturally, a good piece of code must pass the tests :)

Feb 8, 7:28AM EST1
About #TechAMA

Your source for anything and everything in the world of technology.  From cellphone reviews to the Oculus Rift. You won’t want to miss one AMA Event here!

Interested in participating? Our user-friendly channel makes it possible for anyone to create an AMA on just about any imaginable topic that’s relevant to technology--and you. Just click the button on top right called CreateAMA.

The #TechAMA channel (http://www.TechAMA.com) is owned and operated by AMAfeed, LLC.