Quantum Supremacy and Cryptography

The story broke around September 20th that Google was claiming quantum supremacy. It merited not much more than small footnotes in the popular press. It was enthusiastically received in the technology press which makes me think that it is time to start thinking about a world after RSA is dead.

In 1994 Peter Shor published his paper “Algorithms for quantum computation: discrete logarithms and factoring”. At the time quantum computers were nothing but a theoretical figment of many fertile imaginations. Fast forward to 2019, with Google claiming quantum supremacy, and we should be taking them very seriously indeed.

“Quantum supremacy” means (if verified) that Google has a real quantum computer that can solve a real world problem more efficiently than any classical (digital) computer. If their claim turns out to be true, the chances are that the cost of using this computer is astronomical and certainly beyond the means any individual or probably any corporation. But so were IMB’s machines in their early days.

What we experienced back in the early digital age was what we should expect to happen now. As soon as practical uses exist, money will pour in and improvements in the technology will be rapid, probably exponential. Given that most research (outside of secret government research) has been funded by financial institutions, it is a fairly safe bet that those same institutions will be racing one another to translate quantum supremacy into financial market supremacy.

So why should we be concerned about this and what does it have to do with encryption? Well, Shor’s algorithm factorises numbers. If you can factorise a product of two large prime numbers in reasonable time, you break RSA and related cyphers, which account for pretty much all of the messages in the world now. And that is exactly what Shor’s algorithm promises.

We are a few years away from a time with a powerful enough quantum computer to break current RSA keys but if quantum supremacy is proved, you can be sure that time is closer than you think. And don’t forget, your messages are probably being stored by several government agencies the world over right now. Your messages are definitely secure now, but if you care about your messages being secure 5 or 10 years from now you should be asking why we aren’t using quantum safe cryptography now.

Why Codurance?

What Kind of Role Would you Like?

As I've said many times before, we are very lucky to work in the industry that we do. Even if we occasionally moan about what we get paid (and I certainly have done) it is very much a relative moan and not an absolute moan. My point is that most of us working in the technology sector who are any good at what we do can generally command a salary that is way above average and therefore generally "enough", whatever that means. So when I was looking for a new role this Spring and early summer I was doing so knowing that I could afford to select not only on the basis of pay. As I touched on in this post a couple of weeks ago, the fact that you can Google me and find interesting stuff made it even easier for me to get interviews for interesting things.

To be or not to be a Consultant

Very early on in my search I realised that I had a decision to make. Should I continue to be a consultant (and if so, what type of consultancy) or should I think about putting a stake in the ground as some kind of in house development leadership type person. The pros and cons, as I saw them after 4 years of consultancy, of the job were pretty clear:

In Favour of Consultancy:

• The variety of work is interesting and leads to learning stuff about far more different technologies.
• If you hate the gig you are on (i.e. your job) you can change to a different gig relatively easy. The ease with which you can change will be determined by the specific consultancy you are in I guess. Effectively though, you can get a new job without the pain and uncertainty of having to look for a new job.
• There is a certain freedom of consultancy in knowing that you can't be sacked or "managed out" for being too daring or asking searching questions. I certainly played on that a few times where the conversation with a worried client might go "don't worry, if anybody asks, send them to me, I'll take responsibility, they can't sack me".
• You get to do some travel to some places you may not have been to before.
• You get to look at really interesting problems and when you solve them (or at least relieve some of the pains) you can move on to another equally interesting problem.
• It never gets comfortable and therefore boring, and if it does, you can ask to move on.

Against Consultancy

• You learn a little about a lot of things but don't always get the chance to learn a lot about any specific thing.
• You start a lot of things and you may finish the odd thing but it is very rare to both start and finish the same thing.
• The constant change of scenery can be unsettling and there are many periods of onboarding which can be wearing.
• Sometimes you get sent away from home and don't get to spend time with your family.
• Travelling on aeroplanes definitely stops being exciting.
• Positions of influence are common but positions of true responsibility are rare.

I could go on, but the point I'm making is that it was a tough decision for me. I really enjoyed working as a consultant and I learnt loads in four years.

What was on the Table?

I interviewed for 4 or 5 roles outside consultancy. These were all either "head of", "VP of", "director of" Engineering, Development, Software type things or, in one case, a CTO role. I told the recruiters that I wasn't interested in anything that had a scope of less than several teams. So basically, in any small to medium sized organisation this means "head of" or CTO, in a larger organisation it could mean "architect" or "head of" or whatever they use internally. Based on what I enjoyed doing back in my Viagogo days and what I enjoyed doing during my 4 years at ThoughtWorks I think I had a reasonable idea of the type of company that I would like to work for (if I was to go to an in-house role) and, more importantly, the type of organisation I didn't want to work for.

Things I'd Like to work for

• Somewhere with significant organisational problems that recognises it has such problems and has a good appetite to fix them.
• An place that has been around for a while as a bricks and mortar, has loads of legacy systems but realises the need to move on and has the courage to appoint the right people to do that.

Things I wouldn't like to work for

• Brilliantly run startups or scale-ups that have great technology, great engineering capability and practice and no significant organisational problems.
• Companies that need to improve but either don't realise that they need to change or don't have the courage to do what needs to be done.

So what I really wanted was something with issues but a mandate to fix them. This is the kind of profile of the organisations that I consulted in to for ThoughtWorks, for the most part. I did have experience of one place where the CEO was blissfully unaware that they were heading (still are as far as I can tell) for a massive car crash at some point in the next few years and thus was unwilling to change what he thought was a successful course. That was an example of a company that was doing well on its bottom line despite its practices and capabilities, not because of them and was certainly a lesson for me.

Well funded Startup

One company I interviewed with up to the final interview state was an extremely well funded start up. Its parent is a well known multi national group. This new company was created to implement a brand loyalty scheme across the whole of the group. So it is a greenfield thing but there would be lots of potential pain in integrating the new systems with all the legacy of the companies within the group. The role here was "VP Engineering", reporting to the CTO. The initial responsibility would be building a team and working on the MVP of the new solution.

Well Run Tech Company

The other company I went quite deep with was a fairly well known company with a well known web presence. This company is renowned for good engineering practice and is often cited as a "centre of excellence" (I've never quite understood exactly what this means and it seems to be a bit of a self nominated, self selecting thing). In any case, I started to lose a bit of interest in this company somewhere between the third and fourth stage as I wondered exactly what type of deep problems they may have that would keep me interested.

Consultancies and Organisational Takeover

I spoke to a few consultancies. Some bigger (and uglier) than others. The more I spoke to, the more I realised that I had been lucky in working for ThoughtWorks. It seemed that once a consultancy gets beyond a certain size, whatever principles they started out with seem to get thrown away and replaced with a simple goal to rinse as much money from the clients as possible. I had heard this of really big players in the past ("organisational takeover" is apparently a real business model for some) but I, somewhat naively, assumed this was the preserve of only the biggest few.

Fake Agile

The most disappointing thing about consultancies in general is the promise of being an "Agile Consultant". There are many of these around, a lot of the smaller variety. I can't speak for all of them but I spoke to people in one or two and specifically asked them how they go about selling Agile to their customers. Sadly, I didn't get any kind of good answer. I was left, in every case, with the overwhelming impression that these consultancies were not only selling snake oil to unsuspecting clients but that they really didn't even get it themselves.

Worrying Conclusion

So after speaking to a few consultancies and going quite deeply into some interview processes for non consultancy work, I was left with the worrying conclusion that I would find it hard to find a company to work for that was sufficiently broken to need me (or keep me interested) but that also had the sufficient level of executive support for the work that I would know would need to be done. On the other hand, I was struggling to find a consultancy company that I could feel comfortable working with.

Meeting Codurance

I spoke to a recruitment consultant some time in May about a company called Codurance. I was starting to get disillusioned with my search and was resigned to a long summer of frustration. The consultant made all the right noises about this fairly small company and their ethos, largely based around software craftsmanship. He also spoke about how Codurance has no internal hierarchy, an interesting approach to innovation and a progressive set of policies on salaries. So I agreed to find out more.

Software Craftsmanship

The <Title> tag of the Codurance website includes the phrase "Software craftsmanship and Agile Delivery". It is clear that Sandro feels quite strongly about the importance of software craftsmanship. Indeed, in the early chapters of his book, the Software Craftsman, he argues that software craftsmanship should be a core part of Agile delivery but that this is often overlooked in the belief that if you follow the right process everything will work out. I can't argue with this assertion at all. For years I worked under the assumption that code quality was essential to the long term health of a system. I love the emphasis on craftsmanship (although I wonder if we can invent a term that is a bit more gender agnostic) and I do agree that it can be a forgotten element of effective delivery.

London Software Craftsmanship Community

I was even more encouraged when I discovered that Sandro founded the London Software Craftsmanship Community, a meetup group. After my experiences of the previous few years I realise how important it is for a company not just to make the right noises about culture and community but to actually do the right things, and believe in the right things, as well. In addition to the meetup group, Codurance also runs the Software Craftsmanship London conference every year at Skillsmatter in the autumn. So it was immediately apparent to me that Codurance does not just talk the talk but quite clearly it walks the walk too.

Agile Delivery

The other part of the title tag is Agile Delivery. In 2019 I would expect anybody doing software delivery to at least claim that they are Agile (or agile). I know from my travels that fake agile is everywhere and I was keen to understand what Agile means to Codurance. So when I spoke to Steve Lydford, head of PS, before being invited in for a face to face interview, it was very pleasing when he told me that he had watched a video of my Agile is a Dirty Word talk in which I vent (and despair a bit) about the prevalence of fake Agile practitioners, fake Agile methodologies and fake Agile consultants. That formed the basis of a good discussion between us which convinced me that Codurance as an organisation properly understands what Agile (and agile) means and that my experience of Agile delivery would be appreciated

The Opportunity

Codurance is a much smaller company than ThoughtWorks, which is itself pretty small compared to the global players that most people will have heard of. We are starting to grow organically and the current challenge, or opportunity as I like to call it, is to win more work that we would consider to be partnership type work rather than "pair of hands" staff augmentation work. We haven't got much experience of creating fully cross functional teams and this is our current challenge. How do we win and retain this type of work? This is the challenge we are facing now and my experience before Codurance seems to have been the most interesting thing for them looking at me.

Self Managing "Teal" Organisations

Steve recommended me a book to read, Reinventing Organisations, which describes a relatively new type of organisation that has evolved in recent decades. The author calls these organisations "Teal Organisations", which are essentially post hierarchical organisations based on management through self organisation. As I remember it, he used colours to categorise different types of organisation merely to avoid the name implying any kind of meaning. Having worked at ThoughtWorks, I know all about what it means to work in an organisation without hierarchy and I would absolutely not be able to work in an organisation that had anything other than a flat structure so this was all encouraging.

But there is flat structure and there is self organisation and true buying in to self organisation. Certainly I have encountered organisations that claim to have a flat structure but really they have a hidden hierarchy and command and control is everywhere. My early conversations with Steve suggested that Codurance was more genuinely bought in to self organising entities.

Innovation Circles

Through reading Reinventing Organisations and talking to people who have been involved in organisations that are trying to be self organising to a greater or lesser extent, the problem of how to change policy and ways of working comes up again and again. There are many different solutions and I would recommend anybody to read the book to find out how some organisations deal with this. In Codurance if you have an idea to change something you start an innovation circle. This has to be open to anybody that is interested and the discussions must be public. There is a rule on what constitutes a quorate group but the innovation circle is empowered to make changes and to implement them provided that the proposal passes the culture and financial tests. There is no need for approval from any "higher" power.

Open Salary Policy

Codurance has an open salary policy. I was told this by the recruiter when I first spoke to him and this was mentioned in every conversation before I started. Essentially this means that we have a spreadsheet that we can all look at that lists everybody in the company and what their salary is. At first this seemed a little alien and maybe scary but the more I considered it, the more I thought it was a great idea. I ended up reasoning to myself about what the difference could be between a company with open salaries and a company (i.e. every one I've ever worked for previously) that does not have an open salary policy.

Why Not have an Open Salary Policy?

In almost every place I have ever worked there is suspicion and rumours around salaries. Why would you not just publish everybody's salary so that everybody knows? In almost every company it is perceived that the barriers to promotions and pay rises are lower for people coming in from outside than they are for internal people. I don't know why this is but it leads to people changing jobs frequently in many cases as this is perceived to be the only way to get a decent pay rise or a promotion. If this is true, then I can see why you wouldn't publish. If somebody comes from outside with the same job as you but with no domain knowledge and they were getting paid more than you, you will likely be very upset, and rightly so.

I think perhaps the bigger point is that to move to an open salaries policy would mean that fairness in salaries across the organisation would inevitably have to follow and that fairness would cost a lot of money to implement properly. Either lots of people would have to be given pay rises to bring them in line or many people would leave as they perceived that their pay was still unfair even after some adjustments. Certainly nobody would be volunteering to take a pay cut. The cost of these adjustments would just be too great for most organisations to contemplate.

How This Worked Immediately

At my final interview I was told that I would be offered a role, the only question was how much the offer would be. I asked for a number and was told that this was quite a bit more than the only other person at the proposed grade. I pointed out that they had already told me that I would bring additional expectations because of my previous experience. This was accepted and they then told me that any offer had to be agreed by all the people that had interviewed me. As one of those was the person in question, who might be upset by my proposed salary, this seemed perfect to me. Not only would this other person know the outcome of any offer but would actually be involved in that decision.

Conclusion

I took the offer at Codurance because I was excited by the challenge of helping us to grow and mature our offerings, I was enthused by what I see as a genuinely flat, self organising structure and I love the culture of genuine openness that is obviously real and not just a veneer. I'm so far very happy with my decision and very happy to be a Principal at Codurance.

Quantum Computing and Me

Why Quantum?

If you are one of my colleagues or close (technology) friends you'll know that I've been researching quantum computing for a while now. It all started back at Devoxx Vienna in March 2018 when I saw a great talk by Alasdair Collinson (who I've since become good friends with) entitled "The Quantum Computers are Coming". At the time of seeing Alasdair's talk my knowledge of quantum computers was close to zero. I had vague recollections of reading something about quantum key exchange in a book about codes and cyphers years ago, but I've since learnt that isn't really to do with quantum computers anyway. I was lost pretty early in the talk and I wanted to ask him some questions and also give feedback. I thought he should try and give a little more basic material at the start to try and help people along.

Alasdair's was the last talk of the day and if you watch the video, you'll hear Alasdair mention "[releasing the audience] to the beer" at the end. Immediately after that talk was the free beer party. I didn't manage to talk to him during the party but I knew the speakers were being taken for dinner that evening so I thought I would talk to him later.

Unfortunately by the time we got to the speakers' dinner either I was a little tipsy, or Alasdair was, or more likely we both were and we didn't manage to have too useful a conversation. I remember thinking to myself "how hard can it be?" I'll do some research and learn the subject myself and maybe I can do a job of making a more accessible version of this quantum computing talk malarky.

When the conference was finishing up I had a chat with one of the organisers. He told me that he was involved with a couple of conferences in Krakow and asked if I had submitted to them. I hadn't and so he asked me if I wouldn't mind submitting. The CFPs were both closing a day or two later so he urged me to submit as soon as possible. When I got home that evening I decided to submit the same talk that had got me into the Vienna conference and, on the spur of the moment, I knocked up a synopsis of a talk about quantum computers and submitted that as well. I fully expected that the Polish conferences would pick my well known talk on Microservices if they picked up anything. As it turned out, I was wrong. And a few weeks later, having not done much about learning the subject, I suddenly had around 6 weeks to prepare a talk for Devoxx Poland on a subject I knew barely anything about. The result of my learning can be viewed here.

Learning Quantum and Duncan Mortimer

A few weeks after Vienna I was lucky enough to roll off my project and have a couple of weeks on the beach. This was my opportunity to learn about quantum things. I was chatting to somebody in the kitchen in our office and one of my colleagues, Duncan Mortimer, overhearing the conversation divulged that he was interested in quantum computers. It turned out that he was an enthusiast, had studied the field at university fairly recently (he's a lot younger than me) and we agreed to pair on a talk at the ThoughtWorks Away Day. This chance encounter made all the difference as Duncan was able to help me understand enough to cobble together a coherent story for Poland with, crucially, a very basic demonstration of quantum code using Q#. If you watch that first effort of mine at talking quantum you'll see that I used Duncan as a humorous element to essentially excuse my lack of understanding at certain points in the presentation.

A ThoughtWorks Quantum Strategy

At the Away Day I chatted with the ThoughtWorks global head of technology and in the brief chat we had he mentioned that nobody in the UK (or anywhere as far as he knew) was taking the reins of quantum and moving it forward. We need a global strategy on quantum he told me. Would I like to take that on? I told him I had no idea what this means so we agreed to have a chat afterwards. I therefore took on the responsibility of trying to make ThoughtWorks "Quantum Ready". My pitch to anybody that I could engage on the subject is that at some point in the next 5 to 10 years, quantum computers will be a commercial reality in some form. When that happens we (ThoughtWorks) need to be in a position to take advantage of the new opportunities this will create.

Meetups and Conferences

Obviously I needed to know more about the subject. I had managed to go to just one talk in London about quantum computing before the first conference in Krakow. It was a great talk at Microsoft by Dr Julie Love about the Majorana Topological Qubit. They believe that this is the technology that will lead to a stable, less error prone, qubit than can currently be realised by other techniques (of which there are many) and will therefore ultimately give Microsoft an advantage. This was the first time I had gone to a meetup (other than those held at the ThoughtWorks offices) for many years and I realised a while later that the ThoughtWorks culture coupled with this new exciting field had finally combined to reawaken my interest and love for technology that had bene stifled and crushed by the toxic culture and terrible working conditions at my previous job.

Throughout the remainder of 2018 I went to many meetups organised by the London Quantum Meetup group and got to know the organisers of that group. Every time I learnt new things I was able to remove some of the cruft about my learning journey and maybe correct some of the stuff in my original presentation that I had wrong or modify the way I could talk to parts of it to reflect my increasing knowledge. Thus my presentation became a living record of how my learning moved along and I have preserved it as it was when I presented it at various points to various conferences (something I do with all my decks).

Quantum Hackathon

I started going regularly to meetups organised by the London Quantum Computing group. If you live or work in London and you are even vaguely interested in quantum computing I thoroughly recommend you go to some of these meetups, they are great. One of the organisers happened to tell me that they were trying to organise a quantum hackathon. The idea would be that we get a group of people together to work on an organic chemistry problem (a solved problem I might add, quantum computers aren't yet powerful enough to tackle the stuff that classical computers can't solve). Two companies from Cambridge, Dividiti and Riverlane provided some open source software support and IBM were on hand to give us priority access to their IBM-Q computer. The event was a great success.

Manchester Workshop

After the success of the quantum hack day I was asked by our Manchester office if I could organise something similar in Manchester. Unfortunately this wouldn't be possible because I didn't really organise the London thing, I just (through ThoughtWorks) provided the venue and the food. I did suggest that I could give a presentation and perhaps an evening workshop on how to program quantum computers. This was enthusiastically agreed to and I fixed a date with the Manchester community coordinator.

So one lunchtime, we got together in the Manchester office kitchen and I gave a long version of my conference talk (much evolved from the original) which was very well received. The audience was mainly ThoughtWorkers with a few outsiders (it was advertised as a public event) thrown in. 

The evening was a lot more nerve-wracking. The event space was full (I was told 60 people) and this was mainly external visitors. Even though we had advertised the event as "bring your own computer and play along with the presenter" nobody seemed to have read that, or at least nobody seemed to have followed that path or installed the software (Microsoft quantum developer kit) as we had asked them to. So the result was an hour of me talking people through how to use IBM-Q, a five minute break and then an hour and a half of me explaining Q# and showing demonstrations.

Shor's Algorithm

When I gave a talk at a conference in Poland in September it bombed badly. Amongst the torrent of dire feedback were some really useful comments that I determined to act upon in future. One such comment was that the demonstrations I gave were trivial and didn't really demonstrate anything that a quantum computer could do that a classical computer couldn't. This was fair and I resolved to address it.

So in the week leading up to my trip to Ukraine I found myself implementing Shor's Algorithm from first principles. The Q# samples provided by Microsoft actually has a version of Shor but I couldn't really understand it properly and, further, I felt that it was a sub-optimal implementation because the quantum computer was doing all of the work whereas it should only be used to do step 4 (the quantum period finding routine). In my mind, as well as demonstrating the Quantum Fourier Transform (QFT), implementing Shor is a great way to showcase how you should selectively pass control between your classical computer and your quantum computer, only using the (very expensive) quantum compute power for the parts of the algorithm that can't be done on a classical computer.

On the day of the talk I had a wonderfully written, test driven, example of the whole of Shor's algorithm but using a C# algorithm to find the period. All that remained was for me to write the quantum period finding routine and plug it in. Sadly, this was much easier said than done. In the end, I had to compromise and I effectively "lift and shifted" that part of the Microsoft implementation into my own code, which included an implementation of the "Fast QFT" that I didn't fully understand. You can look at my implementation (which has barely changed since I originally made it) on my Github.  

I ran it successfully in the speakers' room about an hour before my talk and sat back in satisfaction. Then I ran it again and it failed. And again. And again. And each time the failure took ages and appeared to involve some kind of .NET kernel memory overflow. Not good. When I was close to despair, it decided to work again so I took a screenshot of the results in case, as seemed likely, it failed in the subsequent talk.

Here is the slide that made it into my deck:

Andrew Bryer

In early 2019 I found myself working in the ThoughtWorks Manchester office a couple of days a week. One of the Manchester people who had reached out to me to see if I would run something quantum based in Manchester had been Andrew. When I started working in Manchester he was on the beach looking for something to do. I got talking to him and asked if he fancied doing some research in Q# and helping me out in understanding how better to implement the QFT. He was only too pleased to help out. So I lent him a book I have, Minds, Machines and the Multiverse, instructed him to read the chapter about the QFT and help me to implement it in Q# without using any library functions. It didn't take him long.

Then, I asked Andrew to look on my Github and see what I had done in my implementation of Shor and just to concentrate on implementing the quantum piece. The first thing he did, after about half an hour if memory serves me correctly, was to tell me that he had found the issue that was causing my implementation to crash and had fixed it. He then proceeded to implement the quantum period finding routine from first principals using his own QFT implementation. I thought that would take him a while, but once we'd established how Q# can be used to link any action to a control qubit (a great feature but I have no idea how it would be supported in a real quantum computer) it didn't take him long. When I was on the train home to London from Manchester that evening, I got a message from him.

So there are a couple of morals to this story. Firstly, ThoughtWorks grads are brilliant. If you have a pure software problem to solve, even if it is in a paradigm that they had never heard of until a few hours previously, they are brilliant at solving it. Secondly, quantum computers are a long way off being actually, practically useful!

Using Many Worlds...

After doing all the research up until the back end of last year and trying to understand the "real" quantum algorithms (such as Deutsch-Josza, Shor and Grover) I realised that I couldn't reason out why they were so powerful without understanding things in more depth. I started to read more books about the fundamentals of quantum physics because so many of those "basic" concepts need to be understood to grok what is going on inside of a quantum computer. This helped me to understand up to a point and certainly helped me to understand the quantum state, which is usually expressed as state vectors, often using bra and ket notation (which I'd never come across before). This work was also, for me,  an excellent refresher course in some of my long forgotten university mathematics.

But something was still missing. I remember in the early days often hearing phrases such as "the qubit is in superposition" or "...holding both the value 0 and 1" and I think I had used similar phrases myself whilst internally holding a picture of the Bloch Sphere and imagining a thing with a state entirely represented by the quantum state arrow on that Bloch Sphere. There are at least a couple of problems with holding that view in your mind.

• Firstly, as alluded to in my previous sentence, the Bloch Sphere is really only valid to help to understand a single qubit. 
• Secondly, we need to be able to convey that the probability of returning a 1 or a 0 is not the full picture; we need to be able to convey that any computation that the quantum algorithm will carry out will use ALL of the possible values of ALL of the qubits that take part in the computation. 
• Thirdly qubits interact with one another and generate interference patterns which can be analysed and exploited.

Many Worlds Interpretation

One of my breakthroughs in understanding came while I was reading (I think) The Fabric of Reality possibly at the same time as reading Introducing Quantum Theory, a Graphic Guide. I had heard and read in one of his different books, that David Deutsch was a believer in the Many Worlds interpretation (MWI) of quantum physics. In fact it could be said, if I understood correctly, that he believes that the very fact that an algorithm such as Shor works, proves that the MWI is correct. I like his assertion that whilst the Copenhagen Interpretation correctly predicts the observations associated with quantum mechanics, it doesn't explain them. On the other hand, MWI predicts observations and explains them.

Young's Double Slit Experiment

Many people will remember carrying out a version of the double slit experiment at school. This was first demonstrated by Thomas Young in the early 1800s. He devised it as a way of "proving" that light is propagated by waves and not, as Newton had suggested and was the prevailing theory of the time, by particles, which Netwon had called "corpuscles". Thus, by showing that light can be made to create an interference pattern, he showed that light must travel as a wave.

But, in the early part of the 20th century, physicists were questioning again whether this view was correct. Indeed, much of the early work in the new quantum mechanics of physics indicated that light was, in fact, propagated by particles, called photons. This led to the creation of the concept of "wave particle duality". The explanation was that as light travelled the photons would interfere with one another so that explains why the interference pattern and the particulate nature or light are not inconsistent.

So far, so consistent. But then, in 1909, Geoffrey Ingram Taylor performed the experiment with low intensity light so that photons were mostly emitted and absorbed singly such that their flight paths from emission from the light source to detection by the detector did not overlap. Subsequent experiments have guaranteed that only one photon is in transit at one time. The remarkable result of these experiments was that if you allow them to run for a time so that each photon incident on the detector has its position recorded, then the interference pattern builds up over time. So interference is still happening, even though there is no other thing in flight to interfere with. The inference drawn, if you believe in MWI, is that the photon, although apparently the only photon there, is interfering with the "ghost photons" that are taking the other possible paths in all the other universes. So far this is the best explanation of what is going on in Young's double slit experiment (single photon version). The Copenhagen interpretation has no explanation for the interference patterns in the single photon version.

Making Videos

In the interests of making my talks more interesting, I revamped the "is Quantum a thing" title into "Using Many Worlds to Solve the Unsolvable". At the same time I made a video with some ThoughtWorks colleagues in which we reproduced the double slit experiment using some crude materials and a laser pointer. That video was debuted in my talk at Codemotion Amsterdam in April 2019 (but I can't find a link to that) and I used it again in Minsk in May 2019.

Adding a live video seemed to go down really well and by summer 2019 I had done a couple of lightning talks that just included the section on Shor's algorithm with a suitable level of abstraction and simplification around the QFT. They were really popular. So much so that I persuaded Devoxx Poland to give me a 40 minute slot to expand the idea and to do a bit of work around the post quantum cryptographic landscape. For that talk I wanted to do another video, this time using my daughters to help me at home. We used polarised light filters to demonstrate how light photons are polarised and thus to lead in to a talk of BB84 quantum key distribution. This longer talk has so far only aired at Devoxx Poland and to private audiences.

Right up to Date

In July 2019, I left ThoughtWorks which was very sad (as I've noted in several places). One of my sadnesses whilst still at ThoughtWorks was that I found it very difficult to get any kind of management interested in quantum computing because it just isn't commercially interesting yet, apparently. When I came to Codurance, a much smaller and more nimble consultancy, the response I got was very different. The small commercial possibilities that did not interest my previous employer are very interesting here. So hopefully I will get the support to continue my passion for learning new things in the quantum space (and giving talks about it) as well as, hope against hope, maybe we'll manage to find some real work to do in this arena before too long. No doubt I will write about it if it ever happens!

Tech Debt Discovery and Cost-Value Quadrants

Introduction

There are various reasons why technical debt is allowed to build up and various reasons why technical debt isn't paid down. I have previously written about this and I won't go into that again. The point of this post is to briefly discuss a method for understanding what technical debt exists, making it visible and stopping it from getting any worse. So for the purposes of this post I'm going to assume that tech debt is a thing, there are things that exist that you can call tech debt on your product and that you want to tackle them.

Cost-Value Quadrants

The idea of a cost v value quadrant is far from new. I can't remember the context of when I was first introduced to them but I've certainly used them many times to help to priortise stuff in many different contexts. The basic idea is that you have a few things that you want to compare. Each of these comes with a cost and each of them has some kind of value. If you draw two axes, one representing value (I usually go low value on the left to high value on the right) the other representing cost (I usually go high cost on the bottom up to low cost at the top, or "hard to do" on the bottom up to "easy to do" at the top) then you have divided the area into "hard to do, low value" (bottom left), "easy to do, low value" (top left), "hard to do, high value" (bottom right) and "easy to do, high value" (top right). This whole idea is not dissimilar to the Eisenhower Decision Matrix.

It is important to note here that cost and value has been the most often used things for the two axes in one of these quadrants. However I have used other dimensions for such exercises. For example, if you have a sense that there are multiple dimensions that need to be considered when comparing a load of things, it might be helpful to first decide (maybe by using sliders) what the most important two dimensions are and then place all the stuff in a quadrant that only considers those two dimensions. This can potentially help to whittle down a large number of possible things to a smaller number before applying some other criteria in turn.

Why go from High Cost to Low Cost on the vertical Axis?

Many people that I have come across have asked me why I effectively put high cost on the bottom of the axis up to low cost at the top of the vertical axis. The answer is simple, I want to focus on stuff in the top right of the resulting quadrant. For some reason I have always found it pleasing to get to a state where we concentrate on things in the top right. That is just me though, if you want to go Low cost to High Cost, feel free. You'll just then concentrate on the bottom right quadrant in a cost v value comparison.

Tech Debt Discovery Workshop

I have seen many organisations handle tech debt badly. Some places are all too ready to create it, "we don't have time for gold plating, get the thing done and we'll fix it later" is a common attitude. Some other organisations create tech debt because their engineering practices are not mature enough, or their quality engineering function isn't strong enough, to understand or prevent tech debt accumulating, "what is a contract test?". The purpose of a tech debt discovery workshop is to socialise what tech debt is, in all the forms that we know that it exists in this organisation, surface all of the items that currently exist and get a basic idea of prioritisation for them.

Setting up the Workshop

The setup of the workshop is very simple. You need a whiteboard with a quadrant on it (as above), some people who know what tech debt items that need addressing, some stickies and some sharpies. Once you've done the setup, your whiteboard should look something like this (the worried looking client tech lead running his first ever workshop and the extraneous stuff on the whiteboard are optional):

If you zoom in closely you'll see that we drew two axes on the whiteboard behind the gentleman in the pink t-shirt. Whoever is facilitating the workshop needs to explain clearly to everybody what the goal of the workshop is (in this case, discover how much tech debt we have and get a feel for what we might tackle first), and explain what the quadrant on the whiteboard is.

Stage 1 - Crowdsource the Items

As with a lot of workshops, one of the goals of the workshop is to get everybody to think they contributed to the outcome and thus get buy-in from all of the people in the group for whatever outcomes you are going to arrive out. Crowdsourcing is a great way to do this. So give everybody a load of stickies and a sharpie and ask them to write down in each stickie something that they'd like to fix that they think is tech debt. They then stick all of their stickies on an appropriate point of the quadrant. It is important at this point to stress that they shouldn't take too much time getting the thing in exactly the right place. There will be time later for a group discussion and adjustments. In my example, after this first stage the board looked like this:

Not that it is far from uncommon in such a workshop for stuff to be grouped to the right of the vertical axis. It is pretty natural for people to only think about stuff that is valuable, hence only stick things on the "high value" side of the picture.

Stage 2 - Discuss, Group and Place Items

After everybody has thought of everything that they are going to think of the facilitator needs to go through every item in turn, make sure everybody understands what it means group it with any duplicates or similar items and position it somewhere sensibly. Note that this has to be an iterative process. We are not putting an absolute value or implementation cost on each item, rather we are interested in saying "is this more valuable than that?" or "is this harder to fix than that?". Also at this stage, the discussion may well prompt more things to get surfaced or some items to consolidate into larger items. If this happens, fine, add them as you go. At the end of this stage, you should have your final session output that looks something like this:

Again, the happy looking tech lead who has just successfully facilitated his first workshop is optional

Next Steps

The next steps will depend on the situation you are in. In the case of the workshop that we ran in which I took the photographs in this post, we had not yet put anything live in our product. We were delivering an internal PaaS offering. Our priority in the early part of the project was to get things ready for the internal teams to use but not necessarily production hardened (unless it would cause undue rework to do the two things separately) and thus we were counting a lot of as yet not done stuff as technical debt for the purposes of the workshop. As we knew that we weren't prepared to go to production without a lot of these items, we made stories out of all of them and prioritised the ones that were necessary for production hardening or that were otherwise high value according to the quadrant.

Keeping the Quadrant As a Project Artefact

As I alluded to at the start of this post, and as I have written about before, some organisations have a hard time getting to their technical debt items. An anti pattern I have often seen is when teams resolve, sometimes at the behest of a CTO or senior manager, to allocate a percentage of their sprint time to debt items. This is problematic in my experience for at least 3 reasons. Firstly, to put something in a sprint plan means it must exist in your card management system and thus you are paying an inventory management tax. Secondly your devs will likely (though not always) want to work on something new rather than something seen as a boring maintenance task. Thirdly, as soon as your team comes under pressure to get all the things done in the sprint that they "committed" to, the debt items are the scope that gets cut. The last of the three is the most dangerous and that type of attitude is probably one of the major reasons why you have a load of debt to deal with. I covered this in the technical debt cycle in an earlier post.

So my favourite way to keep on top of technical debt is to keep the quadrant as part of the product wall. Every time you knowingly create more tech debt, or you discover some tech debt, write out a new debt card and stick it on the wall. Then every day at stand up or tech huddle or whatever, discuss this new thing, get agreement from the whole team that it is a thing and also where it should live in the quadrant. Adding things to the wall should come to be something that people just don't want to do or at least do reluctantly.

Tackling the Debt Wall

Hopefully the stuff on the wall is small stuff, like add one test or refactor one thing. I have had great success in various teams by doing "debt days". Either one day a week, or maybe one afternoon, everybody drops the thing they are working on and picks something off the wall. Either they pair with another developer to learn something new or just to share context or they do something really simple on their own because they think it will be fun or maybe because the thing is something that is causing them some personal pain. It doesn't matter. The outcome will either be that the thing is fixed, or if it turns out to be too complex, maybe there could be a story to play or a spike to consider or a discussion to have. In any case, everybody has a fun time, hopefully, and the debt pile is reduced.

Why Would you leave ThoughtWorks?

What is the Problem to which this is the Proposed Solution?

Last weekend I saw my dad for the first time in a few weeks and he had found out through the grapevine that I had started a new job. His question to me was, essentially, why have you left the company that you always said you loved working for?

Before I worked for ThoughtWorks, I realised that people often jump to solutions before they have fully reasoned out the problem that they are trying to solve. Also, I noticed that people from the business, depending on their level of technical (mis)understanding, would quite often come to us in the technology teams with a "solution as a requirement". For example, I can remember product owners who liked to exhibit their credentials as understanding things might come to me and say, "I have a new requirement for you. I need a new database column." With respect, I might say, that is not a business requirement. That is a solution to some problem. So very often I would say at these times "What is the problem to which this is the proposed solution?"

This line of questioning was always really helpful in the contexts in which I was in because it often turned out that when we drilled into the problem they were trying to solve, their proposed solution may not be the right one. It could even be that there isn't a problem to solve there at all. Maybe they have misunderstood the capability of the tools at their disposal. Perhaps they aren't aware of some feature that already does what they want to do.

So Why am I Looking for a New Job?

Back in May I started to look for a new job. The weird thing was when people asked me why I was looking for a new job was that it was hard to say exactly why. Most people, correctly, pointed out that I really liked working for ThoughtWorks. There is no doubt that it was the best job I'd ever had and the best employer I'd ever worked for. Certainly this is still the case (up until June 2019) and that didn't change drastically. So why was I leaving?

ThoughtWorks History

ThoughtWorks was founded in 1993 by Roy Singham. The company has always had a very strong and unique culture. In particular it has a 3 pillar model based on, I was told, the Ben and Jerry's 3 pillar model. Pillar 3, (referred to internally as P3) states that the company strives for Social and Economic Justice. The way this objective played out varied over time and was always subordinate to pillar 1 (sustainable business) and 2 (technology excellence) but was always used at the very least to inform decisions. For example, there would often be internal debates over whether we should be doing work for Company X or Corporation Y. This debate was always healthy and open.

Activism and P3 Work

Throughout my time at ThoughtWorks Roy was actively engaged in social activism in various places in the world and, as the only major shareholder holding over 99% of the company's equity, removed earnings from the company to fund his activist work. This was well known throughout the company and, whilst you could agree or disagree with Roy's specific politics, nobody seriously challenged the validity of striving for social and economic justice and as far as I could tell, most of us bought into this.

From time to time in various geographies, I saw this happen perhaps 4 or 5 times in London during my 4 years, we would carry out work that we would call "P3 projects". This could be work for a non-profit organisation, for a charity or perhaps for startups that were well aligned with ThoughtWorks culture. The way this happened varied but what I saw in London a couple of times was that we would carry out the work at our offices, staffed by perhaps one or two experienced ThoughtWorkers and several grads. This work would be carried out at hugely discounted rates. We didn't make money on the engagement but some of our less experienced people got valuable experience and we furthered the company's P3 goals.

Takeover by Apax Ventures

In autumn 2017 all ThoughtWorks employees were gathered (I think) simultaneously to hear an "important announcement". I was working on a client site in Glasgow at the time and we were told the day before not to go to the client that day but instead to go to a nearby hotel where we had hired a conference suite. As far as I know the news wasn't leaked beforehand but there was certainly a lot of speculation as to why we were being told to do this and to my recollection there were two strong favourites, one was that Roy was selling, or had sold, ThoughtWorks and I can't remember what the other possibility was.

We learned by way of a pre-recorded video by a member of the Global Coordination Group that ThoughtWorks had indeed been sold to a private equity fund managed by Apax Partners. This was a shock to all ThoughtWorkers and can only be described as a watershed moment.

Saying all the Right Things

Of course we were concerned about what would change. The emphasis of the company was bound to shift wasn't it? Whereas previously we had all been happy to buy in to the fact that our work with our clients was ultimately being used to fund the global P3 activities and Roy's activism (while the company grew organically) it wasn't now clear if that would continue to be the case. Certainly the profits would no longer be used directly by Roy but we were all concerned about what may change.

As the soul searching continued for days and weeks the thought that kept coming back to me was that these people (Apax) aren't stupid. They know that the company has no assets, nothing of intrinsic value to strip. The continuing success of the company relies entirely on keeping the people it currently has and in order to keep those people the company cannot materially change its outlook or its culture. Ergo, my reasoning went, things should not change. Sure, they might alter some management structures, sure they might use their network to introduce potential new clients at a level of executive sponsorship that we may not have been able to achieve previously but surely wholesale change cannot be on the cards.

The ThoughtWorks Salary (anti)Premium

ThoughtWorks traditionally did not pay the best wages. When I started at ThoughtWorks back in 2015 not only was my salary lower than the role I left but it was considerably lower than at least one other job offer that I had at the time. But I wanted to work for ThoughtWorks. And while you work at ThoughtWorks you know that you could leave the company and enjoy a payrise but you are happy to get paid less because of all the great reasons for working at the company. 

In the two years since the takeover they were largely true to their word and nothing major changed. Indeed the changes were in some cases so subtle, and often superficially beneficial to the overall business, that their significance was lost on ThoughtWorkers who had joined post takeover. However, those of us that had been around for any length of time saw these changes creeping in inexorably and understood very well the ramifications of some of them. It would be wrong of me to point to anything specific in this post and indeed, I would still argue that it is a fantastic place to work and I was very sad to leave. 

The best way I can rationalise my decision to leave, therefore, is by saying that each time something seemingly insignificant changed, the gap between what I could earn outside of ThoughtWorks and what I was prepared to accept as a fair wage within ThoughtWorks narrowed. Unfortunately there was no corresponding narrowing of the gap between my actual earnings and the outside world so eventually I reached a tipping point, I'm not sure exactly when that was, but at some point I felt that I was no longer prepared to pay the premium being demanded.

Conclusion

ThoughtWorks is still a fantastic place to work. I still recommend it to anybody that asks. I continued to speak very highly of ThoughtWorks at conferences even as I knew I was falling out of love and jilting it, and will continue to do so. The danger it is facing is, I think, existential, and the management of the company (at least in the UK) is in danger of sleepwalking in to a situation where sufficient numbers of tenured ThoughtWorkers leave the company so that the culture is irreparably damaged. I hope that doesn't happen and I hope the danger is understood and dealt with by the leadership teams because I think it would be a crying shame if ThoughWorks were either cease to exist or if it changes to the extent that it is unrecognisable from everything that has made it great.

Four Years of Reading Stuff

Before Summer 2015

In the last 4 or 5 years that I worked for a startup I fell out of love with technology and learning in general. This was mainly because I came to hate my job. I saw it as a means to paying the mortgage and nothing more. There are many reasons why I got to that state of mind which I won't go into here. A big side effect of this state of mind was that I read virtually no non-fiction books. Looking back on that period of my life, this is the only time that I let myself get into a state of mind where I wasn't acquiring new knowledge.

I would have to ask for the smallest sums of money for a book that I may think I need. It would only get approved grudgingly and definitely only if it was seen to be directly relevant to something that we were doing to earn the company money. General learning and improvement was allegedly encouraged but in reality it was strictly in your own time. I remember even having to take a day off work to go to a training day to learn about a technology that we were trying to roll out.

Starting a New Life

So when I started as a consultant the genuine culture of learning that I found was fantastic. In my first few days in the job, sitting on the beach (other consultants call it the bench) talking to random people, it felt like I learnt more than I'd learnt in the previous 5 years put together. I was told that I had a budget to use for training and if I wanted to buy a book to read, provided it could be liked to any kind of learning that I wanted to undertake, it was fine. As far as I know, nobody ever really audited what books you bought. The result of that was that nobody abused the system, everybody bought stuff they wanted to learn about and virtually all learning was considered valuable to our work as consultants. So I started to read again and I haven't stopped yet. 

Many new starters and graduates asked me for book recommendations and from time to time I produced a list of everything I had bought and read (or sometimes given up on) during my time. I always found it good fun to go through my list of purchases on Amazon and give a one line review of that book. I updated my list from time to time and provided it to anybody that asked. Unfortunately I forgot to export that list when I left ThoughtWorks so I decided to write it up here to share with anybody who might be interested.

Four Years of Reading (or not)

Here is a list of all the books I bought in my first four years working as a consultant in a true learning culture...

The Innovators Dilemma

The Innovator's Dilemma is a business classic. It explains how seemingly established and well run companies can be very quickly put out of business by not being nimble enough to react to innovations in their business space. It has detailed case studies of the mechanical digger industry in the middle part of the 20th century and the hard disk industry from the second half of the 20th century as well as some examples of specific companies. Corporate failures following the innovator's dilemma pattern, and therefore validating the theory, since this book was originally written in the 1997 include Kodak and Blockbuster Video. This book is a must read for everybody interested in how modern businesses should deal with innovation in their industries.

The Whitehall Effect

The Whitehall Effect is a study of how public sector industries the world over fail to deliver value to the tax payers they serve. There are many reasons why this can happen but the patterns of failure are repeated all over the world with depressing regularity. This book is a must read for anybody who may be planning on consulting into the public sector.

Creating and Delivering Your Value Proposition: Managing Customer Experience for Profit

I bought this book just before I was due to start work on my first big gig at ThoughtWorks. In particular I wanted to understand a bit more about what outcomes we might be driving towards in the inception. It was a good easy read with some high level concepts about what a value proposition is and how to help shape it. 

Release it! Michael T Nygard

This book is a MUST read for all software developers. It is easy to read with some great (slightly dramatised) descriptions of real incidents that happened to the author to kick off each chapter. This is essential reading to get a feel for what it means to be production ready and what it means to embrace a devops culture.

The Hacker Playbook

A massive disappointment. I wanted a book to give me some pointers on app sec concepts and this sounded like it would. In fact, when I tried to read it (I had to give up halfway through) it felt like it had good messages but that it had been edited by two blokes in a pub at the end of an all day session. Avoid this one.

The Innovator's Solution

The follow up to the Innovator's Dilemma, first published in 2003. This describes how the author worked with some massive companies after the publication of the first book and helped them avoid falling foul of the innovator's dilemma. If you read the dilemma, you should read the solution.

The Evolution of Useful Things

This one was a fun read. I saw it on Amazon marketplace for 1p and it sounded interesting. If you're interested in product design, try and find a copy (I think it may be out of print).

AWS Scripted

This is an early book about writing infrastructure as code specifically around the AWS SDKs. I'm not sure if it would still be in print but I'd say it is obsolete now anyway.

The Linux Command Line

I bought this one because I wanted to learn Linux. I worked through some of the early chapters when I was on holiday one time but never managed to finish it. It was pretty easy to read but actual work got in the way of me finishing it. If you want to learn about the Linux Command Line from beginner level it is OK.

The Chimp Paradox

This is a pretty famous book about psychology written by Steve Peters who has worked with many elite sports teams and individuals. If you're interested in why we do seemingly irrational stuff at times and possibly how to attempt to control your own irrationality, this is a very good and very readable book.

Difficult Conversations

This is a good book about how to approach difficult conversations. I found this hugely useful as a consultant and for advice on how to tackle difficult conversations with friends and family.

The New One Minute Manager

Very easy to read, very quick to read (I read it in a single short plane journey) short description of how to be a non-micro-managing, non overbearing manager. If I remember rightly the message I took from it was that managers should not be managers so much as facilitators and advisers.

Clojure for the Brave and True

I wanted to learn Clojure and this was recommended to me. It is a good learning tool with nice exercises and some humour (which eventually grates a bit) thrown in. It does make a good effort at explaining the philosophy of Clojure rather than just the nuts and bolts of do this, do that. If you are want to learn Clojure I would recommend it. There is an online version of this book that is available free although, from memory, there are reminders throughout that they would like you to buy the actual book.

Land of Lisp

I bough Land of Lisp at the same time as the Clojure book but I never got round to reading it.

Drive by Professor Daniel Pink

This book is a must read. Pink spent a lot of time investigating what motivates us to work. His conclusions were counter intuitive and controversial at the time. As a consultant reading this book made me realise that I had to understand people's motivations, hopes and fears in order to understand how better to help the organisation move forward. I realised that it isn't enough to put process in place, you have to link that thing that you are asking people to do to what motivates them to work. I thoroughly recommend this book to any consultant that has designs on being an influencer rather than just an implementor.

Javascript - The Good Parts

This one was recommended to me as a good book for learning Javascript but I've never got round to reading it.

The Pragmatic Programmer

This is a classic which, until I was going through my Amazon purchases writing this, I didn't realise I had. Thus, I haven't read it.

The Mythical Man Month

Another classic which contains some proto-Agile thinking and some explanations why traditional project management thinking doesn't work with software delivery. It is amazing that such "traditional" methodologies still exist. Everybody working in software delivery should read this.

Also the source of a classic Twitter gag that loads of people have recycled and repurposed down the years. No idea if the one I've linked to is the original or not. It was just high up the list when I Googled it.

Continuous Delivery

This is Jez Humble's manual on how to do continuous delivery. I would hope that for experienced engineers that this serves as a reference book on how to do things right. For consultants trying to get our clients to a better place this book is a useful thing to have lying around at the client site to encourage people in the right direction. For any grads or apprentices who are great at writing software but lack experience on how to execute software delivery this is an absolute must read.

Working Effectively with Legacy Code

This is a must read for anybody working on a project that is based around legacy integrations or any organisation that has tons of legacy. The definition of legacy is interesting. Feathers tells us that legacy is anything without tests, the age of the technology is irrelevant. Basically this book is great and everybody should read it.

The Elements of Computing Systems

This was recommended by a colleague when we were in the pub once discussing hardware architectures. As I write this I realise I bought the Kindle edition but it somehow isn't on my Kindle. I just downloaded it and discovered I've read the first chapter only. Must do better...

The Phoenix Project

This is a famous Agile Parable. I had actually read this several years earlier when somebody bought it for me for my birthday. I include this in this list because I bought a number of copies to hand out to the client developers at the place I was working after a talk I was giving on Agile principals. If you haven't read this, you should. It is a description of an Agile Transformation squashed into an unfeasibly short time frame to help the narrative of the story. Read with a pinch of salt on the timeframes but not on the lessons contained.

The Goal

Eli Goldratt's famous novella explaining the Theory of Constraints. Similar to the Phoenix Project in style (although published much earlier), it can be regarded as a parable of Lean manufacturing. It is very easy to read and has many valuable lessons about why we do things the way we do in Agile delivery.

It's Not Luck

The sequel to the Goal follows the same character as he is promoted and takes on responsibility for whole companies in the group rather than the single plant he had at the end of The Goal. There are valuable lessons in here on how to approach problems and how to reason towards solutions. The Socratic method is mentioned as a reasoning framework.

Conversations of Socrates

I wanted to read this because of references to it in the Goldratt books. I have only read the start of it and I found it hard to read because the test was too small. I have just rebought it on Kindle so that I can properly read it.

Toyota Production System

This is, straight from the horse's mouth, the description of how the TPS, which underpins much of modern Agile and Lean theory, came about and continued to evolve. It is a fairly short book and everybody needs to read it.

Socrates' Defence

This is a translation of Plato's (he was a disciple of Socrates) version of his time with Socrates. I bought this in paperback around the time that I was discovering that I can no longer comfortably read "real" books. I've just rebought on Kindle...

Socrates' Way

This is a bit more of a practical guide on how to apply the Socratic method. I did read some of this but then I couldn't find the book to continue.

Theory of Constraints

This is a more formalised, academic, treatment of the theory of constraints. I haven't read beyond the early chapters yet.

Godel, Escher, Bach: An Eternal Golden Braid

This is a great book by Douglas Hofstadter, the King of meta. I have read extracts from this from other sources and seen conference talks, including this one from my ex colleague Chris Ford, inspired by this thinking. Sadly the text in the edition I have is so small that it can only be read by ants using binoculars. I have thus utterly failed to read beyond the introduction of this one.

Presentation Patterns

I bought this because I was doing a lot of presentations for conferences and wanted to know if I was missing anything, doing stuff wrong or right. If you want some pointers on how to create and give presentations this is a good place to start. I recommend it.

Clean Code by Uncle Bob

If you haven't read this, you should. Simple as that.

The First 90 Days

Another one that was recommended to me that I bought in paperback before realising I can't read them anymore. 

Computing With Quantum Cats

This is the first book I bought on Quantum Computing when I was learning about it last year. It is easy to read and informative. I thoroughly recommend it.

Minds, Machines and the Multiverse

Another quantum computing book. This has a bit more practical detail on quantum computers. I used this as my reference point when I was working with a ThoughtWorks grad in Manchester on implementing Shor's Algorithm and the Quantum Fourier Transform. It is a good book for sure.

In Search of Schrodinger's Cat

From the same author, John Gribben, as Computing with Quantum Cats, this one is an explanation of the history of quantum physics. If you are serious about learning about quantum computers I suggest this as your starting point (before the above two). I eventually bought this when I realised that I needed a grounding in quantum mechanics in order to attempt to better understand quantum computing. Very readable and I thoroughly recommend it.

Accelerate

This book is great and pretty easy and quick to read. This is from the people who give us the State of Devops report and can be considered as an invaluable reference for transformation type work. The ThoughtWorks Tech Radar now has the 4 key metrics on it in Adopt, meaning that they believe that everybody should be using them. On the last ThoughtWorks gig I was involved in we were pushing for the client to start using the 4 key metrics as their only measures of progress and we were using the 24 capabilities outlined in the last chapter of the book as our tools for moving the needles on the 4 key metrics. This book is essential for any IT professional.

The Garden of Forking Paths

Not really a technology (or business) book. This is a collection of short stories translated from the original Spanish. I bought this because one of my quantum computing books recommended it as a thought provoking idea to help with reasoning with the Many Worlds Interpretation. It only cost £1 so why not?

Mathematics for Quantum Mechanics

I bought this one when I was first attempting to write a quantum simulator and therefore needed to understand the maths better. It is hard going, the typeface is scratchy (it is quite old) and hard to read and the material is dull without enough contextual explanation. Avoid it, read the next one instead.

Quantum Mechanics, the Theoretical Minimum

I bought this at the same time as the one above. It does a much better job. Still pretty hard going with some fairly advanced maths but much more readable.

The Beginning of Infinity by David Deutsch

I bought this expecting a book on quantum physics or quantum computing. Instead I got a brilliant thought provoking book about philosophy, epistemology and various other things into the bargain. It also helped me to form my theory of studying organisations through organisational memes (after I had also read the Selfish Gene). I'm not sure if it is directly relevant to our work as consultants but I thoroughly recommend it as a book.

The Fabric of Reality

The much more famous book by David Deutsch. If you are interested in BIG subjects then this is a great read. Again, not much in here directly relevant to our work but certainly worth reading.

Enterprise Agility

This is written by one of my ex colleagues at ThoughtWorks. It is a great reference on why organisational agility matters, why we shouldn't be happy to just consider Agile as a methodology to help with software delivery and what it means to be agile (small 'a') in the modern business. I read this when I was first doing my talk Agile is a Dirty Word and most of the content was highly resonant to me as a consultant mainly working in transformational roles. I guess that shouldn't have been much of a surprise given the author was a colleague.

Bullshit Jobs: a Theory

I have long believed that organisations invent jobs to keep people employed. Large organisations evolve teams that add no value but have a sense of self preservation and survival. This book was recommended to me by somebody in a pub once when we were discussing this issue. It is easy to read and contains quite a bit of ironic humour that is right up my personal street. If you are interested in understanding where organisational dysfunction comes from, I recommend this one.

Evolutionary Architecture

Written by three of my ThoughtWorks ex colleagues, this book is a must read for anybody with responsibility over any large system. The main takeaway I got from it was the methodology, fitness functions, of actually measuring the effectiveness of your architectural decisions through their effect on those numbers. This book and Accelerate formed the basis of much of my thinking in the conclusions to my talk on Architects and Architecture that I first gave at Devoxx Poland in June 2019 (no video yet posted at the time of writing this). Everybody should read this.

Surely You're Joking Mr Feynman

I bought this because it was written by the famous physicist Richard Feynman and I thought it was a popular science book. Actually it is more of an autobiography in the form of several anecdotes and short stories of periods of Feynman's life. It was hugely entertaining and I recommend it. Absolutely nothing to do with our work though.

New Theories of Everything

A popular science / cosmology book. If you like A Brief History of Time and its ilk, you'll probably like this. I enjoyed reading it.

The Selfish Gene

Richard Dawkins' book propounding his new (when he wrote it 40 years ago) theory of evolution placing the gene as the unit of reproduction, not the organism that carries it. A thought provoking read that I was directed toward by reading The Beginning of Infinity by Deutsch. I used ideas in this book and in Deutsch' book to form my conjectures around organisational memes and how they can evolve into long lived pointless activity that we sometimes characterise as Risk Management Theatre. I haven't yet developed that theory far enough to write about it. It is a great read and I thoroughly recommend it although I'd struggle to link it to our day to work.

Joy Inc

Joy Inc is a book about building a workplace that people enjoy working in. It reads a bit like an Agile case study, a bit like a cautionary tale of badly managed businesses and a bit like an advert for the author's company. It is well worth a read and I recommend all people who are trying to get traction for Agile thinking should read this and recommend it to sceptics.

Infrastructure as Code

Written by a good friend of mine and ex colleague, Kief Morris, this is the de facto standard book on Infrastructure as Code. If you haven't read it and you are, or will be, working in a team that is responsible for infrastructure, then read it. Definitely a must read.

Reinventing Organisations

This was recommended to me by Steve Lydford, head of PS at Codurance, when I first spoke to him on the phone before I came here for an interview. The book examines various types of organisations from early human civilisations up to modern businesses. It proposes a new type of organisation a Teal organisation, in which there is no set hierarchy and units self organise. There are several strong case studies throughout the book and it is packed with anecdotes explaining aspects of the theory throughout. I really enjoyed this and I thoroughly recommend it. In terms of our business context as consultants I felt myself mapping a lot of the organisational principals to Agile principals and I felt like I've seen many of these things happening but generally only within an IT function, not a whole business. This book effectively argues that such ideas shouldn't stop in technology but should be allowed to permeate everywhere.

The Theoretical Minimum

From the same author as one of the quantum books I'm reading. An explanation of classical physics. Haven't read it yet.

Special Relativity and Classic Field Theory

Again from the theoretical minimum series. Again, haven't read it yet.

The Software Craftsman

And finally, the last book I expensed to ThoughtWorks was ironically written by Sandro Mancuso of Codurance. After I interviewed here and met Sandro I thought I'd read Sandro's book. I'm pleased to say I thought it was excellent. If you work for Coduracnce, you'll have been given a copy of this book. If you don't work for Codurance I recommend you read it.

On Leaving ThoughtWorks

Back in 2015...

Back in 2015 I was looking for a job having been made redundant from my previous job at Viagogo.com. Fortunately, I was left pretty well off financially from the redundancy, having worked there for 9 years, so I wasn't under any kind of immediate pressure to find a job. I had, to my recollection, about 4 months' of runway before we'd struggle to pay any bills so it felt like plenty of time.

There were two important side effects of that runway. Firstly, I could afford to be choosy about what to accept and secondly I could afford to go to some interviews just to get interview practice. It was a long time since I had looked for a job previously and the world had changed a lot between 2005 and 2015. In the end the runway worked out well for me. I was able to delay the time I went to the interviews at ThoughtWorks until after I'd had plenty of practice and I was also able to understand by then a bit better about where I might stand in the marketplace.

Where I was left behind

The previous time that I had searched for a job you handed out paper CVs or emailed them to people and they got passed on. There was no expectation for anything else. Some people blogged back then but it wasn't a massive thing. In many circles it felt like a bit of a self indulgent thing to write online articles that few people read. If you weren't Martin Fowler or Uncle Bob, why would you waste time writing for your audience of very few?

But in 2015 a recruiter friend of mine asked me to update my CV with details of my online presence. "Online Presents?" I asked. What does this mean? So she explained that I needed to include my LinkedIn contact details, my Twitter handle, the URL to my website (or blog) and my Github. The only problem with that was that I had none of those things, except the Twitter handle, and I wasn't really keen on sharing that as I had only used it up until that point to moan about stuff that I came across in life. Quite simply I had no online presence remotely related to my job as a technologist.

Somehow, though, despite this lack of a modern CV ThoughtWorks did offer me a job and I spent a very happy 4 years working there until last Friday. I took onboard the notion of having an online presence and one of the first things I did was to buy my name as a domain and set this blog up on that domain. It took me nearly 3 months to do (I think I was busy learning new things) but eventually my first post, Becoming a ThoughtWorker went live in September 2015. I also signed up to LinkedIn (which made it a log easier to find a job this time round) and signed up to Github, although only when I started experimenting with quantum computing did I put anything at all worth looking at on there.

Moving on in 2019

In my 4 years at ThoughtWorks I learnt more than the whole of the rest of my working life put together. I learnt at least 5 new programming languages, I got a wealth of experience working in different environments in various stages of dysfunction, I met dozens of fantastic people that I hope will remain my friends (I actually tried to enumerate them all but I realised I was missing people out and I gave up when my list got to about 130) and above all, for the first time in at least 10 years, I really enjoyed work. For the first time in my life I realised that getting paid for work is but a small part of the reward we should be looking to get from our work, provided we are lucky enough to work in an industry, at a level of seniority,'' that means that we earn "enough", whatever that means.

At some point though, you realise that you need another challenge. ThoughtWorks was by far the best job I've ever had but I got to a stage, probably last year sometime, when I realised I was finding it hard to always get the kind of the work that I really enjoyed. So I started to look around to see if there was anything out there that might help me to enjoy my working life even more than I was doing at ThoughtWorks. I must stress that at no point did I find the work frustrating or boring or unfulfilling. I just felt that I would like to have just a little more influence on the bigger picture. That was never going to happen in ThoughtWorks with it being the size that it is.

As a member of PS at ThoughtWorks, I was only ever peripherally involved with helping to sell our services. I did enquire some time ago as to whether there were openings in our sales effort for technical people to work in a sales support capacity but at the time our sales effort in the UK was being restructured and I was heavily warned by senior ThoughtWorks people to not go "post technical". I did help put together pitches from time to time when I was on the beach and I did get to attend some presentations but it was never more than an occasional, very ad hoc, who's on the beach today, kind of thing.

So I looked around for what the job market had to offer and the big difference between 2015 and 2019 was that I had an online presence. Not only do I have a passable blog site with some reasonable content (if feedback is anything to go by) but since autumn 2017 I've been a pretty regular speaker on the technology conference circuit which means there are a load of videos online of me expressing my opinions and sharing what I've learned from being a ThoughtWorker. The latter thing in particular opened many doors for me and I on a few occasions, interviews started with me being told by somebody that they had watched one of my videos. So all that online presence stuff really works!

Where Next?

So after my time at ThoughtWorks I spoke to a few different places, found some interesting stuff, some not so interesting stuff, found as many bad interviews this time around as last time and eventually realised that the thing I really wanted to do was to work in consultancy but at a much smaller place than ThoughtWorks. So today, I started as a principal craftsperson at Codurance. I'm hoping to still do all of the stuff I loved doing at ThoughtWorks but hopefully some of the stuff that I wanted to do and never got the chance. So in other words, and hugely optimistically, I want to have my cake and eat it. Hopefully that will happen, no doubt I will be posting a blog entitled "Becoming a Craftsperson" in a few months' time.