User Manual

Overview

• Backend engineer by day, educator by night. I build scalable systems at Pathao and teach data analysis and test automation at Nexxvali. My work sits at the intersection of reliable infrastructure and transferring knowledge to others.
• CS graduate from Ahsanullah University of Science and Technology, co-author of a research paper on misogyny detection in Bangla text, and occasional music composer. These things are more connected than they sound.

Strengths

• Breadth across the stack. I'm comfortable moving between backend development, test automation, data analysis, and teaching. My best work tends to happen where these overlap.
• Automation-first thinking. When I see a manual process, I immediately think about how to eliminate it. This applies to code, testing, deployments, and workflows.
• Teaching what I build. I've trained 200+ engineers and can take complex technical concepts and make them learnable. This makes me a better engineer — if you can't teach it clearly, you don't understand it well enough.
• Moving fast without breaking things. Speed compounds. I put heavy emphasis on iterating quickly while maintaining quality through solid testing practices.

Weaknesses

• Overextending. I get excited by a lot of things and spread myself too thin sometimes. If you see me taking on too much at once, tell me to focus.
• Context dependency. I need a holistic view to contribute meaningfully. When I don't have enough background on why something is being built, I struggle to make good decisions about how to build it.
• Perfectionism under pressure. I hold a high bar for output quality, which can slow me down when shipping speed matters more than polish. Working on calibrating this better.

Principles for Thinking

• Start from first principles. Question the assumptions. Just because something worked before or is the default doesn't mean it's the right call now.
• Writing is where clear thinking happens. Writing forces fuzzy ideas to sharpen. If you can't write it down clearly, you probably don't understand it well enough yet.
• Diverge before converging. Explore the space fully before committing. The best solutions often come from options you almost didn't consider.
• Separate signal from noise. Most information is noise. The skill is knowing what matters and ignoring the rest.
• Invert. Think about what could go wrong, what the opposite looks like, and what you'd need to believe for the other side to be right.

Principles for Working

• Bias towards action. Getting started is the best way to begin making progress and start learning. Avoid unchecked inaction.
• Document as you go. Good documentation isn't a tax on engineering work — it's part of the work. Future-you and your teammates will be grateful.
• Test at the right level. Unit tests, integration tests, and end-to-end tests each have their place. Knowing which level to test at matters as much as writing the tests.
• Attention to detail. The small things matter. Quality shows up in the details, and it's usually worth the extra effort to get them right.
• Feedback is a gift. Give it directly and receive it openly. The team gets better when everyone is honest with each other.

More Quirks

• Systems thinker. I naturally want to understand how all the pieces fit together. Sometimes I'll zoom out to make sure we're solving the right problem before diving into code.
• Music and code. I compose music outside of work. It's taught me a lot about structure, iteration, and the difference between technically correct and actually good.
• High bar. I can be hard on myself and the work. If I think we're not doing our best, I'll say so. It's never personal — I just care about the outcome.
• Async preferred. I do my best thinking in writing. I'd rather have a well-structured async thread than a meandering real-time meeting.

Favorite Quotes