This means war!

Being the 150th edition of Overload , an editorial was called for. However, I have not managed to think for long enough to write one. Instead, we have waged war on our house, in an attempt at a long overdue spring clean. Why do I say ‘waged war’? It was the first phrase that sprang to mind, and it did feel like a battle. We can now find things in the cupboard under the stairs. Previously, I was afraid to open the door, for fear of being buried under a pile of goodness knows what. Injuries were sustained, well I broke a nail. However, it was worth the fight. We did well.

Could I describe the tidy up in less military terms? Certainly. We had a tidy up. That doesn’t sound as attention grabbing, click-baity, or exciting. Is this the only reason we use clichéd phrases for titles, talks or even code? Niels Dekker’s lightning talk at C++ On Sea , ‘noexcept considered harmful???’, ended up on reddit [ Dekker19a ], accused of being a ‘snowclone headline’. I personally loved the talk, and am curious to see the discussion continue. Does noexcept slow your code down? Niels has asked an interesting question, in a considered manner. I personally think this was exactly the right title for his talk. He’s shared resources on his github page if you want to investigate further [ Dekker19b ]. The meme title, ‘X considered harmful’ has a long history, and was originally click-bait. Dijkstra’s short letter to the Communication of the ACM in 1968 was given the title by the editor, presumably because that sounds more punchy than the suggested ‘A Case Against the Goto Statement’ [ Wikipedia-1 ]. I say ‘punchy’, which sounds a tad violent. Why do we use the terms we use? And why are so many of them violent or warlike in nature?

Much of the history of computing is based in military research. Wars and rumours of wars can produce magic money trees, or at least extra sources of funding, for research and development into new technology. Bletchley Park became a hub of industrious innovation during the Second World War. I suspect these roots lead us to use military phrases, often without realising. Why do we have variables or functions named foo and bar in our code? Kate Gregory’s ‘Oh the humanity!’ keynote at C++ On Sea [ Gregory19 ] reminded us the original spelling was ‘fubar’, meaning something like fouled up beyond all recognition. At what point this became ‘foo’ instead of ‘fu’ is not clear. ‘Snafu’ is another related term. Situation normal, all fouled up. In fact, it seems the American military created a series of cartoons, entitled Private Snafu , [ Wikipedia-2 ] to train service personnel about security, safety and protocol. There’s a suggestion that these terms were partly introduced to ridicule military acronyms [ Wikipedia-3 ]. You can certainly hide some horror behind TLAs (three letter acronyms), and encourage people to use them without thinking. “ Ours is not to reason why, ours is but to do and die, ” as the saying goes. Not literally true for most programmers. Literally true for the light brigade, whom Tennyson was writing about in his poem. Sometimes we use whole words rather than TLAs. Kill script, anyone? Deadline? To be fair, there is only sketchy evidence this originally referred to shooting prisoners who tried to cross boundaries, or even imaginary lines [ Online Etymology Dictionary ]. So much violence.

Despite software teams tending to use military terms, we are not in a war room. I watched a talk by Portia Tung a while ago, called ‘Enterprise Gardening’ [ Tung12 ]. She discussed the use of bullying, dehumanising terminology, with roots in warfare. Her main point was metaphor gives shapes to our thoughts, language and behaviour. “ It’s important we do gardening instead of pick fights. ” Allowing plants, or people to grow and thrive is a much better aim than fighting a battle. Plants need light, water and food. So do people. Kate’s keynote touched on similar points, for example, changing a variable name from errorMessage to helpMessage might give you a clearer perspective on what to write in it. What happens in your head if you say ‘user help’ instead of PEBKAC or ‘user error’? RTFM seems harsh. Though I do remind myself to do this sometimes, and make sure I’m reading the correct version of a manual. How many times have I tried something in Python while reading v2.x instead of 3.x, or ElasticSearch, though I’ve lost track of ES version numbers, since they move so fast. I have used the phrase RTFM on many occasions. In fact, one of my favourite books is called RTFM: Red Team Field Manual . [ Clark14 ]. There is a blue team field manual too. It has lots of clearly written scripts, for use in cyber-security CTF (Capture The Flag) training sessions [ CTF ]. The blue team defends the ‘flag’ – system, network or similar – while the red team tries to take over. Now there’s a thing. Cyber-security is absolutely full of military jargon. And computer gaming. Offensive? Humorous? To be considered harmful? I love the book because it has a glider on the cover and is small. Many books are far too big. This fits in my handbag easily. Five stars.

Military terms do have a place. I was surprised to find some people didn’t know the origins of ‘foobar’. I don’t remember how I discovered its background. I do have a tendency to speak up when I don’t understand something, so probably asked what on earth someone was on about when they first used the phrase at me. If you don’t know something, speak up. Or look it up. Finding the origins of meaning of words, AKA etymology, is informative. And helps me concentrate on how to spell words from time to time. I wonder what the etymology of etymology is? Will I break the universe if I look that up? Nope. All still there. The internet mentioned something about PIE. I digress. Anyway, many programmers’ language involves war stories, fire-fighting and Foo, Bar as well as Baz.

This warfare and fire-fighting talk isn’t always negative though. I recently saw a conversation on twitter between parents with fire-fighters in their family. They were discussing protocols for handing over a small baby. It went something like, “ I’m handing you the baby ” to which the response “ I have the baby ” was required before the first person would let go. This ensures a vulnerable person, or small baby, is held securely. Protocols, pre-flight/commit/release checklists have a place. They make sure you are communicating clearly, and paying attention in high pressure situations. Using a protocol or procedure to keep things running smoothly is a good thing.

Broadening out the discussion, the problem with waging war in a software context is the potential collateral damage. People can get hurt. Maybe no-one dies, but feelings get hurt. Shouting and swearing happens. Blame gets attributed, while problems don’t get fixed. Svn blame or praise; that is the question. People have been talking about and measuring user experience, Ux, for a long time and its value is well recognised. I’ve recently noticed developer experience, Dx, being talked about too. What is your experience as a developer like? What does this involve? Team structure? Ways of working? Your office? Your desk and keyboard? Perhaps that’s more DI; developer interface. Your toolchain? How confident you are when you commit code? How code reviews are conducted? Is the rebuild button right next to the build button in your IDE? If you use Visual Studio and have ever hit the wrong button wasting hours, consider adding to the Developer Community ‘Option to confirm rebuild or clean all’ [ VS Dev Community ]. You are not alone.

I can’t find a precise definition for Dx, though many blog posts talk more about the toolchain than the overall developer experience. For me, Dx includes the team you work with. Kind, supportive team members count as much as, if not more than, stable build tools, quick-running tests and a comfortable chair. That said, you can still make your life easier if you observe what is slowing you down, or making you annoyed. If you change one line of code and two projects build, ask why. Find out and fix it. If you come to a project with an old FORTRAN code base and a word document showing how to build it, create a make file instead. Typing ‘make’ is much simpler than having to re-read a large document and copy/paste commands, which end up with non-Unicode characters in. If the Wiki instructions are out of date, update them.

A podcast about Dx [ Boak ] talks about developers being people too. Ux came about to make sure people have a good experience using software. Well, probably to ensure buy-in and customer loyalty, if you are a cynic. If you download something on your phone and can’t get it working in 30 seconds, you will probably give up and find a different one. How many dev tools have you got working in a matter of seconds? How long does the on-boarding process take for a new team member? How do you know when they are on-board? This podcast hinted at many developers not liking quick start wizard tools, preferring to figure out complicated stuff by themselves, thereby gaining some pride. I’m not sure how generally true that is. Some people do tend towards building up their secret knowledge, becoming the team wizard or warlock for specific problems. Some people are better at sharing the knowledge and leaving simple-to-use tools for others.

If you are a developer on a live product, is it too easy to break things? Do you have root permissions? How easy is it to follow the logging from your system? Do errors leave you confused? Are most of your errors ‘normal’? Are warnings actually critical? What about compiler errors? To quote a recent Valentine’s tweet:

Roses are red

Violets are blue

initializing argument 1 of std::_Rb_tree_iterator<_Val, _Ref, _Ptr>::_Rb_tree_iterator(std::_Rb_tree_node<_Val>*)[with _Val= std::pair<const int, double>, _Ref= std::pair<const int, double>&, _Ptr = std::pair<const int, double>*]

On line 22

Does a failing test give you a clear message? If you see “ Expected True, actual false ” that might not be much help. Instead of adding a breakpoint to find out the values, consider including the values in the assert, so you can see immediately what happened. Wage war against the things that cause you grief, not people. Instead of fixing the blame, fix the problems. What can you do you make your own Dx better?

Many developers I know put up with the process being harder than it has to be. Perhaps there is an element of feeling like a tenth Dan wizard master if you figure out how to do something complicated, which might leave you tempted to keep things as they are. Other times, I suspect fear stops people changing things. I’ve frequently heard people saying, “ It only takes a couple of minutes. ” That sounds reasonable, but if you can automate that down to a few seconds, it’s worth considering. All the seconds add up. Chris Oldwood wrote about keeping things clean and tidy in a recent edition of the magazine [ Oldwood18 ]. He mentioned lashing out, and generally unpleasant behaviour. He even mentioned the Second World War. Perhaps Chris’ piece encouraged me to tidy up our house a bit, and start musing on warfare, though trying to blame him for my continued failure to write an editorial might be taking it too far. If you want to see a proper editorial in Overload , remember anyone is welcome to try their hand as a guest editor. Get in touch. Remember, Overload is available online so is read by many non-ACCU members, which is fine. If you’d rather do something a little less public, you can also volunteer to be guest editor for CVu instead. Get in touch.

So, war – what is it good for? Absolutely nothing, apart from technical innovations, and thinking about clear ways of communicating. Pick your battles. Be kind. Be aware of the language you are using, and its history and real meaning. If you can’t follow all of the strange in-house acronyms when you start a new gig, or panic while learning something new as soon as ‘foo’ or ‘widget’ gets mentioned, take a breath. You are not alone. Let’s see what we can do to ensure we all have a great developer experience.

We have met the enemy and he is us ~ Pogo Possum [ Wikipedia-4 ]

References

[Boak] Steve Boak, David Dollar and Justin Baker ‘Don’t Make Me Code: Ep. #5, Developers Are People Too’, available at: https://soundcloud.com/heavybit/dont-make-me-code-ep-5-developers-are-people-too

[Clark14] Ben Clark (2014) RTFM: Red Team Field Manual CreateSpace Independent Publishing Platform; 1.0 edition (11 Feb. 2014)

[CTF] https://ctf.hacker101.com/ (for example)

[Dekker19a] Niels Dekker (2019) ‘noexcept considered harmful???’, presented at Cpp On Sea 2019, available at: https://www.reddit.com/r/cpp/comments/apg0yk/noexcept_considered_harmfull_benchmark_and

[Dekker19b] Niels Dekker (2019), resources on github: https://github.com/N-Dekker/noexcept_benchmark

[Gregory19] Kate Gregory (2019) ‘Oh the humanity!’, presented at Cpp On Sea 2019 , available at: https://cpponsea.uk/sessions/keynote-oh-the-humanity.html, and search on YouTube for CppOnSea

[Oldwood18] Chris Oldwood (2018) ‘Afterwood’, Overload 148, Dec 2018, available at: https://accu.org/index.php/journals/2584

[Online Etymology Dictionary] https://www.etymonline.com/word/deadline

[Tung12] Portia Tung (2012) ‘Enterprise Gardening’, available at: https://www.slideshare.net/portiatung/enterprise-gardening

[VS Dev Community] https://developercommunity.visualstudio.com/content/idea/432348/option-to-confirm-rebuild-or-clean-all.html

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

[Wikipedia-2] https://en.wikipedia.org/wiki/Private_Snafu

[Wikipedia-3] https://en.wikipedia.org/wiki/SNAFU

[Wikipedia-4] Pogo (comic strip): https://en.wikipedia.org/wiki/Pogo_(comic_strip)#%22We_have_met_the_enemy_and_he_is_us.%22