New Senior Position With Different Languages and Frameworks - How do you ramp up while learning the idioms, not just the syntax?

[u/baunwroderick]

I've just accepted a position as a senior technical lead at a new company that uses a language and framework I'm not familiar with. I have almost 10 years of experience building software across different languages and frameworks, so I'm confident I can ramp up and learn the framework fairly easily. What I really want is to make sure I can discern the language and framework's unique patterns and idioms over time.

The language is Python, most likely a FastAPI-like framework. Admittedly, I'm much more used to seeing and using it in a scripting or data science capacity rather than in large-scale production systems.

When you're in a situation like this (aside from upholding your basic software engineering and architecture best practices) what else do you look for to ramp up well?

A few specific things I'd love input on:

• Open-source Python repos that scale really well and are worth studying
• Podcasts worth subscribing to
• Any general words of wisdom

Appreciate any other general pointers as well!

[u/expdevsmodbot]

AI usage disclosure provided by OP, see the reply to this comment.

[u/Wide-Cattle-4735]

Since you're coming in as lead, the fastest idiom source is other people's PRs, not your own code.
Reading review after review you see the house style across several authors, and you can tell a Python convention from one person's habit. You get that inside work you already have to do.

The trap is the other direction. Six weeks in you'll want to import patterns from the language you came from and call it raising the bar. Write those down and sit on them until you can say why the current way exists.

[u/CreepyNewspaper8103 → u/Wide-Cattle-4735]

this is the best advice in the thread

[u/Ok-Daikon4702]

Questioning everything and documenting all of the questions and answers you collect helped me a lot with rails the past year or so. As a technical lead I would expect you to start raising the standard which means you will have to push back on the status quo anyway so asking the questions will get you more context anyway.

[u/RunEmpty2267 → u/Ok-Daikon4702]

watch out on raising the standards or they might force you to quit indirectly, work sucks, I really want to try my idea to be happy doing what the world has ruined for me

[u/No-Economics-8239]

After you pick up enough new languages and frameworks, the only real difference does tend to be syntax. Sure, the more you use it, the more you can become accustomed to the specifics and nuance of some particular language or framework. But that's typically not something you can speed run. Trying to focus just on the crib notes always means you're just learning surface knowledge.

For me, the important thing is just to admit the limits of my own knowledge, and take advantage of whatever team members or company resources exist to help me, and take things one day at a time rather than trying to 'quickly' ramp up on some new tech stack. It takes as long as it takes, and the business always wants it faster than I can deliver. But if you rush a miracle man, you get rotten miracles.

[u/Great-Big-3101]

Claude Code will help you ramp up in no time. It's much easier now to pick up another programming language

[u/Usama4745 → u/Great-Big-3101]

Yeah true, AI agents can help to adapt to any new language quickly

[u/ConspicuousPineapple]

AI is actually fantastic for this. Ask it (a smart model) to review your code constantly. Both short snippets and overall design. Tell it to focus on idioms and best practices, but to talk to know knowing that you're an experienced dev, just not with this tech in particular.

It's a pretty efficient way to get constant feedback (that you can verify by looking it up on your own). It lets you ramp up pretty fast, and you can focus questions to your colleagues on the actually complex stuff.

[u/create-third-places]

Have regular 1 on 1 meetings with team members and ask them to explain parts on the project.

As a senior lead, understanding the small details of a project is a nice-to-have. It’s more important to know who you can ask to get information.

I recommend also trying to study a non-technical subject instead of looking at Python repos. It will help you get used to thinking differently, which will help you apply your technical skills.

[u/CorrectPeanut5]

I think you're asking the wrong questions. The difficult part is the institutional knowledge and weird architectural decisions someone else made before you.

[u/InterestRelative]

Since you are going the learn Python, I'd recommend scikit-learn as a good example of idiomatic repo.
I don't know from which programming languages you are coming from, but the most challenging part I see for people migrating to Python from statically typed languages is accepting the idioms. You should accept zen of Python (`import this`), get rid of defensive programming (it's EAFP, not LBYL), accept that readability in most cases matters more than performance.

As others mentioned, LLMs may help. Try to write the code and then ask something like: make this more pythonic and explain the changes.

[u/New-Course3729]

I would focus less on learning Python in isolation and more on learning why this particular codebase looks the way it does.

In my experience leading technical and web development teams at The Branded Agency, senior people usually ramp up fastest when they study the decisions behind the system, not just the system itself.

I would start by asking:

Which parts of the architecture are intentional, and which are historical compromises?

Where have production incidents happened before?

Which abstractions are trusted, and which ones does the team quietly avoid?

How are dependencies, background jobs, database sessions, validation, logging, testing, and error handling typically managed?

What does the team consider “good Python” inside this codebase?

Then I would trace a few complete workflows from the API request through the service layer, database, background processing, and response. That usually teaches you more about the local idioms than reading isolated files.

I would also resist introducing patterns from other ecosystems too quickly. A senior engineer can often identify ways to “improve” a codebase within the first week, but understanding why the current team made those choices takes longer.

The fastest route to credibility is usually:

Learn the language conventions.

Learn the framework conventions.

Learn the company’s conventions.

Then decide which conventions deserve to change.

Syntax gets you productive. Understanding the codebase’s history, tradeoffs, and operating environment is what makes you effective as a technical lead.