Plenty of times now, we've exhorted you to write software which will be useful for others. We've also asked you to ensure that you know what you're up to and that you've planned well in advance. But once or twice we've mentioned that doing something "for fun" is plenty reason enough.

When learning a new programming language, I (and others that I know) have a simple ritual set of small programs that I implement in order to get to know how a language works. For example, I try and implement simple problems from the Project Euler website, along with some simple unixy commands such as a basic cat, echo, ls set. A friend of mine always tries to implement a simple number guessing game because she likes interactive programs.

Learning a new programming language, especially one which isn't quite like the ones you use day-to-day can be a very humbling experience; especially if you don't let yourself start by modifying someone else's code. It can help to remind us that we're all levelled by something which isn't quite in our realm of normal thought. At this time of year I like to learn a new language to see if the following year I should have a go at something new. Of the various resources out there with programming puzzles, something new started last year and has continued this year - The Advent of Code. Last year I did it in Haskell because I wasn't quite ready to learn something completely new, but did want to improve my confidence in Haskell. This year I'm trying out Rust.

We're only a week into The Advent of Code and that's not quite enough to make it impossible to catch up. While I'm not suggesting you must do it in a different language from those you are normally comfortable in; I am suggesting that to work your way through a set of programming puzzles can be extremely satisfying, and I encourage you all to have a go. If doing so at this time of year isn't quite for you, you can always revisit the puzzles in the new year.

And if doing something so blatantly Christmas themed isn't your thing, then I suggest visiting Project Euler if you're mathematical, or perhaps picking something from the list here instead.

Something that repeatedly comes up about free software projects is how much it's possible to achieve. Can you write an operating system from scratch? That's been done, several times. A desktop environment? Been done. A complete toolchain (compiler, linker, essential libraries)? Yeah, done.

These are all examples of large, impressive systems that have been made by one or a small number of people, even just in their free time. How is that possible? Here's a couple of ideas.

• Have fun. If you're not enjoying it, and you're not getting paid (and maybe even then), you should perhaps do something else. Or something differently. Is it not fun because memory management in C is tedious? Maybe use a different language or some helper libraries that take the tediousness away. Is it not challenging enough? Make N bigger.

• Do not believe the people who say your idea isn't plausible to do. They might be right, and if you idea is ambitious, it might take a long time to get it done. Believing everyone who says you can't is just demoralising, especially online where there are always at least 12765 people awake and happy to denigrate anyone else's ideas.

  Do it. If you fail, you've had fun for a while and you probably learnt a thing or two. If you don't even try, those who don't believe in you were right.

• Start small and simple, then grow organically. No, smaller and simpler than that. There is much truth in Antoine de Saint Exupéry's saying, "It seems that perfection is attained not when there is nothing more to add, but when there is nothing more to remove.". Your first version should be as small and simple as you can make it. If you can think of anything to remove that doesn't render the thing unusable for all use cases, you can simplify further.

  When you have the smallest, simplest first version that is possible, you can start growing. Get a user (even if it is just you), and whenever they want a new feature, and that feature fits in your vision of your program, implement that next. Repeat a thousand times. Keep doing it. Find others to help. Don't give up. Persevere. It might take a year or ten, but you'll eventually have something that makes people wonder how you managed to make something so impressive.

Some people give gifts at this time of year, I prefer to give presentations. Well, I like doing it at any time of year really; but I thought I ought to try and make some concession to the time of year.

At most conferences I go to, I end up giving a presentation (and no, that's not just because you can sometimes get paid to attend if you speak) and so I've tried most of the Linux-based presentation tools over the years. I'm sure there are new ones I haven't yet encountered, but I thought I might include some of the ones I've been at least marginally successful using. If you are wanting to give presentations from a Linux laptop then you might find the following useful.

Things I've used

Libreoffice Impress

If you're used to "traditional" "powerpoint" "presentations" then you will likely find Libreoffice's presentation tool to be very easy to get used to. It is quite easy to get basic presentations going with relative ease. It is not, however, very modern in its presentation design, which can result in quite dated-looking slides.

Pinpoint

If you prefer a simpler looking presentation style then you might enjoy the Pinpoint from the Gnome project. Pinpoint is a very simple presentation tool which focusses on providing simple slides which look clean, and making it nice and easy to manage your presenter notes. Unlike Libreoffice, Pinpoint's input is a plain text file which makes it much easier to version your presentation in Git.

PDF Presenter Console

If, on the other hand, you prefer to generate your presentation in some other tool which can then output a PDF; then pdf-presenter-console may be for you. It takes a PDF (and optionally some presenter notes) and provides a multi-screen presentation tool with presenter notes. You can edit your notes in the tool if you notice problems during your test runs, and it's a good example of doing one thing and doing it well.

Things I've not used

I know various people who use Pandoc combined with [slidy][] or even write their own LaTeX with beamer or similar. Personally I think that if I used those, I'd then want to use pdf-presenter-console to give me speaker notes capability though a PDF with no notes is a useful way to have a presentation which is easy to transfer to other computers.

As an alternative to slides, some people prefer to type messages on the fly. To do this you can use screen-message which displays text as large as possible as it is typed. This is useful for when you improvise a presentation (or want to make it appear improvised).

A few tips

If you're new to presentations then it can be very tempting to fill your slides with useful information so that you feel like your audience will get a lot out of your talk. This is a bad thing™ and you shouldn't do it. In fact there's so much useful out there about how to give presentations that I'd suggest you go and look at things like this.

This is of course a pun on the old phrase "If you don't tidy your room, you won't be getting any pocket money this week." in which privileges are withdrawn if tedious chores aren't completed.

It's not always fun to do the cleanup that follows in the wake of feature development.

Like the admonishment towards children, this has motivations beyond immediate gratification. If you don't tidy your codebase, it will begin to smell. This smell is your technical debt building up.

If you don't clean it up, it will become harder to do so in the future and it will also be more difficult to implement features.

Unlike most people's bedrooms however, you want to let everyone into your codebase so that other people can enjoy it and improve it.

Having an untidy codebase makes this difficult, because it's requires a significant incentive to work on an untidy codebase. Why would anyone else want to tidy your mess?

It's also worth noting that you from a month ago is a different person, so some projects can die from the original developer coming back to the mess they left and deciding it wasn't worth tidying.

So if you have a project that you have not touched in a while try to make some time to tidy up some of the mess.

It helps if you have left a TODO file to tell you what needs to be tidied rather than having to read through your codebase again to find the smells.

Tips for tidying C projects

It would be hypocritical for me to make these sweeping generalisations if I then did not follow through with it, so I am yet again going to use my linux-fsops project as the example.

1. Tidy your source files into a directory of their own.

   Your project is more than just your code. There will be other artifacts you want to version control and at least in the short term one of the best places for this is your source code repository.

   So sorting your artifacts into a nice hierarchical tree helps especially when you need to keep track of things.

   It is also valuable in some programming environments. For example, Rust expects to have a src directory if you are using cargo, and for python projects it is handy to separate your code out into a library named after your project since this allows you to automate package generation.

2. Split up large source files.

   Many helper functions would be usefully shared within your project and if you've defined your functions with low coupling then they may be useful independently, so splitting those functions out into separate source files is a step towards having a library that would be useful to others.

   Once every usefully divisible function has been split out, mark the rest as static, partly to ensure their defenitions don't leak, but also to signal intent that they aren't shared.

   Later steps may include turning it into an actual library by changing it to build as a shared object, having it install headers separately, and shipping the headers and shared object as separate packages, but until then it is still useful as a copy-library.

   Of special note is to have a missing.h for all the definiions that are not available from your system headers. It is conveneient to split it out this way since if you later decide to move to automake it has support for generating it automatically.

3. Tidy your build-system.

   This is often the most-overlooked part of a project as it doesn't make the result itself better, but it makes it easier to make those improvements.

   In a Makefile it is necessary to ensure your make rules' dependencies and clean rules are correct.

4. Don't worry about tidying everything at once.

   While it's better to have a completely tidied codebase, requiring that as a goal is likely to kill any enthusiasm in doing so.

   Incremental improvements are great. Every step is a step towards the goal. Perfect is the enemy of good. Other platitudes are available.

   Don't get hung up on the fact that your codebase still has stuff to tidy. So long as you've done something to improve it, you have not wasted your time. You can always do more later.

To to this end I have tidied up the build-system and split funcionality out in my linux-fsops project.

Now, if you're feeling particularly generous, you might think of a project you are involved in, and give the gift of tidy code this festive period!