Start from the Data, but also just Start.
I got my start in the field as a 'JAM' stack developer.
This was a fairly short lived trend, but what it boiled down to was that the company I worked for built many small static site style resources, and served markdown as the content glue of each page.
At the time, this felt revolutionary. GraphQL. MongoDB. React hooks. Everything was changing fast, and I landed right in the middle of it. My first few years were a flurry of code. Two weeks here, two weeks there, until suddenly I was the brood mother of two dozen webapps that all did different things. Projects lived and died on a bi monthly cycle, and I was doing whatever I could just to keep up.
It was busy and interesting, but I never really learned how to stand something up that would last while the ecosystem shifted underneath it. Sure, I have some sites from the 2018 era still up, but nothing I’d consider durable or useful today.
So here’s a thought for younger devs on how to structure a project so it has a fighting chance of succeeding, now that I’ve been around the block a few times.
Start with data and structures first
There’s a reason data structures are the core of CS coursework, and why almost every interview or leetcode style question boils down to turning this into that. Turning this into that is basically what we do. The other two percent is trying to structure environments so they don’t become tech debt. (Spoiler: they will.)
When you’re planning a project, sit down with a piece of paper or a tablet and sketch out the core of it. What data you’re capturing, what you’re transforming, what shape the world needs to be in. Think it through, but don’t get lost in it. A couple days max.
Then go build the MVP fast, and get it in front of other people immediately.
I cannot stress this enough. Other people must use and interact with what you’re building, because the first version is wrong. People won’t like parts of it. They won’t use it the way you imagined. Your assumptions will be off.
Good. That’s the point.
Take their feedback, go back to the data step, rethink the structure, and build another MVP. Don’t give up. Seriously. Don’t give up.
One of the biggest regrets developers have is not finishing more projects
It’s perfectly fine to abandon projects. That’s part of learning. But if you’re passionate about something, stick with it. Take the feedback, iterate, and try again. That’s all “agile” was ever supposed to mean.
Keep iterating, keep trying, and most of all, start, and don’t give up.
The time is going to pass anyway.