R.E.S.P.E.C.T.

Respect to our writers. We’ve had so many submissions for this issue, I have spent all my time reading through them instead of planning an editorial. Good work people! I also had to stay in the office late for two nights running in order to help with a release, which obviously used even more of my time. I bet several of you manage to release your code during office hours. Perhaps you should write in and tell us how. Anyway, this adds to my excuse for not writing an editorial. On the plus note, one of the business people said thank you on a slack channel when we were finally done. Never under estimate the power of saying thanks. Years ago, in another company, one of the senior devs always said thank you at the end of the day, which seemed a bit odd on the face of it. I’d turned up to work, and mostly done what I was told. Why a word of thanks after that? It turns out, it made me feel appreciated and keener to work harder. Or talk to him when I had ideas of how to make things better, quicker, leaner, meaner. You know. Saying thank you is a small act of kindness that can make a big difference. Respect Keith. If you’re reading this.

Who do you respect? Do you have a favourite writer or speaker? Or band or composer? I’ll bet there’s someone. What makes you respect them? Consistent quality performance? Ability to adapt and react to an audience or situation? Who would you choose to partner with you on a late night release? Why? We recently got a new team member. He’s a rubber duck, called Quackson. He’s the best listener ever. I don’t know how he manages to sit still and say nothing while others rant and rail at him. I find it very hard to do that. I tend to say, “Hang on, that can’t be right.” Or, “I don’t understand.” That sort of thing. I have much to learn from the duck. The colleague who brought in Quackson had never heard of rubber duck debugging [ RubberDuck ] before, but spontaneously started telling the duck what he was up to. It’s a bit like an imaginary friend you tell your woes to, explaining what you are up to and why, and what you need help with. Then,

At some point you will tell the duck what you are doing next and then realise that that is not, in fact, what you are actually doing. The duck will sit there serenely, happy in the knowledge that it has helped you on your way.

Sometimes you give people grudging respect. My editor of choice is Vim. At the expense of fuelling an editor war, a colleague some years ago used Emacs. Watching him find entries in logs and reformat text was a wonder to behold. I know how to exit Emacs, which is good enough for me; however, seeing a man who could drive his tool of choice so well commanded immediate respect. Good work, Moshe.

Respect usually revolves around interactions between people. Respect can take the form of being mindful of other’s needs. Don’t stand in front of the white board and talk to it, if you expect a room of people to hear you. If someone in the meeting is deaf or partially sighted, you need to be even more thoughtful about the layout of the physical space and the format taken. Bigger font sizes. Making sure the person speaking can be seen, if someone needs to lip read. If people are dialled-in to a meeting, make sure they get a chance to speak as well. Don’t speak over people. I’m sure you can draw up your own list. Alternatively, avoid the problem completely and never have a meeting.

Many organisations have a hierarchy, no matter how flat they claim it to be. This often carries an implicit assumption that more important people will automatically be obeyed no matter what. Respect the badge. Respect your elders and betters. This sometimes means blind obedience. In some situations, there isn’t time to argue and no harm will come from doing something now and dealing with any fallout later. In other situations, much harm can happen. A classic, often quoted, example is the so-called ‘Charge of the Light Brigade’. During the Crimean War, in 1854, Lord Cardigan led the light cavalry, armed with swords, against Russian forces, armed with guns. Due to a miscommunication, they were sent straight up against the artillery and most ended up dead or injured. [ Wikipedia-1 ].

Respecting those in authority, your elders, or even your parents is not the same as doing exactly what they ask. On another late night release, many years ago, a senior manager said he thought you shouldn’t call fabs directly as it could be slow. A team mate thereby halted proceedings and tried to make us go through the code and swap out the calls for a hand-crafted piece of code. I eye-balled the disassembler with another co-worker and could see it was one floating point instruction. Now, I believe the absolute floating point function may have been slower than hand crafted versions once upon a time, but things change. While respecting what the manager said, we showed him the compilation to a single instruction. He was horrified that we’d even considered holding up the release to hack around the code at midnight. Not the charge of the light brigade, but… Try talking to senior people once in a while, and checking what they say. You might get home earlier. Respect is not the same as mindless obedience.

Respect and obedience, though often conflated, are not the same thing. The root of ‘respect’ is ‘re’ for ‘back’, and ‘specere’ for ‘to look at’, giving a similar word ‘regard’, re+gard, or ‘back’ plus ‘guard’ or ‘watch’. You should have watched Moshe driving Emacs, though! Perhaps respect has something to do with looking and seeing. Not just glancing and vaguely guessing what’s going on, but actually looking and paying attention. James 1:23-24 says:

Anyone who listens to the word but does not do what it says is like someone who looks at his face in a mirror and, after looking at himself, goes away and immediately forgets what he looks like.

Do you remember what you look like? Perhaps. Look, carefully; watch, in detail; act, respecting the people and situation you observe.

Respect isn’t always about people. Given coding guidelines, you can either respect them, perhaps automatically enforcing them, or you can subvert or blatantly disobey from time to time. If you code in C++ and request a function to be inlined, does the compiler respect your wishes? Inline is a request, and therefore might not be respected.

No matter how you designate a function as inline, it is a request that the compiler is allowed to ignore: the compiler might inline-expand some, all, or none of the places where you call a function designated as inline. (Don’t get discouraged if that seems hopelessly vague. The flexibility of the above is actually a huge advantage: it lets the compiler treat large functions differently from small ones, plus it lets the compiler generate code that is easy to debug if you select the right compiler options.) [ CPP ]

I wonder what the ‘right’ compiler options are? Have an experiment and report back. It’s not just inline. Introduced in C++11, _Alignas is also a keyword in C11, where alignas is a preprocessor macro. [ CPPref ]. Aside from this potential clash, the request for alignment may not be respected. Over-alignment (asking for a bigger number) may not be respected [ Stackoverflow ]. Some may say alignas is always respected for a reasonable use, i.e. no more than max_align_t . If surprising things happen in your code, it might be down to your misunderstanding. Optimisations can uncover data races and similar undefined behaviour (UB). Nasal demons may result [ Maudel13 ].

One of the responsibilities is to learn and understand the contract between yourself and the compiler. If you break the contract, then anything can, and will, happen.

I’ve never witnessed demons flying from someone’s face, but have been confused by UB once in a while. You should respect the tools you are using, and take time to learn them. There will always be more to learn, but that’s what makes programming fun. If you get stuck, ask for help. The accu-general mailing list is a good place to turn to.

Enough of your compiler not respecting your requests, or you not respecting stated boundaries or requirements. Sometimes, respect is meant in a sense of perspective, or looking in a certain direction. This fits well with the sense of looking back. We talk of velocity changing with respect to time in physics, of the derivative of y with respect to x in calculus. It crops up so often, you tend to see WRT as short hand. It is important to clarify when ambiguity is present. If a function has several variables, talking of its derivative might be unclear. In computer science, the complexity of a function can be with respect to execution time or memory usage. This respect aims to give precision and clarity. These are fundamentally important for clear communication. I suspect most blazing rows in meetings happen when communication has broken down. Finding ways to reword ideas and suggestions can bring about revelatory changes in perspective and attitude.

I mentioned hierarchies earlier. Sometimes you may find yourself in a minion-type role. If you have to pass a code review before being allowed to commit code, this may feel like a subordinate position. However, code reviews can be an enabler. I recently had a great code review. We refactored my changes together and ended up with much clearer, and neater code. The reviewer encouraged me to fly in the face of some anti-patterns that were starting to emerge in the code base. We made everything feel better, just for a small corner of the code. We had fun. Not all code reviews work like this. Sometimes someone demands a specific code style or approach, and seems to be nit-picking for the sake of it. Nits should be picked, but a mixture of kindness and encouragement goes a long way. Pair programming can be contentious too. Todd Sedano gave a workshop at Agile 2019 , entitled ‘Considerate Pair Programming’ [ Sedano19 ]. An important point he raised was “ adjusting for any power imbalances ”. There will always be expertise imbalances, but real experts are usually good at working with other people, apart from the occasional diva moment. We all have our off-days. I encouraged the student on our team to review my code a while ago. He was surprised, since he saw himself as too inexperienced to comment on my code. I reassured him that he could at least tell me if he could follow the code. Power imbalance levelled. If you do code reviews or pair programming, are they conducted with respect? Find out what it means, to you at least.

Lean software development talks of empowering the team [ Wikipedia-2 ]. Wikipedia emphasises managers empowering rather than telling workers how to do their own job. We are told, “ Respecting people and acknowledging their work is one way to empower the team. ” The idea is an empowered team gets things done. The article also mentions trust; “ trust them to get the work done ”. In some senses, trust and respect are similar. You might claim respect is earned. If someone manages to do something amazing or useful, or consistently manages to simplify a difficult problem, or steer a meeting to clear action points, they will earn respect for their particular talent. If a new manager is parachuted in, they may well be treated with suspicion until they prove themselves. You could say until they earned your respect, or trust. This is orthogonal to being thoughtful, considerate and kind, which could also be described as respect. If things are going wrong, don’t forget Hanlon’s razor – “ Never attribute to malice that which is adequately explained by stupidity. ” But my corollary is, “ Don’t call people stupid. ” Some actions are daft, and everyone has their off-days. It’s OK to refuse to obey orders, and question things. But strive to be kind. Let’s help each other. And keep writing articles.

References

[CPP] https://isocpp.org/wiki/faq/inline-functions

[CPPref] https://en.cppreference.com/w/cpp/language/alignas

[Maudel13] Olve Maudel ‘Demons may fly out of your nose’, Overload 115, https://accu.org/index.php/journals/1857

[RubberDuck] https://rubberduckdebugging.com/

[Sedano19] https://agile2019.sched.com/event/OD03/considerate-pair-programming-an-interactive-workshop-todd-sedano

[Stackoverflow] https://stackoverflow.com/questions/35365624/alignas-keyword-not-respected

[Wikipedia-1] https://en.wikipedia.org/wiki/Charge_of_the_Light_Brigade

[Wikipedia-2] https://en.wikipedia.org/wiki/Lean_software_development#Empower_the_team