Leaning to code

I have to say I am slightly impressed and pleased with my son's abilities in coding today.

He has been working on tools to have transaction details from Monzo, specifically to handle money loaned and repaid. I have written a load of C code behind the scenes for him to get the transaction data and run a script of his.

The fact Monzo have an API is great for this, and the real-time nature of the web hooks is even better. They lack an "update" web hook, but all in all it is pretty impressive.

Now, what struck me as insightful is a couple of questions James asked, and importantly he asked before he hit the problem caused by them!!!

1. He realised that if he happens to be set up to track Monzo accounts for both sides (him and his girlfriend), he will see the same transaction twice, and hence record the transaction twice, once from each side. But there are scenarios where he is not tracking both sides and so only sees it once. He needs to de-dup the transactions. I am impressed he realised this, and he has managed to find a reference in the transaction which is the same on both sides (a p2p transaction id). So he can de-dup that. He even worked out that matching by amount and parties and time is a really bad idea to de-dup this stuff.

2. He also realised that he might get the two sides of a transaction concurrently and so code that checks for it existing, and if it does not, goes on to add the transaction, could happen concurrently and add both. This can be solved in many ways from locking around the transaction handling script, to table locks in SQL, to unique keys on tables. But the fact he worked out it was a risk is excellent. So many people do not understand "real time" coding and race conditions, and he spotted this as an issue, and once again did so before it happened.

So, well done, my mini-me is growing up.