Editorial: Be lucky

Unfortunately, I have failed to write an editorial yet again. My hopeless, failed attempts may be auspicious though. We have previously considered failure being a potentially good thing. Perhaps we should now consider my misfortune. Could I be luckier next time? Am I just not trying hard enough? Does luck matter, or even mean anything? If people wish me “Good luck with that!” they may be stating I don’t have a hope, or they may genuinely be ‘wishing me luck’. Do wishes ever come true? Yes, they do, but you can’t always tell in advance if you’re onto a winner.

‘Luck’ seems to have its roots in a Dutch word ‘gheluc’ meaning fortune. To me this has a hint of ideas concerning gambling – “You win some, you lose some…” Some viewpoints might subscribe to an alternative stance taking on a notion of destiny or perhaps karma. “You reap what you sow.” If you happen to be born into a fairly well-off family in a resource-rich country, you may have had the good fortune to be bought a PC at a young age, giving you the opportunity to learn to program in the privacy of your own bedroom. If you are the less fortunate other sibling, you might not get a chance to get anywhere near the aforementioned computer. On the other hand, if you don’t have your own bedroom, don’t have enough money for a computer, don’t have an electricity supply, or perhaps have all these, but are told “You’re not technical enough – you won’t be any good at computers”, you are jinxed, in a sense. Such a curse is the opposite of luck. Many a rational person would claim they don’t believe in either. Yet the right circumstances can make a positive outcome more likely, while awkward circumstances make things harder. Some innovators are becoming aware of situations other than their own, so we see clockwork radios and computers, the Raspberry Pi, Code Clubs and so on. I have recently read several stories of women in Africa learning how to program which have left me amazed [TechWomen, Jjiguene, AWAP]. Even if fate hands you a lemon, you can make lemonade, to coin a phrase.

Different cultures have different ideas of luck. People will carry charms, which vary from place to place. I personally never understood how a rabbit’s foot could be lucky. It certainly wasn’t for the rabbit. These superstitions often have a long and interesting history, but sometimes their origins are lost in the mists of time. People will light joss sticks to appease the Gods. Or sacrifice some unlucky creature. I had also heard ‘joss’ used as a Chinese idea of luck, but was surprised to learn it comes from Portuguese ‘deus’, for God. As programmers, do we burn joss sticks, maybe just to mask code smells? Do we carry round a rabbit’s foot, maybe an OS on a stick or similar, which could be a bit more use than a foot, even if it is the left hind foot of a bunny killed in a cemetery when there’s a full moon? We probably all have rituals that we resort to, to make us feel ‘luckier’ or more hopeful of getting it right. Running tests, looking at the results of a static analyser, changing the whitespace and code layout to make it easier for us to read (while causing a massive fight with other team members), getting a greater variety of people to conduct code reviews in the vague hope of flushing out problems... The list is long. There is hope, and we constantly find new ways of making the situation more hopeful. If there’s no hope, the people perish.

Can programmers ever be considered lucky or unlucky? Imagine for a moment you catch a multi-threading bug with some load testing in a development environment, thereby circumventing potential disaster for your customers, and your team. Is this lucky? In a sense, yes. In another sense, no, since running load testing in the first place was designed to flush out exactly this sort of issue. And yet, that you have heard of load testing is either lucky, or you have made an effort to read the right books or listen to the right talks or simply just have the imagination to find ways to make your life easier. Imagine instead, you don’t have any automated tests round your code, try to manually test a few scenarios for a new feature and are told you must release this now because there’s a deadline, and despite your protests, the release goes ahead. And then gets rolled back a few days later due to the bug reports. Is this unlucky? Perhaps. However, I suspect many readers would see this as a predictable and probably avoidable outcome, which happens surprisingly frequently. Why did ‘the suits’ not listen to your protests? Managing to make yourself understood is often about more than luck. Instead of complaining to people that an obscure edge-case may not work or that you can’t possibly estimate how long it will take you to do something you’ve never done before in your life, it is better to try to understand what they are trying to achieve and what information they need. Linda Rising and Barbara Chauvin wrote an article a few years ago about the clash between programmers and managers in ‘Using Numbers to Communicate – in the Spirit of Agile’ [Numbers]. They suggested it helps to ease communication if you find a common way to talk, rather than perpetuating the ‘us-and-them’ attitude. In a fictitious scenario, they observe that if a programmer had “converted the issue to something numeric instead of personal, the issue would have been much clearer and easier for him [the manager] to understand the impact.” Rather than complaining about meetings, keep a diary showing how many hours are spent in them. Then subtract how many hours have been saved by the face to face conversation. If it takes days to manually test a scenario comparing the numbers between today and two days ago, guestimate how long it might take to re-architect the code so you can artificially inject a different business date into the system. Then you can show if there will be a saving in programmer hours over the next budget period. Keep evidence, don’t just rant. As you look at what you measure, you may even realise you were wrong and something completely different is holding you up. This might make you look heroic, and then you may be listened to more in the future.

You can do a variety of things to increase your luck. Finding a good ‘coding buddy’ who you can turn to for help or advice designing a new system or troubleshooting an existing one is fortunate. Being a lone ranger who never gets a code review might make you look heroic, but is a lonely place to be. Why are no people working with you? Does your amazing talent frighten them off? Do you need to make an effort to be more approachable? If you are a newbie you can practise your craft. It is still worth practising whatever your skill level. A popular custom at the moment is coding katas, but just writing code might make you better. Getting the chance to pair program from time to time can be really useful. It might inspire you with new ways of working. It is often just a keyboard shortcut that speeds you up in the future. How auspicious. If you do feel isolated, you could join a geek group, for example the ACCU, just to have a new stream of ideas, thoughts and opinions. If you try to be nice to people, to listen, help and inspire you can grow your network in a useful way. People may start listening to you then. Sometimes it feels slower to work with other people, but it is often worth it. Just the knowledge sharing makes the process resilient in the face of staff turnover, illness and so on. Sometimes you might be wrong. Be willing to say “Oops” gracefully. Sometimes you might be right. Just stating your case tends not to bring on board any converts. If you can’t convey your point with words, and stamping and finger pointing, then try a different approach. Drawing pictures can convey information, often more clearly than words or even tables of numbers. If you start to measure what’s going on in your code-base, for example spotting files that change frequently but have no tests, this can be graphed easily. And no-one ever argues with facts, right?

You might find as you start measuring things your instinct was incorrect. Being honest is important. If you know you get stuck on something or are not very good at it, you can plug gaps in your knowledge. As mentioned, you could try code katas, read a book or write an article to get the idea clearer in your head. You could get a review from an expert in the subject. However, there is not enough time to become an expert at everything. It is ok to delegate to other people. If someone in your team is very good at something, allow them to get on with it. Do make sure they work with someone from time to time to avoid lone rangers and cowboys though. Perhaps they will give you an executive summary and you might learn a little yourself. You may find you have to do boring grunt work – fill in forms, grep log files, while the bright young things get on with the exciting stuff. That’s OK. If you manage to do it without grumbling, or interfering with them too much, they may appreciate you. You might successfully automate the boring stuff while you are there, making everyone’s lives better. Luck might therefore be about finding the right people to give you a leg up or a helping hand. “Stand on the shoulders of giants” as the saying goes. Or just frustration leads you to find a better way of working once you have figured out the root cause of the problem. The glass may be half empty, rather than half full. But that might be enough to motivate you to go to the bar and get a round in for everyone. Then your pint pot may overflow.

A person’s environment or circumstances does affect the potential outcomes. However, this is not the full story. Difficult circumstances can drive innovation. Things being easy, even if not ideal, may stifle innovation. You may work in a business that is risk-adverse so suspect any great change is impossible, but even then you can make small things simpler. The saying about seeing a glass as half-empty or half-full I alluded to earlier is about attitude to the circumstances you find yourself in. It could be if you start to feel unlucky, then you sink into a downward spiral. You might start looking for things that are going wrong, and become paranoid. If this happens, you may find people notice, and they do start watching you. On the other hand, if you see a less than full glass as a chance to grab another pint, or make small but valuable tweaks to the process, code-base or team morale then the difference you have made might be noticed. Even if it’s not noticed, which might be a good thing in an ultra-conservative environment, you have made your own life easier. Your attitude can influence your luck. Or your peace of mind. To quote Monty Python, “Let us not be down-hearted. One total catastrophe like this is just the beginning!”

Various studies have been conducted to analyse the perceived idea of luck. I am not convinced of the scientific status of any of these. Nonetheless, they can give pause for thought. For example, Richard Wiseman [Wiseman], writes about a study he conducted of 400 people who considered themselves to be either lucky or unlucky. He claims he found some distinct patterns in the two groups. Many of these revolved around attitudes. An important and believable point he made was lucky people followed their instincts, perhaps trusting themselves, while unlucky people expected trouble making themselves anxious in the process. If you don’t believe in yourself, how can you expect anyone else to? Another point I got from the article regarded an experiment which asked how many pictures were in a magazine. The lucky people got it right, more quickly. There had been a statement part way through suggesting there were a given number of pictures in the magazine. The lucky people noticed and went with this, in the main. I can personally imagine not trusting this in the same way I might not trust a code comment that proudly claims “//This is correct”. Yet, on other occasions, I will be on the look-out for clues. If I have a meeting coming up about some middleware I have never used before, I will catch a brief moment to read about it, so I can start thinking through what questions I need answered. I want to know the throughput and latency. Not just one. If I have an interview, on either side of the desk, and spot someone has an unusual name, I may search the internet to see if they have written an article or have some code up publicly. I can then have a more interesting exchange with them.

For one final thought, if everything does appear to be going wrong, and you consider yourself the unluckiest person in the world, I learnt one very valuable lesson in 2015. I attended the one-day Agile in Banking conference [AiB] where the closing keynote was given by Linda Rising. She was talking about Fearless change of course [Rising], which I must read one day. In the course of the talk she also told us about Maria’s Rule – “there are very few problems that cake cannot solve.” If everything appears to be a disaster, just bake the team a cake. Or buy donuts. This might be the best way to win friends and influence people. Then you may become the luckiest person in the world. The trick might be to spend time thinking about what you regard as lucky. As discussed, there are ways to increase your luck. What is the most unfortunate thing that’s ever happened to you in your programming career? Perhaps you got sacked, but then ended up with a much better job. What’s the luckiest thing that ever happened? Was it actually a close shave that you can avoid another time?

References

[AiB] Agile in Banking, http://agileinbanking.net/2015/

[AWAP] http://www.africanwomenadvocacyproject.org/PDFs/AWAP_Report_Jan%20201_Final.pdf

[Jjiguene] ‘Women and girls are the answer to innovation in Africa’ http://blogs.worldbank.org/nasikiliza/women-and-girls-are-answer-innovation-africa

[Numbers] ‘Using Numbers to Communicate – in the Spirit of Agile’ Rising and Chauvin, 2008, http://www.infoq.com/articles/rising-agile-spirit-numbers

[Techwomen] https://www.techwomen.org/feature-story/josephine-kamanthe-innovates-youth-education-with-solar-power-in-kenya

[Rising] Fearless Change: Patterns for introducing new ideas Addison Wesley 2004

[Wiseman] ‘Be lucky – it’s an easy skill to learn’ June 2003http://www.telegraph.co.uk/technology/3304496/Be-lucky-its-an-easy-skill-to-learn.html