Fourteen months of the same week

The hardest part of any week arrived at the same point in it.

A new algorithm would be explained, and it made sense while it was being explained. Then the first problem using it went up, and I sat in front of it with no idea where to begin.

I spent fourteen months in that gap, at A2SV — Africa to Silicon Valley, a US nonprofit that teaches software engineering to university students across Africa. Its required first year was data structures, algorithms, dynamic programming and competitive programming. I did it remotely with the sixth generation, from January 2025 to February 2026.

A friend at university had recommended it. He said it was one of the strongest programmes in Africa, and that it aimed at producing engineers who have the mindset rather than people who can write code. I said: why not. He never joined himself. He did not have the time.

The second reason I would not have written on the application. The programme ran in English, my English then was middling, and I did not like speaking it in front of people. None of that was the obstacle it looks like. It was the situation I needed to be put in. The phrase I used for it at the time was أرمي نفسي في البحر — throw myself into the sea.

The interview was in English

The interview had a problem-solving question in it, a relatively simple one. I solved it, then talked through the time and space complexity of what I had written.

The complexity is the part I would point at now, because it turned out to be the programme in miniature: not whether the thing runs, but what it costs to run. I had thought competitive programming meant contests, a set of problems you solve. It came to mean that last question, over and over.

I read the solution for one thing

It happened with the difficult algorithms, new to me or heard before and still hard, and knowing it was coming never made it smaller.

When I was stuck I tried again, repeatedly, and sometimes read somebody else's solution — but never only read it. I read it for one thing: the exact point where I had got stuck. Then I worked out how that person had thought, and wrote the implementation myself. Once I understood how the solution got past it, the rest usually came clear.

I stopped trying to picture the middle

The topic where that gap stayed open longest was dynamic programming, and the hard part of it was never the code. It was the picturing. The problem is built on something that repeats. I tried to hold the whole repetition in my head at once — every state, and how each connected to the one before it and the one after. There was too much of it, and the parts that were supposed to connect came apart while I looked at the next ones.

What got me out was giving that up.

Instead of imagining everything in the middle, I fixed the ends: where the state starts, where it stops, and what the base cases are — the states whose answer is known without computing anything. Those three are small, they fit on paper, and you can tell when you have them wrong.

Then the recurrence handles what is between them. It is a statement about one step: this state in terms of the states it depends on. If the step is right and the ends are right, the middle I could not picture is already accounted for. I never have to see it.

That reads like a shortcut and it is the opposite of one. The middle is not mine to imagine. It is the thing I have handed over.

Five sessions a week

Each week opened a new topic — DFS one week, BFS another — covered in theory first, then on easy problems, then on problems that stopped being easy. The last day, Friday or Saturday, was a Codeforces contest we all entered together. Four sessions on the topic, then a fixed set of problems and a clock. Nowhere for a half-understood idea to hide.

On some days the last ten or fifteen minutes were not technical at all. Everybody was paired with a random person from the programme, to talk. We joked, and sometimes played something online. It ran in English like the rest. It is the first thing a technical schedule drops for time. I had joined partly to be put in that position, and it came in the part of the week nobody was scoring.

The sessions were at night, which helped it sit beside a degree, an internship and a company. There was no method to the balance. A2SV was giving me enough that I was not prepared to drop it, and the price of keeping it was pushing myself harder to fit everything else around it. I joined some of them exhausted and treated the session as the most important thing I had to concentrate on.

What the cards say

Six times in 2025, A2SV published a Best Performer of the Week card with my name on it. Each carries four numbers. Attendance is out of five, which is what tells you the week had five sessions in it: 5/5 on four cards, 4/5 on the other two. The consistency strike is out of seven, so it is daily — 7/7 on five, 6/7 on one. Problems solved on their HUB ran from 15 to 26. Contest problems are out of six: 6/6 once, 5/6 three times, 4/6 twice.

Cards that name a week's best performer are a highlight by construction. Mine still contain two missed sessions, a broken daily strike, and two weeks where I solved four of the six contest problems.

Second, in a contest of A2SV's own groups

Both of the standings below are from A2SV's own contests, run on Codeforces as private contests among its groups. Mine was G6E.

In A2SV Remote G6 Contest #14 I finished second on the frozen standings, with six problems and a penalty of 339. First place also solved six, with 243, and third also six, with 377. The top three had all solved everything. What separated us was penalty time. In A2SV Remote Group Contest #2, with a teammate, we finished second with seven problems and a penalty of 404.

Second there means second in that contest, across those groups — not a position on Codeforces, though lifted out of its contest it would read as one. A number is a fact about the experiment it came from, including when it is mine.

The better moment is the one where I lose

The best part of it is the moment the solution arrives, and it is strongest after a problem has beaten me several times and I finally see the point that had been stopping me.

There is a better one, and it is the one where I lose. Reading a solution simpler and smarter than mine, and thinking: how did this person think of it that way?

Some people take it harder than that — angry at a problem, or wound tight over a contest. The competition by itself produces the drive to write the best code you can rather than the first code that runs. As far as I could see, the anger added nothing to it.

What changed in the code I write

Before this I could write code with one question in front of me: does it work? That question has an answer, the answer is eventually yes, and it is a small question. Now the first working version is where I start rather than where I stop. How long does this take? How much memory does it consume? Is it right, or only right on the cases I happened to try? Is there a simpler and faster route to the same result?

Two smaller things came with them. I trace execution in my head more clearly, so I reach a bug's likely position faster. And I can look at code and predict better whether it will be slow on a large input.

You need it to judge the job, not to do it

None of this is necessary for an AI engineer, not directly and not daily. That work is mostly with models that already exist, with libraries and ready-made tools. Building models from scratch, or optimising at that level, is where it would matter more.

It is not useless either, and there is one place where it stops being optional: code I did not write. A model will write you a great deal of it, and it runs. It is not always optimised, and it sometimes takes a long way round to something simpler. Telling which of those you are looking at needs the thing the year was spent on — complexity, structure, and a sense of what code will do when the input grows.

So the objection — I have AI write the code, so I do not need to learn this — has it the wrong way round. The case is not that you need this in order to do the job. It is that you need it in order to tell whether the job was done well. Otherwise the only test left is whether the thing ran, and running is a low bar that generated code clears constantly.

The half I cannot show in numbers

The engineering half of what I was there for I can show in numbers, with the caveats attached. The English half I cannot, and I will not invent a measurement for it. What I can say is that I joined partly because I did not like speaking a language in front of people, then spent fourteen months of nights doing exactly that. Asked now what the hardest part was, the English does not come to mind at all. The first problem after a new algorithm has been explained does.

The programme did not teach me to write code that works. I could do that in January 2025. It taught me to ask what the code costs, and to keep asking about code I did not write.