A Humble Proposal

I have been busy writing conference and workshop proposals recently, so haven’t got around to writing an editorial. Each conference has a slightly different form to fill in, so even if I want to reuse a talk I need to format the idea with different word counts and different sections. I usually then spot different angles to emphasise and end up tweaking my slides too. It takes ages. As so often happens, a quick task ends up taking a very long time.

Reusing a talk and tweaking the angle is a relatively new experience for me, and even when people do reuse a talk, they need one to begin with. How do you find an initial idea? Most people who have never volunteered a talk think they don’t have anything to say. That is not true. Everyone has managed to solve a problem, or wonders how things work, or learnt something in the first place. Consider suggesting a talk if you’ve never done this before and are in a place to take part in a conference. If you can’t find the funds or spend the time travelling, there are hybrid and online only options. Of course, not everyone wants to spend hours listening to people speak about coding or to take part in a workshop. Some people have a life outside IT (if you don’t, you might need to broaden your horizons). Nonetheless, speak up at work. You might be able to give a short talk to your teammates one day. Or suggest a different approach to a problem. If you’re a team lead, find ways to encourage your team. Some people are too shy to speak up in meetings, so give them another way to share, for example let everyone write ideas on Post-its when you’re discussing things.

If you are serious about giving a talk somewhere, watch the recent recording from MeetingCpp about giving talks [MeetingCpp]. The content is much broader than C++, and applies equally well to almost any technical talk. Various people gave short pieces of advice, from pacing the talk to live demo Pro Tips, and dealing with nerves. Tina Ulbrich’s advice was called ‘But I have nothing to talk about!’ She pointed out we all have something to say really, and suggested listing what you do every day as a starting point. Your list proves you do know stuff. What sort of problems have you solved? Someone else might want to know. Alternatively, what do you want to learn more about? Giving a talk gives you a chance to learn and writing a talk will help you learn. Tina also pointed out that it is OK to talk about the basics. Talks don’t all need to be new, shiny things. Leave that to the rock stars. Finally, talk about your ideas, otherwise you might talk yourself out of it. Of course, they might talk you into it.

If speaking isn’t for you, writing is another option. Perhaps you could write an article for us. I wrote some guidance a while ago [Buontempo23]. I gave some ideas on how to decide what to write about. You could summarise a discussion, maybe from accu-general or somewhere on social media if you don’t have a new groundbreaking innovation. If you only have the vaguest of ideas, feel free to email me and tell me your humble proposal. Maybe you don’t want to write either, but may have ideas about articles you would like to see. Well, let us know. Again, accu-general might be the best place for this, or just tag ACCU somewhere on the socials. There are links on the bottom of the accu pages (https://accu.org/) if you want to connect.

I have told you about preparing proposals, creating conference talks and writing blogs. And yet, no editorial? Again? So, why did I decide to become Overload’s editor? A very good question. Russel Winder asked me that once, and I owned up. He was amused, but understood, so perhaps I’ll tell you as well. I had noticed I wasn’t managing to read all the articles in Overload because other things crowded in. Ric Parkin was editor previously; he asked if anyone was interested in taking over back in 2012. Glad I updated the Wikipedia page so I knew a quick way to look this up [Wikipedia-1]. Unfortunately, since the ACCU website reorg, some links on Wikipedia were no longer correct so I updated them, giving me even less time to write an editorial. Going back to my main point, I volunteered, and Ric paired up with me for a couple of issues while I started to get the hang of (almost) everything. I now do read all the articles. As often happens, stepping up and volunteering to do something opens up more than you might expect. On a few occasions I have had emails from people I consider to be C++ ‘Rock stars’ which makes me feel like a complete fraud, but also delighted they have written for us or shared blogs to reach a wider audience. Being editor has forced me to stay up to date with various aspects of C++ and learn much more besides. If you would like a chance, we are open to guest editors, both for Overload and the members’ magazine CVu. Get in touch. You could even write an actual editorial, putting the world right, for one edition only! Of course, you can do more than one if you want.

Any small idea can lead to unexpected consequences. I frequently find when writing an article or blog post, or preparing a talk, that I have some gaps in my knowledge or can’t fully explain something. To my mind, the latter is often a sign you don’t really understand a topic properly. Likewise, if you code alone, and never get input from anyone else, you might be missing out on better ways of doing things, or be relying on something which changes when you upgrade compilers or similar. You don’t need a person to review your code, but it can be valuable. Paying attention to warnings, or using a static analysis tool can reveal potential issues. These may not help with the code structure though. Some complexity measures can help, for example cyclomatic complexity et al [Wikipedia-2]. A pre-emptive approach might be avoiding if statements altogether. If you have never tried this, give it a go. I am on a mission to avoid using bools at the moment, and Spencer’s ‘Replacing bool Values’ article for Overload has many alternatives and reasons why this is a good idea [Collyer21]. It is interesting to watch how one small change can have a big impact.

Not all small changes end up eating all your time or changing the world. You may have noticed a recent C++ proposal for println by Alan Talbot [P3142]. It means we will be able to say println() rather than println(""). The motivation section asks, “Why bother, it’s only two more characters.” It’s a small proposal, but Alan points out why it matters. The number of people who have mentioned the proposal is surprising. The comments usually start with “Why bother?” It is, after all, a very small thing. However, trying to keep things tidy as you go, like putting dirty bowls in hot soapy water to soak while you cook, is always a good thing. If you don’t try to keep things clean and tidy, you end up creating more work for yourself in the long run. Furthermore, the proposal has a great recipe at the end, so read it. If you do have a niggle about something small, do something about it. Whether that means submitting a C++ proposal, reporting what appears to be a compiler bug, or something smaller like reporting a bug in an app you use, you have the chance to make the world a better place.

We rebooted the ACCU Study Groups, using my Learn C++ by Example book [Buontempo24] recently. We haven’t had a study group for a while, which was a shame. The idea is for ACCU members to read through a book together and help each other learn. Sometimes the author has joined in, including Scott Meyers and Bjarne Stroustrup. Previously, we only used emails to discuss a book, but it felt like a good way to get to know other people and ask ‘dumb’ questions less publicly. This time we have set up a short video call once a week. Only a small handful of us make these, but it’s a great way to put faces to names. We hope to run another one later this year, using a different book. I suggested the reboot because I noticed several new members asking why they weren’t happening. It has eaten up an amount of time, but I brought this on myself; however, it’s been great. Inevitably, people involved have found typos and mismatches between the code in the repo and a few listings in the book. Fortunately, nothing major. Books always have mistakes. Fact. It is awkward reporting problems, but thanks to everyone who spoke up. I can add these to the errata and fix incorrect listing numbers and typos in comments in the repo. This might help other readers. If you spot a mistake in a book or a blog or an Overload article, let the creator know. Obviously, find a kind way to point out the problem, rather than being brash. The chances are someone else was wondering too. Several comments on the println proposal were along the lines of “Yeah, that was annoying me too.” It’s almost never just you.

The MeetingCpp session on ‘Talking about C++’ also mentioned questions in talks. These can seem frightening in theory if you aren’t used to public speaking, but it shows the audience are listening. It can also be difficult to ask if you’re in the audience. ‘What if this is obvious to everyone else, and I end up looking foolish?’ and related thoughts are common. Well, like the println proposal, you will probably find you are not alone. There’s no such thing as a dumb question. As a speaker, it is worth asking the audience questions too, because it helps you gauge if people are following. Maybe no one will answer, but don’t panic if that happens. Patrick Winston’s ‘How To Speak’ talk [Winston18] gives some advice about this, and other tips for speaking. He says to pause for several seconds to give people a chance. If no one is willing to speak up, I sometimes go for a show of hands – people are less self-conscious about this.

Perhaps we don’t always step up because we get overwhelmed. Some people always barge in, either because they like the sound of their own voice and have missed the point, not realizing they don’t know much, or because most people are painfully aware they know little and prefer to keep quiet. Take a moment, and follow Tina’s advice to list what you do every day, maybe ignoring some of the distractions and rabbit holes you go down. You do know a lot. It might only be 20% of the language you use day to day, or how to fix a broken build, but you are an expert in a small section of your realm. We all know the Pareto principle: 80% of outcomes come from 20% of causes. (That’s about a fifth correct, but you get the idea.) You don’t have to know ALL the things, just some. If you don’t even have 20%, fear not. A European folk story tells of a group of travellers who arrive at a village with an empty cooking pot, which they fill with water and put over a fire. They put a single stone in the pot, and the villagers notice and ask what they are doing. “Making stone soup, but it could do with some extra flavour.” A villager adds carrots, and the next villager to come by asks a similar question. Eventually, you guessed it, the pot turns into a grand stew, so the stone is removed and everyone gets fed. Variants involve nails or an axe instead of a stone but they all make the same point [Wikipedia-3]. So, if you think you have nothing to offer, you are wrong. Speak up, question, or even volunteer to be guest editor. It’s about time Overload had an editorial.

References

[Buontempo23] Frances Buontempo ‘How to write an article’ in Overload 178, December 2023, https://accu.org/journals/overload/31/178/buontempo-2/

[Buontempo24] Frances Buontempo (2024) Learn C++ by Example, available at https://www.manning.com/books/learn-c-plus-plus-by-example or via O’Reilly’s subscription: https://www.oreilly.com/library/view/learn-c-by/9781633438330/

[Collyer21] Spencer Collyer ‘Replacing ‘bool’ values’ in Overload 163, June 2021, https://accu.org/journals/overload/29/163/collyer/

[MeetingCpp] ‘Speaking about C++’ (https://meetingcpp.com/) On YouTube: https://www.youtube.com/watch?v=O-hR-u_jFlM

[P3142] Alan Talbot: ‘Printing Blank Lines with println’, available at https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2024/p3142r0.pdf

[Wikipedia-1] Overload (magazine): https://en.wikipedia.org/wiki/Overload_(magazine)

[Wikipedia-2] Cyclomatic complexity: https://en.wikipedia.org/wiki/Cyclomatic_complexity

[Wikipedia-3] Stone Soup: https://en.wikipedia.org/wiki/Stone_Soup

[Winston18] Patrick Winston, ‘How to Speak’, transcript available at https://ocw.mit.edu/courses/res-tll-005-how-to-speak-january-iap-2018/bc92763ffa0dad0ecafe44967e834e16_Unzc731iCUY.pdf

Frances Buontempo has a BA in Maths + Philosophy, an MSc in Pure Maths and a PhD using AI and data mining. She's written a book about machine learning: Genetic Algorithms and Machine Learning for Programmers. She has been a programmer since the 90s, and learnt to program by reading the manual for her Dad’s BBC model B machine.