🗣️ Discord is now available, come chat!
🔗 https://discord.gg/Y7hEKnxPGf

To support the channel and get some nice perks:
💟 https://www.patreon.com/coderized

Regardless of your current skill level, embracing clean coding practices, establishing maintainable code structures, and effectively managing oneself are crucial for becoming a competitive and sought-after programmer in today's professional industry.

In this guide, we will explore essential coding topics that every proficient programmer should be well-versed in:

- Adhering to programming standards
- Programming design principles, such as:
  - Single Responsibility Principle
  - Open/Closed Principle
  - Liskov Substitution Principle
  - Interface Segregation Principle
  - Dependency Inversion Principle
- Design patterns, including:
  - Creational patterns
  - Structural patterns
  - Behavioral patterns
- Enhancing code readability through effective naming
- Testing concepts, like:
  - End-to-end (E2E) testing
  - Unit testing
- Managing time efficiently
- Strategically pacing project development

---

It's important to recognise that everything I present here is just a guideline, not a rule. I call them "sins" but in reality, there's exceptions to everything. I think all of the points mentioned in the video could misused, if you're not careful. I've seen people who over-engineer simple codebases to the point it's unreadable, just to have a fully modular codebase; or obsess over perfectly following standards, even when it becomes incompatible in certain situations; or spending way too much time trying to achieve 100% test coverage, when it added no more benefit to do so. 

The best way to interpret this video is to have a little understanding of the topics, and choose the things that you want to learn more about. This is not a doctrine in any way, just some tips to kickstart more knowledge and understanding. Everything mentioned in the video once had a pain point behind it that will have led to its creation, but maybe you don't have these same pain points... yet! Just remember the potential solutions for when you do, or use them as a foundation for your own exploration!

---

(longer description)

Are you ready to level up your coding skills and avoid the seven deadly sins of programming? In this video, we'll explore common mistakes made by developers and how to fix them, leading to better code quality and more readable code.

Join us as we dive into programming standards and the importance of consistency in file structure, whitespace, and coding philosophies. Learn about SOLID principles, a set of design principles that will help you write maintainable, scalable, reusable, and testable code. We'll also discuss programming design patterns and how they can serve as a universal vocabulary for better understanding your code.

Discover the importance of using descriptive names in your code and explore various testing methods, from end-to-end testing to unit and integration tests. We'll also touch upon time management, emphasizing the need to provide accurate estimates and avoid rushing through projects.

By the end of this video, you'll have the tools and knowledge to create clean, efficient, and human-readable code. As Martin Fowler once said, "Any fool can write code that a computer can understand. Good programmers write code that humans can understand." Let's get started on your journey to becoming a better coder! Don't forget to like, comment, and subscribe for more programming tips.

---

Special thanks go to Vita and Jakob, for helping me with all my thoughts and suggesting improvements!

---

00:00 - Welcome the 7 deadly sins of programming
00:37 - You should pick and use a standard, always
01:19 - Principles are the lifeblood of programmers
04:45 - Patterns let us learn from our programmer ancestors
06:20 - Names are often badly... named?
07:58 - Tests give us confidence
09:06 - Time, the impossible enemy
09:51 - Speed vs. productivity, what's better?
10:39 - Leveling up

#programming #code #coder #coding #programmingtips #codingadvice #programmingstandards #designpatterns #namingconventions #codetesting  #timemanagement #codingproductivity #programmermindset #codequality #codereadability #maintainablecode #codingbestpractices #programmingmistakes #codingpitfalls #betterprogramming

---

Special thanks go to Vita and Jakob, for helping me with all my thoughts and suggesting improvements!

There are what I would consider to be 7 deadly sins when it comes to programming.

Things that will grind your code quality into dust if you don't heed their lessons.

Now I hope you've never had to hear someone tell you that you write bad code, but if you have, there's really nothing to be embarrassed about.

We all write flawed code as we learn, and the good news is, it's fairly straightforward to make improvements if you're willing.

In essence, that's why I've created this video, to guide you to becoming a better coder.

So let's look at the mistakes you might be making and see if we can fix them.

The first thing I see people doing is not using programming standards.

They give us rules to follow, like white spacing, file structure, and other philosophies that we apply to make our code consistent and therefore easily readable.

It's also especially important when working with other people, because it allows everyone to rely on shared expectations.

If we don't keep standards, it's kind of like switching fonts all the time.

We can read it, sure, but the subtle differences throw us off and slow us down a bit.

As for choosing a standard, if you aren't given 1 by your team, then there's plenty to choose from in the wild.

The second thing, programming design principles, are probably some of my favourite ways to improve.

You can think of principles like a general guide into becoming a better programmer.

Now there's a lot of principles out there, too many to cover in this video, but I will quickly show 5 very important ones which go under the acronym of SOLID.

The S in SOLID stands for single responsibility, and it teaches us that we should aim to break our code down into modules of 1 responsibility each.

So, if we have a big class that is performing unrelated jobs, for example, we should split that up into separate classes to avoid violating the principle.

It's more code, yeah, but we can now easily identify what the class is trying to do, test it more cleanly, and we can reuse parts of it elsewhere, without having to worry about irrelevant methods at the same time.

This actually becomes more important as we progress.

The oh-so-open-close principle suggests that we design our modules to be able to add new functionality in the future, without having to actually make changes to them.

Instead we should extend a module to add to it, be that wrapping it or something else, but we should never modify it directly.

Once the module is in use, it's locked, and this now reduces the chances of any new additions breaking your code.

Luckily, the Luminous Liskov leaves us a lesson that loosely limits how we leverage our legacy code.

Liskov wants to tell us that we should only extend modules when we're absolutely sure that it's still the same type at heart.

For example, we can probably extend a hexagon into a six-pointed star, because that still makes sense as a six-sided shape.

But we can't really do the same if we wanted a 5 or seven-pointed star, because that would no longer be compatible with what a hexagon represents.

It just wouldn't fit cleanly anymore into parts of your code that expect hexagons, and so it will have failed the principle.

If that's the case, it should extend something that fits its design, or become its own type instead.

Almost at the end now, and we have I for interface segregation.

It says that our modules shouldn't need to know about functionality that they don't use.

We need to split our modules into smaller abstractions, like interfaces, which we can then compose to form an exact set of functionality that the module requires.

This becomes especially useful when testing, as it allows us to mock out only the functionality that each module needs.

Which brings me to Big D, which stands for Dependency Inversion.

This 1 is pretty simple to explain because it says that instead of talking to other parts of your code directly, we should always communicate abstractly, typically via the interfaces we define.

Dependency inversion breaks down any direct relationships between our code, and isolates our modules completely from 1 another, meaning we can swap out parts as we need to.

Because they communicate with interfaces now, they don't need to know what implementation they are getting, only that they take certain inputs and return a valid output.

The cool thing about solid is that when we combine all these principles together, it ends up decoupling our code, giving us modules that are independent of each other and making our code more maintainable, scalable, reusable and testable.

Programming design patterns, not to be confused with principles from the last chapter, are also something I see underused a lot, when they really should have more of a place in your mind.

Patterns give us some real solutions to our code problems, but they aren't fixed implementations, so they're still kind of open to interpretation.

We use them to architect our software systems, matching the right shapes to fit the needs our software has.

First up, we have creational patterns, which are there to help us make and control new object instances, such as the factory method pattern, which turns a bunch of requirements into different modules that follow the same interface, but aren't necessarily the same type.

Then there's structural patterns, which are concerned with how we organize and manipulate our objects, such as the adapter pattern, to wrap a module and adapt its interface to 1 that another module needs.

Finally there's behavioral patterns, which focus on how code functions and how it handles communication with other parts of the code.

Such as using the observer pattern to publish and subscribe to a stream of messages in an event-based sort of architecture.

Now there's a bunch of different design patterns under each category, some of them you might have used before.

A lot of these patterns are used by frameworks and by professionals in huge corporations, and that kind of ties in with another pretty unique benefit.

The benefit of creating a universal vocabulary of programming.

Have you ever written some code that seemed great at the time, but later you had trouble understanding it?

Well, it often comes down to the way you name things.

It's quite short, but it's hard to interpret what's going on without some thoughtful analysis.

First up, we should avoid unnecessary encodings, such as type information, which make it harder to read code in a natural way.

Next we have many abbreviations and acronyms that don't really explain well enough what they are.

We should expand them to their full names to avoid any miscommunication.

Looking better, but it's not really clear what some of these variables hold.

We should aim to use names that more accurately represent the nuances of the code we're working with.

We also want to replace magic values, such as the organ index or trigger word string, with named constants.

By doing so, we clarify their significance, and we help to keep things in sync if they're used elsewhere.

Ok, we can now read this code and understand what it's doing without having to think too hard about it.

However, we can still improve it further.

If you have any compassion for your future self, or other unfortunate developers who might have to read your code, be descriptive with your names.

Ideally, we want to find a balance between being clear enough to quickly understand what the code does, without being so verbose that it becomes an information overload.

Remember that no matter how good you think your code is, if it's not easy to read, I would argue that it's not actually good code at all.

Many people don't test their code, and that's understandable I think.

Writing tests can be very difficult when code is not properly architected.

At the high level we have end-to-end testing, which lets you test the system as if you were the end user.

It's useful because literally any spaghetti code can be end-to-end tested, assuming you can simulate the inputs, as it never actually touches the code itself, only what it delivers to us.

They can be tricky to set up though, due to the need to always have a fully functional application running, but they are surprisingly valuable.

At the lower level, we have unit tests to verify the operation of our modules in isolation, and integration tests to examine the interaction between those modules.

These provide validation that our code is doing what we expect it to, rather than focusing more on behaviour like end-to-end tests.

If the thought of writing tests seems overwhelming right now, try applying the solid principles you learned earlier.

You might be surprised at how much easier it becomes when your code is modular and decoupled.

Time estimation is a process I still fail in sometimes.

A common rule of thumb is to double or even triple your initial time estimate for a task.

It feels excessive, but it's impossible to predict the unknown problems we will encounter along the way, so we need to account for those.

For example, this video took 3 times as long to make as I had predicted.

I really should take my own advice sometimes.

Remember that creation goes hand in hand with problems, So in the end, it's better to overestimate and deliver ahead of schedule than it is to miss a deadline.

Alright, this 1 is a bit cheeky as it's still kind of related to time, but I needed 7, not 6 points to make the Deadly Sins reference, so here we are.

All I wanted to say here is that you should try not to rush.

Things can feel great when we're blazing through a project and there's definitely a place for that in prototypes, but remember that if this is going to be a long term project, Take your time and think things through from day 1.

We'll never get all our decisions right first time, but we can at least give ourselves a better foundation to work from, and hopefully avoid some of that nasty code debt later.

Anyway, you're likely to finish in less time regardless if you're not constantly battling decisions you can't easily fix because of poor architecture.

We want projects that get easier with time, not harder.

Go forth and be the programmer you were always meant to be.

I'd like to end with a quote from Martin Fowler.

Any fool can write code that a computer can understand.

Good programmers write code that humans can understand.

It's been many weeks making this video but it's all worth it to see that smile of yours now.


Speaker 0: Hi there! There are what I would consider to be 7 deadly sins when it comes to programming. Things that will grind your code quality into dust if you don't heed their lessons. Now I hope you've never had to hear someone tell you that you write bad code, but if you have, there's really nothing to be embarrassed about. We all write flawed code as we learn, and the good news is, it's fairly straightforward to make improvements if you're willing.

In essence, that's why I've created this video, to guide you to becoming a better coder. So let's look at the mistakes you might be making and see if we can fix them. The first thing I see people doing is not using programming standards. They give us rules to follow, like white spacing, file structure, and other philosophies that we apply to make our code consistent and therefore easily readable. It's also especially important when working with other people, because it allows everyone to rely on shared expectations.

If we don't keep standards, it's kind of like switching fonts all the time. We can read it, sure, but the subtle differences throw us off and slow us down a bit. As for choosing a standard, if you aren't given 1 by your team, then there's plenty to choose from in the wild. The second thing, programming design principles, are probably some of my favourite ways to improve. You can think of principles like a general guide into becoming a better programmer.

They're the raw philosophies of code. Now there's a lot of principles out there, too many to cover in this video, but I will quickly show 5 very important ones which go under the acronym of SOLID. The S in SOLID stands for single responsibility, and it teaches us that we should aim to break our code down into modules of 1 responsibility each. So, if we have a big class that is performing unrelated jobs, for example, we should split that up into separate classes to avoid violating the principle. It's more code, yeah, but we can now easily identify what the class is trying to do, test it more cleanly, and we can reuse parts of it elsewhere, without having to worry about irrelevant methods at the same time.

This actually becomes more important as we progress. The oh-so-open-close principle suggests that we design our modules to be able to add new functionality in the future, without having to actually make changes to them. Instead we should extend a module to add to it, be that wrapping it or something else, but we should never modify it directly. Once the module is in use, it's locked, and this now reduces the chances of any new additions breaking your code. Luckily, the Luminous Liskov leaves us a lesson that loosely limits how we leverage our legacy code.

Okay, that's enough of that. Liskov wants to tell us that we should only extend modules when we're absolutely sure that it's still the same type at heart. For example, we can probably extend a hexagon into a six-pointed star, because that still makes sense as a six-sided shape. But we can't really do the same if we wanted a 5 or seven-pointed star, because that would no longer be compatible with what a hexagon represents. It just wouldn't fit cleanly anymore into parts of your code that expect hexagons, and so it will have failed the principle.

If that's the case, it should extend something that fits its design, or become its own type instead. Almost at the end now, and we have I for interface segregation. It says that our modules shouldn't need to know about functionality that they don't use. We need to split our modules into smaller abstractions, like interfaces, which we can then compose to form an exact set of functionality that the module requires. This becomes especially useful when testing, as it allows us to mock out only the functionality that each module needs.

Which brings me to Big D, which stands for Dependency Inversion. This 1 is pretty simple to explain because it says that instead of talking to other parts of your code directly, we should always communicate abstractly, typically via the interfaces we define. Dependency inversion breaks down any direct relationships between our code, and isolates our modules completely from 1 another, meaning we can swap out parts as we need to. Because they communicate with interfaces now, they don't need to know what implementation they are getting, only that they take certain inputs and return a valid output. The cool thing about solid is that when we combine all these principles together, it ends up decoupling our code, giving us modules that are independent of each other and making our code more maintainable, scalable, reusable and testable.

Programming design patterns, not to be confused with principles from the last chapter, are also something I see underused a lot, when they really should have more of a place in your mind. Patterns give us some real solutions to our code problems, but they aren't fixed implementations, so they're still kind of open to interpretation. We use them to architect our software systems, matching the right shapes to fit the needs our software has. First up, we have creational patterns, which are there to help us make and control new object instances, such as the factory method pattern, which turns a bunch of requirements into different modules that follow the same interface, but aren't necessarily the same type. Then there's structural patterns, which are concerned with how we organize and manipulate our objects, such as the adapter pattern, to wrap a module and adapt its interface to 1 that another module needs.

Finally there's behavioral patterns, which focus on how code functions and how it handles communication with other parts of the code. Such as using the observer pattern to publish and subscribe to a stream of messages in an event-based sort of architecture. Now there's a bunch of different design patterns under each category, some of them you might have used before. A lot of these patterns are used by frameworks and by professionals in huge corporations, and that kind of ties in with another pretty unique benefit. The benefit of creating a universal vocabulary of programming.

Have you ever written some code that seemed great at the time, but later you had trouble understanding it? Well, it often comes down to the way you name things. Take a look at this snippet. It's quite short, but it's hard to interpret what's going on without some thoughtful analysis. Let's fix this in steps.

First up, we should avoid unnecessary encodings, such as type information, which make it harder to read code in a natural way. Next we have many abbreviations and acronyms that don't really explain well enough what they are. We should expand them to their full names to avoid any miscommunication. Looking better, but it's not really clear what some of these variables hold. They're quite vague and ambiguous.

We should aim to use names that more accurately represent the nuances of the code we're working with. We also want to replace magic values, such as the organ index or trigger word string, with named constants. By doing so, we clarify their significance, and we help to keep things in sync if they're used elsewhere. Ok, we can now read this code and understand what it's doing without having to think too hard about it. However, we can still improve it further.

If you have any compassion for your future self, or other unfortunate developers who might have to read your code, be descriptive with your names. Ideally, we want to find a balance between being clear enough to quickly understand what the code does, without being so verbose that it becomes an information overload. Remember that no matter how good you think your code is, if it's not easy to read, I would argue that it's not actually good code at all. Many people don't test their code, and that's understandable I think. Writing tests can be very difficult when code is not properly architected.

At the high level we have end-to-end testing, which lets you test the system as if you were the end user. It's useful because literally any spaghetti code can be end-to-end tested, assuming you can simulate the inputs, as it never actually touches the code itself, only what it delivers to us. They can be tricky to set up though, due to the need to always have a fully functional application running, but they are surprisingly valuable. At the lower level, we have unit tests to verify the operation of our modules in isolation, and integration tests to examine the interaction between those modules. These provide validation that our code is doing what we expect it to, rather than focusing more on behaviour like end-to-end tests.

If the thought of writing tests seems overwhelming right now, try applying the solid principles you learned earlier. You might be surprised at how much easier it becomes when your code is modular and decoupled. Number 6 is... Time. And how you manage it.

Time estimation is a process I still fail in sometimes. A common rule of thumb is to double or even triple your initial time estimate for a task. It feels excessive, but it's impossible to predict the unknown problems we will encounter along the way, so we need to account for those. For example, this video took 3 times as long to make as I had predicted. I really should take my own advice sometimes.

Remember that creation goes hand in hand with problems, So in the end, it's better to overestimate and deliver ahead of schedule than it is to miss a deadline. Alright, this 1 is a bit cheeky as it's still kind of related to time, but I needed 7, not 6 points to make the Deadly Sins reference, so here we are. All I wanted to say here is that you should try not to rush. Things can feel great when we're blazing through a project and there's definitely a place for that in prototypes, but remember that if this is going to be a long term project, Take your time and think things through from day 1. We'll never get all our decisions right first time, but we can at least give ourselves a better foundation to work from, and hopefully avoid some of that nasty code debt later.

Anyway, you're likely to finish in less time regardless if you're not constantly battling decisions you can't easily fix because of poor architecture. We want projects that get easier with time, not harder. And that's it! Wow, you leveled up! Go forth and be the programmer you were always meant to be.

I'd like to end with a quote from Martin Fowler. Any fool can write code that a computer can understand. Good programmers write code that humans can understand. Thank you so much for watching. It's been many weeks making this video but it's all worth it to see that smile of yours now.

See you next time.

See all Coderized transcripts on Youtube

How principled coders outperform the competition