"The Beauty of Code Is To Express Meaning In A Way That Involves Elegant Abstractions That Are Simple To Understand": Understanding Interfaces

I take absolutely zero credit for the wonderful quote at the start of this post - it is all thanks to my mentor.

Understanding the interfaces of objects is key to reading code effectively. 

So what is an interface? Well you can think of every single section of code as a tool that we use.

Think about the calculator. The calculator is a tool that we use: we punch buttons and it does things.

Facebook is a tool, that we use too; it looks pretty and it does things.

Code is a tool too. 

Unlike Facebook, or a calculator, a function isn't necessarily designed to look pretty (hey matter of opinion! I love code and I think it's beautiful. I love code).

But it is a tool that is designed something.

And so in order to be able to do more and become more efficient software engineers (I hope my manager is reading this, lol), we need to be able to improve at reading code and at using tools better. We need to pay less attention to what is going on under the hood - both my manager AND my mentor are telling me this constantly - and I am listening.

So read on to learn a bit more about how you too can learn to skip the docs and read the code.

And about how breaking down software engineering problems is all about breaking them down into smaller, easier challenges.

Generic Types

• Types document the code and let us know how to use something
• A type is an interface
• We know the type of a csv FILE
• We know the type of reader
• We know that reader is an iterable
• What is the type of row?
• In this case, the answers are in the code
• We don't haver to go to the documentation to know what this code is doing
• And how to use objects in the code

Interfaces

"How does this actually work?"  - you can use an interface or a return type to look at a piece of code and to understand what that piece of code actually does without reading into it too deeply or without looking too deeply under the hood. All code compiles down into something deeper until you can break it down into machine code and ones and zeroes.

We could spend forever understanding what every single line and piece of code does, but that would not make us efficient. As software engineers, we are paid to be efficient. To put it simply, our job is to build things; our job is not to know everything or to understand everything perfectly; but our job is to deliver working solutions to problems.

Levels of Abstraction

Many many levels of abstraction in the code exist, which is not useful from day to day.

Within Python code: we can have an interface which is a level of abstraction on top of the implementation.

Understanding Interfaces Is Core To Code Comprehension

Taking the example of a Python datetime.combine() method (one which I have used very recently in my code at work to solve a major coding problem).

The interface for a combine method is that:

• it takes a date
• it takes a time
• it takes some extra stuff

It might take some extra stuff but we don't care what it is.

The main thing to think about when thinking like a method (like this often, but just with any one) is to think about the inputs and the outputs. 

A lot of this links in with the other themes that there have been on this blog. Think about all the posts on toasters that this blog has had recently!

The bigger picture

And just in terms of datetime types - the datetime class can do a LOT. It can do a LOT of different things in Python.

What we actually care about is just a small part. This ties in with a theme that my mentor and I talk about every single time we talk, virtually, which is reducing cognitive load. Breaking things down. 

We speak about this every time as well, almost. Normally when we solve a problem we only want to have to learn one or two new things to solve it. Sometimes in the earlier days of your career you might have to learn 10 things first but that can get a bit overwhelming, so ideally we don't want to learn more new things than we have to in order to solve a software engineering problem.

But how do we know how deeply to go? And what if we never want to stop learning? I never want to stop learning, that's just a thought. Anyway, then gradually you will learn enough - to solve any problem.

Inputs and Outputs

When looking at the interface of a piece of code, for example a function, we can learn more about the function through looking at the input types.

But we can learn even more about this function by looking at the output types.

This is because by looking at the return type of the output we can understand very quickly what the code is trying to return here, and therefore what it is trying to do.

That's why return types and types in general are really useful to code comprehension.

Types

Because: types remove ambiguity, and you can infer meaning from types.

I repeat, types remove ambiguity and you can infer meaning from types.

Types remove ambiguity and you can infer meaning from types.

So: Why Interfaces, Good Names, and Types are Important:

Interfaces, naming things, and type annotations are important, because they help us to understand things without the docs.

The Most Important Part of Code

The most important part of of code and of programming languages is this:

Language is so amazing because of its ability to convey meaning.

Language is an abstraction of what the real world is. Just like numbers are.

And just like what all software and technology is, actually.

The beauty of code is to express that meaning in a way that involves elegant abstractions that are simple to understand. I'll repeat it again: the beauty of code is to express meaning in a way that involves elegant abstractions that are simple to understand. And remember with tasks: we want them to be simple to understand. We want to break things down and make thing simpler. We want to break it down.

🔑🗝🔐🗝🗝 The Key To Problem Solving

• The key to problem solving is to break things down.
• The key to problem solving is to break things down.
• The key to problem solving is to break things down.
• The key to problem solving is to break things down.
• The key to problem solving is to break things down.
• And understanding the interfaces of objects is key to reading code effectively.
• Understanding interfaces of objects is key to reading code effectively.

Understanding interfaces of objects is key to reading code effectively

• You can learn about an object from reading how it's used. You can learn about an interface of an object just by reading code where it's used.
• To know how to use something,  we don't need to know how it works internally or exactly what it is.
• We can read some code 
• We can infer from the code what it does
• And we can understand it
• Ju y reading it

And we don't have to read documents.

A few great last quotes from my software engineering mentor (just in case you are still struggling to understand interfaces)

 An interface defines how you can use something and the types of parameters and return type are both part of that interface. If an interface uses generic types (e.g. Iterable) instead of specific types (e.g. list, tuple, generator, etc.) it is more generally useful

Thank you so much 🫡