My initial prototypes are just a bunch of comments(todos) explaining what each section/block of code is supposed to do. You then get a high level idea of what needs to be done and everything looks much cleaner. Put todos everywhere, including todos for handling errors. Before you ship, make sure all todos are checked off. This is a very procedural way of completing tasks, if procedural code is your thing.
For speed reasons, C/C++ is my main tool for scientific modeling; however, because it's so tedious and time-consuming, I will usually do prototyping in Python first to make sure I've discovered the "rough edges" of the project. It saves SO much time in the long run.
Have you considered Julia? I use it at work for scientific modelling like you. For example a project I work is deployed on ~1000 core multi node cluster. I can't imagine doing this by myself in C++ (ofcourse I'm a C++ noob, but it also scares me).
@@ChimiChanga1337 This. The other nice thing with it is that it is an incredibly good language to prototype algorithms in, because it actually lets you try different approaches with minimum friction and it has amazingly good profiling & code introspection tools. In python, every opcode is a cache miss so you never get to know what is fast and what is slow if the thing were written in a compiled language.
Yeh this is the crux of it. I can’t see this going well. I’d love to rewrite things 2-3 times but the reality is they will just see it done and only allocate time to do the “prototype”
My dad was a programmer who started off with machines with punch cards. When I started programming as a kid he taught me "throw the first version away". Its a good article articulating the benfits of something progammers have know for decades.
Didn't realize the value of throwing away the code really, until the mentioning of the psychology part - that there really opened my eyes, because the point of "you go fast" when you don't have to worry about re-using it is so damn true!
I've unintentionally done this so many times and it always ends up better than it was before. The things you tend to especially remember are the edge cases or 'pain points' you had in the first version. (I do tend to write those down explicitly too for future reference) It may sounds scary but it really works!
I do this for the project as a whole, and then for major features within the code. I always have a project to hand called Scratchpad, and it contains a lot of rough and ready prototypes and experiments. The code is a slapdash sketch, but I always learn a lot and yes, I'll sometimes keep an algo that actually worked well. But the production code starts with a blank sheet and a much more considered structure. As the author argued - refactoring is more difficult and restricting than starting again from scracth.
Jokes on you guys I've thrown away every version of my code. In fact I've written scripts to make it delete itself after 24 hours and then those scripts subsequently delete themselves.
Dude I've got OCD with my ADHD and this philosophy has been really helping me to not get so hung up on stuff. It's really difficult but I'm slowly learning how to stop thinking as much and write more code
Same. (ADHD, not OCD). I used to write down every crazy idea and thing I wanted to learn, but would never have the time to get to a fraction of them. Now, I prototype ideas. It satisfies my distracted dopamine-hungry brain, but in a more productive way.
For private projects, I've been throwing away lots of code when things get too mushy and complicated. It's a carthatic experience to just delete two days of work and begin anew.
this is so true, in university I had a course for modeling system and the whole thing was think about the system don't write it first. Like, how the fuck am I supposed to know what the system looks like if I've never worked on something like it!?
I iterate all the time on my code, I start with a new project, copy code that I know I want to keep, and continue from there. If it ends up looking the same as before I know it's good enough. Because when you build on top of your initial work you constrain yourself even more. So that there are no regrets it's important to have a great foundation.
💯% agree; but go even further. If you're making a conceptual change to the functionality, throw away function, files and even entire modules. A lot of time it's quicker and better (quality) to rewrite rather than refactor.
For the longest time, I didn't bother with prototyping. I love to just jump into a project head first and it can be a blast! I recently dropped another long project after realizing how insane the scope was and finally got feed up with this. For context, I mainly focus on video game projects which are already massive undertakings and the end product also has to be enjoyable. I decided to try making a prototype for a mech themed arena shooter (generic, I know) and realized how boring the gameplay was very early. Rather than keep at it, I decided to keep trying other ideas to see which one sticks. I'm already seeing how much time that prototyping can save and regret not trying to make it a habit earlier.
I've pushed this idea at my last 2 companies and was called in for a meeting with HR for "wasting company time and money". Has anyone been able to explain this process to non technical management?
Yes. I've told people that it's like Formula 1 drivers who do the warmup lap first - they get to study the hazards, corners and problems so that they know what they're *really* up against when the race starts.
Great advice, Pramorgen! Everyone loves to do the same work twice. And we all know that when we messed up the first time, the second try has to work. That's how I make millions in the casino!
Really it just comes down to if you are going to do something with a lot of unknowns, do a spike, make a prototype, make a proof of concept, etc, and then don't be tempted to ship the prototype 10 years ago at my work we had an "architect" make prototypes and then they got thrown over the wall and we got told to "just productionize it" and it was expected to be done quickly. It was horrible and lead to a lot of tech debt.
I have trouble with this too sometimes. It's definitely feels a little like sunk cost fallacy, where I'm mixing the effort to come up with the prototype (including the lessons learned) with the code itself, leading me to not want to throw it out. So although it sounded like Prime was backpedaling a little bit at the end when he said he actually didn't throw out to code but kept it on the side during the rewrite, that's what I tend to end up doing as well.
2:05 FREAKING TRUE THAT'S ABSOLUTELY TRUE I LIVED THAT EXPERIENCE WHEN I WAS CODING A TODO APP THAT SENDS THE TODOS TO A SERVER AND THEN THEY GET PROCSSED BY AN AI MODEL TO PROVIDE INSTRUCTIONS ON THE BEST WAY TO PERFORM THE TODOS I FELL SHORT AT IMPLENTING USING REACT, THEN CHAT GPT MADE IT WORSE IT KEPT SUGGESTING DEAD END SOLUTIONS BASED ON MY CODE BASE SO I DID WHAT A MAN WITH A MUSTACHE DOES. I DELETED THE WHOLE PROJECT FOLDER, DID NOT RELY ON CHAT GPT AND WITHIN FEW DAYS AFTER CHANGING MY PERSPECTIVE OVER THE IMPLEMENTATION OF MY IDEA, THE PROJECT IS FINISHED.
it's the same in crafts. the first chair that you make is probably gonna be ugly and patchy. you wouldn't use the best material nor put it in your house. It's a throwaway. You are just practicing, figuring out all the details that you need to pay attention to. Once you have the right mindset, you can make chairs like a pro.
It's also a solution to the problem where you get stuck with TDD. Just do it old style, then throw it away, and it will be more clear how to do effective TDD the second time around.
@@rewrose2838 You're right, it's not TDD, but at least you're moving forward and the end result will be done with TDD. I'm a big proponent of TDD, but sometimes forcing it is just counterproductive.
I didnt delete all the code but maybe i consider that for the future. Its such a good feeling to have a clean code in the end, and in my experience, i always have to go through mess before writing something clean
Hell yes typing! I took typing (yes, typing, not keyboarding) in HS, and I would say that it is just as important a skill as all the STEM that I use in my real job. Its the work tool. Documents, code, or email … it’s the tool nobody realizes they use (until you break your thumb in some stupid sport that you’re not ready to admit you’re too old for.)
I like this concept, its like create a branch, build your ideia and throw away and doing again better. When you are talking about mastering your tools for one second, remember me Jordan Peterson hahahha
Funny enough... thats what I just did. Started a project, two days later, new branch ... rewrote stuff.. next day, next branch.... rewrote stuff, today, Im done and happy with better code
lol kinda true. I scrapped off my entire frontend project (yes, react) because of 1 problem. start it from 0 and few days after, I solved the problem and had more progress than months that I built the first one.
I have a tendency to this by accident and so far it's worked in my favor. In all seriousness though - the couple of times my code did somehow get deleted my second and later iterations when I was refactoring it would be SO much cleaner.
That was a good article in general at last it made me think about my argumentation. I should not give advices how to incremental refactor i should directly say ok step one we delete prod.
Especially your advent of code... code. These challenges are designed to make you think, not to make you code clean, safe, and reusable. Redo the challenges again in another programming language.
This feels like advice for someone new to coding. But once you've been doing it for 20 years, you've got 20 years of code you've "thrown away" that your brain is working from.
I don't agree, but maybe because my experience is frontend related and styling takes way too much time. On one project we did most of our features in a separate project and then transferred it to the real one with lessons learned. It took way too much time. But I recommend taking a lot of time in the beginning and commenting code out that you don't like but may use if nothing better comes up. After enough time you will have a working version and you will have explored enough of angles to know which solution is the cleanest. Sometimes I sit all day on a problem and then finally find a clever solution and in the end where I have 10 lines of readable code instead of 50 that I were going to write quickly. So, we all agree all later versions are cleaner. But I don't think these are versions, it's just taking time, exploring possibilities and finding better solutions.
Every time I've lost my work by mistake and reinvented it, the new version has been so much cleaner.
This is why word is actually the best code editor.
So you're saying we'd be better off without VCS? brb killing all my company's github repos.
I hate dirty code. Nice when it’s clean… I like to give my code a hot bath and scrub the fuck out of it. So fresh and so clean!
My initial prototypes are just a bunch of comments(todos) explaining what each section/block of code is supposed to do. You then get a high level idea of what needs to be done and everything looks much cleaner. Put todos everywhere, including todos for handling errors. Before you ship, make sure all todos are checked off.
This is a very procedural way of completing tasks, if procedural code is your thing.
@@0xCAFEF00Dtwitter brain got you bad, friend. OP said absolutely nothing of the sort
Your code is not precious. The result you get with that code is.
yep!
For speed reasons, C/C++ is my main tool for scientific modeling; however, because it's so tedious and time-consuming, I will usually do prototyping in Python first to make sure I've discovered the "rough edges" of the project. It saves SO much time in the long run.
Have you considered Julia? I use it at work for scientific modelling like you. For example a project I work is deployed on ~1000 core multi node cluster. I can't imagine doing this by myself in C++ (ofcourse I'm a C++ noob, but it also scares me).
@@ChimiChanga1337yeah. Julia it's perfect for that problem. It was created with that in mind.
Cool, an added benefit is probably the fact that you are forced to "throw away" the code since it's not in the final implementation language.
@@ChimiChanga1337 This. The other nice thing with it is that it is an incredibly good language to prototype algorithms in, because it actually lets you try different approaches with minimum friction and it has amazingly good profiling & code introspection tools. In python, every opcode is a cache miss so you never get to know what is fast and what is slow if the thing were written in a compiled language.
At the day job, it takes a special kind of management to see something working and watch you delete everything.
Just dont tell them 😅
@@fabianletsch1354 Oops, code gone. Backups too.
Bro out here deleting production
Yeh this is the crux of it. I can’t see this going well. I’d love to rewrite things 2-3 times but the reality is they will just see it done and only allocate time to do the “prototype”
@@ChillAutos Yep, once it works, it’s locked in. 10/20 code forever.
I don't delete just my code, I delete any and all that get in my way.
chad
My dad was a programmer who started off with machines with punch cards.
When I started programming as a kid he taught me "throw the first version away".
Its a good article articulating the benfits of something progammers have know for decades.
Didn't realize the value of throwing away the code really, until the mentioning of the psychology part - that there really opened my eyes, because the point of "you go fast" when you don't have to worry about re-using it is so damn true!
I've unintentionally done this so many times and it always ends up better than it was before. The things you tend to especially remember are the edge cases or 'pain points' you had in the first version. (I do tend to write those down explicitly too for future reference)
It may sounds scary but it really works!
I do this for the project as a whole, and then for major features within the code. I always have a project to hand called Scratchpad, and it contains a lot of rough and ready prototypes and experiments. The code is a slapdash sketch, but I always learn a lot and yes, I'll sometimes keep an algo that actually worked well. But the production code starts with a blank sheet and a much more considered structure. As the author argued - refactoring is more difficult and restricting than starting again from scracth.
Jokes on you guys I've thrown away every version of my code. In fact I've written scripts to make it delete itself after 24 hours and then those scripts subsequently delete themselves.
Your system should also be deleted
Dude I've got OCD with my ADHD and this philosophy has been really helping me to not get so hung up on stuff. It's really difficult but I'm slowly learning how to stop thinking as much and write more code
Same. (ADHD, not OCD). I used to write down every crazy idea and thing I wanted to learn, but would never have the time to get to a fraction of them. Now, I prototype ideas. It satisfies my distracted dopamine-hungry brain, but in a more productive way.
I just felt personally attacked for "thinking more than typing". Point taken, will work on it
For private projects, I've been throwing away lots of code when things get too mushy and complicated. It's a carthatic experience to just delete two days of work and begin anew.
kinda weird after a year of entertaining Prime's ideas i feel like 3X as productive. Thanks for the good stuff man
Not 10x? Washed.
this is so true, in university I had a course for modeling system and the whole thing was think about the system don't write it first. Like, how the fuck am I supposed to know what the system looks like if I've never worked on something like it!?
Instructions unclear. Threw away my PC.
And then you get the next Dell iteration PC.
This is a useful approach for so many things beyond just coding. Especially when you are creating things or working with ideas.
I iterate all the time on my code, I start with a new project, copy code that I know I want to keep, and continue from there. If it ends up looking the same as before I know it's good enough. Because when you build on top of your initial work you constrain yourself even more. So that there are no regrets it's important to have a great foundation.
💯% agree; but go even further. If you're making a conceptual change to the functionality, throw away function, files and even entire modules. A lot of time it's quicker and better (quality) to rewrite rather than refactor.
For the longest time, I didn't bother with prototyping. I love to just jump into a project head first and it can be a blast! I recently dropped another long project after realizing how insane the scope was and finally got feed up with this. For context, I mainly focus on video game projects which are already massive undertakings and the end product also has to be enjoyable. I decided to try making a prototype for a mech themed arena shooter (generic, I know) and realized how boring the gameplay was very early. Rather than keep at it, I decided to keep trying other ideas to see which one sticks. I'm already seeing how much time that prototyping can save and regret not trying to make it a habit earlier.
Now I want a t-shirt with Prime licking the split keyboard.
I've pushed this idea at my last 2 companies and was called in for a meeting with HR for "wasting company time and money".
Has anyone been able to explain this process to non technical management?
Yes. I've told people that it's like Formula 1 drivers who do the warmup lap first - they get to study the hazards, corners and problems so that they know what they're *really* up against when the race starts.
@@philadams9254 That's a good approach. Sports metaphors of practice in general might also work well. Thank you.
Great advice, Pramorgen!
Everyone loves to do the same work twice.
And we all know that when we messed up the first time, the second try has to work. That's how I make millions in the casino!
Really it just comes down to if you are going to do something with a lot of unknowns, do a spike, make a prototype, make a proof of concept, etc, and then don't be tempted to ship the prototype
10 years ago at my work we had an "architect" make prototypes and then they got thrown over the wall and we got told to "just productionize it" and it was expected to be done quickly. It was horrible and lead to a lot of tech debt.
The crazy part there is all the value of the prototype is in what happens in your head making it, and there's negative value in the prototype code.
I have trouble with this too sometimes. It's definitely feels a little like sunk cost fallacy, where I'm mixing the effort to come up with the prototype (including the lessons learned) with the code itself, leading me to not want to throw it out. So although it sounded like Prime was backpedaling a little bit at the end when he said he actually didn't throw out to code but kept it on the side during the rewrite, that's what I tend to end up doing as well.
This is the hottest but most correct take you've commented on here on this channel. GOTTDAM, the name is the PROTOGEN.
2:05 FREAKING TRUE THAT'S ABSOLUTELY TRUE I LIVED THAT EXPERIENCE WHEN I WAS CODING A TODO APP THAT SENDS THE TODOS TO A SERVER AND THEN THEY GET PROCSSED BY AN AI MODEL TO PROVIDE INSTRUCTIONS ON THE BEST WAY TO PERFORM THE TODOS I FELL SHORT AT IMPLENTING USING REACT, THEN CHAT GPT MADE IT WORSE IT KEPT SUGGESTING DEAD END SOLUTIONS BASED ON MY CODE BASE SO I DID WHAT A MAN WITH A MUSTACHE DOES. I DELETED THE WHOLE PROJECT FOLDER, DID NOT RELY ON CHAT GPT AND WITHIN FEW DAYS AFTER CHANGING MY PERSPECTIVE OVER THE IMPLEMENTATION OF MY IDEA, THE PROJECT IS FINISHED.
Straight out of The Mythical Man-Month. What's old is new again.
I about did a spit-take of my coffee at 5:36. I love my mech keyboard.
it's the same in crafts. the first chair that you make is probably gonna be ugly and patchy. you wouldn't use the best material nor put it in your house. It's a throwaway. You are just practicing, figuring out all the details that you need to pay attention to. Once you have the right mindset, you can make chairs like a pro.
Yes! This strategy is something I've suggested to my junior devs for years.
5:36 did something to me that I can't explain
I laugh at your 8k line function. I have worked with a 30k line function
It's also a solution to the problem where you get stuck with TDD. Just do it old style, then throw it away, and it will be more clear how to do effective TDD the second time around.
Its no longer TDD then, since your work is not driven by the tests.
@@rewrose2838(that's the joke)
@@rewrose2838 You're right, it's not TDD, but at least you're moving forward and the end result will be done with TDD. I'm a big proponent of TDD, but sometimes forcing it is just counterproductive.
I didnt delete all the code but maybe i consider that for the future. Its such a good feeling to have a clean code in the end, and in my experience, i always have to go through mess before writing something clean
I do prototyping as I'm writing up design docs and it never fails to save 2-3x that time when implementing.
Hell yes typing! I took typing (yes, typing, not keyboarding) in HS, and I would say that it is just as important a skill as all the STEM that I use in my real job. Its the work tool. Documents, code, or email … it’s the tool nobody realizes they use (until you break your thumb in some stupid sport that you’re not ready to admit you’re too old for.)
5:35 I TRIED STOP SCREAMING AT ME 35 WPM IS MY LIMIT
i just did, and will
I like this concept, its like create a branch, build your ideia and throw away and doing again better.
When you are talking about mastering your tools for one second, remember me Jordan Peterson hahahha
Funny enough... thats what I just did. Started a project, two days later, new branch ... rewrote stuff.. next day, next branch.... rewrote stuff, today, Im done and happy with better code
it always seem to be a better approach
lol kinda true.
I scrapped off my entire frontend project (yes, react) because of 1 problem.
start it from 0 and few days after, I solved the problem and had more progress than months that I built the first one.
I have a tendency to this by accident and so far it's worked in my favor. In all seriousness though - the couple of times my code did somehow get deleted my second and later iterations when I was refactoring it would be SO much cleaner.
6:57 this is why branches are good! You can prototype in your code base… and the. Throw the branch away!!! #davefarleywouldnotapprove
OMG, the bagels.
I hear this since the 90s, what makes people think this time someone will listen 😂?
That was a good article in general at last it made me think about my argumentation. I should not give advices how to incremental refactor i should directly say ok step one we delete prod.
Fantastic advice!!😊
Roger that! I do it hundred times.
I would love to work with a project manager like that
Forget learning vim, most of us don't even know how to type without pecking lol.
I'm sure most of use are forced to work with the keyboards provided at work, which just suck ass
I've never used thee delete key while prototypingg
Whoa. The Lickagen.
How do i convince manager that it's absolutely necessary to rewrite working feature?😂😅😢
Of course you keep the good stuff from your prototype. That's the whole point 😂
Yeap, that's why I rewrote my library ~5 times. Each time it was better and simpler.
Agree with this idea, make a prototype to develop ideas and methods, not a product. Then make the product.
This is a hard refactoring 😂
your thumbnails are so good
edit: makes me click every time
What is the model of your keyboard 😂
Don't throw it away! Stash it in a git repo so you can refer to it later if need be.
Great video
I do this all the time => pet project 4 years in making
Can you give me a link to your keyboard? I am going to get it for me as a birthday present.
Everything Pizzagle.
how can i learn to type faster?
Get a typing tutor program, sign up for a typing course
Wow! He really loves keyboards! I wonder if he works at Netflix…? 🤔 haha jk! Great video
Nice
Even my advent of code solutions?
Especially your advent of code... code. These challenges are designed to make you think, not to make you code clean, safe, and reusable.
Redo the challenges again in another programming language.
I thought this was what everyone does.
Bruh i love this channel but i cant watch on weekends because i end up coding. And ive gotten into habit if i aint getting paid i aint coding 🤣
This feels like advice for someone new to coding. But once you've been doing it for 20 years, you've got 20 years of code you've "thrown away" that your brain is working from.
Is this an argument to throw away React? Can we just agree that it was very long prototype phase?
Write a shitty prototype then rewrite it in Rust.
how does it make sense?
recactoring seems much more logical
Don't love your code.
Everything bagels with almond maple spread sounds TERRIBLE.
I don't agree, but maybe because my experience is frontend related and styling takes way too much time. On one project we did most of our features in a separate project and then transferred it to the real one with lessons learned. It took way too much time.
But I recommend taking a lot of time in the beginning and commenting code out that you don't like but may use if nothing better comes up. After enough time you will have a working version and you will have explored enough of angles to know which solution is the cleanest. Sometimes I sit all day on a problem and then finally find a clever solution and in the end where I have 10 lines of readable code instead of 50 that I were going to write quickly. So, we all agree all later versions are cleaner. But I don't think these are versions, it's just taking time, exploring possibilities and finding better solutions.