A production bug
Reported by a user, reproduced from a vague description, fixed without breaking three other things.
The engineering experience
What a week inside Barmaj actually looks like — the ceremonies, the work, and the parts nobody tells you about before your first role.
The engineering experience
One loop, run properly, over and over
This is not a syllabus. It is the loop a professional team runs every sprint, and you run it from the inside.
- 01
Backlog
Real work, written as tickets — bugs, features, debt.
- 02
Refinement
Read it, question it, find what the ticket does not say.
- 03
Planning poker
Estimate independently. Nobody sees a number before the reveal.
- 04
Sprint
A committed scope with a start and an end.
- 05
Development
A branch on your own fork of a codebase you did not write.
- 06
Pull request
Described well enough that a reviewer can start immediately.
- 07
Code review
A senior engineer responds within one business day.
- 08
Merge
It ships when it is right, not when you are finished.
- 09
Feedback
What you did well, what to change, and why.
- 10
Skill evidence
An attributed record, linked to the work that proves it.
Then it starts again, with a harder ticket.
Not tutorial projects
The work you have never been given
No blank folders. No finished specifications. No projects that exist only to be finished.
A legacy refactor
Code that works and nobody wants to touch. Change it without changing behaviour.
A feature request
Written by someone who is not an engineer, and missing the three details that matter.
A performance problem
Something got slow. Measure before you optimise, and prove it got faster.
Testing debt
A module with no tests and a history of regressions. Decide what is worth covering.
An architecture decision
Two reasonable options. Pick one, write down why, and defend it in review.
An incident simulation
Something is broken now. Diagnose under time pressure and communicate while you do.
Technical debt
A shortcut somebody took, and the argument about whether now is the time to pay it back.
Reviewing someone else
Reading code you did not write and finding the useful thing to say about it.
#128 · feature/retry-timeoutAdd retry to the payment client
Illustration of review style- Blocking
What happens if the provider times out here? Right now the caller gets a resolved promise and no data, which is indistinguishable from an empty result.
- Suggestion
The retry logic and the parsing are doing two jobs in one function. Splitting them would let you test the retry without a fixture.
- Nit
Naming — `data2` will not mean anything to you in six months.
First response within one business day. Every comment says whether it blocks.
Mentorship & code review
Senior attention on your actual work
This is the part you cannot get from a tutorial, a course, or an AI assistant that agrees with you. Someone experienced reads what you wrote and tells you what they think.
- Code review
- Line by line, on every pull request, with the reasoning attached.
- Architecture feedback
- Whether your design fits the system or fights it.
- Engineering feedback
- How you work, not only what you produced.
- Decision guidance
- How experienced engineers choose between two reasonable options.
You don’t need another tutorial.
You need experience.
Applications are read by a person, and places are limited by how many pull requests we can review properly each week.
Apply to Barmaj