There is a tale about a photography professor credited as Jerry Uelsmann, where students would either be graded on the amount of photos they took during a semester, or the quality of the best photo they wanted to submit. It was found that at the end of the term that the students that ended up with the best quality photos were the ones in the quantity group. Personally, I don't think that it applies 1:1 to software development. It is very easy to end up in the trap of having 1 year of experience 10 times instead of gaining deep knowledge of how software needs to be able to evolve over time, but it I do agree that there is a huge benefit to putting in the repetitions, iterating, and experimenting with any new tool or pattern past what you need to get the current task done. Reading about something and implementing it 'perfectly' one or two times without consciously thinking about it any deeper or allowing your mind to steep in the ideas with more iterations is often not sufficient to really gain an appreciable level of skill that will show in how you apply it in your discussions and work.
This was the exact thing I needed to hear !! I am a perfectionist, caught up in the Analysis-Paralysis Loop !! In this case, Quantity over Quality is the only way to get out and start Creating instead of Analyzing and Perfecting things further !! Thank you
Random question: In the spirit of encouraging others to share, can you explain what your process is to quickly make these videos? Like just rapid fire your tools, how much (or little) time you spend on each part, how you tell yourself "this is good enough, stop obsessing on this"
I dont know if you reading this thank you for the video , it came at the right time for me. Am a perfectionists and i suffered from this alot. Thanks for the video again 💯
Well said. It's often difficult for us to "zoom out" and tell when we have sufficient quality to deliver value to others. No one demands perfection like we do of ourselves.
Yeah, the problem here isn't a "quality" issue imho, it's more about the definition of done, defining time windows or similar constraints and match your behavior with your objectives. From this short video, your goal seems to create a webapp and make money out of it, without a specific problem or context, just find a webapp that will make money, and if it's your goal, then quick prototyping, throwing it at the wall and see if it sticks might be ok for you. But it doesn't work for every projects nor any goals. It works if you want to get in a form of VC investment flow regarding what you're developing, that's it. Also, to me, even with those ojbectives in mind, you should have spend enough years with quality in mind to get this working. In that case, you got a lot of "good habits" that will allow you to do quantity over quality, yet, with a quality good enough that you have a working product at the end. And if you can really create your product with horrendous "quality" and only quantity in mind, you're mostly not solving any important or new problems, just another random crud app or similar, or will be crushed by any competitor that raised the quality bar a bit less lower, then yeah you do you. EDIT: nvm, didn't realized this was an ad for your devlaunch app, kinda understand better why you're pushing this narrative now. This is kinda deceptive. Have fun with your startup incubator-ish project.
Thanks again. :) I have trouble with this concept, but I understand how and why it works. I just hope I can come up with enough ideas to crank out, that tends to be my biggest issue. Maybe I will work on an app for that. LOL
It works for the world's best athletes. They don't have some secret magic workouts, they just train for 2-3x the hours of the average enthusiast. Their bodies can't argue with the quantity, so adapt. The quality comes as a by-product.
This is probably true for most "value discovery" projects, and very wrong for foundational projects. For most things, a mediocre solution today is better then a perfect solution tomorrow. Often a product needs to pivot many times, so excessive early quality is wasted. However, in mature areas this is wrong, and quality is paramount. Nobody wants 1000 half baked web frameworks, operating systems, compilers, or web protocols; they want a handful of high quality options to choose from.
This comment should be on the top! I'd rather watch videos someone took their valuable time for to make it as good as they could in a reasonable amount of time. Of course, everyone can have their different standards, but don't waste other people's time just to maximize yours.
I actually would agree with you one month ago but something changed my perspective. I did an interview before the holidays. The interviewer frankly said that I may not fit the offer as I'm too passionate on the technical side. I was shocked as I have never rejected from an interview nor have I ever been given that remark. I was drained and disgusted after the interview. But after a week of reflection, I finally came to realize that he was kinda right. We live in a very very fast evolution of the market. Every day/week you spend putting all the mechanics of the devops and build the architecture in place are time spent not working on the product to put it in the market and test the audience. Today's innovation may be tomorrow's obsolete. So, the ideal is just do the minimum necessary to validate the product. By minimum necessary, I mean, just do basic API system, very basic caching system, a simple front and back-end and clean code as needed. You always can split the projects later or migrate the data in the databases.
I hate any statement with “always” Learning fast and building fast iterations is great for learning and finding a product fit. Enterprise systems that have the potential to scale and handle large volume: quality. Aiming for quality every time will lead to over engineered maintenance nightmares
Fake programmer I cant accept it: i got beaten and abused for being a nerd and now its so cool people are faking it on internet and wear fake glasses 😢 Like wtf bro
I'm a similar age to you and this is something I also came to believe recently. Like you, I always thouight quality is what matters, not quantity. In some fields, that is the case, but in software, and professional life more generally, it's not.
There is a tale about a photography professor credited as Jerry Uelsmann, where students would either be graded on the amount of photos they took during a semester, or the quality of the best photo they wanted to submit. It was found that at the end of the term that the students that ended up with the best quality photos were the ones in the quantity group.
Personally, I don't think that it applies 1:1 to software development. It is very easy to end up in the trap of having 1 year of experience 10 times instead of gaining deep knowledge of how software needs to be able to evolve over time, but it I do agree that there is a huge benefit to putting in the repetitions, iterating, and experimenting with any new tool or pattern past what you need to get the current task done. Reading about something and implementing it 'perfectly' one or two times without consciously thinking about it any deeper or allowing your mind to steep in the ideas with more iterations is often not sufficient to really gain an appreciable level of skill that will show in how you apply it in your discussions and work.
He said that you have to "improve a little bit every time"
This was the exact thing I needed to hear !!
I am a perfectionist, caught up in the Analysis-Paralysis Loop !!
In this case, Quantity over Quality is the only way to get out and start Creating instead of Analyzing and Perfecting things further !!
Thank you
Random question: In the spirit of encouraging others to share, can you explain what your process is to quickly make these videos? Like just rapid fire your tools, how much (or little) time you spend on each part, how you tell yourself "this is good enough, stop obsessing on this"
I dont know if you reading this thank you for the video , it came at the right time for me. Am a perfectionists and i suffered from this alot. Thanks for the video again 💯
I like of your point of views because most of the time we get struggle to be perfectionist and fail before start!
do small small stuff... learn in small chunks.. and one day all of a sudden realise that "I" did so much 🙂
I would say this is more action over theory instead on quantity over quality.
Well said. It's often difficult for us to "zoom out" and tell when we have sufficient quality to deliver value to others. No one demands perfection like we do of ourselves.
I agree with it 100%. I realised it when creating e-commerce product listings. To achieve quality we need quantity first.
Thank you, I needed this.
Yeah, the problem here isn't a "quality" issue imho, it's more about the definition of done, defining time windows or similar constraints and match your behavior with your objectives.
From this short video, your goal seems to create a webapp and make money out of it, without a specific problem or context, just find a webapp that will make money, and if it's your goal, then quick prototyping, throwing it at the wall and see if it sticks might be ok for you.
But it doesn't work for every projects nor any goals. It works if you want to get in a form of VC investment flow regarding what you're developing, that's it.
Also, to me, even with those ojbectives in mind, you should have spend enough years with quality in mind to get this working. In that case, you got a lot of "good habits" that will allow you to do quantity over quality, yet, with a quality good enough that you have a working product at the end. And if you can really create your product with horrendous "quality" and only quantity in mind, you're mostly not solving any important or new problems, just another random crud app or similar, or will be crushed by any competitor that raised the quality bar a bit less lower, then yeah you do you.
EDIT: nvm, didn't realized this was an ad for your devlaunch app, kinda understand better why you're pushing this narrative now. This is kinda deceptive. Have fun with your startup incubator-ish project.
Thanks again. :) I have trouble with this concept, but I understand how and why it works. I just hope I can come up with enough ideas to crank out, that tends to be my biggest issue. Maybe I will work on an app for that. LOL
It works for the world's best athletes. They don't have some secret magic workouts, they just train for 2-3x the hours of the average enthusiast. Their bodies can't argue with the quantity, so adapt. The quality comes as a by-product.
> so adapt
yeah, and then pain and unhealthy aging is their destiny.
It's not just quantity tho, the training is specifically tailored for the athlete so quality is a must :)
@@dandogamer yes, agreed. But 95% of their training is just about getting the quantity in - volume/hours
can you make a video about interesting saas ideas?
It's so hard to build just one
This is probably true for most "value discovery" projects, and very wrong for foundational projects. For most things, a mediocre solution today is better then a perfect solution tomorrow. Often a product needs to pivot many times, so excessive early quality is wasted.
However, in mature areas this is wrong, and quality is paramount. Nobody wants 1000 half baked web frameworks, operating systems, compilers, or web protocols; they want a handful of high quality options to choose from.
Never! Quality is always over quantity! Why add to the technical debt? This is terrible advice! Don't conflate "quality" with "perfectionism"...
This comment should be on the top! I'd rather watch videos someone took their valuable time for to make it as good as they could in a reasonable amount of time. Of course, everyone can have their different standards, but don't waste other people's time just to maximize yours.
I agree! Their's already enough junk out their . No excuse . Especially when their's an Ai assisting with the coding.
I actually would agree with you one month ago but something changed my perspective.
I did an interview before the holidays. The interviewer frankly said that I may not fit the offer as I'm too passionate on the technical side. I was shocked as I have never rejected from an interview nor have I ever been given that remark.
I was drained and disgusted after the interview. But after a week of reflection, I finally came to realize that he was kinda right. We live in a very very fast evolution of the market. Every day/week you spend putting all the mechanics of the devops and build the architecture in place are time spent not working on the product to put it in the market and test the audience. Today's innovation may be tomorrow's obsolete.
So, the ideal is just do the minimum necessary to validate the product. By minimum necessary, I mean, just do basic API system, very basic caching system, a simple front and back-end and clean code as needed.
You always can split the projects later or migrate the data in the databases.
I hate any statement with “always”
Learning fast and building fast iterations is great for learning and finding a product fit. Enterprise systems that have the potential to scale and handle large volume: quality.
Aiming for quality every time will lead to over engineered maintenance nightmares
Quality is often a blocker because you obsess over and don’t move forward. “Perfection is the enemy of progression”- Voltaire
60% of the time it works…every time.
I‘m always surprised that you split screen into 3 on 13 inch laptop display 😮
Was about to write the same. I'd split it to 8.
Fake programmer
I cant accept it: i got beaten and abused for being a nerd and now its so cool people are faking it on internet and wear fake glasses 😢
Like wtf bro
I'm a similar age to you and this is something I also came to believe recently. Like you, I always thouight quality is what matters, not quantity. In some fields, that is the case, but in software, and professional life more generally, it's not.
Dude if I build 1000's of Todo lists I wouldn't ever be successful
4:53 How to work on your project daily:
#1 Get rid of wife and kids
thanks :D
Quantity makes the world a worse place