Transcript
00:00:00Do you know why some people never seem to grow as a developer even though they spend years in
00:00:04this field? There are various factors involved. And one of those reasons is not understanding
00:00:09the underlying principles of programming. These are not just some theory concept you learn once
00:00:14and forget. These are the real stuff that will actually make you grow faster as a developer.
00:00:19Let's start with first principle, boy scout rule. This principle comes from boy scouts in America.
00:00:25So basically, they have this one simple rule, leave the campground cleaner than you found it.
00:00:31I don't know how many of you know Uncle Bob, but he is the one who popularized this concept
00:00:36among programming community, which is the practice of leaving code slightly cleaner than you found it.
00:00:41When making changes to an existing code base, the code quality will often degrade, which can
00:00:47increase the technical debt. And technical debt can be reduced by continuous improvement,
00:00:52no matter how small it is. Suppose, for example, you were assigned a task to make a change in the
00:00:57value in this function. You did it, but you can see that the variable naming is not understandable
00:01:03enough. So like most developers, you could just ignore it and commit what you were assigned.
00:01:08But if you follow this principle, you would also change the variable name to something more
00:01:12understandable. This is just a simple example, not just variable names, but if you see anything that
00:01:18can be improved, just do it. And just this simple gesture will be really valuable for the code base.
00:01:24Second principle, avoid premature optimization. So what this means is, don't try to make your
00:01:30code faster before it actually needs to be fast. First, make it work. Only then, optimize if needed.
00:01:36There was this famous quote by Donald Knuth, premature optimization is the root of all evil,
00:01:42which is true because programmers often waste most of their time worrying about the speed of
00:01:47non-critical parts of their programs. That's because there have been fade this concept of
00:01:51optimizing everything. This principle is not against optimizing your code base. It's about
00:01:57understanding what needs to be optimized and most importantly, when to optimize. And I think this
00:02:03is weakness of most developers because I have seen people using microservices even though they have
00:02:08100 users or adding a caching for something that is not even required. Third principle,
00:02:14write code for the maintainer, which simply means when you write code, you should write in such a
00:02:19way that the future developers who will maintain your code won't have a hard time managing and
00:02:23understanding it. That's because the code you write today will be maintained by other developers or by
00:02:29yourself. If you now just focus on making it work and don't focus on clarity, then in future if you
00:02:35need to come back to the code, you will have a hard time understanding what's going on. Just look at
00:02:39this example. Both of them work and do the same exact functionality. But which one would you prefer
00:02:45to see in your code base? So the takeaway is whenever you write or generate code from AI,
00:02:50always make sure that it's easier to understand and maintainable before you commit your work.
00:02:55So our fourth principle is called YAGNI, which is just a short form of you aren't going to need it.
00:03:01So this principle simply means you shouldn't build something you don't actually need or just because
00:03:06maybe you'll need it in future. Because most developers have the habit of predicting what
00:03:10they might need in future. But most of the time, they are never going to be used and just add extra
00:03:16complexity to the project. Always remember this. If you are working on something that may require in
00:03:21future, you are not giving your time to the thing you currently need. Fifth principle, do the simplest
00:03:27thing that could possibly work. So what this means is whenever you face a problem, always choose the
00:03:32simplest solution that would actually work. Don't overthink it. Don't over engineer it. Just ask
00:03:38yourself, what is the simplest thing that could solve this right now? This idea comes from extreme
00:03:43programming, which tells us to build something simple first, then refactor it into something
00:03:48better. Most developers don't realize this, but they often try to build the perfect solution from
00:03:53the start, which eventually overcomplicates their solution. With this principle, you get a working
00:03:59code sooner and even though you have to change later, it is usually easier than fixing a complex
00:04:04design that was wrong. And trust me, as a developer, realizing when you are over engineering something
00:04:10is very important. So these were the five programming principles that you should start
00:04:14implementing right away. Apart from these, there are also other principle which I haven't covered
00:04:19in this video. If this was helpful, let me know in the comments and I'll create a second part for this.
00:04:24For now, let's do this much. Make sure to show some love and I'll see you guys in the next one.
Community Posts
No posts yet. Be the first to write about this video!
Write about this video