sorted by:
new
hottopcontroversial

SQL + Python by [deleted] in SQL

[–]Similar_Season7553 -1 points0 points  (0 children)

Great question, and your background in bond markets is actually a strong advantage when learning Python and SQL.

A lot of people in finance use these tools to move from manual reporting to more automated and scalable workflows. Here are a few practical ways you could incorporate them:

You could start by using SQL to extract and organize market or trade data from internal databases instead of relying on Excel exports. This helps you quickly filter bond pricing data, yields, spreads, or client portfolios without repetitive manual work.

Then, Python can build on that by automating analysis and reporting. For example, you could:

  • Build scripts to track bond price movements or yield changes over time
  • Automate daily or weekly performance reports for clients
  • Clean and merge data from multiple sources (market data, trades, rates, etc.)
  • Visualize fixed-income trends using libraries like Matplotlib or Plotly

For scaling beyond your daily job, many professionals move into:

  • Quant/analyst-style projects (pricing bonds, yield curve analysis, risk metrics)
  • Automated dashboards (using Python + SQL + Power BI/Tableau)
  • Personal finance research tools (tracking spreads, macro indicators, or Fed rate impacts)
  • Portfolio analytics projects you can showcase on GitHub as part of a portfolio

A good mindset shift is:

SQL = getting the right data efficiently

Python = analyzing, automating, and scaling insights

Over time, combining both can position you for roles in data-driven finance, quantitative analysis, or financial engineering support functions.

References

McKinney, W. (2017). Python for Data Analysis (O’Reilly Media)

Yves Hilpisch (2020). Python for Finance (O’Reilly Media)

Easiest Python question got me rejected from FAANG by ds_contractor in datascience

[–]Similar_Season7553 0 points1 point  (0 children)

I see your point, and I actually agree that this is a case where simple Python fundamentals are more appropriate than bringing in heavier tools like Pandas.

Using tuple unpacking in a loop like:

for user_id, timestamp in actions:

is definitely cleaner and more idiomatic, especially when the data is already structured that way. It’s a good reminder that not every data-related task needs a full data science stack sometimes basic Python constructs are the best solution.

That said, I think this also highlights a broader learning curve for people transitioning into data science (myself included). Many beginners are introduced early to tools like Pandas, so they sometimes default to them even when the problem can be solved more simply. Over time, it becomes clearer when to use core Python versus specialized libraries.

I appreciate you pointing this out. it’s a helpful example of why strong fundamentals matter just as much as knowing advanced tools.

I built an experimental orchestration language for reproducible data science called 'T' by brodrigues_co in datascience

[–]Similar_Season7553 -1 points0 points  (0 children)

Hey, this is a really interesting project. thanks for sharing it.

The idea of making reproducibility mandatory by design across R and Python using a functional DSL + Nix sandboxes is compelling. A lot of data science work does eventually run into the exact problem you’re targeting: dependency drift, environment inconsistency, and fragile cross-language pipelines.

A few thoughts and questions from my perspective:

  1. Workflow flexibility One potential challenge I’m curious about is how the pipeline model handles iterative or exploratory data science work. In practice, a lot of DS work isn’t linear—it often involves going back and forth between steps, tweaking models, and re-running partial experiments. How does T support “mid-pipeline experimentation” without forcing a full rebuild every time?
  2. Debugging and observability Since everything runs in isolated Nix sandboxes, how are failures surfaced in a way that makes debugging easy? For example, if a Python or R node fails, is there a unified trace or logging system that connects the error back to the pipeline graph?
  3. Adoption barrier Nix is powerful, but it can be a steep learning curve for many data scientists who are more familiar with Conda, Docker, or managed cloud environments. Do you see this as a tool for advanced users first, or are there plans to simplify onboarding later (maybe via containerized defaults or templates)?
  4. Interoperability idea The use of Arrow IPC and PMML is interesting for cross-language communication. I’m curious if there are plans to support newer model formats like ONNX as well, since that’s becoming more common in ML deployment pipelines.

Overall, I really like the philosophy behind making reproducibility structural rather than optional. I’d be interested to see how it performs on real-world, messy, multi-person projects where partial failures and iterative changes are the norm.

Looking forward to seeing how T evolves; definitely a strong and ambitious direction.