How principled coders outperform the competition

Summary

This video script addresses seven common mistakes that degrade code quality, offering guidance to improve programming practices. It emphasizes adhering to programming standards for consistency and readability, mastering design principles like SOLID for better code structure, and utilizing design patterns for effective problem-solving. The script also stresses the importance of clear naming conventions for maintainability and the necessity of testing to ensure code reliability. Additionally, it advises on proper time management and avoiding rushing to prevent technical debt, ultimately aiming to enhance a programmer's skills.

Takeaways

• 📜 **Use Programming Standards**: Adhering to programming standards like whitespace, file structure, etc., ensures code consistency and readability.
• 🔑 **Follow Design Principles**: Principles like SOLID provide guidelines to write better, more maintainable code.
• 🔒 **Single Responsibility Principle**: Aim for classes with one responsibility to simplify code and enhance reusability.
• 🌟 **Open/Closed Principle**: Design modules to be open for extension but closed for modification to avoid breaking changes.
• 🔄 **Liskov Substitution Principle**: Ensure that derived classes are substitutable for their base classes without affecting the program's correctness.
• 📚 **Interface Segregation Principle**: Design interfaces to be small and specific to the needs of the modules that use them.
• 🔄 **Dependency Inversion Principle**: Depend on abstractions, not on concrete implementations to reduce coupling.
• 🧩 **Utilize Design Patterns**: Patterns provide proven solutions to common software design problems.
• 🔍 **Improve Code Readability**: Use clear naming conventions, avoid unnecessary encodings, and replace magic numbers with named constants.
• 📈 **Write Tests**: Testing at different levels (end-to-end, unit, integration) ensures code correctness and behavior.
• ⏱️ **Manage Time Wisely**: Overestimate time for tasks to account for unexpected challenges.
• 🏃‍♂️ **Avoid Rushing**: Take time to think through decisions to establish a solid foundation and avoid technical debt.

Q & A

What are the seven deadly sins of programming mentioned in the script?

The script does not explicitly list seven sins but focuses on common mistakes that degrade code quality. These include not using programming standards, not following programming design principles, and other issues related to code maintainability and readability.

Why is adhering to programming standards important?

Adhering to programming standards ensures code consistency, making it easily readable. It's particularly crucial when working in teams as it allows everyone to rely on shared expectations, similar to how not switching fonts all the time makes reading smoother.

What is the SOLID acronym in software design principles and what does each letter stand for?

SOLID is an acronym for five object-oriented design principles intended to make software designs more understandable, flexible, and maintainable. S stands for Single Responsibility, O for Open/Closed, L for Liskov Substitution, I for Interface Segregation, and D for Dependency Inversion.

Can you explain the Single Responsibility Principle from SOLID?

The Single Responsibility Principle states that a class should have only one reason to change, meaning it should only have one job or responsibility. This helps in identifying the purpose of the class, testing it cleanly, and reusing it without unrelated methods.

What does the Open/Closed Principle suggest about module design?

The Open/Closed Principle suggests that modules should be open for extension but closed for modification. This means new functionality should be added by extending modules rather than modifying them directly, reducing the risk of breaking existing code.

How does the Liskov Substitution Principle guide the extension of modules?

The Liskov Substitution Principle states that objects of a superclass should be replaceable with objects of a subclass without affecting the correctness of the program. It guides the extension of modules by ensuring that subclasses remain compatible with what their superclass represents.

What does Interface Segregation Principle imply for module functionality?

The Interface Segregation Principle implies that no client should be forced to depend on methods it does not use. It suggests splitting modules into smaller interfaces that can be composed to provide only the required functionality, which is beneficial for testing and reducing dependencies.

Can you describe the Dependency Inversion Principle?

The Dependency Inversion Principle states that high-level modules should not depend on low-level modules; both should depend on abstractions. Abstractions should not depend on details; details should depend on abstractions. This promotes loose coupling and high cohesion.

Why are programming design patterns important in software development?

Programming design patterns are important because they provide tried and tested solutions to common software design problems. They help in architecting software systems by matching the right solutions to the needs of the software, making the code more maintainable and scalable.

What is the significance of using clear and descriptive names in code?

Using clear and descriptive names in code enhances readability and maintainability. It helps future developers, including oneself, to quickly understand what the code does without extensive analysis. It also aids in avoiding miscommunication and keeps the code in sync if certain values are used elsewhere.

Why is it recommended to write tests for code?

Writing tests for code is recommended because it verifies that the code operates as expected. Tests can be end-to-end, unit, or integration tests, and they help catch issues early, reduce bugs, and ensure that future changes do not break existing functionality.

What is the advice on time estimation and project management in the script?

The script advises to overestimate initial time estimates for tasks, considering the unpredictability of problems that may arise. It also encourages not rushing through projects, especially long-term ones, to avoid technical debt and ensure projects become easier to manage over time.

Outlines

00:00

📝 The Seven Deadly Sins of Programming

This paragraph introduces the concept of seven deadly sins in programming that can severely degrade code quality. It acknowledges that all programmers write flawed code as they learn and emphasizes that there's no shame in receiving criticism for bad code. The speaker aims to guide viewers on how to improve their coding skills by identifying common mistakes and offering solutions. The first sin discussed is the neglect of programming standards, which are essential for maintaining consistent and readable code, especially in team settings. The paragraph also touches on programming design principles, highlighting the SOLID principles as a guide to better programming practices. The SOLID acronym stands for Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion, each principle aimed at creating more maintainable, scalable, reusable, and testable code.

05:02

🔍 Design Principles and Patterns in Programming

The second paragraph delves into programming design principles and patterns, emphasizing their importance in creating well-structured software systems. It explains the three categories of design patterns: creational, structural, and behavioral. Creational patterns assist in the management and instantiation of objects, structural patterns deal with the organization and manipulation of objects, and behavioral patterns focus on the functionality and communication within the code. The paragraph also discusses the value of a universal programming vocabulary, suggesting that clear and descriptive naming conventions are crucial for code readability and maintainability. It advises against using abbreviations and magic values, recommending the use of named constants instead. The summary stresses the importance of writing tests, suggesting that well-architected code following SOLID principles makes testing more manageable. Lastly, it touches on the importance of time management and estimation in programming projects, advising to overestimate time requirements to account for unexpected challenges.

10:03

⏳ The Importance of Patience and Time Management in Coding

The final paragraph stresses the importance of patience and careful planning in programming projects. It warns against rushing through projects, especially long-term ones, as this can lead to poor architecture and code debt. The speaker suggests that taking the time to make thoughtful decisions from the outset can prevent future issues and result in projects that become easier to manage over time. The paragraph concludes with a quote from Martin Fowler, emphasizing that good code should be understandable by humans, not just computers, and thanks the viewers for their time and attention.

Keywords

💡Programming Standards

Programming standards refer to the set of rules and guidelines for arranging code in a consistent and readable manner. They include aspects like whitespacing, file structure, and other philosophies. In the video, the speaker emphasizes the importance of adhering to these standards to ensure code is easily readable and maintainable. For instance, not following standards is compared to switching fonts all the time, which can be read but is less efficient due to the subtle differences.

💡Design Principles

Design principles in programming are fundamental philosophies that guide developers to write better code. They serve as a framework for thinking about how to structure and organize code. The video mentions SOLID principles as an example, which are a set of five design principles intended to make software designs more understandable, flexible, and maintainable.

💡SOLID

SOLID is an acronym for five object-oriented design principles intended to make software designs more understandable, flexible, and maintainable. It stands for Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, and Dependency Inversion principles. The video explains each principle in the context of creating modular, decoupled, and maintainable code.

💡Single Responsibility Principle

The Single Responsibility Principle states that a class should have only one reason to change, meaning it should only have one job or responsibility. The video uses the example of splitting a large class performing unrelated jobs into separate classes to adhere to this principle, making the code easier to understand, test, and reuse.

💡Open/Closed Principle

The Open/Closed Principle suggests that software entities should be open for extension but closed for modification. This principle is illustrated in the video by advising to extend a module rather than modifying it directly to add new functionality, thus preventing the risk of breaking existing code.

💡Liskov Substitution Principle

The Liskov Substitution Principle states that objects of a superclass shall be replaceable with objects of a subclass without affecting the correctness of the program. The video humorously explains this by stating that a hexagon can be extended to a six-pointed star but not to a five or seven-pointed star, as it would no longer fit into the code expecting hexagons.

💡Interface Segregation Principle

The Interface Segregation Principle argues for the preference of many client-specific interfaces over a single general-purpose one. The video explains that modules should not need to know about functionality they don't use, advocating for splitting modules into smaller interfaces that can be composed to provide the exact set of functionality required.

💡Dependency Inversion Principle

The Dependency Inversion Principle suggests that high-level modules should not depend on low-level modules but should depend on abstractions. The video simplifies this by stating that instead of modules communicating directly with each other, they should communicate via interfaces, which allows for greater flexibility and easier module swapping.

💡Design Patterns

Design patterns are reusable solutions to common software design problems. The video categorizes them into creational, structural, and behavioral patterns. It mentions examples like the factory method pattern, the adapter pattern, and the observer pattern, which are used to architect software systems by matching the right shapes to the needs of the software.

💡Code Readability

Code readability refers to the ease with which a reader can understand the structure, logic, and intent of the source code. The video stresses the importance of clear naming conventions, avoiding unnecessary encodings and abbreviations, and replacing magic values with named constants to improve code readability. It argues that even if the code is functional, if it's not easy to read, it's not considered good code.

💡Testing

In the context of the video, testing refers to the process of checking code to ensure it meets the required functionality and to prevent software failures. It mentions different levels of testing such as end-to-end, unit, and integration testing. The video suggests that applying SOLID principles can make writing tests easier by creating modular and decoupled code.

💡Time Management

Time management in programming refers to the ability to accurately estimate and allocate time for tasks. The video advises doubling or tripling initial time estimates to account for unforeseen problems, which aligns with the idea that it's better to overestimate and deliver early than to underestimate and miss a deadline.

💡Code Debt

Code debt refers to the accrual of technical debt in the form of poorly written code that needs to be refactored. The video cautions against rushing through a project and emphasizes the importance of taking time to think through decisions from the start to avoid accumulating code debt that makes projects harder over time.

Highlights

There are seven deadly sins in programming that can degrade code quality.

Writing bad code is a natural part of learning and can be improved.

Programming standards like whitespace and file structure are crucial for readability and teamwork.

Adhering to standards prevents confusion and slows down the development process.

Programming design principles are essential for improving as a programmer.

SOLID principles are a set of five important design principles.

Single Responsibility Principle suggests one responsibility per module.

Open-Closed Principle advocates adding functionality without modifying existing modules.

Liskov Substitution Principle emphasizes extending modules only when they are of the same type.

Interface Segregation Principle states modules should not depend on unused functionality.

Dependency Inversion Principle promotes abstract communication between modules.

Combining SOLID principles results in decoupled, maintainable, scalable, reusable, and testable code.

Design patterns provide solutions to common coding problems and should be used more often.

Naming conventions are crucial for code readability and understanding.

Avoiding unnecessary encodings and abbreviations improves code clarity.

Using descriptive names and replacing magic values with named constants enhances code maintainability.

Good code is easy to read and understand, even if it's not perfect.

Testing code is essential, with different levels like end-to-end, unit, and integration tests.

Applying SOLID principles can make writing tests easier.

Time management is crucial; overestimating time for tasks can prevent missed deadlines.

Avoid rushing through projects to prevent long-term issues and code debt.

Good programmers write code that is understandable to humans.

Transcripts

Hi there, there are what I would consider to be seven 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 whitespacing, 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 you 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 one 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 five 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 one 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-closed 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 a module is in use, it's locked, and this now reduces the chances of any new additions

breaking your code.

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

code.

Okay, that's enough of that.

Lyskov 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 five 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 one 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 one 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 organise and manipulate

our objects, such as the adapter pattern, to wrap a module and adapt its interface to

one that another module needs.

Finally, there's behavioural 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.

Something 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

used elsewhere.

Okay, 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 six 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 three 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 one is a bit cheeky, as it's still kind of related to time, but I needed

seven, not six 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 one.

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.