“Never doubt that a small group of thoughtful, committed citizens can change the world; indeed, it’s the only thing that ever has.” – Margaret Mead

I want to start this final blog post with some interesting statistics. According to ZDNet, at the end of 2018, there were about 6.3 million C/C++ developers.

Now consider this: ISOCPP, the committee which determines that standards for C++, reports an attendance at their triennial meetings of 100-140 people (about 0.0022% of the C/C++ community). FYI, this meeting is open to anyone who wants to attend.

You would think that software engineers, who rely heavily on an active, informed, egalitarian community to promote the advancement, security and stability of their work, would be climbing over each other to participate in something like this.

The C++ committee is a “small world” that affects a universe of developers. C++, like every programming language, has compromises, flaws, and problems. How many of us will fix these problems and advance our discipline?

With the enormous amount of trust we place in the code and modules we use, we must promote critical discussions about standards and practices to protect our industry and clients.

One thing I love about programmers is they are quintessential skeptics. If you ask a coding question on the internet, you’ll inevitably get 5 different (and probably valid) responses. You’ll also get statistics, documentation, citations, workarounds and philosophical arguments. But too much reliance on discourse like this is counterproductive, creating confusion, lack of standards, and in some cases creating bad habits.

We should try to focus our efforts on being productive communities and good citizens of the communities we occupy. Be curious – don’t be afraid to speak up – listen with intention. The kindness and hard work we share can only help us make the future of programming as bright as we imagined it when we were kids.

I’ve enjoyed writing this blog, and would like to end with a challenge to you (and to me): be a part of something bigger than yourself in 2022 – get out of your comfort zone.

Attend PyCon or find a programming meetup in your city.

Read the docs (the whole thing!) – and fix any mistakes you find.

Post challenging questions.

Learn the history of your primary programming language.

Start a coding study group!

Write a library to solve a problem you frequently encounter.

Be a patient teacher. Be a good citizen. Be kind.

“Never Doubt That A Small Group […]”. National Museum of American History Behring Center.
https://americanhistory.si.edu/collections/search/object/nmah_1285394 (accessed Feb 18, 2022)

L. Tung. “Programming languages: Python developers now outnumber Java Ones”.
https://www.zdnet.com/article/programming-languages-python-developers-now-outnumber-java-ones/ (accessed Feb 18, 2022).

“Meetings and Participation”. ISOCPP.
https://isocpp.org/std/meetings-and-participation (accessed Feb 18, 2022).

“Join us at PyCon”. pycon.org.
https://pycon.org/ (accessed Feb 18, 2022).

This week, I had a code review with not 1….not 2….but 9 developers, at the same time. My first code review in a professional environment! This was part of the C++ Study Group I talked about joining last week. While terrifying, the experience was also very enlightening. I can’t post the code, so I’ll do my best to generalize the kinds of feedback I got and my general thoughts.

1. More Comments! Before the meeting, I reviewed my code to make sure it was relatively self-explanatory. I thought my variables were well-named, my comments explained intent, and my functions were small enough to be easy to follow.
   
   I quickly realized that I largely underestimated how much explaining I’d have to do on the spot. What do these nested loops do? Why are you declaring this variable at this scope? Why are you using an iterator here?
   
   My best analogy for the experience is: it’s like making a chocolate cake. I had spent hours studying the recipe, working with the batter, making test cakes, and then I brought my best cake to show the other chefs. But when I arrived, I just showed them the finished cake and expected them to understand. What I really needed to bring was the recipe with all my notes. Next time: more comments!
   
2. Always Ask “Why”? As we looked through the code, the group wanted to know why I made certain choices, on what I considered very basic decisions like:
   
   > Initializing variables
   > Using cout instead of printf
   > Why I used “\n” instead of endl
   
   I didn’t have good answers for these questions (partially because I’m not a strong C++ programmer) when I should have.
   
   Just because something works doesn’t mean it’s the best choice. Next time: I’ll research the functions and methods I’m using to see if it’s the best choice for my code.
   
3. Full-Time Developers Know A LOT. (and they don’t always agree) Almost every step along the way, the developers introduced me to syntax and logic that I hadn’t even considered when writing the code. I realized how powerful it is to get that many diverse perspectives in the same place to compare notes.
   
   The most interesting part of this was that they didn’t all agree on what the right choices were at each step. Everyone had their own preference that suited their coding style. Some developers had matter-of-fact answers that “method A” was demonstrably faster than “method B”, but another developer would come back with a rebuttal about readability or reuseability of code, or whether a specific method that was too obscure to be understood by most developers.
   
   The one thing they all agreed on: your indenting must be consistent! While there are different indenting and bracket placement preferences, this should be the same across your code.
   
   Next time: I hope to have more coding experience so I can be part of the debate!
   
4. Fewer Variables = Better. One of the best general comments I got was:
   
   Finding ways to eliminate variables or declare them as constants is almost always a good choice.
   
   Looking through my code, I realized I sometimes declare variables as a note to myself or clarification why a certain value goes in a specific function. I realized if I write better comments, I can fix this behavior and write cleaner code that doesn’t require extra variables, saving me the time when I come back to the code of having to figure out what those variables are doing, and why they are there. Next time: fewer variables!

This is a post I expect to come back to in the next few months as I work more on my C++ proficiency. I hope some of these notes are useful to you too!

This week, I spent an hour talking to a C++ veteran – someone who has been coding since the 90’s and works as a full-time software engineer. I asked him what he thought it would take to develop from a college graduate to a very good engineer. I thought I would share some of his recommendations.

The first recommendation he had was to join a coding study group. This is a place where professionals can meet to share information, questions, and best practices without the pressure of the deadlines associated with our 9-5 work. I had a chance to join this engineer’s C++ study group and was really impressed by how many topics they explored in an hour – coding conventions, data structures, learning resources, pedagogical approaches (and of course lots of C++). Hearing these professional developers reflect on their relationship to the code they write was very illuminating.

The next recommendation was to comment the intention of your code. This engineer shared some of his code, and at first, I thought his comments were quite verbose. He raised the point that in a long-term code base, code is expected to be used for years, and that high-quality comments keep the code accessible. He also emphasized that comments should not explain what the code is doing (e.g. don’t explain that x++ “increments x”; instead, explain that this “moves the cursor right” or whatever it is x is doing.)

One of the recommendations we talked about a lot was reading well-written books on coding. Specifically, he shared “The Definitive C++ Book Guide and List” posted on Stack Overflow (more on Stack Overflow in a minute.) Looking at this list, it’s easy to see why he recommended it. Authors include Bjarne Stroustrup (the founder of C++), Herb Sutter (widely-cited C++ expert) and Andrei Alexandrescu (one of the developers of D). I started in on the list this week and am looking forwards to several months of learning from this list.

We talked for a while about coding conventions, copying code, and Stack Overflow. This engineer expressed that as soon as an answer to a coding question becomes highly ranked on SO, that code (or some version of it) will inevitably find its way into professional code bases. This engineer did not suggest that copying code is the right move, but rather that if you are contributing information about coding publicly, you have a responsibility to ensure your answer is well-informed. He implied not all information that is widely shared is following current best practices or is good engineering.

We talked more about D, Rust, the future of C++, the growing number of professional programmers, Matt Godbolt, the C++ committee, networking, internal culture clashes, and the pros and cons of siloed organizations. Overall, this was one of the most informative conversations I’ve had in the last 2 years and got me excited at the prospect of engaging with other engineers.