DEV Community: chonito7919

I Built a Tool to Parse SEC Dividend Data (And Actually Shipped It)

chonito7919 — Fri, 03 Oct 2025 20:54:29 +0000

I've been working in the electrical trade for years, but I've been teaching myself software development on the side. A few months ago, I had an idea: build a free, open-source tool to extract dividend data from SEC filings. There are paid services that do this, but they're expensive, and I thought, "How hard could it be?"

Turns out, pretty hard.

The Problem I Tried to Solve

If you want historical dividend data for US stocks, you have a few options:

Pay $50-500/month for services like SimFin or Intrinio
Scrape Yahoo Finance (legally questionable for commercial use)
Manually look up each company's investor relations page
Parse SEC filings yourself

I chose option 4.

The Journey (Or: How I Failed Before I Succeeded)

First attempt: HTML scraping. I wrote code to download 8-K, 10-K, and 10-Q filings and used an LLM to extract dividend amounts from the messy HTML.

Result: Complete garbage. The LLM extracted $3,910 as a dividend for Coca-Cola (it was reading the wrong table column). Processing took 50-60 seconds per company. This approach was dead on arrival.

Second attempt: Use XBRL data instead. The SEC provides structured JSON APIs with financial data in a standardized format called XBRL. No HTML scraping, no LLM guessing, just parsing structured data.

This worked much better. Processing time dropped to ~3 seconds per company, and the data was mostly accurate.

The Real Challenge: Data Quality

Here's what I learned about parsing SEC data that nobody tells you:

Companies report annual totals alongside quarterly dividends. Target, for example, reports both their $1.10 quarterly dividend AND a $4.38 annual total (sum of all 4 quarters) in the same filing, with the same XBRL tags. My parser had to figure out which was which.

Every company files differently. Some use one XBRL tag, others use a different tag. Some report fiscal quarters cleanly, others don't. There's no standard for "this is a sum" vs "this is a single payment."

Perfect accuracy is impossible. After weeks of work, I got the parser to about 85-90% accuracy. The remaining 10-15% needs manual review. I had to accept this.

The Solution: Confidence Scoring

Instead of trying to achieve 100% accuracy, I built a confidence scoring system. Each dividend gets scored 0.0-1.0 based on:

Is the amount reasonable? (Too high = probably an annual total)
What's the period duration? (365 days = annual, not quarterly)
How does it compare to other dividends for this company? (4× the median = suspicious)
Is there proper metadata? (Missing fiscal quarter = lower confidence)

Anything scoring below 0.8 gets flagged for review.

Test results:

Johnson & Johnson: 52 dividends, 100% confidence, zero manual review needed
Apple: 46 dividends, 96% average confidence, 2 flagged from 2012
Target: 65 dividends, 79% average confidence, 15 annual totals correctly flagged

The system works.

What I Learned

1. Perfect is the enemy of done. I spent weeks trying to get 100% accuracy. I was debugging edge cases for companies I'd never heard of. Eventually I realized: 85-90% automatic + flagging the rest is good enough. Ship it.

2. Data quality is never 100%. Even Bloomberg and FactSet have errors. The difference is they have teams of people verifying data. For a solo project with zero budget, confidence scoring + review workflow is the realistic solution.

3. Actually shipping something feels different than planning to ship something. I've started and abandoned dozens of projects. This is the first one I've actually pushed to GitHub with documentation, tests, and a proper license.

The Tech Stack

Language: Python 3.8+
Database: PostgreSQL (confidence scores, audit trails, review workflow)
Data Source: SEC EDGAR XBRL JSON APIs (official, free, no scraping)
License: Apache 2.0 (free to use, modify, even commercially)

The code is on GitHub: DivScout

What's Next?

Honestly? I don't know. The project is shipped. It works for what it does. Maybe I'll add more features. Maybe I'll use it to build something else. Maybe it just sits there as proof I can finish something.

For now, I'm just glad I shipped.

For other people learning to code while working full-time: You don't need a perfect project. You need a finished project. Even if it's 85% accurate. Even if only 5 people look at it. Even if it's not as good as the commercial alternatives.

Shipping something imperfect beats planning something perfect forever.

From Copper Wire to Code: A Master Electrician's Journey into Software Development ⚡💻

chonito7919 — Fri, 26 Sep 2025 16:12:35 +0000

Hey everyone! I'm here to share a bit about my current journey—one that's taking me from the physical world of Master Electrician work and small business ownership into the digital realm of software development. It's a huge, exciting, and sometimes terrifying shift, and I know I'm not the only one making a big career change.

Licensed to Wire: The Foundation of Logic

For years, my world revolved around circuit diagrams, voltage testers, and the precise logic of electrical systems. As a Master Electrician with multiple licenses and a contracting business owner, my days were defined by planning installations, ensuring safety, and troubleshooting complex systems. The work required meticulous precision and a deep understanding of how components interact.

Recently, I felt a pull toward something new—the systems that run the digital world. I realized the core skills I use every day were transferable, and I decided to make the leap into software development.

Building a New Toolset: Learning in Public

Making a career switch this big means going back to the fundamentals. I'm currently diving into two powerful languages: C++ and Python. C++ is my choice for building robust, high-performance tools, while Python is my versatile go-to for rapid scripting and utility.

My entire workspace is built on an open platform: I run exclusively on Linux—specifically Debian. I appreciate the stability and control it offers, making it the perfect environment for a builder like me. My approach is simple: learn by building practical applications that solve real problems.

Project Deep Dive: Real-World Solutions

I'm focused on creating tools that provide real utility, like my gambling tax calculator written in C++. I decided to build this tool to handle the complexities of tracking winnings and losses in different jurisdictions. The challenge lies in designing a system that can be easily updated to reflect changing tax laws—it's about creating flexible logic, much like designing an electrical system that can handle future expansions.

You can check out the source code and how it's progressing here: Gambling Tax Calculator GitHub Repo.

Sharing Knowledge: Developer Cheat Sheets

As I learn, I'm also creating resources that help me solidify my knowledge and, hopefully, help others in the community. I'm building a repository of developer cheat sheets for the terminal tools I use constantly, specifically tmux and vim.

Vim is my editor of choice (if you know, you know!) and mastering its efficiency is a key focus.
tmux helps me keep my terminal sessions and workflows organized.

Creating documentation like this is an easy way to contribute to the community without writing complex code. Feel free to check out and contribute to the cheat sheets here: tmux Cheat Sheet and vim Cheat Sheet.

The Transferable Skill: Troubleshooting

What does a Master Electrician bring to coding? The answer is systematic troubleshooting.

The core of electrical work is systematic problem-solving:

Isolate the issue: Is the problem upstream (the breaker) or downstream (the load)?
Form a hypothesis: A loss of power suggests a loose connection.
Test the hypothesis: Check for voltage at the first junction point.

This process translates almost perfectly to debugging code:

Isolate the issue: Is the bug in the data input, the logic, or the output?
Form a hypothesis: An unexpected value suggests a variable scope error.
Test the hypothesis: Use a debugger to set a breakpoint and inspect the variable state.

In both careers, you're dealing with a hidden system where one small error can cause a catastrophic failure. Both require a meticulous, logical approach—you can't just guess your way to a solution.

The Self-Taught Path and My Big Challenge

My learning approach is strictly self-taught. I don't have a Computer Science degree, which brings both massive freedom and significant challenges.

The biggest challenge is tackling complex programming concepts independently. Ideas like memory management and design patterns can feel abstract when you're trying to figure them out alone. It's a constant battle between practical application and theoretical depth.

But my philosophy remains: build real solutions to real problems. That tangible sense of accomplishment is what keeps the motivation high, and I believe my practical background offers a unique and valuable perspective in this new field.

Looking Ahead: My Next Wires to Connect

My transition from Master Electrician to software developer is built on a decade of experience in systems architecture, problem-solving under pressure, and reliable project execution. As I continue to expand my skills in C++ and Python, I look forward to applying this rigorous, real-world discipline to future software development opportunities. I believe the ability to quickly diagnose and resolve complex system issues, a trait honed in the trades, will be an invaluable asset in any development team.

Join the Conversation

This transition is an intense solo effort, and connecting with the wider developer community is essential for growth.

If you're a developer, especially one who works in C++ or Python, I'd love to hear from you.

If you're a career changer who's made a jump from a trade, service industry, or any other non-traditional background—how did you bridge the knowledge gap? What was your "a-ha!" moment?

Drop a comment below! I'm eager to connect, exchange advice, and share war stories from the trenches, whether they involve 220 volts or a nasty core dump.

Call-to-Action:

Have you made a career change into development? Share your "before" and "after" story in the comments!
Got any essential VIM or TMUX tips for a new developer? I use vim, so drop your best .vimrc or .tmux.conf snippets!
What open source project do you think every newcomer should check out?

Let's learn together! 🤝