Clean code practice

- Yes, document your code. Next. Testing is very good. You need to figure out ways to do that, because when you're starting to work with a reusable framework over time, you need to make sure that you're not experiencing regressions. But that seems kind of obvious. So going into writing clean code, I think this is the most important thing to go over. There are a lot of things that processors these days brag to be able to do on the orders of thousandths or 10 thousandths of seconds. If you're not in an academic environment where that kind of edge is required, and I've been in that kind of environment where 1/10,000 of a second is important, it's not so common to run into that anymore. Make sure that what you make works and make sure that you're open to learning new ways to do things. Let's say, for example, you iterate through a loop of something and someone says, "Oh, it sucks that you did that that way. "I have a better way to do it, "and it'll save you 1/100 of a second." Consider the pros and cons of that. Don't just blindly go into it because it's automatically better. It might be a more difficult way to go about it. It might not fit into the scheme of your application or your framework that you're developing. But just make sure that it works for you. Consider the environment that you're in, whether or not that kind of time difference is really important and pertinent to what you're working on. But when it comes to writing clean code, don't be afraid to make mistakes and be open to constructive criticism from people. - I would say, for one thing, do what works for you. Not everybody else's process is going to be the exact right process for you. Also, again, take the time to be passionate about the code you write. When you write something that's ugly and it's going to keep you up that night, try to take the time to go back and clean it up. It won't probably take as long as you think. Also, share that with other people as other people shared that probably online with you through various resources. And that can help improve it. They can make suggestions to your code. But really be passionate about it. Enjoy it. Sometimes that elegance of something you write is something you can really be proud of, even though, again, a lot of people may not see it. You'll also be glad a year from now when you have to go back in and change it or fix bugs that it was well-written and nice and clean. But that's part of it. I mean, sometimes the back of a tapestry can be artwork too, and so sometimes the code is something that you can really take pride in beyond just the result of the app running on the phone or whatever you're developing. - We write documentation, and everyone assumes that because, whatever, you speak fluent English and that you can write English, therefore you can do documentation. But it really doesn't work that way. Documentation is all about who you're writing it for. You have to understand your target audience. Who actually is going to use your product? And how can you present this information in a very clear, concise way? Developers in general overestimate how much their target audience knows always. So you need to think lower. If you make the documentation too basic, quote, too basic, it's really not too basic. It just means it's very understandable for beginners. And for advanced people, they get to what they need really, really quickly. You're not going to offend anybody if you make your documentation too easy to understand. - Good documentation has saved me so many times. I can't even tell you how many times. Because especially now in my career where I'm working on multiple projects at the same time, each process has its own needs, its own bits and pieces, being able to refer to a source of truth where this is how we're doing the project, this is what our expectations are for the project, that's an amazing thing. Now, keep in mind that I am referring to documentation at a larger scale, at a project scale. I work at the project level, and so I'm always thinking about what are the style guides we use? What's the playbook we have in place for this? What are our standard solutions for issues? Do we have our continuous integration system in place, our CI in place? There's also code level documentation. My preference for code level documentation is self-documenting code, which is its own sort of technique, its own skill, being able to write code in a way that is readable. I forget who said it, very famous developer. He basically said he spends 90% of his day reading code. That was a very powerful moment for me, because I realized he was absolutely right. I spend more time reading code than I do writing it, and so having self-documenting code, code that's easy to read, that makes sense as soon as I see it, I don't have to think about it beyond what I'm seeing, that speeds up the process tremendously.