The room is small. There are about 50 laptops on long tables, give or take, and the only sound is the soft chorus of mechanical keyboards and the occasional kettle. Someone is wearing red headphones. 2 people are arguing politely about whether to pre-allocate a slice in Go. A guy in a brown kurta is staring at a stack trace like it personally offended him. Nobody is on stage. There is no stage.
This is a Dev Weekends Tech Grind. It runs once a month for 2 days, 12 hours per day, and the whole thing exists because we got tired of leaving "productivity" weekends with new tabs open and nothing built.
What it actually is
A Tech Grind is not a workshop. It is not a hackathon. It is not a meetup with a different name on top.
It is a small group of people sitting in the same room for 2 long days, each of them working on their own thing, holding each other accountable to actually finish it. Some weekends, the loudest sound in the room is someone biting into a samosa. Most of the day, you are heads-down on your own goal, occasionally pulling a neighbour into a 5-minute debugging conversation that turns into an hour and ends with both of you having learned something.
If you have ever felt that you knew enough to build the thing but kept failing to actually build it on your own, this is the room you have been missing.
A typical Day 1
People show up around 9am. There is some shuffling, laptops opening, water bottles being filled, and then a single rule for the start of the day: before you take your first proper break, you have to declare your goal for the weekend out loud, in front of the room.
Not "I want to learn React." That is not a goal, that is a vague hope. The kind of goal that counts is closer to "I am going to ship the authentication flow on this side project, including password reset, by Sunday evening." It needs to be small enough to finish, and concrete enough that someone else can tell whether you finished it.
After that, 3 deep-work blocks. About 3 hours each, with a real break in the middle. Lunch is shared and a bit chaotic. Late afternoon usually slows down for an hour, the room gets quieter, and a few people pair up. By the end of Day 1, almost everyone is somewhere in the messy middle of their problem.
What people are usually working on
Different desks are doing different things, and that is a feature, not a bug.
A few people are deep into ICPC-style problem solving, dry-running solutions on whiteboards. A few are pushing pull requests upstream into open-source repositories, the same kind of work that, 2 cohorts in, has now produced 14 GSoC and other open-source program selections for the community. A few are building real systems, APIs and dashboards and the unglamorous middle layer that ties them together. A couple of people are usually writing, cleaning up technical blogs, or getting a portfolio into shape before applying for jobs.
The point is not that everyone in the room is doing the same thing. The point is that everyone is doing something, in front of other people who are also doing something. That alone changes how the day feels.
Day 2 and the closing
Day 2 starts a little quieter than Day 1. People have a clearer picture of where they are stuck. The room generally has a better feel for who is fast on what, so debugging conversations get easier and shorter.
The closing on Sunday evening is one of the few rituals we are strict about. Each person stands up and tells the room 3 things: what they actually shipped, what got in the way, and what they are doing next. There is no performance to it. If you spent 2 days fighting a single bug and only fixed it at 5pm on Sunday, you say that. The pretending-to-have-shipped energy you sometimes find at hackathons is exactly the thing the format is meant to push out.
What changes
The thing you walk away with is not really the project. The project is partly finished, or fully finished, or sometimes pivoted into something more interesting halfway through Day 2. That part is good but it is not the main thing.
The main thing is that you spent 2 full days doing only one kind of activity, in a room of people doing the same kind of activity, with no excuses available to you. After a year of weekends like this, careers compound in ways that are hard to describe to people who have not done it. You stop being someone who reads about what senior engineers do, and you start being someone who occasionally has the same thought before they have it. That is real. We have watched it happen with 2 full cohorts now.
Who it is for, and who it is not for
If you are stuck in the tutorial loop, this is for you. If you know the concepts and cannot bring yourself to actually finish a project, this is for you. If you are getting ready for an internship or a GSoC proposal or a portfolio review, this is for you. If you want to learn what real engineering thinking feels like by sitting next to someone doing it, this is also for you.
If you are looking for a passive workshop, a panel, or a networking event, this is not the format. If you do not have a goal yet, that is fine, just come to the next one with one. And if you need to be entertained more than engaged, you will be bored within the first 3 hours, and that is on us, not on you.
How to come
The next Tech Grind weekend is coming up alongside the start of the Dev Weekends Fellowship 2026 and DSOC 2026, both of which begin June 1. Tech Grind sessions run alongside both, so if you are already in either program, you do not need to do anything extra.
If you are not yet in the community, the easiest way in is to join the Discord and say hello. Most of the people in the room you saw described above arrived exactly that way.
2 days will not change your life.
But 2 days, every month, for a year, very quietly will.