Lesson video

Hi there.

I'm Rebecca, your computing teacher for the programming part six unit.

For this lesson, you are going to need your account, which you should have already set up with your parent or carer's permission.

It's also a good idea to have a pen and paper handy to make any notes that you need to, and to try your best to remove as many distractions as possible so that you can enjoy the lesson and really focus as well.

Once you've got all of that ready, we can begin.

In this lesson, you will determine the good habits of a programmer.

You'll explore alternative approaches to programming solutions.

And you'll append to a CSV file.

What I'd like you to do then is to make a list.

Think about what you've learned about programming in all six parts of this unit.

That's quite a lot of learning that you've done.

Make a list of the good habits that a programmer should adopt.

So pause the video while you do that.

Right, I've got some examples of things that you might have written.

So use meaningful identifiers, keep backups, keep a document of useful code snippets, test often, comment on code to make it clear what each part does, break problems down into subroutines, follow the naming conventions for the language, read the documentation, that is an important one, write code that is easy for others to read and interpret, and avoid multiple entry and exit points with code blocks.

So let's look at using meaningful identifiers.

If you want to make a variable that holds a score for a game but you name it bob, will the programme still work? Yes, of course it'll still work.

Why is it not a good idea to name a variable that holds the score bob? Well, it makes the code difficult to read, and you can lose track of what the variable does.

When your programmes start becoming much, much larger, it's going to be very hard to keep track of what those variables do if you don't identify them properly.

At the moment, it is pretty difficult to know the purpose of this code.

This is because meaningful identifiers have not been used.

By changing the identifiers to something meaningful, the code becomes easier to understand, and now you can clearly see what is actually happening there.

Programming languages use naming conventions that are typically specified in their documentation.

This is to make the code easier to read and to keep consistency across programmes.

So which of these variables has been declared using the correct Python conventions? Pause the video while you have a look.

It's actually that bottom one there because it's two separate words.

In Python, we have variable names with all lowercase, and then we separate words with that underscore.

Would the other variable names still work, though? Yeah, of course they would.

So why is it good practise to test your code early and often? So testing code early and often makes it easier for you to find and fix errors.

If you break your code, then you can easily go back a few steps to the last time it worked.

Problems can often feel too big to solve.

All programmers experience this at varying levels.

The trick is to start small and decompose the problem.

Break a large problem down into small sub-problems. If the sub-problem is still too challenging, break it down even further.

For example, you are asked to create a guess the number game that will select a random number between one and 100, allow for five guesses, give feedback like higher or lower, tell the user if they won or lost, and reveal the number of guesses.

That's quite a lot.

You might start by seeing if you can check if the guess is correct by writing some code.

So that's quite some simple code there that you can quite quickly do, and once this bit is working, you move onto the next small chunk.

So another thing that good programmers do is they use commenting.

Code should be clear and readable.

Adding comments can help to provide extra insight into what the code does.

And you can see there, you've got the single line comment, which is the hashtag, and that's my favourite one.

Or you've got the multiple line comment as well with those quote marks.

This doesn't mean that you should comment on every single line of your code.

That's a little bit excessive.

Your variable names and the structure of your code should make it easy to understand for the most part.

And then those hashtag comments are more for when something isn't quite clear and you need just a little bit of an additional explanation.

A sensible amount to add clarity is helpful.

So they you go.

But what do programmers say? So these are all real programmers that work in the industry now.

And they are going to give you some advice about what it's like to be a programmer and what they do.

So this is Cassidy Williams, and you can follow her at cassidoo on Twitter with your parent or carer's permission, or you can get your parents to follow them and see what they've been up to, what she's been up to.

"Programming is all about continuing "to try and learn, "even when it gets tough.

"There are so many times "where I've been building a project, "something stops working, "and I have no clue why, "and I have to figure out what went wrong.

"As you gain more experience, "the major habit to build "is to ask questions sooner "rather than later.

"Programmers like myself have egos "and we hate admitting that we don't know something, "but the sooner you ask a question, "the sooner your problem is solved and you move on.

"Plus, you never know if your question is something "that someone else needs answered, too.

"Ask questions, and share your knowledge." And then this is from Anna Lytical, and they're a developer relations engineer by day and coding drag queen educator by night, and this is what they have said.

"Practise empathy for your users.

"Learn about the people using your product, "try out the tasks they do "and see how those experiences differ from yours.

"It's motivating to understand how your work "can affect people's productivity and happiness." Then we've got Emma-Ashley Liles, and she is a senior software engineer at Kaluza.

And this is what she said.

"Embrace change.

"Keep challenging yourself to learn something new, "read books on a new technique, "try writing a basic programme in a new language "or watch a talk about a new platform.

"There is a lot of change "and great programmers embrace it.

"Try and become a better communicator every day.

"In your variable and function names, "readme's, and git comments.

"Good programmers can communicate "what the intent of their code is "to other people." And then we have Maimuna Ahmed, and she is a software engineer at the Raspberry Pi Foundation.

And she says, "Always make sure your code "is accessible for anyone.

"This means that no matter what level "of programming someone is at, "they should be able to easily read "and understand what you have done.

"Don't forget to include comments.

"They are helpful for understanding "and explaining code steps, "especially when starting out programming.

"Make sure you have relevant function "and variable names and not some random ones.

"For example, if your function and variable "relate to getting a book title, "they should be named something like getBookTitle "and bookTitle, not foo or func.

"Simplify your code.

"Separate big functions into other files "and import call them where needed.

"Make sure the order of your code "matches what it does in execution.

"This makes it easier to read and follow.

"And cut down on your lines of code by optimising it." So here are some code alternatives that you need to look at.

When writing programmes, there are always plenty of ways to reach the final solution.

Taking the time to explore and experiment can make a real difference to your own skills and the solutions that you develop.

During this unit you have learned quite specific ways to find solutions, but there are always alternatives.

You'll become more confident with using different approaches as your programming skills develop.

So for example, we've got the input function.

During this unit you have used the input function in this specific way.

It is broken down into two steps.

So you provide the instruction and then you prompt for the input.

But actually you can do it a different way.

You have learned to do it this way, because it allows you to see that there are two separate steps taking place.

There is an alternative approach.

You can pass the instruction as an argument, so you can actually reduce it down to one line of code and pass whatever those instructions are in the argument, which is a different way of doing it, but it does exactly the same thing.

So in this case as well, it all appears on the same line.

So you would have Enter your name and you just write Becky right next to it, rather than have it on a separate line.

This is how you have learned to increment a variable in Python.

You have learned it this way.

So you can clearly see that you are adding value to the value score.

So just take a look at that.

Now, this is an alternative approach.

You can just do plus equals one instead.

Seeing this as a beginner programmer can be a little confusing but as your confidence builds you find it much easier to use this approach instead.

Another thing we've done is we've used f-strings.

So you've been using f-strings to display variables within a string.

This is a really clean way to present variables, but there are alternative approaches that you might find helpful in some situations.

So one approach is to use commas to separate the variables and the string.

So you can see that happening there.

And you can also concatenate the string using a plus sign.

And this requires an extra step if any of your variables are not of the string data type.

So just take a look at that there.

Now, then we've got assigning versus direct calls.

So this programme is designed to iterate through the list from the fourth item to the final item.

A separate variable has been used to hold the length of the list.

Again, this approach steps through the process for you making it easier to understand what the code is doing.

Here is an alternative approach.

There is no need to have a separate variable because len can be called directly inside the parameters.

By experimenting, you will find that you can use direct calls in many different contexts.

Sometimes that extra variable really isn't necessary.

So what I'd like you to do now is explore some of those alternatives.

So use the Explore the alternatives section of your worksheet to practise using alternative code snippets in your programmes.

So pause the video while you have a go.

So here's the solution to challenge one.

As I always say, you might have done it slightly differently, but this is what you could have done.

Pause the video to check that with your own.

And then this is challenge two solution.

As ever, I tried to fit it on the screen as best as I can for you.

So the left side is the top of the code, and then the bit part to the right of those dots is the bottom part of the code.

So just pause the video while you check that.

We're now going to look at appending to a CSV file.

This is the very last bit of new knowledge that you will learn in this whole lot of the units.

So pay attention.

Last lesson you learned how to write to a CSV file.

You will now see how to append to a CSV file and complete a programming challenge.

So appending to a CSV file is just like appending to a standard text file.

Why is it important to open a file in the correct mode, do you think? Pause the video.

Well, opening the file in write mode will delete any existing file and replace it with a blank one, which we don't want to do when we're appending, do we? So use the Appending to a CSV file section of your worksheet to append to a CSV file.

Make sure you use any alternative approaches that you have learned today in your solution, and remember to comment on your code.

Pause the video while you do that.

Excellent.

So here is the Appending to a CSV file solution that I did.

Now, again, as I always say, yours might be slightly different and that's fine if it is.

But pause the video and check that with your code.

Now, what I'd like you to do, because we're right at the end of this unit, this whole learning, and you're about to start a big project in your next lesson, what I'd like you to do is write a letter to yourself in the past on your first day of this unit.

So think right back when you began it.

What advice or encouragement can you give yourself, and what is your top tip for getting the best out of this unit? So just pause the video while you write that.

Excellent.

So that is the end of all of that learning.

And in next lesson, I'm going to introduce a big project for you to have a go at.

This is your big challenge.

It will build on all of those things that you have picked up throughout all of those parts of this big programming unit.

And if you'd like to, please ask your parent or carer to share your work on Instagram, Facebook or Twitter tagging @OakNAtional and hashtag LearnwithOak.

It'd be lovely to see those letters to yourself and see what you've written there.

That would be really nice.

And I'll see you again soon for that big challenge next lesson.