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 like resources, and then served markdown as the actual content glue of each page.

At the time, this was revolutionary. GraphQL! MonogoDB! React … hooks! it felt like everything was changing, right when I got my start, and so the first few years I programmed was a flurry of code. I’d spend two weeks here, and then two weeks there, until I was a brood mother to two dozen webapps that all did different things. Projects lived and died by the bi-monthly process, and I was doing all I could just to keep up.

It was busy, and interesting, but I never really learned how to stand something up to last while the ecosystem changed. Sure, I have some sites and webapps up from the 2018 era, but nothing that get’s actually updated, or I’d consider incredibly useful.

So here’s a though for the younger devs on how to structure a project to actually achieve success, now that I’ve been around the block a few times.

Start with data & structures first

There’s a reason that data structures are the core of CS coursework, and basically every interview/leetcode style question boils into turn this into that. Turning this into that is pretty much 98% of what we do as programmers, and the other 2% is structuring envs so that they don’t become tech debt (Spoiler, they do).

So when you’re planning out a project, sit down with a piece of paper, or ebook, or whatever it is, and then draw out the foundation of what data you’re capturing, and manipulating, and then work through the problems. This can take a while, but try to keep it under a few days to start.

Then, go and build the thing in MVP fashion, and as fast as you can, get it in front of others.

I cannot understate this fact .Other people must use, and interact with what you’re building, because what you just built is wrong. People won’t like it, or use it, and you’re conceptions are off base.

Now take their feedback, and go back to the data step all over again. Build a new MVP. Don’t give up. You hear me? Don’t give up.

One of the biggest regrets of developers is that they didn’t finish more projects

It’s perfectly good to abandon projects. This is how you learn, but if you’re passionate about something, stick with it. Accept the feedback, and iterate. This is what we as an industry have nicknamed ‘agile’. Or the core of agile, and what it’s supposed to be at least.

Keep iterating, keep trying, and most of all, just start, and then don’t give up. The time is going to pass anyways.