“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.

Looking back at my last few posts, I realize the theme I am most occupied with this quarter is communication.

Despite being almost constantly connected to text, email, chat, phone calls and Slack, sometimes I feel lonely. Like I’m on an island, sending messages in bottles to other islands.

The bottles take a few milliseconds to get to their recipients, and often contain enough hyperlinked and networked information to fill a book, but still some element is missing. And video chat isn’t the solution (see Stanford researchers identify four causes for ‘Zoom fatigue’ […]).

Last week, I talked about miscommunication and realignment. This week, I’d like to discuss non-verbal communication.

Most of us aren’t performers. We leave the singing, dancing, acting, standup comedy, and rock star stuff to the professionals.

It is perfectly acceptable, and largely culturally endorsed, to maintain a professional persona that’s a little more formal, a little more restrained, and a little more “high-register” than how we act outside of school and work.

When we shift into this mode, we change the ways we communicate. Small interactions and meetings can suddenly feel a lot more restrictive or tense depending on who we’re communicating with, and why.

Introducing new methods of communication to our normal channels can help us be understood better. However, this is not a post about “Pivot to video“. There’s a lot of communication that’s best in text. Imagine if you had to listen to your test engineer read every bug report. (You’d probably get bored and look for something more interesting to do.)

With all of the fatigue we have from remote meetings, you might hear the phrase “could this meeting have been an email?”. I am going to argue that meeting could be a video, or short audio clip.

Adding more of ourselves, our voices, our expressions, can be essential to understanding. If you went to the doctor, but you could only communicate through text message, you might not be able to adequately convey your concerns. But for a lot of us in engineering disciplines, this is exactly what we’re doing – having almost all of our communication through emails and chat.

Is this really an engineering topic? For me, absolutely. We are changing the way we work. We won’t be going back to big offices full of cubicles. So we have to adapt in ways that may initially feel uncomfortable or strange.

My capstone partner is separated from me by 11 hours and about 7,000 miles (11,265 km). We’re making good progress despite the distance, but I can do better to make myself understood. In addition to our chats and meetings, I’m going to try video recordings for our offline chats. Asynchronous, but more personal that replying to a thread. This will also allow me to incorporate video demonstrations and simultaneous commentary that expresses emotion and intent. The more I write about it, the more it seems crazy that I’m not doing this already!

This post is a challenge to myself – don’t just send the text, write the email, blog the blog. Try something different. Dance.

Ramachandran, Vignesh, “Stanford researchers identify four causes for ‘Zoom fatigue’ and their simple fixes”, Stanford News, Feb 23, 2021, https://news.stanford.edu/2021/02/23/four-causes-zoom-fatigue-solutions/

“Pivot to video”, Wikipedia, accessed Jan 2022, https://en.wikipedia.org/wiki/Pivot_to_video

We’re now a few weeks into our Website Security Research Project capstone project, and just completed our first Standup.

In this standup, my research partner used the phrase “the long pole in the tent” to describe their perspective on the most important portion of the project. (Aside: if you’d like to read a fascinating and anecdote-rich article on this phrase, the NYT has you covered).

The reasons this particular phrase stuck out to me is:

1. I had never heard this phrase before
2. We have different ideas about what the “long pole” is in this project
3. It is a great visual/engineering metaphor

During this project, my project partner and I are going to quickly learn a lot about each other. We’ll have to, if we want to stay on track with our deliverables, which are largely self-defined in this project.

To get there, we’ve got to address all three points above: We have to learn to communicate effectively, we have to learn to agree on critical infrastructure decisions, and we have to find ways to make our own voice and experience present in our work.

So what is the “long pole in the tent” in this project?

I tend to start projects by working on the least functional parts of the project first: interfaces, data definitions, API decisions, and routing. I like having the stuff that doesn’t “do” anything, done first. To me, I feel like I have to get this done before I can focus on individual coding problems.

I admire engineers who do the reverse – people who want to dive in to the individual problems in a project right away, discussing, deriving and demonstrating solutions.

I am going to argue that my partner, who is in the 2nd group, is more “right” about this being our bigger problem to tackle in this project. Without working proofs of concept, we won’t really have anything to stand on for the mid-project presentation of our work. We can always shuffle those demonstrations around in a different interface or implementation later in the project.

Writing this makes me realize I need to put aside my own work biases and dig in to what is best for the team. Can I shift my priorities, try new ways of working, and develop outside of my comfort zone? The answer to all these is: yes! One of the best parts of working as a team is learning how your perspective compares to others. To be an adaptable, modern software engineer I feel there is no other way of working.

Once we’re working this way, we’ll be on our way to building something with a great foundation that can go to spectacular heights.

Safire, William, “A hot metaphor emerges”, The New York Times, Jan 6, 2020, https://www.nytimes.com/2008/01/06/opinion/06iht-edsafire.1.9037962.html

This is one of my favorite sayings. It encapsulates the human condition – pleasure, desire, pain, survival – so efficiently. It’s a simple, great proverb for chefs and competitive athletes.

But is also a great proverb for anyone who is passionate about their work.

Let’s talk about what this means for coders.

When coders mention “bloated” code, we know immediately what they’re referring to. Code that attempts to do too many things, code that is verbose, code that has too many comments, code that is inefficient and not fun to work with.

When we talk about “clean” code, we’re talking about code we enjoy working with. We like code that is self-evident, descriptive and logical. Clean code is humane code, and since (almost) none of us make a living as 1-person coding phenoms, it’s extremely important.

In my mind, hungry code is the opposite of bloated code, with clean code falling in-between.

Hungry code wants to do more than just what it was originally written for. Hungry code anticipates being modified, re-used, referenced, branched, merged. To me, C++ templates are a good example of hungry code. Templates require you to think not just about the problem you’re trying to solve today, but the problems you’re going to solve tomorrow. You can write perfectly good, clean, non-extensible solutions to many problems, but the “hungry” version of the code will always win in the end. Code that is useful twice is code you don’t have to write again!

For our capstone project on web security, we must be hungry in order to succeed. Since my last post, node.js (which will be an integral component of our project) released patches for multiple medium-severity CVEs. The only way we will be able to be trustworthy researchers is if we are constantly reading, updating, searching, and asking the question – “what’s next?”

Hungry code requires a curious author. If “perfect is the enemy of good”, complacency is the enemy of hunger. Are you aware of both cutting-edge solutions and historical best practices for the problem you are trying to solve? Do you understand both the micro- and macro- processes at work in your system? We must constantly re-examine what we know, un-entrench our old practices and continually educate ourselves and those around us.

We won’t have the opportunity to be authorities on every topic, but we can ask “Why?” One example of this mindset I appreciate is the Python documentation for random.py. This documentation not only explains how it implements its functions, but why it chose specific solutions, and makes recommendations to the end user about when to use this library. I believe we owe it to our evolution to make this mindset the status quo.

So here’s a reminder to listen to your passion, to let yourself hungrily pursue truth, and embrace the journey it will lead you on.

“random — Generate pseudo-random numbers”, docs.python.org, accessed Jan 2022,
https://docs.python.org/3/library/random.html

English, Bryan, “January 10th 2022 Security Releases”, node.js.org, Jan 11, 2022,
https://nodejs.org/en/blog/vulnerability/jan-2022-security-releases/

𝄾 𝄽 . , // # <!– 🖐

What do all of these have in common?

They’re all ways for us to request silence. Momentary interruptions in the flow of information. They are essential tools in how we process sensory input. A pianist plays a phrase, and the rest allows the audience to process what they just heard. Silence helps our brain sort out the world around us.

Our OSU senior group projects have been assigned, and our team will be working on a Website Security Research Project. In this project, we get to make, break, and harden a web app against common security exploits. Fun!

During this project, in addition to doing a lot of coding, we’re going to do a lot of communication. We’ve got weekly standups to prepare for, articles to write, and progress to demonstrate.

In my last blog post, I implored you to explore an artful life, regardless of your role. In this post, I am asking you to embrace silence – visual, written, symbolic, auditory, interpersonal, gustatory silence. Think about sipping a warm cup of tea or a glass of wine. You could guzzle it down, but most of us prefer to add silence — time between sips — to extend and deepen our experience.

In this article, I am giving you a little extra silence.

In this article, I’m preparing where I can add silence to our project, to make it more effective.

Our web app will need a basic interface, a user database, CRUD functionality, multiple live versions, endpoints to access our hardening demonstrations, and good, modular code our team can quickly iterate on. We’ll need to set up a well-organized GitHub and write thoughtful articles. We’ll have the opportunity to plan our silences throughout:

• A minimal web app interface, to make it clear how to interact with the site (visual silence)
• Thoughtful, consistent comments in the code (functional silence)
• Time between standups, emails and text to allow the team to work on their own sections (interpersonal silence)
• A GitHub split into logical sections, that don’t contain too much information (symbolic silence)
• Well-paced presentations to demonstrate our progress (auditory silence)

Good communicators understand that silence is one of your most powerful tools. At the start of a project, we’re abuzz with ideas, conversations and plans. There’s so much to do and explore that the time for silence can get lost.

I am going to do my best to give silence its due in this project. I will not add feature “fluff” to our interface to take up space. I will slow down and write good comments. I will give my teammates the time they need to do their best work. I will plan and practice what I am saying, so I can be understood.

I will enjoy this warm cup of tea, and the silence it contains.

What is art? And why talk about it on an engineering blog? It is my job (as author of this post) to convince you that there are immediate and deep benefits to considering your role as a “*er” (coder, teacher, lawyer, etc.) from the perspective of an artist.

Consider that art, as a philosophical reduction, exists to communicate that which cannot be communicated in another way. It is the job of an artist to bring attention to, affect, and realize an understanding of something that is otherwise ineffable.

This is in contrast to craft, which is the application of skill to a measurable goal. “Craft” is frequently used in reference to the creation of a physical thing – a wood table, a scrapbook, a sword. In this case, I’m referring to any service or product, whether you’re a paralegal drafting a will, a chef poaching a pear, or a programmer writing a module for an application.

Visualize your dentist. Your dentist has many opportunities to demonstrate proficiency of their craft. They can use their tools to take x-rays, measure your gums, check for cavities, clean your teeth, and perform restorative work. If your dentist is skillful, they will be able to maximize the effectiveness of your visit. You want to have a skillful dentist.

A dentist who is artful communicates empathy for your experience as a patient. You want to feel safe, comfortable, and respected when you are at the dentist. This is an difficult task during an interaction many people associate with uncertainty, pain and financial distress. If you have a dentist you love to visit, they are probably communicating with you in an artful way, letting you know they care about you as a person, in a way that is real to you.

The absence of art is invisible. If I take my car to a mechanic and they fix it, but they ignore all my questions about their shop and only provide me the minimum amount of information needed to complete our transaction, the only thing I will get out of our interaction is a repaired car. It would make no difference to me if they fixed my car or a robot did it. But if they slow down and take the time to share their expertise and understanding of my problem, I might feel a real human connection which transcends the application of craft.

Similarly, the presence of craft is invisible. If I get my car back in perfect condition, I might have no idea how those repairs were completed. But, if they forget to tighten one of my lug nuts and it falls off on the highway, I will absolutely notice the absence of skill.

I encourage you, in whatever your professional role is, to make your interactions with others artful. For coders, make your comments artful. Remember there is a human (who is sometimes, but not always you) reading those comments. Strive to communicate effectively. Empathize with the student, intern, colleague reading those comments 2 years from now trying to understand you.

Working artfully takes practice, and requires you to flex muscles you don’t always need to use to get the job done. Artful interactions frequently involve slowing down from your normal rhythm and taking time to explain the story of why or how you are doing something. Does the person I am communicating with feel that I care about their health, happiness or success?

I hope you will find opportunities to transcend your role as a “*er”, to deliver to your clients and colleagues not only rigorous craftsmanship, but also humane artistry.

This blog post is written in preparation of my capstone project at OSU, to help me set the appropriate frame of mind for delivering both a product and experience I can be proud of.