Why You Should Write Bad Code
HTML-код
- Опубликовано: 31 май 2024
- Sometimes it's better to write bad code than to waste time on writing a well built solution! It's all about reversing the idea of technical debt to your advantage.
Patreon:
/ dafluffypotato
My Projects:
dafluffypotato.com/projects
Discord:
/ discord
Special Thanks to my Potato Tier Patrons:
Agent Effe
Christ Birster
Dale Topley
David Graey
Eivind Teig
GaryTMSFruitcake
Potatoboy
Shore
Vasia Bogoradov
Timestamps:
0:00 - technical debt can be reversed
0:55 - game jams
1:39 - the conditions for "bad" code
3:47 - a model to follow
7:37 - time investment is a slider!
#programming #computerscience #coding 
Наука
To be clear the definition of "bad code" I'm using is vaguely defined by the slider example from later in the video. It's code that makes sacrifices in readability, extendibility, or performance but can end up taking less time to write.
Personally I want it to work first and then I'll try to engineer it to be good for the future.
I never though about it like that, but it makes perfect sense. There is no need to over engineering something if it doesn’t need to be perfect.
I think I should probably be writing more bad code, but for my personal projects I can think of countless times where I’ve over-engineered a system within my program and it ends up being used in dozens of later projects.
For example: my text rendering library I wrote for a game that only had text for the fps counter. I’ve been using that in almost every project since because it’s so robust and easy to use. It took a long time to think through, but it’s saved me just as much time as I put in. If it’s a system that will be usable many times in the future, I think it’s worthwhile to over-engineer.
Ikr, most of my code is over engineered in such a way that normally it doesn’t even work because I unconsciously did it the most difficult way possible.
I cant count the the hundreds of times i had to write "bad code" just to meet work dead lines. Of course we then have sprints to shave off technical debt but client must see the features working first so we take time to optimize what we wrote
DRY, KISS will get you most of the way. The rest is just refactoring, but only when needed. So I wouldn't necessarily write a "bad" code, as much as I try to avoid overengineering as much as possible (YAGNI).
To expand, I would only focus on the ease of refactor. Think changing the function implementation (easy) vs changing its signature in 50 places (hard).
But yeah, In general, I agree with your point. (34yr old programmer)
this
The game looks great! I like the shake / blur effect on the items when in the inventory :D
This was a hard lesson for me to learn, but over time I've realized that it's almost always quicker to write "bad code" and adapt it later to be "good code" than it is to right the "good code" from the beginning, especially when you consider that you usually don't even need to adapt all of the "bad code" anyway
Many good points here I think. I think you mentioned this also but I often write relatively sloppy code in prototyping phase. Enterprice and game or desktop programming alike. Because of two main things, many times you do not know how one part will play together with another part. If you then have polished one part too much and you start the next, if they don't "play well " with each other, you have 2 main choises. Redo that polished part, or make crazy work around to glue those parts together (this is common in OOP). Sloppy code is much easier to delete or redo because you don't care about it as much. Then when the product, or at least the MVP is working like you want it, THEN you make the parts polished and extendible or what ever is needed.
This is a video I've waited way too long to watch but definitely one I needed, coding for over 4 years and never released even a simple game so far, with both a combination of irl issues slowing me down, and a tendency to abandon projects after spending too much time overengenering them ^^
I feel like you could do a whole other video, or series of videos, about what "bad code" means, and how the definition changes over time as you get more experienced. Everyone writes bad code at the start, because you simply have no idea what good code is. Over time, you can write "bad code" in strategic ways, such as linear searching an array rather than using a hash table, since those are trivially replaced later when the array gets large and it actually matters (in fact, using a hash table to find things in very small arrays is a known anti-pattern that hurts your performance!). It's definitely interesting to think about when and where to sacrifice things that aren't actually important, but which you've been taught matter a lot (e.g. OOP, which I now consider to be barely important even for very large projects).
Makes complete sense to me, learning how to write more extensible code and learning how to write dirty code quickly are both useful skills. The problem is I'm not nearly as good at doing either, the best I can do atm is mediocre. But I am learning!! :D
its like taking a loan the day before you die so you never pay it back
Perfection is the enemy of progress. Great video
ooo wise quote but I beg to differ. progress achieves perfection
This also extends to not worrying about the most efficient method I think too. Far too often I spend so much time planning best implementation than just doing
Interesting video. I think technical debt is something many people get wrong. They either use the term as an excuse to write bad code OR they use it to constantly rewrite their systems. I've found it's best to consider the risk of leaving the debt in VS how much effort it takes to fix.
The main problem for me is not "bad code" rather, especially in the Python community, is an over emphasis on readability over everything else. If you are in a team of developers who have different approaches to things, this understandable. However, especially with solo developers, readability becomes extremely redundant in some cases. If you understand the method behind your madness, especially if you come back to it later, there is no reason to follow standardization of formatting of code.
Since I'm still in the early learning stage of game programming, I like to write bad code so that when I come back to it later, I'll have more knowledge on how to tackle the problem. I find it easier than reading 10 documentations at once and writing the best code the first time.
Actually writing full fledge OOP is even worse than procedural.
how does one contact you if you don’t respond to your emails?
VERY INSPIRING!!!
Could you make a video on how to be a better at programming for rocket's software.
for me its all about performance nothing else matter just performant there is some down sides to this though like i have a 10,000 lines of code file and i am scared to do anything and have a headick when ever i do anything but if something gives me a 0.0000001% performance boost i am doing it
Hi could you make a video reacting to "Object-Oriented programming is bad" by Brian Will. I know the title seems a bit extreme but what matters are his arguments. Since I'm a beginner I can't really differentiate between what's right or wrong, or better and not better in terms of programming.
Greeting from South of brazil.
I don’t know if writing “bad code” is even faster then writing “good code” cause debugging, troubleshooting and making changes will take longer. Upfront cost is easy to calculate but hidden cost, and recurring cost can dwarf upfront cost. So you may think it’s faster to write sloppy code but amortized over the lifespan of the application it may slower. However sloppy code can make you feel like you’re making more progress but for a complex application debugging is 50% of the work so take whatever progress you think made and divide it by half. That being said, I usually promote refactor as you go so start out as simple/straight forward as you can and refactor if you see you code being used and updated more often (or is a critical component).
There's a reason why people, companies, countries use debt as a tool. It lets you achieve things in the short term and build beyond your means at the time. You have to use it wisely, but it's such a powerful tool that basically everyone needs to know how to use it.
If don't lag and you can read , so it's ok ?
Im not a bad coder… im just following your advice… totally
Hard agree, no need to waste time writing efficient and general code for something that doesn't require it. At best it's a waste of time, at worst it can end in big rewrites for no practical gain.
All code is good, bad is not to be able to code at all, we need to make things easier and easier not the other way around(BLOAT)
I do that all the time
Guess I'm doing everything right then
You're the best
It's not bad code as long as it works.
My code is bad no matter what I do
Well that makes you the one to call in the rare case a project only requires bad code :)
my code is the most efficient in the industry
okay
okay
Okay
okay
okay
Estou sentindo uma treta!
Volte do lugar que voce venho, doente
can you help me make a ryhthm game
Hiiiii
Meanwhile all the TF2 programmers.
I disagree with the title, you shouldn't ever write C++ code.
Simple ,
Write bad code where good code does not matter!
EZ clap
So Yandere Dev was right all this time?
I'm a simple person. I see a new fluffypotato video, I click.