Hello, my name is Jonathan Boccara. I'm your host on Fluent C++. I have been a C++ developer for 6 years, working for Murex which is a major software editor in the finance industry. My focus is on C++ and particularly how to write expressive code. I'm happy to take your feedback, don't hesitate to drop a comment on a post, follow me or get in touch directly !
Jonathan Boccara's blog
Such are the words that resonated across the planet during the last 24 hours (and you’ll keep hearing them all January!)
So let me join my voice in and wish you the best for this new year, that it be full of exciting projects and satisfying achievements. And that you get better at what matters to you.
Actually, let’s talk more about this.
Even though we counted down the latest seconds to midnight, coming into the new year is not an achievement in itself. Rather, it’s a wonderful horizon to achieve new things.
And to do that, we need to decide what exactly we want to achieve and how exactly we want to improve. We need to take resolutions. Otherwise, we’ll be counting down to next year and without having accomplished meaningful things until then.
Since Fluent C++ is about writing better code, here are 7 Good Resolutions to Write Better Code This Year. They are of two kinds:
I’ve also made a video about those 7 resolutions, filmed from the cosy living room of my mate Greg where we spent the new year’s eve this year:
Let’s start by 3 resolutions about how to get into a more productive attitude:
When we encounter a piece of code that doesn’t look expressive to us, our primary reaction may be to go: “oh that’s such terrible code”, “I don’t understand s***”, and so on. Such are the words that also resonate across the planet all year long in many software projects.
But complaining just for the sake of it is detrimental for morale and for productivity.
If we truly aim at writing expressive code, it means that our purpose is to produce code that others can understand easily.
The best way to test this is to measure how long it takes someone else to figure out the code we’ve produced. So during code review, if someone tells you that they have a hard time understanding what you wrote, I suggest to start from the predicate that they are right and that it is hard to understand.
Sometimes, that’s just life and there is only so much you can improve about a certain commit. Maybe because it is located is a difficult area of the code and that you can’t refactor everything at the same time, for instance.
But often, it seems that the new code only needs an incremental change to make it much clearer to them. Like making some naming clearer, or packing some code off to a function for example.
So during code reviews, let’s keep an even more open mind and listen closely to how others perceive the clarity of our code.
Getting interested into the problems of others can be very rewarding.
Of course, you have your work, you don’t have a lot of time and you won’t take up the charge of others.
But being available when someone asks you for a second look on their code, or to listen to a technical problem they’re facing, doesn’t take so much time and can be beneficial.
How? Well, for the other person, they can get the help they need. And if you’re the person that helps, you’ll get exposed to a new situation, that you may not have encountered yet. This brings you experience, and experience is a very valuable commodity out there.
So this year, a good resolutions can be to make a special effort to offer support to your colleagues when they face technical problems, and be available to give a second look to their code when they need it.
Let’s continue with the goals that you can set for this new year:
It’s been a recurring motto on Fluent C++: if you want to become proficient in C++, you need to know your STL algorithms. I learned that in Sean Parent’s famous talk C++ seasoning. The more you know them, the more elegantly you can manipulate collections in code.
STL algorithms are part of the C++ standard library. You need to know what’s in there, and the use cases and pitfalls related to the various algorithms that sit in it.
For this goal, you will find an STL Learning Resource on Fluent C++. It contains articles on the various groups of algorithms that explain how to use them, and also how the STL is designed and how to use it effectively as a whole.
It is in progress and this year I’ll continue writing posts and shooting videos for it. And I will make a presentation called “100 STL Algorithms In Less Than An Hour” at the ACCU conference in April, to present an overview of all the algorithms in the STL, in a way that I hope will make them easy to retain.
This resolution goes beyond just programming in C++.
There are quite a few ways to structure data in code. You can store it in trees, in graphs, in queues, in stacks, in priority queues, in heaps, in maps, in hashmaps, in sets, in multisets, in tries, in ropes, in matrices, and so on and so forth.
Each of those data structure has its advantages and drawbacks, and knowing as many as possible lets you choose the right trade-off for each of your situations, in terms of usability and performance.
One good resource that I have tried is the Berkley CS 61B: Data Structures and Advanced Programming course (it’s no longer on YouTube but seems to be online at some places like here). It’s a bit old but it shows a fair amount of data structures, and I found it very clearly explained.
Dumping on a sheet of paper (or on computer) what you know on a given topic, in a structured way, is a very effective way to gain a deeper understanding of it. Even if you start with little knowledge on this topic.
I am 100% sure that you know enough, or are able to research enough, to write about 3 topics related to writing good code. My best advice is to do it. And one year is a large amount of time to achieve this.
You can either write your 3 articles and keep them somewhere on your computer, for later reference when you want to go back to this topic.
Or you can share them with other developers.
You can share them with your colleagues if it is useful to them, and to get their feedback. You can also consider submitting them to Fluent C++. Indeed, the blog is open to guest posting, and by writing on Fluent C++ you’ll get exposure and a chance to interact with the hundreds of readers of the blog. Give it a shot!
Attending software development events is a great way to learn about the hottest topics in the software development community, and to meet lots of people from your industry. And have a good time.
There are plenty of events all over the world, ranging from local meetups to conferences gathering thousands of people. Of the major conferences of C++ are CppCon, Meeting C++, ACCU conference, C++Now, PacifiC++, C++ Russia, ++it, and I’m probably forgetting others.
In most cases, attending a conference will require financing for travel and accommodation. But you can consider negotiating with your company since you’ll be representing them there. And if you’re selected as a speaker, a lot of the financing is typically assured by the conference itself.
Have other resolutions to write better code this year? Let me know!!
You know how new year resolutions of going to the gym or eating healthy get smashed to pieces by February?
Don’t pick too many resolutions or something too big to be realistic. If you feel that the above resolutions will bring something to you, I suggest that you pick one from the “attitude” group, and one from the “goals” group. And that you stick to them this year.
Then next year, before counting down the last seconds to midnight, I wish you to have the satisfaction of having become a better software developer, having produced better code.
A wonderful new year to you and your family.
JonathanShare this post!     Don't want to miss out ? Follow: