DRY vs WET vs AHA coding styles
Thought this article was good. https://kentcdodds.com/blog/aha-programming
I particularly liked the idea of "Optimize for change first"
As an indiehackers, we try a lot of different things and optimizing for change makes it easier to get something off the ground.
Trending on Indie Hackers
Can we add "avoid premature optimization"?
Having worked with a numerous developers across various projects, I've come to understand a few things that successful developers do:
Rough Draft / Final Draft: Just like you would if you were writing a blog post, start with the rough structure and code in flow state for as much time as makes sense. This code is more like compileable pseudocode than a finished product. Helper methods can be stubbed (e.g.: public boolean validate(SomeData someData) { /* TODO */ return false; } ) and filled-in later. Once you can see whether or not your approach makes sense, refine your draft into something that you'd be proud to show in a code review. You'll see where common components can be externalized, simplified, and shared. Attempting to write finished code from the get-go is a form of premature optimization.
Build more projects! Rather than spending all of your time in a handful of projects (with established structure, coding standards, helper utilities, and configurations), spin-up small throw-away projects to accomplish minor tasks. Repeat. By building lots of little things from scratch, your toolbox will expand with more tools that can be applied to the "keeper" projects. By solving more problems, you'll be much better able to estimate task duration. Small disposable projects like this allow you to code without requirements or specs. You'll be able to test theories and learn frameworks (the basics, at least) without the risk committing feature-creep in your bigger projects.
Here's the beauty of these approaches: by following the latter, you're more likely that your rough draft implementation will resemble your final draft!
Love this idea. Really like the idea of compileable pseudocode.
Like the Rough Draft / Final Draft approach and analogy to writing. "First make it work, then do it right, then do it better" <-- this is what it says at the top of the web app that I am currently building (which is not even styled yet, just black and white)
That's so arbitrary..
I used to work in places where DRY was the golden rule.
Nowadays I work with people who couldn't care less about DRY, they WET all over the place, not caring one bit, and I just need to re-wrap my brain about it.
But as an indiehackers, if the business MVP is the goal, you shouldn't be looking at these at all, it's just, does this pice of code get me in front of customers? or possibly add, would it make sense to my next me? (me in the future that forgot everything)
:shrug: :2cent:
Totally. Speed to market is paramount when starting out. Just get it in front of users. But the second you hit any type of scale, you have to start dealing with your code issues.
This comment was deleted 3 years ago.