Mohamed Yousif

This is a deep dive in payment for developers. The purpose of this rather lengthy article is to show in a very simple way how payment works, while always relating and linking it to the overal progress in technology: servers and security. Fintech and payment is my personal passion and for many years I have been working with teams, business people, tech founders, banks, regulators, international companies and I feel I have a thing or two to help developers with. It is also intended for this guidline to work particularly well for backend and servers developers since I believe majority of complexity lies in there. You will see lots of graphs and I’d highly recommend you to click on them to enlarge them and look at them thoroughly. I have came to realize, personally, sometimes a picture is worth a thousand words. Another angle that this article is trying to push for is “learning by example”. We are following a practical approach with less focus on jargons and theory, and more on the whys and hows. Working with noebs, an open source payment gateway has also left us with a solid open source foundation and ready codebases that curious developers can tap into for even more practical examples. The intention was never to write a book, that would never be possible for my time and resources. Another consideration (reads big catch) is that I deliberately dropped citation and referneces. Usually that is a big red flag, but in my defence I was eager to get a first publishable draft out of my way; and with the advent of chatbots and AI, it became practically trivial to throw in the whole text to any free chatgpt-ish service and ask it for resources. But mostly it was for my personal convenience: listing and citing resources would have added a considerable burden on me that I just was not able to do. Lastly, I wrote this preface after I finished a draft version of this article, so there’s that. ...

I have been writing and documenting my ai usage here in couple of posts. Some patterns are emerging, for example I find great usage of AI in computer usage. That is, using AI to do things that I would have done manually. A clear example from the last month or so. I have a personal app that I use to stream some media I own. I used codex to spin up a VM build a stremio-recongnizable endpoint which feeds my media to stremio of which I can watch in the TV. I have done that in any afternoon where I was attending to other family matters. The code is nodejs which was odd to me (why would my agent pick this?) but I was not really interested much in checking what the code does (this is not a financial system and I have no risk here). I run it by chatgpt and asked it to spot any security issues and that was it. Doing this exercise by myself is still possible. I know exactly what I need to do: just implement x APIs, read from that source and process data in some format and pass on those links to the other source. But I’d have most likely churned halfway through that (and most definitely wouldn’t had spent time with family). ...

Some bugs haunt you somewhere in the future. Majority of them comes from technical debts. I.e. something you or your clanker must have overlooked or underestimated it at the moment, and we know how that ends. It can come as a late night production incident, or via product request in what you hoped to be a quiet sprint planning. I want to mention the bugs that dies with time though and I have particular story to tell. We have this system where it has a sliding window. In essence, some data will just be invalid after n period of time. The bug was in the data but it was not too devstating as the system would work but not in the “business preferred branch”. The engineering effort to fix this would be manageable to fix this issue. But what if we did not do anything? Well, it turns out one can just sleep on this bug and let it turn itself into a feature n months later.

I use ai to ask stupid questions that I’m (was) too ashamed to ask in a stackoverflow. I remember during my graduation year and while picking up my thesis I asked a question on stackechange (either math or physics). And boy I truly had some balls back then. Now with ai I spend more time igniting my curiosity. Asking silly questions, trying things out and exploring domains that I was rather unfamiliar was (and it has high churn to do them manually). I also use the chat sessions quite heavily when coding. The old savage way of copying code manually from here to there and back. I reckon this helps me get the best of AI, and hopefully avoiding the bad stuff.

I remember a conversation I had with a friend 8 years ago. Our CVs almost started to have some entries as we were substituting hoppies “i like to walk and play football” with 3 months internship at some company where i learned to work under stress and tight deadlines. I was arguing that coding is my virtue in and on itself. And that being a project manager or any manager for that matter is not better. Perhaps we didn’t define the definition of “better” here as that would had untangled the argument. My friend’s argument retrospectily now was rather more mature. He said something along the lines of you cannot just be a developer in order to grow you need to be a PM or a Manager. You cannot continue be just a coder. That part struct me the hardest, because I never wanted to not write a code. That is my dream to continue work at coding. Coincidentally another friend (developer as well) from my circle of whom i admired a lot – she also “jumped” to a business role. Life is strange also. Since then i had went through roles where the business expectations for me was usually those you would expect of a manager. I had my nice share of failures too but in many cases being a strong on the technical side helped my bosses to ignore my lack of management skills. ...

One of the things i remember early from my early childhood is the concept of throwing a joke. The act of throwing a joke for a kid (myself) didn’t come off naturally. I had to try and learn it. I think jokes are quite sophisticated to manufacture. They require creativity, making things up, subtleity in tones, some narration as well. Doing an impression is even a higher complex tier there. I remember i decided one day that I’m going to teach myself to throw jokes. ...

World is a crazy place. Back in 2023 I witnessed the military build up around Khartoum (in fact, around my office and close to where i lived). I thought it would be just a bluff. The bluff is still there 3 years later. 2 months ago the situation was more or less repeating itself in GCC and even though this time more than before I can tell that “quick adventure in and out” is never really so

Probably you have read that a lot. This is not e/acc and nor is it a 9/9/6. The best developer i know is 9-5. But he is there when needed and he truly and deeply cares about his craft. He takes good pride in his work. You need to be that. You gotta give a shit about what you are effectively spending your most useful time on. Otherwise, what does really matter? You cannot half-ass your way through your tasks. I mean, let’s zoom out a bit: an organization where no one gives a shit is doomed to fail. An organization that people actually cares will have higher odds at succeeding. Because there are always those who care. ...

I have stopped writing since roughly 2023. In part because war had changed my perspective on things. But that perhaps for another article. The main reason though that I stopped writing was due to AI: I felt lack of originality and I also tend to em a lot. But here we are 2 3 years later after we were promised chatgpt and artificial general intelligence are bound to happen. The goal of this post, albeit of the bumpy start is about software the engineering part. I’d like to share some of the small things that usually you learn somehow but you rarely find them in a textbook. Or a youtube video. They are nonetheless pre-requisites and everyone just assumes you have prior knowledge. ...

Designing a software program that can work efficiently very well, and testable in that new features and enhancements can be added to it is a bit of work. The way I approach can often be labeled as a lazy or naive way. That is a fair statement. I believe a good design is the simple one. A simple design is iterative in its nature, always assume that your first version of your program is a beta one. Even if your program was the best, it might not meet the expected requirements, or the requirements might have just changed. ...