Odyssey Projects

Journeys of intellectual wandering, that involve learning, problem solving and discovery, where the destination isn’t that important.

By the end of this article I hope you can see why investing your time in such projects is interesting and useful, and how such projects could be beneficial for you.

Photo by Filip Mroz on Unsplash

odyssey (n): an intellectual or spiritual wandering or quest

Merriam-Webster online dictionary https://www.merriam-webster.com/dictionary/odyssey

Introduction

Ever since I got into computing and technology, I’ve embarked on large, ambitious solo projects to create things. Most of the time, but not always, by writing code. While the initial idea is to create a useful thing, these projects often become voyages of learning and discovery that I cannot tear myself away from, and extend late into the night (and early morning!).

My personality and mindset is just built in a way that loves an interesting problem - thinking it through, and experimenting with new ways to work out how to solve it. Sometimes this can be a single intense and interrupted block of time — hours or multiple days, but some projects can string together several blocks of time, with breaks or inactivity in-between weeks, months, or even years of working on a problem or a whole project.

When looking at those hundreds and hundreds of projects and the time spent on them over the span of well over 15 years, I’m left with a painful feeling of frustration. That is because only a very small handful have ever seen the light of day. When the interesting problems are solved, there is very little motivation to “finish” the project and show people. There is rarely a time where I’ll release a project, or promote the work I’ve done. Almost nobody sees or uses anything I’ve invested so much of my time into. This leads my journeys of discovery often going completely unnoticed.

I take some comfort in knowing that I’m not alone here. Just look at the hundreds of thousands of Open Source projects on GitHub that have a single contributor, who keeps working away at the project. There are people writing their own Operating Systems, people writing in totally obscure or dead languages — there are even people maintaining the Apollo Guidance Computer code in the year 2020! While many people might be doing this for other reasons, such as preserving history, or nostalgia, and many projects do eventually get abandoned — I feel a lot of the work that goes into those projects comes from passionate people who just enjoy the journey.

So, why do we bother? Why do I personally continue to invest so much time into my projects that will almost certainly go unused? I’ve asked myself that a lot over the years, and it’s taken me quite some time to learn how to become comfortable with that, and to learn how to articulate it to others. However, after a lot of internal processing — my answer is simple;

I work on projects that I rarely ever “finish” because I enjoy the journey more than the destination.

Journeys of intellectual wandering

So, if it’s not the destination that keeps me going, you might naturally ask what is it that I enjoy about the journey? That’s easy to articulate — what I love is learning, problem solving, and discovering new things. That is what I mean about “intellectual wandering”. To me, it is super satisfying to pick an ambitious goal far in the distance, and then navigate a path with the goal on the horizon. In designing, debugging, and developing at each step, the path rarely goes in the direction I first imagined. Paths have unexpected obstacles. There are times where I end up creating a new path around an obstacle, maybe with the intention to come back to it later. Sometimes, the obstacle can be simply pushed aside. Other times, the obstacle has no other way around it, and I find myself chipping away, piece by piece, until I break through. Navigating these obstacles — the learning, problem solving, discovery — that’s enjoyable.

My domain is computing and technology, and I do a lot of coding as a hobbyist.

This isn’t supposed to be a love letter to coding; even though the times I spent coding can often be described as some of my most enjoyable and valuable journeys. I also don’t think that “everyone should learn to code” — but that is a point I’ll make at another time. However, in my domain, there is an almost inexhaustible source of journeys to be had and many of those can be expressed in code. However, many projects don’t involve coding; such as soldering, building new computers and desktops, debugging networks, etc. With that being said, code is a just a language for expressing rules and logic — it rarely ever has obstacles that become so frustrating or apparently insurmountable to the point that makes me want to flip the table and give up — unlike when I damage an expensive component that I am soldering!

So, do I embark on these odyssey projects solely because I enjoy them? No. I do them because I learn a lot, and what I learn is ultimately the most valuable thing. I’ll speak more about this later on.

Defining an “odyssey project”

Why do I feel compelled to label my projects as “odyssey projects’? Well, I’ve been trying to justify and reconcile the time I’ve invested, in enjoying the journeys of learning, problem solving and discovering new things — when essentially I have very few deliverables to show for it. I’ve come to terms with it, but I’ve been trying to think of a label for them for years.

I’m not just trying to think of something that sounds pretentious, or cool (but “odyssey” is both — it’s a nice side effect!) While considering appropriate labels, I disregarded several options that came up, including “learning projects’’. This is because if you embark on a “learning project”, you normally are specifically trying to learn a single thing. Once you’ve learned that thing, the project is normally over. That doesn’t really capture the meaning of what I am trying to define here. Learning, yes, but it’s also about the wandering path and learning things that you didn’t necessarily set out to learn in the first place.

To put this into an example, a project where I set off to “learn 100 words of the French language” would not be what I would call an odyssey project. However, a project to “go and write a poem in French”, when the only words I know to begin with are “déjà vu” and “bonjour”, while the only poems I already know are children’s rhymes — well, that is an odyssey project to me! It’s an ambitious goal. I’ve got to do a lot of learning, and I’m not expecting to become a French poet by getting started on that project. I’ll probably end up on a journey of learning things about the French culture, or sentence structure, or what moves people in a poem, along with the basics of the language as I wander towards the ambitious goal that is on the horizon. If I stop before finishing the poem, or change my mind and instead write a novel, or a song, then that is just fine. I’m being led by where the journey is taking me, no necessary what I initially saw on the horizon.

To put it simply:

Odyssey Projects are journeys of intellectual wandering, that involve learning, problem solving and discovery, where the destination isn’t that important.

What are the criteria for a good “odyssey project”?

Meets 1 or more of the following criteria;

1. An ambitious initial goal that, often, ultimately fades into insignificance as you work on the path towards it.
2. Multiple opportunities to learn new things, or refine skills and techniques you already know.
3. Enough freedom, scope, extensibility, and possibilities, that you can go off in entirely new or unforseen directions.

The objective is not on a deliverable, but on the journey of intellectual wondering. If forced to establish some success factors, those would be: learning, problem solving and discovery.

If you’re trying to judge if something could be described as an odyssey project, you should not be asking questions like “is the end result worth it?”, “will people use this?”, “is this viable?”, or “did it get completed?” Rather, the questions you ask yourself in retrospect should be “Have I learned something new or tried out a new idea?” and “How is what I’ve learnt helpful?“

Examples of my odyssey projects;

You can safely skip this section if you’re a non-technical reader, or if you just don’t care about my personal projects! :-)

With all this rambling about the virtue of such projects, let me give you just three examples of projects I have worked on over the years. Like I said, this is from a selection of hundreds of project directories that are unlikely to ever leave my hard drive, but have given my value. These are all coding projects, but your odyssey projects do not have to be coding related.

Example 1) Upsilon project — http://www.upsilonproject.io/

This thing is a monster :-) Originally started following my university years almost as a successor to Tau, I remember thinking that I wanted a system that could check my email, texts, news, instant messages, and especially the status of my various servers — ping times, uptime, free disk space, and those sort of things. Having such a useful system would be such an advantage to my productivity in life! I initially started using Nagios, and was actually pretty successful in getting a lot of the server-monitoring stuff running, and built several extension scripts for emails, etc. Ultimately, I got frustrated with Nagios’ crude web interface and having to reload the monitoring daemon for new checks and similar.

Over the years the objective has morphed and changed — it wandered into being a big data system (amongst other things). It’s been a platform for me to really build and extend upon. Others looking in might see a mess, whereas I see a lot of time well spent!

I’ve invested THOUSANDS of hours in Upsilon, and I’ve learned SO much from it.

Upsilon project — Things I learned (technical)

• Detailed experience of implementing Microservices architecture — containers, service meshes, fast-failure vs. graceful-failures
• Distributed architectures — communicating with “daemons” running at work, at home, managing configuration changes. Pushing out updates while keeping a stable API.
• Message brokers — AMQP (RabbitMQ). Amazing stuff.
• Scaling — databases with 100Mm+ rows, and goodness knows how many archived records.
• CI+CD. I learned some pretty advanced usage of Cruise Control, and then a lot of Jenkins. I fell in love with Jenkins, and now I’ve learned to hate it!
• Porting — this project is like a decade old. It has “outlived” several libraries., I converted a bunch of code from Java to PHP, from PHP to Python, and now in Go!
• Golang! ❤
• AsciiDoc, including automated builds of documentation. http://docs.upsilonproject.io/
• I’ve learned the hard way that Python sucks for anything > 50 LOC!
• Packaging — RPMs. Debs. Windows MSI files.
• Versioning. I created a whole separate system for versioning (called `buildid`). I created another system for managing RPM repositories (called `hacky-repository-manager`). Yes, I reinvented several wheels… it has been glorious!
• Prometheus, Grafana, Kubernetes, Service Meshes, Nagios — so many other projects too.
• This list is basically endless.

Upsilon project — How this has helped me;

I have no doubt that Upsilon has given me a significant edge in my career. Absolutely no doubt.

I’m a sales engineer (officially a “solution architect”), and I can speak to developers and engineers in their own language, and sympathize with their struggles in a confident way, because I’ve actually been there. I know how much time goes into packaging properly. To setting up tests. To porting a project from one language to another. The same thing goes for speaking to systems engineers. I’ve got actual hands on experience, and frustrations of automation, Docker, Kubernetes, more than I could get from just reading slides or documentation — from this project. While this project lacked any real production scale, I’ve still taken a lot of fairly real world skills from it.

Also see; http://www.upsilonproject.io/why

Example 2) Tau project

My university dissertation, which I certainly won’t link to (because it’s not online, and it’s incredibly embarasing!). Started in 2008, the idea was a system that glued together the various different types of personal information stored all over the place. Text (SMS) messages on Symbian phones and vCard address books (Java ME app), to a desktop app (Java SE) that read Outlook PST email files, which then was going to connect to various other things. It turned into a total mess! :-)

Tau — Things I learned (technical)

• Super satisfying in 2008 to write Java SE code that ran on a Symbian mobile phone (this was an era of no app stores, very rare to get third party apps, no Android, etc).
• Lots and lots of Desktop GUI design with Java Swing (eugh, I know!)
• Offline caching, some basic systems architecture stuff, and big desktop apps get messy quickly.

Tau — How this helped me

Thinking back, there were probably two big components to this project, but it got me thinking of ambitious goals in a new way. My experiences in learning Desktop GUIs really put me off designing any new big desktop apps and really focus on the web as the main UI. It also put a level of fear into me about building and maintaining mobile apps — something to this day that is a lot more involved than you might think. Probably of most use, it has spurred me on to try new things, and got me thinking about new ideas…

Example 3) Greyvar (game) https://greyvar.github.io/

Lastly, Greyvar is a game that I specifically started to create with the goal of creating a game I would actually play. Ha. While I don’t really even have anything playable, it’s turned into an odyssey project in it’s own way.

Greyvar — Things learned (technical)

• Another reminder that > 50 LOC of Python just is a pain to maintain.
• Modern C++. This has been a lot more enjoyable than you might think.
• Protobuf + grpc.
• Wrote my own YAML parsing library in C++. (Yeah, really. It’s not used anymore though).
• More Golang.
• SDL ❤ (Graphics, audio, input).
• Trying to create a multiplayer game as your first game idea is really stupid if you want something playable!
• Pixel art?!
• Early communication/promotion is really quite pointless in building a community. Get something working first.

Greyvar — How this has helped

I included this, because the outcome and the way it has helped me is quite different from the other two projects outlined above. It’s really just getting more of an understanding of how these areas of technology work. It rounds out my understanding of a new part of the computing and technology domain. Exposure to new types of problems and new things is good. I’ve no doubt it’ll have a more direct impact in the future.

Odyssey projects: more than ‘just’ computing & technology

The examples given in this article are all in the computing and technology domain. That’s just because that’s my context — I’m a techie. However I think that what I am describing here is about far more than just my domain. I think that this concept of odyssey projects could work in science, in humanities — whatever your domain is.

With that being said, I’d like to list some more computing and technology projects that are not purely coding based. These are listed in brief — but each of these have presented learning opportunities and have had lots of helpful benefits — again, all in computing and technology;

• Making video game maps for Half Life and Quake 3 (many years ago!)
• Hosting websites online on Linux virtual machines.
• Managing my own DNS server “by hand”.
• Building home file servers, and setting up absurd levels of redundancy with Git Annex (❤)
• Building a “homelab” — many noisy servers, switches, and weird hardware at home.
• Many many more — like I said, lots of projects on my hard drive!

I’m also pleased to say that certainly some projects have been used by quite a few people other than myself over the years! But I don’t want to list them here.

Summary

I would like to encourage you to consider embarking on some new and deliberate odyssey projects of your own. I hope that you can see that projects don’t just have to be about a deliverable or a destination, and rather on learning on the journey towards that destination — which is often far more valuable in the long run.

To get started, pick an ambitious goal, check that there is some scope for discovery, improvisation, freedom to mess things up, that sort of stuff. You’re on the right track.

Hopefully I’ve defined more than just a helpful way of looking at past projects that might have “failed”. However, if you’ve got projects in your past that you see as wasted time, instead, like me, consider thinking of the effort that you invested as being a valuable opportunity to learn, and list how those things that you’ve learned have been valuable to you. It doesn’t necessarily matter if your project got a poor reception, got cancelled, or if nobody heard about it. If you can write a list of things that you’ve learned, and think about how they helped you, then you could call that an odyssey project.

To be clear, I’m not just talking about looking back on previous projects and labelling them as “odyssey projects”. I deliberately set out on new odyssey projects all the time. For me, it’s become a useful way to reconcile and justify my time invested in interesting journeys — it’s become my preferred way of learning, problem solving and discovery.

TLDR: It’s a good thing to work on projects where the journey involves learning, problem solving and discovery. Be led by where the journey is taking you, not necessarily what you initially saw as the goal on the horizon. Try starting some deliberate odyssey projects of your own.

—

Footnotes:

• I’ve never read Homer’s Odyssey, and it has been pointed out to me that the usage of “odyssey” as a word might have some rather unfortunate unintended meanings. Oh well, I’m sticking with it :)
• I’m writing this at a time when my first baby is due to be born any day — the irony of the amusing timing is not lost on me, where I may well not get the opportunity for personal projects any longer!