Recommendations on AI or Blockachain

Zoe on 2025-02-05

The target audience is adults with limited technical knowledge working in the business/financial sector.

A few general recommendations that cover both fairly regularly: patio11‘s Complex Systems and Bits about Money and Patrick Boyle

Artificial Intelligence

Advances in Financial Machine Learning (summary) is the go-to book for finance, but it is technical and will require a background in Artificial Intelligence. I’d start by Learning how AI works from a real LLM implemented entirely in Excel, maybe following up with Artificial Intelligence for Beginners. AI is a large subject. You can start by looking at Generative AI, Deep Learning for Finance and AI for time series.

The State of AI Report is worth a look for an overview of where things are, as is The Gradient for some current work being done.

Blockchain

I made a post about blockchain years ago aimed more at software engineers. Last Week Tonight with John Oliver is still my go-to link for anyone new to blockchain. They have since made a follow-up episode.

I’d start with Money in the Twenty-First Century. It is a short and easy read that gives a good overview of the landscape. A couple of other takes on the same area Web3 in Financial Services and From Hoodies to Suits. Two different views of blockchain: The Politics of Bitcoin and Check Your Financial Privilege. Central banks are also looking at this area. The Bank of England is looking at a digital pound and BIS has some notes on cryptoasset.

On-call

Zoe on 2023-09-19

Leigh asked:

Anyone read or have any good advice for organising out of hours cover for small dev teams managing their own services? E.G. how to fairly compensate for overtime, organise rotas, manage escalation of issues, etc?

Read More about On-call

Combining an LLM and a Rules-based Chatbot

Zoe on 2023-08-30

A rules-based chatbot allows for rapid development. Adding rules as you go, some of which can contain complex logic. Rules-based systems do not use large amounts of computation and especially don’t require GPUs, cheaper running costs and more responsive replies. As powerful as rules-based chatbots are, they also come with downsides. Creating rules is time-consuming and challenging to cover all the scenarios. The rules files quickly become quite large and cumbersome. Workarounds such as having a final catch-all rule can somewhat mitigate this.

Read More about Combining an LLM and a Rules-based Chatbot

Chatbots

Zoe on 2023-08-29

I’ve been working on chatbots on and off for a while now. The other day, I received a question about how I built the latest Chatbot.

“I love the Chatbot, and it has been something I’ve been trying to replicate. There is so much noise. I’m finding it hard to find a good solution. I’d be grateful if you could point me in any direction, tools or what to search for.” 

I had always intended to write about it. The scope may have expanded a little since then into a short series. This post covers some background on chatbots, a few principles for conversational interfaces and building a basic chatbot.

Read More about Chatbots

Language choices

Zoe on 2022-09-21

Very much a part two of ‘Mistakes I’ve made in my career (so far)’

The Question

My Experience

I am expanding on my Twitter thread.

At a previous start-up. Greenfield project. New team. We got started with building version one. We began as a free for all. The mindset was the best tool for the job. Resulting in every service being in a different language. Node, Go, Haskell, Python.

For the MVP, everything was in containers, so deploying and running the system was not that bad. Maybe a little too complex for the features we had but nothing too horrible. Engineers worked on the same service most of the time. No one was switching back and forth between services. Maintenance or anything post-demo got zero thought. We needed to ship sometime that vaguely worked.

Post MVP. Maintenance was a problem; only certain people could work on certain services. Hiring was the other major problem and ultimately forced the issue. No one knew all those languages. Even people that knew two or three of them were not at the same level in all the languages. Mentally switching between different languages is tiring.  

We took the difficult decision to standardise on Go. The largest and most active service used that. Everyone on the project would work in Go at least sometimes. We still had some other languages but only for specific uses. For example, python for data science tasks, but the default was Go for everything. We took the hit of rewriting services not already in Go over time. In the end, it cost a couple of months to get back to where we were for the MVP.

I do not think anyone thought the MVP code would survive long-term. I certainly did not. We were always going to rewrite, expand the services and remove all the last-minute fixes we needed to get the project out the door. If those services had already been in Go, that would have been an incremental refactoring process. We would always build a shippable version of the project. Instead, we broke everything and could not ship anything for what seemed like aeons. in start-up time. We were lucky and only needed to demonstrate the project on one or two occasions. Each time was a painful experience until we had finished the rewrite.

Hiring was more focused. We had less of a laundry list of skills and languages—this ultimately allowed us to hire some junior engineers. You can not expect someone at the start of their career to be able to write production code in three or four languages. Maintenance was more manageable with only a single language. Everyone in engineering could help each other. The general quality of code went up.

Painful lesson learnt.

At my current place we started off standardising on Node. Not because it is my favourite language but because the centre of gravity in the project is around Node. The same with yarn.

Cold Calling

Zoe on 2022-09-12

“Be good to hear your thoughts on something I think could benefit you – can you spare a minute?”

I get a regular stream of messages like this, sometimes multiple ones a day. The text provided zero context. About the only thing I learn is some random person I don’t know wants to have a call with me. A half an hour call isn’t only half an hour of my time. I need to read your material to prepare questions. Check the service is relevant to the company.

I know times are tough. Running a business is challenging at the best of times. These aren’t the best of times. Cold calling is hard. Messaging many people hoping a few will say yes, has got to be pretty soul-destroying work. Low effort, one-line, no-context messages don’t put me in the best mood if I reply to you. Block, report as spam and move on seems a more straightforward response.

Seeing generic messages like these are so frustrating. I’m an optimist. Anyone that starts a business is worth celebrating. I want you to be more successful. I know you can do better.

I’m going to look at your message and ask a few questions:

Is your product relevant to the company? Have a quick look at the company’s website to check we are the correct type of company for your product. if we are in the wrong area or have no use for your services. Messaging wastes your and my time.

Will your product save time or money? Tell the story of how you will make my life simpler. I’m always interested in hearing about that.

How can I get an overview of your product? Give me a one-page summary of what you offer as an attachment or a link to a landing page. Make it easy for me to see the value you can provide.

Resources for New Managers

Zoe on 2021-02-04

Expanding on this comment. So you switched from building things to management. Read these to understand your new role:

Here are a few resources I found useful when making that switch.

Newsletters

Blogs

(Both for newsletters and blogs. RSS is your friend to help keep on top of things. I use Feedbin)

Conference

Books

Community

Other Resources

More Links