Production and Productivity

I recently returned from this year’s ACCU conference, which was lots of fun and gave me loads to think about. Unfortunately, this has stopped me from even considering what to write for an editorial. It’s difficult to produce something to order, by a deadline, at the best of times. I would claim to have resisted the temptation to ask ChatGPT [OpenAI-1] to write an editorial for me, but am currently arguing with it about economics. I asked about production and productivity after all, so shouldn’t be surprised the chat was not about coding. After much discussion on employment, economic growth and automation to replace humans, ChatGPT told me

As technology advances, the role of software developers will evolve, but it is unlikely that machines will completely replace human coders.

Now, I mustn’t waste all day arguing with an AI chat bot. Distractions can eat into our time, and there’s never enough time.

How do you avoid distractions, and stay focused? I am told there are many productivity influencers ‘out there’. Chris Bailey has a few talks based around his books on hyper-focus and the productivity project. He has had several million views on YouTube. I hope they weren’t all by the same person, because if they were, they were clearly very distracted at the time. Apologies for flippancy. Sometimes you need to stop the distractions, but listening to YouTube on a connected device often means I spin up other things, so I only listened to a few minutes before getting distracted by something else. Being at a talk at a conference is a different experience, perhaps because I don’t have my usual distraction around me. I absolutely can focus, but it’s nice to allow your mind to wander as people talk. Sometimes you need space to let your mind drift. Slowing down and noticing your surroundings is grounding. You give space for ideas, and time to recall things you may have forgotten to do. We all need to rest sometimes. To an observer, this may not look very productive, but downtime matters and can make you more productive in the long run.

Some productivity hacks from so-called influencers can be interesting, but what works for one person may not work for another. I’ve recently heard mention of the ‘5am club’. Robin Sharma introduced the idea twenty or more years ago, and wrote a book with the subtitle ‘Own your morning, elevate your life’ in 2018. [Sharma18]. Many people seem to be trying a version of the suggested approach of getting up, far too early to my mind, and scheduling blocks of 20 minutes to do various tasks. I suspect that different approaches work for different people. There are lots of other ‘productivity’ blogs and posts out there. May Pang [Pang23] wrote a Medium article, explaining why she decided to defy the 5am club. She claims, “I watched with glee as my productivity continued to skyrocket with each conventional productivity rule I challenged that didn’t feel right for me.” Most productivity articles make big claims. She does sensibly point out circadian rhythms differ. Some people are productive early in the morning and some are not. Take anything that claims it will change your life, or solve your problems for you, with a pinch of salt.

Another fad attracting attention is ChatGPT. I lost a considerable amount of time arguing with it this morning. OpenAI’s blog [OpenAI-2] tells me ChatGPT admits its mistakes. Try asking it to write C++ coroutine code for you. It did say “You are correct, sorry for my mistake” or “You’re correct. I apologize for the oversight.” on many occasions. It can generate code, which may not compile. It can even generate tests for its own code. Would you trust something that marked its own homework? OK, to be fair, developers often write tests for their own code, so perhaps that’s the wrong question. I can imagine letting AI generate some boilerplate code for a simple task might be acceptable. You can even wire ChatGPT into your IDE, via Copilot [Dias23]. You add a comment, and a little frog icon has a ‘think’ then offers suggested code. If you leave the comment behind, others will know how the code was generated. I presume later versions, trained on different data, may come out with alternative suggestions, so maybe the comment will become obsolete at some point, as most comments do. Whether this counts as AI writing code for us, I’m not sure. It’s doing some kind of statistical based guess. I wrote about AI code generation a while ago [Buontempo21]. I used genetic programming (GP), rather than a neural network. GP is like genetic algorithms, but uses tree structures, and so can generate ASTs and therefore programmers. Unlike ChatGPT, my code worked, though maybe Fizz Buzz is easier than C++ coroutines? If you don’t know about genetic algorithms, buy my book, or read the Overload article I wrote ‘How to Program Your Way Out of a Paper Bag Using Genetic Algorithms’ [Buontempo13]. In some ways, using AI generated code is similar to copying code from the internet or even documentation. However code is generated, it’s always worth looking at the code and seeing if it is easy to understand, in case you ever need to revisit it. At very least, check it compiles and does what you want.

Some boilerplate code is tedious to write, and it might be more productive to auto-generate such code. Kate Gregory gave the closing keynote at this year’s ACCU conference. Her talk was called ‘Grinding, Farming, and Alliances, How words and ideas from casual gaming can make you a better programmer’. She drew analogies between games and programming. Grinding meant tedious work, like clicking lots of buttons to get a reward, and seems very similar to writing boilerplate code, to my mind. Kate confessed to outsourcing some of the grinding work, getting a child to click buttons in a game, because the young girl loved seeing hearts materialize and float up the screen. A productivity win-win. When I did my post-doc, the lecturers often tried to outsource tedious work to a PhD student. They thereby avoided the hard grind of experiments, and the student got results they could use towards their qualification. If someone other than you might get some benefit or reward from doing a task, even if it might be a long slog, delegating might be the productive way to go. Of course, if you have lots of tasks to complete, hiring loads of minions to do the work might not be optimal. We are all aware of The Mythical Man Month by Fred Brooks. If you double the number of people on a project, the time to completion is unlikely to halve. He died at the end of last year, aged 91. He made “landmark contributions to computer architecture, operating systems, and software engineering” [ACM]. I believe the 8-bit ‘byte’ may be due to him. Sometime little things make a big difference. This seemingly small contribution allowed upper and lower case letters to be represented easily, allowing the use of computers in text processing. Whether that directly caused large language models and ChatGPT is another matter.

So much for productivity. Let’s think about production. As much as you prepare for something to go live, things can always go wrong. I gave a talk at the ACCU conference, which I had practised a few times. My laptop powered off live on stage and refused to start up again, until the following day. I had a copy of the talk in BitBucket, but they have recently rearranged the UI, so when I logged in on someone else’s laptop, I couldn’t see any of my repos. Fortunately, someone in the audience had recently had a similar problem, and managed to help. Several minutes later, I just about managed to continue where I left off, though some of the fonts weren’t supported on the other laptop and I had to remember what various bits of maths on some slides should have said. I also didn’t have time to build the demos I had prepared. Now, I could have had a pdf of the slides to avoid the font issue, and saved screen-casts of the demos, but whatever I had prepared would still have left open the possibility of yet more things going wrong. Sometimes you can’t prepare for every possible scenario, so it’s more important to be able to think on your feet and form a Plan B on the spot. Monitoring what’s happening live on stage, or in production, is important. The time to recovery is often the best metric. Preparing for every eventuality is not productive. Having a backup plan or two is sensible, but you cannot fool-proof anything completely. Overthinking, whether it be of potential disasters or normal use-cases, is often a waste of time. The phrase analysis paralysis [Wikipedia] springs to mind. Chris Oldwood recently reminded me of one of his blogs about overthinking [Oldwood18]. He points out:

Solving those problems that we are only speculating about can lead to over-engineering if they never manage to materialise or could have been solved more simply when the facts were eventually known.

However, he also asked how much thinking is over-thinking? He points out thinking about the big picture, and trying a few thought experiments can be relatively cheap and help the system in the long run. Seeming to be productive, and bashing out Jiras or ticking things off a TODO list is all very well, but sometimes pausing for a moment is more productive than just producing a stream of code. Stopping to think about what you are producing and why, and even how, can be very useful.

Perhaps we can’t quantify overthinking, but we still use the phrase. We also describe some code as over-engineered. Using factories, dependency injection frameworks and the like when a simple script would suffice certainly seems like over-engineering. I’ve recently been reading The Art of Darkness: The History of Goth by John Robb. It reminded me of several bands I had forgotten about, and I even dusted off some old vinyl and chilled over some music. John Robb describes some albums as overproduced, a phrase I had forgotten. Now, we’d never describe production code as overproduced. How do you expunge spontaneity or artistry from code? Mind you, a company may insist on certain code layouts and similar, so removing any hint of personal style. Perhaps overproduced code is a good thing? Reading code, or even a book, that switches between personal styles can be distracting. Over-production would be an entirely different matter. If you over-produce a commodity, you create too much of it, and possibly reduce its value. Can you over-produce code? Maybe, maybe not, but you can certainly over-complicate code. Writing less, but clearer, code is harder than cranking out lines and lines that work, but are hard to make sense of. I suspect AI will never generate short, clear code, unless we get better at writing our requirements. If we never read the code, this won’t matter, but that’s a long way off.

So, back to ChatGPT. Is it OK to use AI to write code for us? Yes, it is. It’s OK to look things up on the internet or in a book if we need to, as well. If you regard AI generated code in the same vein, being careful to access what you are presented with, that’s fine. Copilot and similar are often heralded as being able to help us work smarter and harder. Being able to look something up is often the smart thing to do. Whether AI really helps you be more productive is for you to decide. Don’t go down the rabbit hole I fell into, trying to get ChatGPT to register it can’t put co_await in main. As ChatGPT apologised and retried over and over again, I almost ended up willing it to succeed. I would have been more productive if I had written the code myself several times over, or done some housework, or written an editorial. The trouble is, feeling like you are nudging something close to success makes it very hard to stop. Gail Ollis gave Thursday’s keynote at the conference about what she terms ‘humaning’. She asked attendees to pop questions on a card the day before that she would try to answer. One question was why do coders get sucked into something and forget to eat or sleep. I didn’t get that sucked into arguing with the AI, but I did lose some hours. Gail suggested a quest for a dopamine reward can drive us into sticking with a specific task for far too long, eventually losing the plot. We do need to eat and sleep. We’re only human, after all. We can’t be productive all the time, and some things never even make it to production. The important thing should be having fun, and learning from what we do. ChatGPT certainly hasn’t learnt it can’t put co_await in main, but I have.

References

[ACM] A.M.Turing Award to Frederick (Fred) Brooks for ‘landmark contribution to computer architecture, operating systems and software engineering’: https://amturing.acm.org/award_winners/brooks_1002187.cfm

[Buontempo13] Frances Buontempo (2013) ‘How to Program Your Way Out of a Paper Bag Using Genetic Algorithms’ Dec 2013, Overload 118, available at: https://accu.org/journals/overload/21/118/overload118.pdf#page=8

[Buontempo21] Frances Buontempo (2021) ‘Teach Your Computer to Program Itself” in Overload 164, Aug 2021 https://accu.org/journals/overload/29/164/overload164.pdf#page=21

[Dias23] Chris Dias (2023) ‘Visual Studio Code and GitHub Copilot’ https://code.visualstudio.com/blogs/2023/03/30/vscode-copilot

[Oldwood18] Chris Oldwood (2018) ‘Overthinking is not Overengineering’, published 7 December 2018 at
https://chrisoldwood.blogspot.com/2018/12/overthinking-is-not-overengineering.html

[OpenAI-1] ChatGPT: https://openai.com/blog/chatgpt

[OpenAI-2] OpenAI: https://chat.openai.com/

[Pang23] May Pang (2023) ‘4 Rebellious Productivity Rules to Declutter Your Brain’ published in Better Humans on 17 April 2023
https://betterhumans.pub/4-rebellious-productivity-rules-to-declutter-your-brain-190d554b4230

[Sharma18] Robin Sharma The 5 AM Club: Own Your Morning. Elevate Your Life Harper Thorsons, 2018

[Wikipedia] ‘Analysis paralysis’: https://en.wikipedia.org/wiki/Analysis_paralysis

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.