About little me

Hello! I'm a beginner developer with my sights set on backend development and data modeling. Like a lot of people starting out, I didn't come in with a computer science degree or years of professional experience — just curiosity about how applications actually store, organize, and make sense of data behind the scenes. Backend work has always felt like the "engine room" of software to me. While frontend gets the visual credit, it's the data layer that quietly decides whether an application is fast, reliable, and able to grow. That's what pulled me toward backend and database design in the first place. My biggest challenge so far has been learning SQL and data modeling from scratch. It sounds simple on paper — write some queries, design some tables — but in practice it meant rewiring how I think. I had to move from "how do I make this work right now" to "how do I structure this so it still works when the data grows, the requirements change, or someone else has to read my schema six months from now." Concepts like primary keys, foreign keys, relationships between tables, and eventually normalization weren't hard to memorize, but they were hard to internalize — to actually reach for instinctively when designing something from a blank page. A few things clicked for me along the way: A good schema is a form of communication. Table and column names, relationships, and constraints tell a story about the business logic, not just the data. Getting it "perfectly right" on the first try isn't the goal. Iterating on a design after seeing how data actually flows through it taught me more than any tutorial did. SQL rewards precision. Small differences — a missing JOIN condition, the wrong key, an unindexed column — can quietly break correctness or performance, so being deliberate matters. Constraints are a beginner's best friend. Things like NOT NULL, UNIQUE, and foreign key constraints catch mistakes early instead of letting bad data pile up silently. This foundation in SQL and d