@mikeuniturtle3722
This is just my job for the next 20 years, I work in a city government district and we are currently going through 20+ year old code that has only had code slapped onto it. most of the code was from contractors who no longer exist. Its made me realize im a lot better at this job than I ever thought, and that I still have way more to learn.
@fancytanookisuit
Thank you so much for videos like this Tim- as someone with a long career in software development, it never ceases to be frustrating how little consideration the average consumer gives to the intensely hard work that goes into making "good" software, especially something with the complexity of a CRPG.
@jaredfry
Thanks, Tim. I appreciate that you took the time to unpack some of the feelings-based motivations for programmer-types. Writing software is, by-and-large, a creative act. Programmer-types can act like artist-types more often than non-programmer/non-artist types might assume. In a world where programming is less-and-less understood, I hope that this video will help someone treat a programmer with more understanding.
@Comedian-pn6xd
Thoughtful and interesting talk. However, its worth pointing out there's a distinction between Refactoring and Rewriting. A lot of your presentation was really about the latter (and your points in that regard are highly astute). Mixing the two issues is common and unfortunately the distinction is rapidly getting forgotten. To be clear - Refactoring has some important properties. - It is done continually - it is not a distinct project phase. You should never make a conscious decision about it, its just a code writing habit. The old Red Green Refactor cycle. - It is very, very small. "Refactoring" projects or a "large scale" refactoring are bordering on oxymorons - it should never have got to this stage; you are now "rewriting". - It is never done without automated tests in place (so avoiding the issue of bugs, mostly). - It only changes the structure of the code, never its function. You are mostly eliminating duplication, making your code readable and adhering to whatever best practices are common for your paradigm. - It is not done with performance or re-use in mind - those may be side benefits, but they are not the primary goal of refactoring. In fact, as you allude to, the best first condition for code to be in is well organised - this makes potential optimisation much easier IF its needed. Its a continual, constant activity that prevents code sprawling. Also, its important to recognise that almost all of us write software in a commercial context. Having well-structure code should never be a "discussion" with non-developers in the first place. It puts quality/best practice in direct conflict with commercial pressure - this does not need to happen. Using the "quality" lever when delivering projects should come with a triple rated health warning :) Its better kept set to "high". And, human nature being what it is, if refactoring is not a continual, integrated habit, by and large it will not get done sufficiently to have any real impact - and big rewrites become the norm. All this works only because, the red-green-refactor cycle allows you to work more quickly, and thus any perceived "overhead" is more than traded off. Kr Great vids btw...
@penvzila
In my previous job a common reason to go refactoring was usually to make something easier to understand so that we can find security issues. The second most common reason was to get time spent executing down because the code was executing in a factory environment and seconds mattered.
@elfteiroh
I have had one occasion where someone, despite my numerous comments explaining parts of the code accounting for edge cases, got the idea of refactoring to… remove all of them. “They are not needed, these cases will never happen, your over-carefulness is the reason the performances are bad.” Turns out, the day after they made their commit, a bunch of bugs get ticketed for that system. ALL the edge cases were present in the game, and his refactoring let them crash everything, AND he didn’t test with the actual data we had… sigh in the end, I went back to fix it all and to look at how it could be optimized… and the ACTUAL problem was that the server backend had a bug that made it ignore the actual config to use a hardcoded limit of 500 items in the database and we had hit that limit… (Funnily, later, we ended up hitting the actual hard limit of the database, and I ended up needing to create a “pagination” system to manage that monster… and an indexing system. Yeah! Recreating SQL features in house! /s)
@Anubis1101
I couldn't have gotten to a Tim Cain refactoring video at a better time. I just finished the Vulkan tutorial, and now I've got to refactor the code, which was written primarily with the tutorial in mind. That means things like reconstructing a struct entirely within a performance-critical loop, even though only one member of the struct changes each iteration; or using the same name for a variable that's instantiated multiple times in different scopes. Some things, I just don't like the way they did it, it's not how I would write it. I have to go through and decide what I should fix and what isn't worth it, and this video helped me think through it a bit. I love your programming videos, please make more!
@robtibbetts890
This is probably a top-10 most interesting CoG for me. As a career game tester I’ve heard engineers talk about refactoring many times, but haven’t gotten a window in how, why, and why not to do it. Re: spaghettification, there’s currently a vicious cycle where the person who wrote initial code has been laid off, which means there might be no knowledge of why specific code was written as it was, leading to later code that is spaghetti’d on. Then the new person leaves and the next person doesn’t k ke why the initial spaghetti was made or how the new spaghetti is meant to work, so they add more spaghetti.
@luisarthurlobo
Cain, i admire a lot your job and your attitude to share knowlege. Even tough im not a game dev, i use your advices to be a better product designer/product manager and i even recommend your channel when i teach at universities here in Brazil I just want you to know that you are helping to change the world with your videos.
@ray3369
This channel is awesome. Appreciate all the wisdom and knowledge transfer Tim!!
@Jrhovet
The line about programmers using “logic” to back up things that are really just feelings hit close to home. Programmers sometimes like to think that we are as logical as the computers we work with, but unless your name is commander Data, we’re just as human as everyone else.
@ringo2715
This is a top tier Tim Cain video
@mattball8622
Great video, and really thorough! Love the point about being able to adequately pitch a potential refactor, and how that should show if its needed or not. I've been a software engineer for twenty years now and I've seen people (including myself) fall into the trap of chasing the myth of the perfect piece of code. Not being able to demonstrate benefit to someone can lead to a bit of erosion of trust too, sometimes to the point I've seen pushback on any refactoring at all because there's been no past benefit. Not a situation you ever want to be in!
@999998646565
Great video! Was really nice to see that perspective on refactoring. One of the biggest things for me in it was that sometimes "going too clever" might hurt more than help, that made me relax a little about how i like to write code. Thank you!
@TheTooBig
Hey love your videos! One little thing i have noticed here bingewatching, as a non-native speaker understanding speech needs more concentrating than usual. Noticing hand gestures, looking at the persons face help with it, but noticed that background has reflective surfaces, and that makes it more difficult to follow when my attention moves to tertiary things. Really interesting channel by the way, extremely fascinating. Video games are a big part of my life, fuel for my imagination, and being inquisitive i love the behind-the-scenes stuff. Hah, I learned written English before elementary school, playing adventure games like Leisure Suit Larry and other suiteable education games! Considered a career out of it, could still happen sure, but not sure what field. tl;dr: movement attracts attention. attention span low. hand gesturing good, reflections showing gesturing or any other movement bad. Thank you for being a part of the positive things in me and my childhood,
@tomasz.kozlowski
Thanks! I am watching this x2 speed and making notes. I have in a moment a meeting where I need to explain why we need to refactor a lot of code :D Wish me good luck!
@whiitehead
I like to start my day with like 20 minutes of refactoring just to get in the programming mood and get warmed up.
@Konspiracie
This was a very helpful video for me. I've been working on a game project since August and can feel the impending need to refactor my input handling. However, each time I consider doing it, I realize that it's working just fine right now and that there are better things to do. Glad to know that I might have the right idea of focusing on more productive things until that refactor NEEDS to be done.
@jwmcq
Definitely agree on having to avoid getting too clever with the code! Reminds me of Kernighan’s Law: "Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
@MattPritchardOfficial