Breaking Bad (Habits)

As you may have noticed, I have fallen into a pattern of never writing an editorial for Overload and always making excuses. This time is no different. However, I have been contemplating my usual approaches to tasks, and more besides. Breaking bad habits is difficult, but the first step is usually spotting them. Pause for a moment, and ask yourself if you have any tendencies you to fall into on autopilot? Some of these might be useful, like brushing your teeth or going to bed at a specific time. Some may be relatively harmless, for example glancing at Stack Overflow or Reddit when a build or similar is taking a while. Both are possibly better than sitting doing nothing, though it might be more sensible to stand up and stretch for a bit, or having a sword fight [xkcd]. Sitting still for too long doesn’t do us any good. Bad posture is a horrible habit, as we all know, and even using a mouse for too long or typing badly can set off repetitive strain injury. Many people have opinions on potential fixes [reddit], but a standing desk, track ball, or some form of mixed martial arts might not solve all your problems. Changing how you do things might help though.

Waking up on time may or may not be a habit for you. I do wake up, but my preferred time is about half eight or so. Setting an alarm helps. I noticed recent news saying that people’s iPhones are failing to ring when the morning alarm is supposed to go off [Vigliarolo24]. Oops. I remember getting a swanky new alarm clock which plugged straight into the wall socket when I was young. I was paranoid about potential power cuts stopping it working, so always had a back-up hand wound clock. I now rely on my husband as back up, because he’s definitely a morning person, so is usually awake a couple of hours before me. It’s odd to think back and notice how my day-to-day habits have changed over time. This probably means I am getting old(er).

Do you have any good habits? Maybe focus on programming related areas, rather than everything. Do you practice? Read books or articles? Listen to podcasts? Do you always write tests first? Or, like me, do you claim to do TDD, but know full well you have a few ‘scripts’ dotted around that you never tested. Or shovel lots of code in main, which has no tests? Another bad habit I have fallen into is not bothering to use a library to parse arguments in a C++ project. I spent time learning to do this properly in Python, but never got around to picking and learning a C++ approach. I have tried several, so my excuse is too much choice, but not enough time. A very poor excuse, I know. I usually resort to a small hack to try to parse numbers or strings I pass in, but can never remember the order I set up. So, now I have confessed in public, I really must do something about this. Perhaps you can own up to something too, and use that as motivation to change. Acknowledging a problem is the first step to fixing it, after all.

I suspect my argument-parsing laziness is based on feeling it’s a small thing and I don’t have time to do it properly. I feel like my small hack will be quicker. However, we all know the quick workaround often turns out to be a time sink in the long run. Sometimes, I notice other problematic approaches, and after a few times limping along with a ‘bodge’ I created, I get annoyed enough to re-create something better. Annoyance can be a motivating factor, but there are other ways to help yourself change track. I attended Phil Nash’s session ‘Rewiring your brain – with Test Driven Thinking’ at MeetingCpp last year. [Nash23]. He’s given several variations of this talk; do take time to listen to one. He talked about the reward of seeing the green of passing tests being habit forming. If you know you will get a reward for something, you might be more likely to do it. Eventually, you no longer need the reward itself, hence his title ‘rewiring your brain’. His abstract [ACCU24] addresses the idea of spending time doing the right thing seeming wasteful:

We all say we should write tests, or at least we should write more of them.

But we never seem to have the time, and our focus is on the actual problems we’re trying to solve. Nobody wants to be bogged down by busy work.

What if all of that was wrong?

What if tests could save you time, improve your focus – and even be fun!

Maybe the thing to do is promise yourself you will start with just one test first next time you have code to write. Once you have one in place, it’s easier to add others. I have added a single test to a few projects in previous jobs, and it never takes long for others to add more. One small change is all you need to get started.

Now, you might notice something isn’t ideal, but not be sure what to do instead. I don’t know the solution to this, but often talking to others helps. Don’t suffer in silence. Or perhaps, you don’t realise you have a problem. An example might be accidentally relying on undefined behavior. If the code appears to behave on one machine, you may never notice. As soon as you switch or upgrade compilers, things blow up. It’s worth throwing an undefined behavior sanitizer at your code once in a while [Clang]. Sometimes code does work, but may be confusing for someone else to read. Code reviews can pick out potential areas for improvement like this. If you have been deep in something for a while, managing to get it working seems like success. However, as we know, code might need to be read at some point in the future, so ensuring it is readable is sensible. This often requires someone else to look with fresh eyes. If you don’t have anyone to hand, for example if this is a personal project, don’t be shy about asking the accu-general email group, or other community.

In general, if you don’t notice something is a bit broken, you are unlikely to fix it. Stepping back might help you notice the bigger picture though. That’s why I enjoy the conferences. Even if I go to a talk that I think I know a lot about, I always come away with new things to think about, or realise I have slightly misunderstood or forgotten something. Not everyone is fortunate enough to be able to attend a conference, but several now seem to be hybrid, allowing people who can’t afford to travel or even take all the time off the chance to join in. I’m pleased to see some conferences have offered free online tickets to anyone who has a poster submission accepted. Many students have to prepare a poster for a final year project. All we need now is to let Universities know about this opportunity. Let’s change the world, one step at a time.

Change can be unnerving. Once you find a way to do something, it can be very difficult to adopt a new approach. They say you can’t teach an old dog new tricks. However, if the dog is willing to change, then anything might be possible. If someone tries to force you to drop old habits, you might be more likely to defiantly stick to your current ways. However, as Phil’s talk points out, if there is a reward for changing, ranging from a treat, to a warm fuzzy feeling from a notification saying “Tests passed”, even all the way through to saved time or confusion, change can happen. I am experimenting with a small handful of personal mantras to help motivate myself and do the ‘right thing’. For example, I enjoy going to the gym, but keep allowing other jobs to crowd in and stop me. I tell myself, “Go to the gym first, you’ll feel better.” I’m right, but often argue with myself for a bit first. “But, this task needs doing today”… “So, do it later, after the gym.” I’m gradually ending up just needing to say “Go to the gym.” Whether I can talk myself round from all bad habits this way remains to be seen.

Programmers are often caricatured as arguing over silly things, such as brace placement, or tabs versus spaces. We do often end up disagreeing over seemingly simple things, but coming to an agreement with others who have different experiences to you can be hard. I tend to give my variables full names, but if I spend time reading maths code or books, I often fall back to single letter variable names. If I have just read up on a model, and the paper or book uses an x for a variable name, then you will often find x in my code. Don’t at me… I don’t think this is actually bad, or a habit. It just illustrates that current context often influences behaviour. I have to consciously swivel my head back to a fuller variable name, say horizontal_distance, if I am collaborating with others who don’t like the more terse approach. Trying to be consistent and respect conventions when appropriate is sensible. If you find a particular coding style really difficult, maybe you can find an automatic code formatter that will do this for you? Save the arguments for important issues, like potential production crashes or incorrectly implemented algorithms. And of course, automating compliance with rules, so you don’t have to do it yourself, is what might be expected of a proper programmer ☺

Now, automation and AI might not be the solution to every problem out there. And sometimes, you just can’t manage to change what you are doing at the moment. Yes, this might be personal issues like your posture or similar, as well as writing hacky arg parsing code. If you can’t manage to make that change now, don’t beat yourself up over it. I have taken the first step, by acknowledging my terrible code. Next time I need to read arguments to main, I will say “I don’t know how to do better, Yet. But I will one day.” And one day I will make the change. If you have a similar problem, be kind to yourself. Another approach might be finding someone to pair with, or even simply delegating the task. If you can’t do differently, let go. Maybe try an actual person rather than AI though? Just a suggestion.

It seems appropriate to end with the relatively well-known Serenity prayer:

God, grant me the serenity to accept the things I cannot change,
the courage to change the things I can,
and the wisdom to know the difference.

However, I was going to find a reference in case a reader hasn’t come across this before. I now have yet another tab open [Buontempo24], and notice Wikipedia says it needs help. The page for the Serenity prayer [Wikipedia] has a banner at the top saying in bold it needs “attention from an expert in history”. Apparently, the specific problem is “internally discrepant conclusions”, among other problems. I am not sure a history expert can fix that. Maybe a logician or programmer is required? Another section possibly contains “original research”. Shocking. I thought I got a PhD because I had undertaken original research. I suppose my thesis did have a literature review first, sharing references for the state of the art at the time, and when I tried to do something original, I did have references at least to the maths and machine learning techniques I was using. Perhaps I have just owned up to another bad habit – getting distracted by being very literal when I read something. If anyone out there does know the history of this prayer, please go fix the internet for me. I don’t have time, I need to learn an arg parsing library.

References

[ACCU24] Phil Nash ‘Rewiring your brain – with Test Driven Thinking’ (abstract) available at https://accuconference.org/session/rewiring-your-brain-with-test-driven-thinking

[Buontempo24] Frances Buontempo ‘Editorial: I Don’t Believe It’, in Overload 180, available at https://accu.org/journals/overload/32/180/buontempo/

[Clang] UndefinedBehaviorSanitizer: https://clang.llvm.org/docs/UndefinedBehaviorSanitizer.html

[Nash23] Phil Nash ‘Rewiring your brain with test driven thinking in C++’, presented at Meeting C++ 2023, available at:
https://www.youtube.com/watch?v=Hx-1Wtvhvgw

[reddit] ‘Fixing the Developer Posture’ (comments on the document, although the link to the original PDF no longer works):
https://www.reddit.com/r/programming/comments/6dcs7s/fixing_the_developer_posture_pdf/

[Vigliarolo24] Brandon Vigliarolo, ‘Miss your morning iPhone alarm? It’s not just you, and Apple is looking into it’, The Register, posted 1 May 2024, https://www.theregister.com/2024/05/01/miss_your_morning_iphone_alarm/

[Wikipedia] Serenity prayer: https://en.wikipedia.org/wiki/Serenity_Prayer

[xkcd] ‘Compiling’: https://xkcd.com/303/

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.