Good coding habits to start developing NOW

hey friends how's it going so today's video is sponsored by fafsa they asked me to write a question for their techie test if you're based in the uk and can answer this question hint it's a sql question you have the chance to win the ultimate work from home desk setup worth up to 5 000 pounds link in the description and also go into more details later in the video well let's dive into it for those of you who don't know me hi my name is tina i'm a data scientist at a fang company and i've been coding for around five years now i think if there's one single truth about coding it is the fact that it is hard it is really hard it's really easy to have a really complex problem when you get really frustrated and then you just give up it's also easy to really hyper focus into one single domain especially if you work for a larger company to just be really good at doing one single thing and that becomes your specialty which is fine but then that also means that you really stagnate right you don't really progress as a developer as a data scientist as a software engineer you don't really get better anymore and of course there is the always looming doom of burnout so over the years i have learned to develop some good habits some of these i stumbled across just by trial and error and some of them were words of advice that were given to me by mentors number one is to always plan your project and

your analyses this goes for data science or software engineering for development any type of technical project it also goes for non-technical projects as well but especially in technical projects it's really important to have a good plan when i first started out coding i wouldn't have a plan i would just be like okay i gotta solve this issue where i gotta make this project and then i would just start coding right i just be coding and coding and then i run into issue and i try to solve it but what i realize in the end is that if i had actually planned upfront it would have taken me so much less time because when you're just not planning and just coding in general you don't know the best way of utilizing other people's code what's already been built and you also don't really have that foresight of knowing what kind of issues that you might run into if you plan for you would know how to bypass some of these issues by having other alternative ways of doing things or when that time comes you would have a better understanding of what your options are and be able to make your decision onto what path to take more quickly not to mention more often than not if you don't plan ahead of time and you just start coding and you just think that you're quoting the right thing you probably at some point will figure out that you actually need to refactor your entire code base because what you thought you were doing what you wanted at the end isn't exactly what you were coding because you didn't have that foresight so what's really important before starting to write any code at all is to first scope out your project what are the key features that need to be implemented what is the key questions you're trying to answer in your analyses then you need to have a plan for what components need to be done and when you're going to do each thing and lastly i would also recommend just looking at the tools that you'll be using in the project what you think and see if there's anything clearly out of alignment or if there's like you know one way of doing things that is clearly superior to another maybe someone has written a module a very handy module somewhere where you can just incorporate that into your project instead of having to write things from scratch with all this being said though you also don't want to over plan you don't want to like sit there try to exactly figure out every single little detail or anything like that because there's also two fundamental truths about all technical projects the first one is that nothing goes as planned even if you plan super well there are going to be deviations to that and number two is that things always take longer than you think they're gonna take the way that i like to view my plan is that i see it as a guideline not like a definite plan um and i actually put in flexibility within it so for example if i know i need to do something i would actually list out a few different tools or a few different approaches that i can take so that when the time comes i would just choose whichever one fits the most at that time number two is to document

core ideas and code snippets i tend to see two different extremes when it comes to documenting stuff there's one type of person who would literally document every single thing down like they would like copy the api that they're looking at and just write everything down in their own document and then there's the other type of person who would just be like oh whatever like i'll figure it out i'll just like come back to this page at some point so my opinion is that you should be somewhere in the middle like you don't want to be spending so much time that you're writing everything down because you know you can probably just look up most of that and that wastes a lot of time but you also don't want to be that person that would just be like oh i'll figure it out eventually it's like future tina problem but when the future tina finally has to do it you waste a lot of time because you kind of forgot how things worked where the code that you need to copy is so you have to go do that again what i like to do is to document only two types of things the first one is code snippets i find myself copy pasting over and over again for me these tend to be handy functions uh boilerplate code and also definitions for graphs so the code definitions because i tend to use similar types of graphs the second type of thing i document is core ideas or approaches to solving a problem as you gain more experience coding you'll find that a lot of projects or analyses will fall into specific types of projects or analysis and you would use a very similar approach when you come across those kind of problems so what i like to do is that i like to document down the steps in order to solve that kind of issue or do that kind of project because if i'm working on one project that's like a specific type of approach and then like two months later i'm working on another type of project that i've done previously i probably would have forgotten all the things i knew previously so by documenting the approach i can just very quickly run over that approach and be like oh yeah these are things i need to do and then i would be able to use that approach for that project an example of this would be documentation of the approach i take for eda number three is learn how to learn

programming is all about learning new things i would actually argue that it's a field in which you have to be constantly learning because there's just so many new things that are being developed every single day there's new technologies are being developed there's new tools that ways of solving problems that are always being refreshed the best programmers are the best problem solvers and in order to be really good at problem solving you need to have a wide range of tools for you to use and the way in which you gather these tools is by learning these new technologies that are coming out and these new approaches and always learning about everything that's around you so that when the time comes you have that in your toolkit to solve the problems at hand i would recommend two different types of learning the first one is what i call diffuse learning it's when you see something new something interesting maybe it's a new like technology that's come now and maybe for example like gpt3 you're like what's stupid d3 this is very interesting so then you set aside time preferably every day where every other day maybe like an hour or so that you actually learn these new things that are coming out that's not associated with any specific project that you're currently doing the second type of learning is to volunteer for projects that are outside your comfort zone this is especially applicable if you're already working for a company generally people get choices about what projects that they want to do so usually if you don't volunteer for new projects people will probably just give you the projects that you're the most competent at doing because you have the most experience what i would recommend is actually expanding that and asking for these projects that you don't have a lot of experience in for the ones that you don't feel super comfortable about because by having that project it forces you to expand your toolbox learn new things i have a video that goes into a lot more details about how to learn which i will link over here and the video is called how to learn technical things let me tell you a little bit about today's sponsor fast homes is a uk-based web hosting company which offers a wide range of web hosting products and other services they aim to support uk businesses and entrepreneurs at all levels providing effective and affordable hosting solutions to suit any needs today i'd like to highlight two of their services the first one is their virtual private servers that allow you to deploy your own software or data science projects you also get experience managing your own server based upon linux for windows which is a skill that comes in very handy whether you're a software engineer or a data scientist you can get started at just one pound per month another product i'd like to highlight today is their cloud backup service data laws can strike at any time and for any reason like if beep sits on your laptop and deletes everything so give yourself one less thing to worry about knowing that you can restore your data not only from your websites and servers but also your mobile devices too you can test it out by getting five gigabytes of cloud backup for free all right so now how do you get the chance to win the ultimate work from home sell so two criteria as i mentioned before you do need to be based in the uk sorry my non-uk friends and the second thing you need to do is to answer the techie test question drum roll please the question is what is the sql function that combines one or more results into a single table without removing duplicate rows so if you're based in the uk and you can answer this question head on over to the link in the description box to enter your answer for a chance to win now back to the video the next good coding habit to start developing now is making time

for deep work is a concept that's popularized by cal newport in his book called deep work it's about having uninterrupted periods of time for you to get in the zone and really get substantial amount of work done it's the opposite of shallow work which is about when you kind of pretend to work but you're being distracted by a lot of things around you you're like checking your phone you're like looking out the window and then maybe like an hour passes but you realize that you weren't really focusing on what it is that you're trying to do what i would recommend is to schedule at least two to three hours and up to four hours of deep work there's research that shows that you also don't want to go over four hours because that's usually the threshold for people's concentration and during that period of time to focus on the most important task and really try to knock that out this may not be possible for everybody but i do work at a place that gives me a lot of flexibility so what i like to do is schedule my deep work earlier in the morning and then around afternoonish i would then schedule all of my meetings in this way i had that uninterrupted time to do all the deep work that i have to do obviously there's meetings that i don't really have that flexibility to reschedule uh so those i do go to but what i find is that having that standard of doing deep work earlier in the morning and meetings and afternoon it becomes a really good habit and also the people that work with me know to not interrupt me during my periods of deep work the next coding habit is having break schedules coding is a really mentally draining activity and you need to be able to preserve your energy and your focus throughout the day when

you're coding there's this concept of focus versus diffuse mindset i first came across this from the course called learning how to learn by barbara oakley and what she explains is that in the focused mindset this is equivalent to deep work when you're really focused on solving that one question and the other type of mindset called diffuse mindset is when you're not focused specifically on one thing and you're kind of doing other stuff but in your subconscious brain a lot of information and the problems that you're trying to solve is still working itself out even though you're not consciously aware of it and this is the mindset where there's a lot of connections that are being made from distant parts of your brain that kind of come together subconsciously you may have experienced this yourself anecdotally maybe you're working on a coding problem and you're just like i have no idea how to solve this like oh my god this is like literally i just don't know how to do it right it's like i'm just banging my head against the wall over here and then you go out and you go for a walk or something and you're not particularly thinking about that problem you're just going for your walk and just trying to clear your brain and when you actually come back you're like oh i know how to solve it now it's like that solution just kind of pops into your brain that's because when you're taking a walk in that diffuse mindset subconsciously parts of your brain are actually working together and making connections that ultimately led to this solution and it seemingly popped into your brain and another reason to take breaks is to prevent burnout and also to make sure that you can actually focus throughout the day instead of just you know focusing really hard for two hours and then being useless for the rest of the day what i like to do is pomodoros i work for 50 minutes and then i take a 10 minute break afterwards and then i do that over and over again throughout the day some people prefer to do like 25 minutes and five minute breaks uh some people do like one hour and 10 minute breaks fifty and ten just works the best for me and that's something that you need to figure out for yourself through trial and error and ground number seven now i hope it's number seven is having a routine to get yourself into the zone i

have a specific routine that's become a habit for me i get myself in the correct mindset to code i think there's some people out there that are just like yay coding like i'm always in the mood to code but for me personally i have to be in like a quite a specific type of mindset and prepare myself to be in that correct mindset and what i usually do is i have a cup of tea which i put oat milk in it um and then i would usually sit down and i have a very specific playlist that i always listen to get myself into the coding vibes and then i would start coding by having this routine i can very quickly get into the zone and start working especially if i couple it with a habit that i talk about in my anti-procrastination video which i will link over here it's about preparing for big projects the day before so then the next day you can really just jump straight into it and start working on the coat and start coding immediately so the next day for me i would know exactly what i need to do so i would go through this routine of drinking my tea and listening to that specific music which will get me the correct mindset and then i can immediately start coding it takes me about like five to ten minutes or so to get to the zone okay final habit is to lose the ego and just ask for help

there's like this depiction of the lonely programmer or the lonely genius hacker person who's just sitting in the dark being like this the whole time and that is just so untrue coding is a team sport it really is in fact the open source community for coding is probably the most collaborative place on the internet it's all about people helping each other out if you're stuck on something instead of just banging your head against the wall for three hours just go and ask for help like i said earlier programming is all about problem solving so if you can actually ask for help and get the answer and fix your thing that means you're a better problem solver than the person who's just banging their head against them while trying to fix it themselves and in the future because you're able to assimilate information that people help you with next time you come across a problem like that you know how to solve it stack overflow is always open on my screen and my other general rule of thumb is that i will always try to figure things out for one hour with the help of stack overflow in the rest of the internet and if i can't figure out that point i would just go ask them leaning on that open source culture and just also contributing towards it and also make you better as a programmer all right now that is it for this video on good coding habits i should start developing now i'll see you guys in the next video or live stream