Swift-Hyderabad

Why I do this

I am from Hyderabad. I learned to write software there.

I was lucky early. Someone senior sat with me through a code review that should have taken ten minutes and took two hours, and in the process taught me the difference between code that runs and code that is finished. Someone else told me, bluntly, that the way I was thinking about my career was going to cap me. They were right. I would not be where I am without those conversations.

Most junior engineers in India do not get those conversations. Not because seniors are unwilling, but because the matching is bad. People who could help do not know who needs it, and people who need it do not know how to ask without feeling like they are imposing.

Swift-Hyderabad is a community I stay close to because it solves that matching problem, for a small number of engineers, in a way that is easy to sustain. I am not trying to scale it. I am trying to be useful to the person in front of me.

What it looks like

It is not glamorous. It is not a podcast. It is an hour on a Saturday morning, India time, which is a Friday evening for me.

1:1 mentoring. I take on a small number of engineers — usually one to three at a time — who are somewhere in the two-to-five year range. We meet every two weeks. We talk about whatever they want to talk about. Often it is a specific technical problem they are stuck on. Often it is a career question they have not figured out how to ask their manager. Sometimes it is an offer they are trying to decide about.

Code reviews. A few of the engineers in the community send me pull requests from their day jobs when they are unsure of the shape of a piece of code. I do not review for correctness — their teammates do that. I review for taste. Is this code going to age well. Is the abstraction earning its keep. Is the name of this function telling the truth.

Meetups and talks. The community runs in-person meetups in Hyderabad. I join when I can, usually remotely. I have given a handful of talks — on working across time zones, on getting unstuck on hard problems, on what senior engineers actually spend their days doing (most of it is not coding). I try to pick topics that the talk circuit does not over-serve.

Career guidance. The hardest thing for an engineer in their first five years is calibrating. They do not know what good looks like. They do not know whether their job is normal. They do not know whether they are behind or ahead. A lot of my time is just being a calibration point — "no, that is not normal, push back on it" or "yes, that is normal, stop worrying about it."

I am deliberate about not trying to do more than this. I could organize more events. I could mentor more people. I could start a podcast. I do not, because I think the thing that works — quiet, consistent, 1:1 attention to a small number of engineers — stops working the moment I try to scale it.

What mentoring has taught me

Teaching forces you to say out loud the things you have been doing on autopilot. Half the time, when I explain a decision to someone I mentor, I realize I do not have a good reason for it. I have a habit, and I have been calling it a reason. That has been humbling. It has also made me better at my own job.

I have learned that most engineers do not need better advice. They need someone to take them seriously. "Here is what I am thinking about this problem" lands differently depending on whether the person across from you is waiting for a chance to correct you, or is actually listening. I try to listen. I am still not great at it, but I am less bad than I was a year ago.

And I have learned to be careful with the word "just". If I am telling someone to just rewrite their résumé, just switch jobs, just pick up the phone, I am almost certainly underestimating the friction on the other side of the advice. "Just" is the word engineers use when they want to feel helpful without doing the work of actually being helpful.

And I have learned something about what seniority actually means. The engineers I mentor who are going to be very good are not the ones who ask the cleverest questions. They are the ones who come back to the next session with the thing we agreed they would try, actually tried. Consistency is so rare, and so much more predictive of where someone ends up, than talent is. It is the thing I look for now when I am hiring. I did not used to.

The work of mentoring is small. The return, for me, is not. I get to talk to engineers who are earlier in their careers than I am, about problems I have partially forgotten how to see, in a city I have partially forgotten how to see. It keeps me honest.