Life in Octarnal,written from insideit

Octarnal is small enough that the org chart is just a list of names. Muntahi founded it and still does the thing founders of small studios do, which is everything — he will pitch a client in the morning, redraw a landing page at night, and be the one who says ship it when the rest of us are still polishing. Sagor collects problems; he is the co-founder who hears a client describe their week and comes back with the actual product hiding inside the complaint.

Fahim is the CTO, and if something has to run at scale it runs on his rules. He is the reason a schema conversation here takes two hours and a migration takes none. Meraz owns everything between a merge and a user seeing it — clouds, pipelines, the alerts that go off at inconvenient times. Mahfuz is the newest on the frontend and improving faster than anyone else in the building, which is both inspiring and a little rude.

That leaves me, somewhere in the middle of the stack, usually arguing that we should refactor this one more time. Six people is small enough that nobody can hide and large enough that nobody has to do everything. It is, as far as I can tell, the whole trick.

The first thing that surprised me was how little gets approved and how much gets argued. There is no stage where a senior signs off on your idea and you go build it. There is a stage where you say what you want to do and somebody asks why, and you either have an answer or you discover you do not.

That sounds exhausting and it is, for about a month. Then it becomes the most useful habit in the building. An argument you lose in a Slack thread costs twenty minutes. The same argument lost in production costs a weekend. Fahim is especially good at this — he will not tell you your schema is wrong, he will ask what happens when a record is deleted and let you find it yourself.

The rule that makes it work is that the argument ends. Somebody decides, the decision gets written down, and the person who lost it implements it properly rather than sulking in the code. A studio this size cannot afford a half-committed implementation of something nobody believes in.

I came in expecting a queue. What I got was a problem description and a question about how I planned to approach it. The difference is enormous and it took me a while to appreciate it.

A ticket tells you what to build. A problem tells you what is wrong and leaves the what-to-build to you, which means you get it wrong a few times in front of people who have the context to tell you why. That is uncomfortable and it is also the only way I know of to actually learn a system rather than learn its file structure.

The cost is senior time, and it is real. Fahim and Muntahi spend hours a week on conversations that would be faster if they just told us the answer. They do it anyway, because a studio that trades that time for short-term velocity ends up with no seniors in five years, and a six-person team cannot absorb that.

I should be specific about my own case, because it is the only one I can report honestly. I had written a lot of code and shipped none of it to anybody. No review had ever rejected my work. No incident had ever been my fault. I had never had to explain a decision to a person who was paying for it.

The first thing the studio did was refuse to protect me from any of that. My second week I was asked how I would approach a problem, I gave an answer, and Fahim asked what happens when two people do it at once. I did not have an answer. Nobody filled the silence for me. I went and found one, got it wrong, came back, and we went around again. That loop — say it, be questioned, go away, return — is most of what the last year has been, and it is the only reason I can now read a diff and have an opinion about it.

The second thing was being made to write. Before anything non-trivial I have to put down what it must guarantee, what it must refuse, and what it deliberately does not handle. I resented this for about two months. Then I noticed that half the time I discovered the design was wrong while writing the page, before anybody had to tell me, which is a much cheaper way to be wrong.

The third thing was being allowed to break things. I have shipped bugs here. The response has never once been about blame; it has been what did we not have in place that would have caught this, and then that thing gets built. That is a specific kind of safety and it is the only environment I know of where a beginner actually gets faster instead of more careful.

What I did not get was a syllabus. There is no onboarding track and no list of what to learn by month three. What there is instead is proximity — the people deciding things are in the same room, and nobody minds being asked why. For somebody starting at zero that turns out to be worth more than any curriculum, as long as you are willing to be the person who keeps asking.

The pattern I have just described is not unique to me, and that is the part worth reporting. Mahfuz came in at the same starting point on the frontend and has moved along the same curve. Neither of us got a mentor assigned, a reading list, or a protected ramp. We got work that mattered and people who would not let a vague answer stand.

What makes the curve steep is not talent and it is not hours. It is how quickly a wrong idea gets contradicted. In a large team a beginner can hold a bad mental model for months because nothing in their week collides with it. Here it collides on Tuesday, in front of someone who can explain exactly why, and the correction lands while the context is still in your head.

The studio pays for that deliberately. Fahim and Muntahi spend real hours on conversations that would be faster if they just handed us the answer, and they keep choosing not to. From the receiving end it is occasionally humbling and consistently the most valuable thing on offer here. Pairing came back for the same reason, and it has nothing to do with nostalgia — it is the only reliable way we have found to transfer judgement.

We are not all in the same place. Mahfuz works out of Barishal; the rest of us are in Dhaka. That means the default is asynchronous and written, and the exceptions are planned rather than accidental.

The practical version of this is simple. Anything that would need three messages becomes a call. Anything that would need a decision from somebody who is not online becomes a short written proposal with a default — here is what I am going to do unless somebody objects by tomorrow. Defaults are what keep a distributed team from stalling on consensus.

And the together part is not a social event, it is a working one. When a project is at the stage where the model is being argued about, we are in a room. After that, the room adds nothing a thread cannot do better.

This one is written down as a rule and I have watched it survive real pressure. When a page is slow, the first answer is never to remove the animation. It is to find out which of the four things on that page is actually costing the time, fix that, and report the real numbers afterwards.

It would be much easier to delete the motion and claim the win. The reason we do not is that the motion is usually the reason the client hired us, and a fast page nobody remembers is not a better outcome than a slightly heavier page that works. When the budget genuinely cannot be met without cutting the design, the honest move is to say so rather than quietly cut it.

I have come to think of this as the clearest expression of the studio's taste. Taste is mostly what you refuse to do when nobody would notice.

The most senior people in this building are the quickest to say they are not sure. Fahim will say he needs to check before answering a question about a database he has used for six years. Muntahi is routinely the least technical person in a room full of engineers and completely unbothered by it.

That does something to a junior. It removes the performance. If the CTO can say I do not know, I can say it in a review without it feeling like a confession, which means problems surface while they are still cheap. The opposite culture — where everyone has an instant confident answer — is how teams end up discovering in month six that nobody actually understood the integration.

I want to be honest about this part, because studio culture posts usually are not. A meaningful share of any week here is reading somebody else's code, chasing down why a thing worked on one machine, writing the paragraph that explains a decision so the next person does not have to re-derive it, and doing the fourth pass on something that was already fine.

None of that photographs well. All of it is the job. The interesting parts — the architecture conversation, the moment a messy flow finally becomes simple — are real and they are maybe a fifth of the time. The rest is care, applied repeatedly, to things nobody will ever thank you for.

If that sounds like a complaint, it is not. It is the thing I would want to know before joining.

Come if you want to be visible. In a team this size your work is attributable, which cuts both ways — a good decision gets noticed and so does a lazy one. Come if you would rather be asked a hard question than handed an easy answer. Come if you are willing to write things down, because nothing survives here that only exists in somebody's head.

Do not come expecting a ladder with rungs painted on it. There is no quarterly promotion cycle and no title that arrives on schedule. What there is, is a shorter distance between you and the decision than you will find anywhere larger — and if you want that distance, it is worth a lot.