https://twitter.com/levelsio/status/1381709793769979906
This could theoretically be the most complex PHP file you have ever seen, but it's probably not. The message here is that's not what counts (number of files, complexity etc.). The message is: create something of value. If one PHP file does that, great.
I've learned that lesson when working on a $100M ARR product that was basically thrown together PHP spaghetti code that was launched as a prototype and never was refactored again. Most terrible code I've ever seen, yet made a LOT of money.
Some of my best stuff was built by embracing "done beats best practice."
So it completely makes sense in his context. How was he ever going to focus on the other code qualities?
If on the other hand you're experienced it's probably about finding that trade off between perfectly orchestrated software and having something that delivers your vision in an acceptable amount of time.
Not using php or something simple for you it will hold you back. Setting up a top of the line container devops system will slow you down and gives you a false sense that you are doing anything.
It is nice to start with the cleanest best office with a desk but if you spend your time focusing on making your office better you never focus on the actual job.
Years ago I worked for a guy who fell into this. Successful career in insurance industry but going through a failed mariage he pivoted and quit his job and started a recruitoring firm. The office he rented was near my college and he offered me a job.. I was employee #1. First day we decided to skip work and we went on a bonding trip playing golf and go by his exes house to steal a chair. Everyday he would find something to do from making business cards, to buying office supplies to going to colleges to randomly meet people and tell them what we did. He hired two more college students to make a website. Everyday he found something to do.. but he never sat in the office and made the calls he needed to. There was always something else to do. When the money ran out (very soon) and he crashed his car drunk. No one got paid (aside from me) in the backrupacy. In the end he ended up back in insurance in a new relationship he found along the way.
He was playing CEO. Don't play CEO or CTO. Sit down and make the difficult calls.
Even if you can, you shouldn't expend a non-trivial amount of brain cycles on that, especially early on.
> If on the other hand you're experienced it's probably about finding that trade off between perfectly orchestrated software and having something that delivers your vision in an acceptable amount of time.
Don't.
As someone who built (and sold) a business before and is building a new one, I'd say it really doesn't matter before you get traction. Just ship the damn thing however you can!
The chance of a first-time founder succeeding is incredibly slim anyway. So, you're better off spending your time figuring out distribution and finding a good enough market.
You could ask me to build a project with no trade offs regarding time to deliver, it's still not going to be in one single file, primarily because it's one of many "quick wins".
> primarily because it's one of many "quick wins"
Be careful with that, though. You might have an illusion that you're making progress, while in reality, you aren't.
I'm with you on having the fun part!