5 Ways First Principles Thinking Helps You Code Better

Key Takeaways

today I want to talk about how first principle thinking is going to help you become a way better software developer what does that mean a first principle is a proposition assumption that you can't deduce from any other proposition or assumption that's from Wikipedia and it may sound a bit complicated but basically it means think like a scientist now you may think what does that have to do with software design and development actually quite a lot as I was thinking about this I realized that a lot of the things that learned over the past few years actually come down to more first principle thinking and applying that to the way that I design and develop software so today I'm going to cover five ways in which first principle thinking has helped me become a better software developer and once you're aware of these things they'll also help you improve your own skills the first one is that you should identify and Define what fundamental truths are so if you identify the most basic truths or elements in a problem that's actually really important when you're developing a piece of software this can include analyzing the needs of your users having a good understanding of what your software is supposed to do having an understanding of what the domain looks like basically before you spend any time trying to actually solve a problem you need to spend time understanding the problem but it's not just the problem itself that you need to understand it's also understanding the benefits limitations of the tools that you're using what are the strength and weaknesses of programming languages the cloud infrastructure that you're intending to use any of the supporting tools when you Zone in on these fundamentals you going to get a better understanding of what the problem looks like that is trying to solve and by understanding better you'll reduce the chance of making mistakes later now when I say understanding I don't mean that you should design your software to The Last Detail I'm not promoting that we all go back to the word full model it just means that you optimize for problem Clarity so you'll have less surprises when you start solving things and what's interesting is that that also relates to your own limitations as developer as well if you're asked to develop a feature you may be tempted to try that new library that you heard everybody talking about because you want to learn how to use the library but realize when you do that that you're actually changing priorities you introduce an unknown you don't know how that library is going to perform because you never used it so what is your priority do you want to learn about the library and accept that the project may be delayed because it's going to take you more time or there are unforeseen consequences of uset library or do you want to focus on adding the feature on time and making your customers very happy and there may be an overlap because that Library might actually solve a problem that you're looking to solve but be aware that you are prioritizing you want to deliver the feature or you want to improve your skills you need to pick one if it's improving your skills that's fine but make sure you're transparent about it and that it may lead to un seen problems or delays it actually took me quite a while before I really understood that improving my skills and delivering feature would do different things it may seem like completely obvious but it's really easy when you're in the thick of things to just forget about that distinction and diving into some sort of rabbit hole and never getting out of it again a second thing you should do is break down problems to their core so next to understanding problems it's also really important to dissect problems and understand what the core components and challenges are and this can actually lead to better solution because then you can address the root of that problem for example let's say you get a task of creating a system that analyzes stock portfolios and then prepares reports automatically so instead of just diving in and start coding and coming up with ad hog Solutions you can also first take some time and break down the problem to the core and then you might realize that in essence this application is a data Pipeline and that means you can use a pipeline or workflow system and build your whole application around that with which leads to a much more flexible solution now if you didn't break up the problem before you wouldn't have come up with that solution another way of thinking about this is how you incorporate design ideas into your coding practices I sometimes hear other developers ask what design pattern should I apply here in my opinion that's actually the wrong question to ask it's not about applying design patterns it's about understanding what a problem actually is and once you spend the time to understand the core of a problem then deciding on the design pattern that should solve it is actually trivial because design patterns are intricately linked with classes of problems so instead of asking what kind of design pattern you should use ask yourself what kind of problem is this in the core what kind of thing are we dealing with and then take it from there the third thing is to reassemble elements innovatively so once you understand basic elements of a problem you can can reassemble them in innovative ways and that's going to create new solution and often this is where big breakthroughs and really new things happen it may sound cliche but the iPhone is a really good example because it combines separate things into an Innovative new single device when you think about software design don't feel obliged to follow design patterns to the letter but adapt them to what you actually need and combine them in different ways and same goes with functions you can also combine them in various ways you can pass a function as a parameter to another function you can put functions in a list or a dictionary you can use closures you can have a function that returns another function there's tons and tons of possibilities another new area where you can think about these kind of things is large language models how can you incorporate them into the software that you're developing what kind of features are suitable to use an llm for and how does that integrate with the rest of your code and what does it mean in terms of the function alities of what it will deliver the fourth thing you should do is validate your assumptions regularly as you're developing that piece of software always question and validate your assumption throughout the process it's going to keep your solution relevant it's going to avoid unnecessary complexities in the past it happened to me quite often that I ended up diving into some sort of rabbit hole to get a feature working exactly the way that I wanted to but when I thought about what was actually needed in most cases I could have saved myself bunch of time by just letting go of some things for example I remember a project where I was spending way too much time trying to fix some esoteric typing issue with generics I mean type annotations are great and awesome it's really nice if you can get them just right but in some cases it doesn't have to be perfect sounds weird me saying that but it doesn't have to be because especially if it's code that just you are going to use internally it doesn't matter too much and it's way better to spend your time on something that's going to make a bigger difference another another way of thinking about validating assumptions is by writing software test write unit test using for example by test to make sure that the code you wrote actually behaves as expected so don't assume that write a test to check it to make sure and by writing this test you're setting up yourself to validate those assumptions regularly and even better automatically the fifth thing you should do that's actually one of the most important things is to focus on Simplicity and functionality it's really important to maintain a level of Simplicity in your solutions to make sure that they're functional user friendly and not overly complex if you keep your code simple it's often easier to test and also easier to maintain so I always start with a simple solution and only introduce complexity if it actually solves a problem functions for example are typically a bit simpler to deal with in classes and inheritance so I tend to start with functions nowadays and only use classes if that actually leads to a simpler solution and same holds for other more advanced features of python for example I don't really use decorators or context managers or meta classes a lot because in my opinion they're often not needed and I prefer to keep things really simple and that also makes it much easier for me to test my code I will only use something like a decorator if I'm really convinced that hey this actually makes the code a lot simpler and a lot easier to deal with otherwise I just keep my codes using the basic set of features because honestly it's just a lot easier to manage and here's a bonus tip just make sure you learn continuously if you develop for yourself a culture of continuous learning and being curious that's actually vital to applying first principle thinking when you read books read articles watch videos it's going to help you get a better clearer perspective on the problems that you're trying to solve and it also goes for being updated with technological advancement and new programming languages for example now that python 3.12 has introduced way better generic types you can use them to write code with better type annotations assuming that you're not diving into some sort of rabbit hole like I did a couple of weeks ago another thing you can do to make sure you continuously learn is to make sure you're part of a community to help you my Discord Community is a great example of culture that encourages sharing knowledge and helping out each other if you'd like to join for free just go to discord. codes link is also in description below so this has not been my typical tutorial video where I show you a bunch of code but it's more a thinking video so I'd like to hear from you do these things trigger something do you recognize instances where you didn't do some of these things where you didn't apply first principle thinking and it led you to wrong decisions what were the consequences of that do you agree at all with this first principle thinking view on software development and design let me know in the comments by the way a good example of me applying first principle thinking is in my recent refactoring video where I show a five-step process that you can use to make dealing with Legacy code way easier you can watch that right here thanks for watching and see you soon