I'm sitting at an airport, sipping a cappuccino, waiting for my flight to board. I'm mostly in my head, thinking about various bits and bobs, house renovation, project at work, stuff like that, when my eyes rest on two huge TVs playing the same three ads back to back, each lasting roughly 10 seconds.

One is for a Samsung phone. The other is for a Samsung TV. The third is for an electric car made by Opel.

The first two though, is what caught my interest (the car too, but for reasons other than what got me typing these words).

You see, both the phone and the TV are advertised with "Galaxy AI", and "Artificial Intelligence", respectively.

And that got me thinking.

We're about to hit the era where "Handcrafted Media" is a thing. Not in the literal sense, of course, because you can't make any sort of media without automated tools:

A handicraft, sometimes more precisely expressed as artisanal handicraft or handmade, is any of a wide variety of types of work where useful and decorative objects are made completely by one's hand or by using only simple, non-automated related tools like scissors, carving implements, or hooks.

https://en.wikipedia.org/wiki/Handicraft

Rather handcrafted in the sense that without AI. Both in the sense that made without AI and consumed without AI.

Now, I’m not an expert at making movies, or tv shows. I know that a lot of people are involved, and they use a lot of tools, both physical and digital. I’m sure that those tools are already being enhanced with “the power of AI”, whatever that means.

What I’m somewhat of an expert at is consuming media (aren’t we all).

TVs already do a lot to modify images for "the viewer's pleasure", like frame interpolation, or colour correction, or even audio tuning.

As "AI" is getting its foothold in TVs as well, I'm sure that these will go up to 11. With tools like OpenAI Sora, you can already generate life-like videos. Sure, they don't hold up to scrutiny, but we miss a lot of stuff already when watching movies anyway. Not to mention that Sora came out roughly 14 months after ChatGPT, so I'm sure that in the coming years it will get much better.

And that worries me.

Imagine this: you're watching a movie on Netflix, and get an ad break. It's just the thing that you were looking at on Amazon a day before. Because soon it will be possible to have personalized ads for every human being on the planet.

Or worse - the ad gets embedded into the movie! Just For You! There's already a much simpler version of this for football, where the boards next to the fields can have different ads depending on the channel and the country that is broadcasting the match.

Now take that, and insert your browser history.

You’re watching The Fast and the Furius 17,5, and on the billboard in one of the scenes you see an ad for toothpaste, in your own language, for a store chain that has a store near you.

But then you rewatch it and it’s government propaganda.

On one hand, this is worrying. But on the other, this is extremely worrying. Unless you're in advertisement, in which case, yay!

I believe people will fight this, but corporations gonna corporate, and money will most probably win at the end of the day.

Still, concessions will probably be made. “Handcrafted” movies will be made. Features that allow users to opt out of personalised ad breaks and/or “AI enhancements”. I think it’s likely that movies themselves will have metadata to instruct your device whether certain modifications are “preferred to be disabled”.

I imagine a future that is terrible, and hope that I’m wrong.

Never Split The Difference by Chris Voss is one of those books that you wish you had read sooner. It is full of eye-opening insights that probably could've saved me a lot of money in the past had I read it sooner.

You see, I've never been a good negotiator - whether we're talking about haggling for a price, or just trying to push through something at work to do it my way instead of colleagues' solutions.

For example, I always believed that when a price is set, it's not going to move. To me, in the context of the price of an object, buying a car is no different than buying cheese from a grocery store. Both have a price tag, and it's surreal to think that I'd be able to get it for less than that - outside of a discount that the seller provides, but that's still a price that they have set, and not one that I have negotiated for.

This book believes otherwise. One of the biggest takeaways for me is the insight that negotiation happens whether we acknowledge or want to take part in it or not.

The first step to achieving a mastery of daily negotiation is to get over your aversion to negotiating. You don’t need to like it; you just need to understand that’s how the world works. [page 18]

And that hurts, because I was mostly ignorant of this. What's worse, I was cognisant of my ignorance, and was fine with that.

This book is a great slap in the face in that regard. It talks about how to negotiate, which I understand feels like a daunting topic, but I feel that it managed to convey both a mentality, and a lot of techniques that one can use to become better at it (or, in my case, start doing it).

I won't outline every single idea this book tries to teach us, but the ones I found particularly interesting / useful are:

Start with listening

I know that this sounds like a no-brainer, and it is, but many times when we are negotiating (or arguing about something), we use the time the other person is speaking as time to compile what we are going to say back to them.

Chris Voss says: don't. Listen to the other person, actively. Doing so not only makes them feel like they are heard, but also gives you more information about where they are coming from, which you can use to inform how you approach the negotiation.

Decision making is governed by emotion

I'm sure this is also one of those "well DUH" sentences, but when I think about trying to convince someone of something, I always use logic.

And that rarely works.

Instead, emotions always take a huge part in decisions. Logic may get you to the door, but only emotion can get you through it.

Calibrated questions are amazing

A calibrated question is one that specifically makes the other person try to think of a solution to your problem.

Use “How” questions to shape the negotiating environment. You do this by using “How can I do that?” as a gentle version of “No.” [Page 186]

Questions like these are good for saying "no" without actually saying no. They are also good at getting more information out of the other party.

Questions like "How am I supposed to do that?", or "What about this do you think does not work?", or "Why would we choose your competitors over you?".

It's important that these are not yes/no questions. I've been trying to switch my yes/no questions to calibrated ones, and it's hard. But at times when I managed to use some, the outcome was much better (not only from the actual outcome of the negotiation, but also the process, and how people felt afterwards).

Negotiation requires preparation

The other ground-shattering idea (for me, which is kinda sad) was that, quote:

When the pressure is on, you don’t rise to the occasion; you fall to your highest level of preparation.

Such an important message that even the book itself has it on two separate pages: 211 and 251.

When going into a negotiation, it's important to be prepared. It could (and should) be preceded by hours or days of research on the topic at hand. Because when you negotiate, and you have to take a punch (for example, an extremely low-ball offer), you need to be prepared to "fight back", or just walk away, knowing that it's such a bad deal that, well:

No deal is better than a bad deal. [page 115]

Closing notes

There are so many other interesting and useful bits in this book, it's hard to summarise them. From psychological factors like how people like others who are similar to them, to how much the anchoring effect can play in a negotiation (putting aside the replication crisis), to things like how uncovering unknown unknowns can massively alter your position in a negotiation, and the list goes on.

I feel it's also important to emphasise that this book is not about "how to take advantage of the other person", but rather, "if you don't engage in a negotiation, you may be taken advantage of without you knowing".

With all that gleaming words, I must admit that there were parts of the book that I did not much care for. It's written in such a way that the author's past (being a law enforcement official, an FBI negotiator, and a teacher / professor) is interleaved with his teaching, giving examples of the different topics being discussed. While it's amazing what he has done, I felt that some of these were not at all applicable to the situations I usually find myself in.

There were also the stories of what Voss' pupils have done, in a typical self-help book fashion, "when they did what I taught, they achieved great success". These garnered many eye-rollings.

This is a personal preference, and your mileage may vary.

All in all, amazing book, I highly recommend it.

I bought "Make Time" 4 months ago, mostly because I felt that I never have time to do what I really want to do.

Since then I have picked it up and consequently forgot about having read some of it twice already, in a way proving my own point that I indeed have no time (or that's what I thought, at least).

With this on my mind I have picked the book up a third time, and have managed to finish it surprisingly quickly. It was a conscious read - the "what can I learn from this" type. In fact, my first highlight was from page 3:

Whatever you want time for, we think Make Time can help you get it

And to it I have added my only note (the other 48 highlights didn't get any):

I wonder if the book delivers on this

The premise of the book is that we all have the same amount of time, every day, and the secret lies in how we choose to spend the time that we have.

The authors introduce the concept of Infinity Pools and Busy Bandwagons, which usually take up most of our times. And, speaking from personal experience, they really do.

Infinity Pools are sources of infinite time-wasting-capabilities. Be it Youtube, Facebook, Twitter, Netflix, Reddit, or anything that's a "refresh for more content" type. There's just no end to how much time you can spend on these sites, apps, and TV channels

Busy Bandwagons, on the other hand are things that, well, keep you busy. Emails, Slack, never ending Todo lists. Be more productive, do more in less, and the like.

The problem with both of these is that there's no end to them. Regardless of how many emails we answer, we always get more. There's also an infinite supply of content everywhere we look. In a sense, they take up as much time from our lives as we give them.

This book provides a framework-esque system, and many many tips and ideas on how to help you become better at getting away from the infinity pools and the busy bandwagons, and instead focus on what you actually want to do in your free time. In addition, it also provides some ideas on how to stay in the zone and resist the urge of procrastination.

In the book's actual words (from page 19):

Make Time Is Just Four Steps, Repeated Every Day

The book argues that instead of spending time on endless content and being busy for the sake of being busy, you should instead choose a Highlight each day, and aim to do that instead. This could be anything you want to do - a hobby, or spending time with the family, researching paint colours for a renovation, anything.

Then, when it comes time to actually spend time on the highlight, Laser Focus on it. Turn off any distractions, close the door to others, immerse yourself in your highlight, create barriers for procrastination, the list goes on.

You'll eventually get tired, which is why you need to Energize. There’s a couple of ideas on how to stay on top of your game both mentally and physically - including tips on exercising, eating, consuming caffeine and sugary stuff, and also about some steps you could do to get better at sleeping.

Lastly, Reflect on the day, what went well, what could've gone better.

The book contains a bunch of tips for the above 4 - things you can try to do. It acknowledges that some are easier said than done, and that not every tactic works for everyone, but they are all worth a try at least.

It closes out with reiterating that it's all just 3 (+1) steps

The Highlight hypothesis If you set a single intention at the start of each day, we predict you’ll be more satisfied, joyful, and effective.

The Laser hypothesis If you create barriers around the Busy Bandwagon and the Infinity Pools, we predict you’ll focus your attention like a laser beam.

The Energize hypothesis If you live a little more like a prehistoric human, we predict you’ll enhance your mental and physical energy.

Where the Reflect part is about you taking notes about what worked and what didn’t.

Should I read it?

If you’ve ever looked back at your previous hour and regretted your choice of entertainment, thought that “Geez, I could’ve spent that better”, then yes. You should.

It gave me some perspective and understanding about what I’m doing and when I’m doing it. For example, putting the teachings of the book into practice, I’ve read most of the book while commuting to work and back.

I have also cut back on the infinity pool usage by not going to Youtube / Podcasts / Instagram when I’m bored. Of course I still use them for relaxing and as learning opportunities, but not so much for “just pass the time please thanks”

Many of the 87 tips and tricks won’t work for most of us, but if at least some of them work, I call it a success.

And I do call it a success.

See for yourself:

Make Time

Make Time is a friendly approach to finding focus and energy in your daily life. It’s not about crushing your to-do list, optimizing every hour, or maximizing personal productivity. It’s about creating time for what matters by rethinking the defaults of constant busyness and distraction.

Make Time

Until next time 👋

A while ago I read The Checklist Manifesto by Atul Gawande. The book was entertaining to read, it conveyed the usefulness (and life-saving potentials) of checklists in a story-driven way, with some much appreciated data sprinkled in to support its message.

The message of the book is that checklists are good. In fact, checklists can save lives, provided their application is in situations where lives may be at stake.

One of the examples given in the book, where checklists have been used, is US Airways Flight 1549 encountering a bird strike shortly after take off, resulting in an emergency landing in the Hudson river.

The movie Sully is a dramatized retelling of the story. The below video shows what the crew did from after the bird strike until the captain decides that they will have to land in the river (spoilers, I guess)

The main thing to note here (for the purposes of this post, at least) is the captain telling the co-pilot to get the QRH - or Quick Reference Handbook.

It’s a bunch of checklists. Basically, each of them answer one question: “What do we need to do when X happens”. The copilot then goes through the book, performing each step - be it confirming some of the things (e.g.: reading on an instrument, position of a throttle), or doing the steps (e.g.: toggling systems, turning on the APU).

The premise of the book is that the same kind of checklists could be introduced elsewhere, primarily in surgical care, to reduce surgical errors that lead to repeat surgeries, infections, or even death.

The main purposes of checklists are that they can be used as a tool to assist in preventing failures. To quote the book itself:

They supply a set of checks to ensure the stupid but critical stuff is not overlooked

To understand where they can be useful, and how, the book also introduces different kinds of problems: Simple, Complicated, and Complex.

Simple problems are basically sets of steps. They are like a recipe. You may not yet have all the required skills to solve the problems, but once you do, there’s a high likelihood that next time you encounter such problems, you’ll succeed in solving them.

Complicated problems are basically sets of simple problems. Like building a car, or flying a rocket to the moon. You can divide the complicated problem into many smaller, simpler problems, and when you complete each and every one of them, you also complete the complicated problem. It’s important to note that, on a high level, complicated problems are also like recipes, just that there’s a couple orders of magnitude more steps than for simple problems. And once you learn how to solve a problem, you can repeat and perfect the process (like sending the 2nd, 3rd, etc rocket to the moon).

Complex problems on the other hand can’t be reduced into a recipe. Raising a child being the example used by the book. Every child is unique - raising one child does not guarantee that raising the next child will go smoother or easier.

These three pretty much encompass everything that life may throw at us. And when it does, we need to be prepared. Checklists are tools that can help us deal with them, if we (or others) took the time to compile them.

So something went wrong..

When doing a task, and something ultimately goes wrong, you may ultimately reach for a checklist. That’s fair enough for simple and complicated problems - you have steps you can follow, but what about complex problems? Where there’s no recipe, and every situation is unique?

The book brings up two examples of such cases:

1. Building construction, where something unexpected comes up while building out one of the floors
2. A hurricane hits and people are left without food, water, and shelter

In both cases, the book argues that centralizing the control and decision making does not work, and instead both should be pushed to the people on the field with the expertise.

People, being the ultimate problem solvers, will have to apply their expertise, and work together to come to a solution that befits the problem. More so because in such cases, the complexity of the problem tends to exceed the capabilities / expertise of a single human to solve it.

Building a checklist

The book explores two types of checklists:

• DO-CONFIRM: Perform jobs from memory, and use the checklist to confirm that the right things were done the right way
• READ-DO: Carry out the task as they check them off, like a recipe.

Both have their time and place, and when creating one, it’s important to choose the right type.

Other important aspects are to make sure that the checklist is of appropriate size, contains clear, concise, and unambiguous language, and has a clear cut point when it should be applied.

The appropriate size is necessary because humans are lazy, and, given a checklist with too many items, some will inevitable be skipped either by accident or on purpose. Given a checklist with too few items will lead to people not even bothering to pick it up when needed.

As for the language, it is important as each checklist must be clearly understood by each parties to mean the same thing, otherwise it could create more problems than it tries to solve. This may entail profession-specific jargon used to some extent to aid the users.

The cut-point must also be clearly defined, so that people know exactly when to reach for the checklist.

Lastly, checklists must be tested in the real world. As Helmuth von Moltke the Elder stated in 1871 (translated):

No plan of operations extends with certainty beyond the first encounter with the enemy's main strength

Although he was talking about war, the same applies to trying out any of our plans in the real world.

Summary

Overall, I loved the teachings of the book - it’s something I believe we could all learn from. Although I didn’t quite like the presentation of the book, as it sometimes felt like we were taking the scenic route to get to the point, it was still a book that I enjoyed reading, and would recommend to basically everyone.

But wait, there’s more!

Having read the book, and ruminated over it for a couple of months (most of which I spent never even thinking about it, actually), I decided to write a review-ish of it (hint: you’re reading it). On one hand, it’s because my brother did the same, but on the other, I wanted to also start applying what the book teaches, and what better way to do than… to create a checklist.

And so I did. About writing. Which I am arguably horrible at. Now, I’m not expecting the checklist to magically make me write a lot of posts, nor to make the content interesting. Rather, I’m expecting it to distill down all the steps, however stupid they may be, so that I won’t miss any of them when I try to get my grug brain to push words onto the blog.

So let me end it this way - below you’ll find the current state of the checklist for this very post I’m writing, captured as I’m typing out this line.

Until next time,
Dan

I just blew my own mind, accidentally. This is a short little thingamabob about injecting dependencies. But not like that.

I come from a primarily Java background. I dabbled in Go and currently write a bunch in Python for backend and js/ts for frontend.

Yet I still carry with me the way Mr. Martin (a.k.a. Uncle Bob) taught us all, in his Clean Code books - to inject the dependencies, any means necessary. Either directly to the class, as a constructor parameter, or through setters, or some other shenanigan. Use Spring Boot for all we care, just inject the dependency.

Not saying that this isn't possible in Rust. In fact, it's easy. Let's say, for the sake of an example, you have an Action, which has an execute method. And you'd like to, well, execute the action when it's called. But what do you do when you need to use some service or client as part of that execute method call?

Let's talk concretions:

// Action is the trait in question
trait Action {
    fn execute(&self) -> Result<(), anyhow::Error>;
}

// MessageAction represents a message to be sent to a specific user
struct MessageAction {
    message: String,
    user: String
}

// Implementing Action for MessageAction
impl Action for MessageAction {
    fn execute(&self) -> Result<(), anyhow::Error> {
        // do the things
        // then return
    }
}

Now, let's say that we need to send a http request as part of the MessageAction.execute() call. How do we pass a certain client in?

We could do:

trait Action {
    //                v---------------------v This is the new part
    fn execute(&self, client: reqwest::Client) -> Result<(), anyhow::Error>;
}

But what if not all actions need a client? Or some actions need a database connection?

We could add the client to the MessageAction itself:

struct MessageAction {
    // v The newly added field
    client: reqwest::Client,
    message: String,
    user: String
}

Which, works, yes, in a way. But we're now mixing up data (message and user) with functionality (client). We could iterate on the idea a bit more - create a new struct, or an enum, which has the client and the action itself, but that's pretty much the same "mixing data with functionality", just with more steps.

We could also create a tuple. An unnamed tuple. Kind of. See for yourself:

// Note the parentheses around the type
//         here v                         and here v
impl Action for (ChatMessageAction, reqwest::Client) {
    fn execute(&self) -> Result<(), Error> {
        let (action, client) = self;
        // use the client to do stuff with the action
        todo!()
    }
}

Meaning.. we're implementing the trait on a tuple where the first element is the ChatMessageAction, and the second is our http client, and then we destructure "self" to two variables - the action and the client.

But wait, you may be thinking to yourself, how is this better than having a struct like ActionWithClient, like:

struct ActionWithClient {
    client: reqwest::Client,
    action: ChatMessageAction
}

One word: boilerplate.

The less I need to type, the happier I am. Provided that the readability of the code does not suffer because of that. Because then I get grumpy.

Observe the difference:

fn test() -> Result<(), Error> {
    let message = ChatMessageAction {
        message: "hello there".to_string(),
        user: "general kenobi".to_string(),
    };
    let client = reqwest::Client::new();

    // First create the struct
    let struct_version = ActionWithClient { client, message };

    // Then call the execute method
    struct_version.execute()?;

    // redeclaring because Rust.
    let message = ChatMessageAction {
        message: "hello there".to_string(),
        user: "general kenobi".to_string(),
    };
    let client = reqwest::Client::new();

    // Pass in `client` as the second element, and call the execute method
    (message, client).execute()
}

At this point you may still be trying to figure out the benefit of all. In essence, we're still only taking reqwest::Client as the second element in the tuple, why's that good for us?

Enter generics (and some boilerplate, but the useful kind):

// HttpClient is a trait that represents a client that can make HTTP requests
trait HttpClient {
    fn get(&self, url: &str) -> Result<(), Error>;
    fn post(&self, url: &str, body: &str) -> Result<(), Error>;
}

// Implement HttpClient for reqwest::Client
impl HttpClient for reqwest::Client {
    fn get(&self, url: &str) -> Result<(), Error> {
        todo!()
    }

    fn post(&self, url: &str, body: &str) -> Result<(), Error> {
        todo!()
    }
}

After creating a custom trait, and also implementing it for reqwest::Client, we're ready for the last piece of the puzzle

impl<T> Action for (ChatMessageAction, T)
where
    T: HttpClient,
{
    fn execute(&self) -> Result<(), Error> {
        let (action, client) = self;
        // use the client to do stuff with the action
        todo!()
    }
}

There's some syntax to unpack, but generally speaking, it implements Action for all two-element tuples, where the first element is a ChatMessageAction, and the second is any type T that implements HttpClient. This includes reqwest::Client (because we implemented HttpClient for it manually), and anything else we may implement.. For example for testing purposes, we could have a SpyClient which records the calls it gets to be later inspected. We could also implement that in a test module which does not get compiled when we ship our binary.

We could get even further with this, if we want to make it as generic as possible, by introducing another trait:

trait Message {
    fn message(&self) -> String;
    fn user(&self) -> String;
}

And then implement this for our different message types. Then, in the end:

impl<M, T> Action for (M, T)
where
    M: Message,
    T: HttpClient,
{
    fn execute(&self) -> Result<(), Error> {
        let (action, client) = self;
        let message = action.message();
        let user = action.user();
            
        // use the client to do stuff with the action
    }
}

And that is the ultimate form, right there. Implement Action for tuples where the first type implements Message, and the second one implements HttpClient.

We could, of course, add other traits, like DatabaseClient, or DevNullClient, and implement Action for those as well.

Of course, 99% of the power here is coming from generics themselves. But that 1%, that we can actually implement traits (or even just "normal" functions) on tuples directly, is mind blowing.

I've been having a bit of trouble writing Rust recently. I've been second guessing myself a lot about whether choosing it for a side project was a good idea. The reason for that is that I'm creating something that I've never done before, and generally speaking, I don't yet know what I'm doing (as it happens in the beginning whenever we try something new).

Rust is not very good at this, or so we may think. Here's the thing - people pushing evangelizing Rust do so by pointing out the absolute safety you can achieve with it. Or the most beautiful async code, or error handling, or program flow, or performance.

And it can do that. And it does do that.

The problem is if we understand this as "this is the only way to write Rust code", and immediately try to write our magnum opus when starting to work on something new. But as Rome wasn't built in a day, so will we also struggle in the beginning. Not only because there are a truckload of rules you have to adhere to when writing Rust (otherwise the compiler and clippy will gently push you towards knowing better), but also because you have to first figure out what you're building, and if that's what you want to build!

And therein lies the problem. Of course, you can write perfect code for a problem you don't yet know how to solve, but it will be hard.

When you're typing some idea out for the first time, you usually don't know what it will eventually take to get right. You may have incorrect assumptions about the problem domain, or the language, or the concurrency model, or all of them.

If you just spent hours coming up with the best abstractions, the best control flow to go with it, and exceptionally descriptive errors and error handling, only to find out that it's actually unusable because you haven't thought about how you need to put stuff into the database, then that's hours wasted.

So what I learned is to first get it done, then get it right. Feel free to use .unwrap() and .clone() as if they were free. Use anyhow and make every error return anyhow! errors. Don't worry about panicing.

Explore the problem domain. Find working solutions.

Only after you have something that works, then refactor. Use Rust's advantages to your benefit. It has all the necessary tools and safeguards that allow you to refactor somewhat fearlessly. You may break things, but not in a horrible you'll-find-out-in-four-months-on-production way.

At this time, you should have a solution that works. Now you can replace the unwrap() calls with proper error propagation. Or see if you can replace the .clone() calls with references, or some other kind of magic.

It's okay to start with "quick and dirty" code.

P.s.: This of course isn't unique to Rust, as you can fall into the same pit with most other strongly typed (and even dynamic) languages. It's just that I feel it exceptionally with Rust.

This has been brewing for quite a while.

I've witnessed many debates on programming languages - which is better, which is worse, how dumb you are for choosing one against the other.

And while I think that there is merit to these conversations - to some, at least -, there's one aspect that I feel gets lost almost every time.

It's the fact that you, someone who's standing on the outskirts, can't fully understand the value proposition.

Alright, definition time. If we Google for "define value proposition", we get this gem

value proposition
noun
(in marketing) an innovation, service, or feature intended to make a company or product attractive to customers.

Perhaps easier if we define the words separately, this time from Merriam-Webster:

value
noun
relative worth, utility, or importance

..and..

proposition
noun
something offered for consideration or acceptance : proposal

In simple terms, for our use-case, it's "if I use this, what can this thing do (for me)?"

I've had my fair share with programming languages - I've shipped code to production in Java, Python, Go, and Javascript / Typescript, have dabbled in shell scripting, Clojure, Kotlin, C#, and currently whacking together something in Rust.

You might say I have a problem when it comes to sticking to a single language. You might be right.

But the point is - each and every one of these languages have taught me important lessons about writing software. And most importantly, lessons I could take over to other languages.

The power of plain functions

Take Clojure, for example. It's a lisp-like language on the JVM (and CLR and browser, and also apparently transpiles to Dart?), wonderfully crafted with very strong ideas about the value of type systems. Or rather, the lack thereof.

See, Rich Hickey, its creator, decided that (apart from the primitive ones), 4 types are perfectly enough to write production-grade, maintainable, extensible, and performant software. An array list, a linked list, a map and a set. That's it.

But the whole language is designed around these 4 types. You can easily transform them into one another. You can iterate through them, check if they contain elements, filter them, transform them, and in the end, "it's just data".

And it works. People love Clojure (3rd most loved language in the StackOverflow's 2022 developer survey), and do build amazing applications - like Datomic (a database), or NuBank, a Brazilian bank, which has most (if not all) of its services written in Clojure.

I myself have only dabbled in Clojure. And I see the glimpse of its value proposition - I see that if I were to have a project, a real project, that I finish, I would fully understand its value.

But until then, I can't claim that The Clojure Way is Good (or bad, for that matter). What I can claim, is that I've taken a much more simplistic approach when writing code in other languages, because I saw how powerful that approach can be.

No need to over-complicate everything.

Checking everything at compile time is good

Then there's Rust. Rust pushes you towards types, and being explicit. Everything you do, you should use types. Create types. Implement traits. Fight the borrow checker, then yield because it's actually right.

It's a struggle. You suffer. But in the end, after months, it clicks. You no longer fight it. You create your nifty little types, you look ahead and see that you're about to embark on trying to implement a cyclic data structure, but you already have the scars to prove that that's not a good idea, in Rust at least.

So you rethink, redesign, reimplement. And the end is glorious.

I have enough experience with Rust to understand its value proposition.

And yet I don't, at least, not to its fullest. I don't have any services running in production (yet), so at this point I can't be sure that the promises that the borrow checker and Rust in general is giving me will come to fruition.

If the suffering up front is worth the calm after deployment. Only time will tell (and when it does, I'll write it up).

What I've taken with myself to other languages is that I now see whether some patterns I'm trying to implement would work. Whether there's a possibility of a race condition, or memory leak. I'm not good at finding them, but when I do, I'm happy (and a bit proud)

How to make a decision when you're looking to learn a  new language?

Let's say you're evaluating learning a new language, say, Rust. Or Go. Or Javascript, it doesn't really matter. The point is, you have hearsay about it - people telling you how awesome or how horrible it is. Be that talks, books, or just chatting with people on Discord.

Here's what I want you to think about.

You don't know what the language is like, because, well, you don't know the language.

Your friends / coworkers / authors / presenters may very well have the adequate experience to have an authoritative opinion about it. And maybe they're very happy to share their opinions with you.

But they are an outsider for you. They don't have your experience, or your knowledge, or your current circumstances, what they have is theirs. So their experience, while it may be valuable for you, may not be as applicable for you as it is for them.

It's the same reason why people say YMMV. Or idk tho. Because they are not you and you are not them and therefore what they went through and what they have learned may not apply completely for you.

So the only way to know whether a language is worth learning is to learn it. There is no other way.

Which, when you think about it, is not the best situation to be in. By the time you actually realize what the language can offer you, you already know the language, and therefore, have made the task of making a decision void.

If you want a quicker decision, then the only piece of advice I can give is to go back and look at the value proposition. Think about whether that's something that could complement your already existing skillset, or if it's something that can be applied to the problems you're working on. Or heck, maybe help you find a position which you'd enjoy more (and also earn more).

Look for a language that can teach you something. Be it functional programming, compile-time memory safety, REPL-driven-development, type-driven-development, or what have you.

You can (and probably should) look for people in the space you're trying to enter, and listen to what they say, and hope they're not bullshitting you.

This past two weeks I've been off work - yearly PTO and everything. In that time, doing some personal project, I've been contemplating about work - the things we have to do and the things we do enjoy. What better way to spend Christmas, right?

I was also listening to the Build For Tomorrow podcast's latest episode: What People of 1923 Predicted About 2023 - in there, Jason (the host), said the following:

I have mostly chosen what to do for a living, and I really enjoy it, which is a luxury. Maybe for people like me, work is a kind of luxury, a kind of leisure. (...)
I don't know, maybe if I tallied it all up, I'm doing four hours a day of work, work I don't want to do, of which there is plenty, believe me. And the rest of it, well, it's my version of luxury.

This got me thinking - I never thought about making a distinction between work I enjoy doing, and work I don't. To me, it was either work (thing I'm paid to do), or it wasn't (personal project at home, for example).

I'm incredibly lucky to be in a profession in which I enjoy working - I'm a software developer, and even when I'm not working, I'm either typing away on some idea (that usually never gets anywhere), or thinking about some problem I'm trying to solve in one of my various projects (to the dismay of my wonderful partner).

But until now, when looking at opportunities, I only evaluated them based on how @cassidoo suggests:

Money, Learning, People: the opportunity should have at least two

Which means that the best opportunity is where you earn good money, can learn new things, and are surrounded by amazing people.

It never really occurred to me to also think about the ratio of work I'd enjoy and work I wouldn't.

Perhaps it's time for me to add that to the list of things I weigh when deciding on staying at a company or going for another opportunity.

Because let's face it: it's important that we try to enjoy it to the best of our abilities. We spend a lot of hours doing work, after all.

I understand that I'm privileged - I have the option to even consider an opportunity based on how much of the work I'd enjoy doing versus how much of "work work" there would be.

Right now, current place - perhaps the scale is tipping in the wrong direction, which I now understand is the reason why I was thinking about these things this past two weeks.

So "new year, new me" I guess - let's start evaluating.

Some days ago there was a long discussion about generics on one of the Discord servers that I frequent. It was rather topical: Go is getting support for generic typing in 1.18, and the question arose: What are they good for? It's a divisive issue for sure - half the developers rejoiced that generics are finally landing, while the other half either hate it, or just don't understand why Go needs generics.

I've been writing code in a couple of languages in the past decade, with both languages that have generics and some that don't, so I had my fair share of run ins with this feature set.

I don't want to go into the question of why they are being added to Go, because I haven't followed the Go developer space for quite some time, and frankly, I don't know all the reasons.

What I would like to do, however, is try to shed some light on what generics are, and what you can use them for.

What are generics?

When we're talking about generics, we usually mean that something is generic over something else. It's usually about functions being generic over some input parameters, or structs / types / classes being generic over some of their fields.

But what does that mean?

It means slightly different things in different contexts, and we'll explore each of them in a bit.

But first, let me share a useful framing device: When designing a function, or writing up a struct or a class, it's useful to think about what kind of restrictions we're putting into place for our users (other developers, in this case), because our choices can mean the difference between a good API that is easy to use, and an API you wish you weren't forced to use.

On to the main course; I categorize generics into 4 different types:

1. Concretions
2. Slot generics
3. Generics over functionality
4. Full generics

Concretions

All right, I admit, concretions aren't generics. In fact, they're exactly the opposite. I still wanted to include it, because if we look at a scale of "how generic is this thing", concretions are at the absolute start: none at all.

For example, imagine we have a web app and have created this struct to help us return results over the wire:

type Result struct {
	Status  uint
	Payload string
}

We have a struct, which has a uint and a string field. This is a concretion, because we are restricted to only using a uint and a string for those fields, respectively. In other words, as the designer of this struct, we have restricted our users to these two types.

What if we wanted to return a list of items? Well:

type ListResult struct {
	Status  uint
	Payload []string
}

Though this is better, we're still looking at a concretion: we can only return list of strings. If we wanted to return a list of, say, numbers, we'd need a NumberListResult.

Having a non-trivial application, we can see where this may lead us: A proliferation of structs that are each good for one specific purpose.

This can get considerably worse if we're a library author and want to provide some convenience functions on instantiating our numerous Result structs. We can easily explode the codebase to handle all the use cases we can think of.

And then there's the domain of use cases that we can't think of. What if our users want to have a MapStringStringResult, and we absolutely loath using maps for anything, so much so that our brain ignores the existence of maps? There's little chance that we'd have a constructor function for that use-case.

Let's look at how Generics can help us solve this problem.

Slot generics

When I say slot generics, I mean that a struct (or class) is generic over one or more of the fields it contains. I call this slot generics, because we're specifying one or more slots which can hold a value of a type that will be specified later.

To go back to our previous Result example, we could have a generic version such that:

type Result[T any] struct {
	Status  uint
	Payload T
}

This is weird syntax, but it's rather straightforward. In the above example, T is not a concrete type, it's an identifier, or placeholder for a type. You can read this type declaration the following way:

Result is a struct which has a generic type T. It has a field Status of type uint, and a field Payload, of type whatever T will be when Result is constructed.

How does one construct a generic Result?

package main

import "fmt"

type Result[P any] struct {
	Status  uint
	Payload P
}

func main() {
	//   	 👇 important bit
	result := Result[string]{
		Status:  200,
		Payload: "Hello there",
	}

	fmt.Println(result)

	//        👇 also important bit
	result2 := Result[[]string]{
		Status:  200,
		Payload: []string{"Hello there", "General Kenobi"},
	}

	fmt.Println(result2)
}

// output
{200 Hello there}
{200 [Hello there General Kenobi]}

Above we've constructed a Result struct with both a string and a []string. The syntax may seem weird again, but it's as simple as the type declaration was:

1. Result[string] is a Result[T any] where T = string
2. Result[[]string] is a Result[T any] where T = []string

The best part is since T can be anything, we can have nested generics (if we want, of course):

result3 := Result[Result[uint]]{
	Status: 301,
	Payload: Result[uint]{
		Status:  404,
		Payload: 401,
	},
}
fmt.Println(result3)

// output
{301 {404 401}}

But wait! Go already has the empty interface (interface{}), why do we need generics? We could just plop in interface{} and get the same results, right?

package main

import "fmt"

type IResult struct {
	Status  uint
	Payload interface{}
    //      👆 Oh look, a change!
}

func main() {
	iresult := IResult{
		Status:  200,
		Payload: "Hello there",
	}

	fmt.Println(iresult)

	iresult2 := IResult{
		Status:  200,
		Payload: []string{"Hello there", "General Kenobi"},
	}

	fmt.Println(iresult2)

	iresult3 := IResult{
		Status: 301,
		Payload: IResult{
			Status:  404,
			Payload: 404,
		},
	}
	fmt.Println(iresult3)
}
// output
{200 Hello there}
{200 [Hello there General Kenobi]}
{301 {404 404}}

Yep, same result. Does this mean that Generics is just a more verbose syntactic sugar (or in this case.. salt?) for using interface{}?

Not exactly. Generics has two aces up its sleeve, and to show that, let's first see what happens here:

package main

import "fmt"

type IResult struct {
	Status  uint
	Payload interface{}
    //      👆 The interface version
}

func main() {
	iresult3 := IResult{
		Status: 301,
	//          👇 When instantiating, Payload gets an IResult as its value
		Payload: IResult{
			Status:  404,
			Payload: 404,
		},
	}
	fmt.Println(iresult3)

	// 				  👇 Overwriting the IResult with a string
	iresult3.Payload = "oh no"

	fmt.Println(iresult3)
}

In this instance, we're using the empty interface. Is this valid Go code? Let's ask the compiler:

$ go run prog.go
{301 {404 404}}
{301 hehe}

...yep. Alright, moving to the one with generics:

package main

import "fmt"

type Result[T any] struct {
	Status  uint
	Payload T
    //     👆 The generic version
}

func main() {
	// 				  👇 Typing it to an embedded Result
	iresult3 := Result[Result[uint]]{
		Status: 301,
		Payload: Result[uint]{
			Status:  404,
			Payload: 404,
		},
	}
	fmt.Println(iresult3)

	// 				  👇 Trying to overwrite it with a string
	iresult3.Payload = "oh no"

	fmt.Println(iresult3)
}

And the compiler says...

./prog.go:20:21: cannot use "oh no" (untyped string constant) as Result[uint] value in assignment
Go build failed.

Oh no. The compiler yelled at me. And it feels good (your mileage may vary).

What's the difference here? Well, the empty interface, per the wonderful Tour of Go:

...may hold values of any type. (Every type implements at least zero methods.)

That's the absolute opposite of using a concrete type. While concretions restricts our users (devs) to using one specific type, the empty interface allows anything, even changing the value to another type within the same struct! And that's dangerous.

We can thus change the value of a uint to a value of a string, because they are both interface{} types. The compiler is happy - we're still upholding the restrictions we've put in place.

Another drawback of using the empty interface for this is that once we put a type in, we have lost information about what that is. We can of course get it back later by doing type assertions, and, sure, it works:

package main

import "fmt"

type IResult struct {
	Status  uint
	Payload interface{}
    //     👆 hello interface
}

func main() {
	iresult3 := IResult{
		Status:  301,
		Payload: "hehe",
	}
	fmt.Println(iresult3)

	// Type assertion right here 👇
	val, ok := iresult3.Payload.(string)
	if ok {
		fmt.Println("it's a string: ", val)
	}
}
// result
{301 hehe}
it's a string:  hehe

But we've essentially delegated type checking to happen at runtime instead of at compile time, which can be the source of issues that the compiler could catch for us.

This is one of the points where generics shine: As soon as we create a Result[string], the type of Payload for that struct will always be string. And it is a string, through and through:

type Result[T any] struct {
	Status  uint
	Payload T
    //     👆 generic type
}

func main() {
	//                 👇 instantiating with a string
	result3 := Result[string]{
		Status:  200,
		Payload: "yep",
	}

	list := make([]string, 0)
    //    👇 Adding Payload to a slice of strings
	list = append(list, result3.Payload)

	fmt.Println(list)
}
// output
[yep]

We couldn't say the same for the empty interface version without doing a type assertion:

./prog.go:26:22: cannot use iresult3.Payload (variable of type interface{}) as type string in argument to append: need type assertion

The other thing that generics lets us do is that once a T is specified, anything that has that type parameter must be of that type.

For example, let's look at the following:

package main

import "fmt"

type Pair[T any] struct {
	First  T
	Second T
	//    👆 Yes, you can use the same type parameter for multiple fields
}

func main() {
	//          👇 T = string, so both First and Second are string
	p := Pair[string]{
		First:  "Ball",
		Second: "Food",
	}

	fmt.Println(p)
}

// output
{Ball Food}

Once we instantiate Pair[string], both First and Second within Pair has to be a string. We can't do p.Second = 142, because we'll be yelled at again:

./prog.go:31:13: cannot use 142 (untyped int constant) as string value in assignment

This is tremendously useful, and a huge benefit over using interface{} for both fields, as that would allow any combination of types both at instantiation and later down the struct's life.

One more thing

Go already has slot generics, all the way back from day one. I'm sure every go programmer has used them already, especially since it's part of the Tour of Go as well.

Arrays (and by extension, slices) and maps are both generic types in Go. They fit our restrictions of slot generics perfectly, although they have different syntax to what Go is getting with 1.18:

// Arrays
// primes is an array with 6 int elements
primes := [6]int{2, 3, 5, 7, 11, 13}
// names is an array with 2 string elements
names := [2]string{"Alice", "Bob"}

Arrays specify the length of its elements, as well as the type of said elements. The same holds true for maps as well:

// Maps
type Vertex struct {
	Lat, Long float64
}

// m is a map which has string keys and Vertex values
var m = map[string]Vertex{
	"Bell Labs": Vertex{
		40.68433, -74.39967,
	},
	"Google": Vertex{
		37.42202, -122.08408,
	},
}

All in all, Go 1.18 is getting the same kind of flexibility that arrays, slices, and maps already had from day one (with regards to specifying the types at instantiation).

Generic over functionality

We can call this generics just as much as we can call concretions generics. Not really.

It's interfaces. Interfaces aren't considered to be generic, but in some sense, when they are used, they kinda are.

Going back to our previous example, what if all we cared about for the payload is that it can be turned into a string?

package main

import "fmt"

type SResult struct {
	Status  uint
	Payload fmt.Stringer
    //      👆 A wild interface appears!
}

type Msg struct {
	message string
}

//   👇 Msg implements fmt.Stringer because of this.
func (m Msg) String() string {
	return m.message
}

func main() {
	result := SResult{
		Status:  500,
		Payload: Msg{message: "Internal Server Error"},
	}

	fmt.Println("result is:", result)
}
// output
result is: {500 Internal Server Error}

Naturally, the above is a silly example, but it shows that interfaces can also be used for typing our structs. In that case, we're essentially telling the compiler (and our users [devs]), that we don't care what's in there, as long as it implements the Stringer interface.

That's a form of generics, in my book. The SResult struct above is generic over the Stringer interface. From a restrictions standpoint, we've restricted the allowed types to only those that fulfill the Stringer contract. The compiler will check this for us, and the compiler will yell at people to provide what is required if they want the code to compile.

I don't really want to dwell too much on this - Go has this feature, and I believe it's well understood by pretty much all the devs. Nevertheless I felt that it was an important point to make, because...

Remember that 13 Page-Ups ago, I mentioned that

We also see that T can be anything. More on this later.

The best part about generics is how easy it is to further restrict what our code can do. For example, to get the same functionality as the SResult above (that Payload must be a type that implements fmt.Stringer), we can do:

package main

import "fmt"

//          👇 This is the only part that's different from the above example
type SResult[T fmt.Stringer] struct {
	Status  uint
	Payload T
}

type Msg struct {
	message string
}

func (m Msg) String() string {
	return m.message
}

func main() {
	//        👇 Okay, and this as well
	result := SResult[Msg]{
		Status:  500,
		Payload: Msg{message: "Internal Server Error"},
	}

	fmt.Println("result is:", result)
}
// output
result is: {500 Internal Server Error}

It's the same thing, we just moved some characters around. Some languages allow for a bit more powerful features when it comes to generics, for example, Rust can require that a type fulfills more than one trait (which for our purposes, are kinda like interfaces)

use std::cmp::Ord;
use std::fmt::Display;

//            👇 T must implement both Display (~fmt.Stringer) and Ord (can be ordered)
struct SResult<T: Display + Ord> {
    status: usize,
    payload: T,
}

fn main() {
    let r = SResult {
        status: 200,
        payload: "Success!",
        //       👆 &str implements both Display and Ord, so can be used here
    };
}

Unfortunately, at the moment Go doesn't seem to allow more complex restrictions, such as specifying that the type must implement more than one interfaces (or I haven't found how to do it yet). I'm hopeful it'll be possible though, as this can be rather useful.

What it does allow, is creating type unions:

package main

import (
	"fmt"
)

//  👇 Number is either a uint, an int, or a float64
type Number interface {
	uint | int | float64
}

type SResult[T Number] struct {
	Status  uint
	Payload T
}

func main() {
	//                👇 in this case, we type it as an int
	result1 := SResult[int]{
		Status:  500,
		Payload: -10,
	}

	fmt.Println("result1 is:", result1)

	//                👇 in this case, we type it as a float64
	result2 := SResult[float64]{
		Status:  500,
		Payload: 10.0,
	}

	fmt.Println("result2 is:", result2)

	//                👇 in this case, we type it as a uint
	result3 := SResult[uint]{
		Status:  500,
		Payload: uint(10),
	}

	fmt.Println("result3 is:", result3)
}
// output
result1 is: {500 -10}
result2 is: {500 10}
result3 is: {500 10}

..but as soon as we try to use a type that is not one of the ones we specified:

result1 := SResult[string]{
	Status:  500,
	Payload: "oh no",
}
fmt.Println("result1 is:", result1)

// output
./prog.go:17:21: string does not implement Number

This is important - the compiler is yelling at us again. But how is this useful? Well, one thing I haven't talked about yet is that functions can be generic as well:

package main

import (
	"fmt"
)

type Number interface {
	uint | int | float64
}

//      👇 Same as with structs; Add is generic over T, which has to be of type Number
func Add[T Number](a, b T) T {
	return a + b
}

func main() {
	//										           👇int, int
	fmt.Printf("result: %[1]d, result type: %[1]T\n", Add(-10, 20))
    //										           👇uint, uint
	fmt.Printf("result: %[1]d, result type: %[1]T\n", Add(uint(10), 20))
    //										           👇float64, float64
	fmt.Printf("result: %[1]f, result type: %[1]T\n", Add(10.0, 20.0))
}
// output
result: 10, result type: int
result: 30, result type: uint
result: 30.000000, result type: float64

Two powerful mechanisms are at work here:

Type restriction on the arguments

Add is generic over its input arguments. It requires that both a, b, and its return type is a Number. In addition, it is also required that a, b, and the return type must be of the same type. For example, the following causes a compile error, even though both uint and int satisfy the Number interface:

Add(uint(10), int(39))
// output:
./prog.go:20:16: type int of int(39) does not match inferred type uint for T

And that's huge. It allows us to move a myriad of type checking from runtime to compile time, as well as writing code that can leverage such restrictions, just like the silly little example for Add above.

Type inference

Have you noticed that Go's type inference leapt into action? There's three things we didn't have to do:

1. Specify what types we're calling Add with. The compiler was able to deduce that since we're invoking it with a valid type, we don't have to explicitly state the type like with the struct versions (Yes, I did have to add uint, but that was to make sure we're using that version of the function).
2. In case where we had to cast one of the arguments (uint(10)), we didn't have to do the same for the second. The compiler figured out that since Add requires that both its arguments have to be T, the second argument must also be a uint, so it did the "cast" for us.
3. The return value is typed accordingly as well, as can be seen from the output, so that was inferred for us as well. No need for type assertions 🎉

Some closing thoughts

I hope by this point you can see just how powerful generics can be, if used in the right places. Not all places are good for generics, mind you, sometimes all we need is a sturdy type and that's it. Other times we can use interfaces, but there are some situations where using generics is just a better approach altogether.

Go's map does this as well, and it even uses some restrictions. If we read through the post about maps on the official Go language blog, we'll see the following section:

A Go map type looks like this:

map[KeyType]ValueType

where KeyType may be any type that is comparable (more on this later), and ValueType may be any type at all, including another map!

...later on (emphasis mine):

As mentioned earlier, map keys may be of any type that is comparable. The language spec defines this precisely, but in short, comparable types are boolean, numeric, string, pointer, channel, and interface types, and structs or arrays that contain only those types. Notably absent from the list are slices, maps, and functions; these types cannot be compared using ==, and may not be used as map keys.

This sounds a lot like generics to me. You can use anything for the KeyType as long as those things can be compared to one another, and everything goes for the values.

I'd argue Go's maps are powerful. I'd argue that the doors generics open are also powerful.

Lastly, one thing I didn't mention, but is an important notion: You can have as many generic types on a struct / function as you want, and have different sets of restrictions for each of them. This is fair game:

type Tuple[T1 any, T2 any, T3 any, T4 any, T5 any, T6 any] struct {
	First  T1
	Second T2
	Third  T3
	Fourth T4
	Fifth  T5
	Sixth  T6
}

Of course, you'd probably want to stop at one or two generic types, anything above that can become hard to understand. As with any tools, one can go overboard and abuse it, generics isn't immune to that.

Code responsibly, and use the right tools for the job.

Until next time 👋

I've been working in IT for over a decade now. Most of it as a Support Engineer, moving onto Software Engineer positions. Yet I chose 2022 as the Year of Foundation.

Don't know what this "Year of" thing is? Check out this post:

On yearly themes

The one about how new years resolutions are bad and how you can do better for yourself

Dan's thoughtsDaniel Javorszky

There are many aspects of this year's theme. So far, I've identified the following:

Health

Continue working out. Put focus on making the movements correctly and in control throughout the exercises. Even if that means doing the simpler routines, slower, and with smaller weights. Nail down the fundamentals before graduating to more complicated exercises.

Cooking

Learn the basics. Like how does one make bread? What are the different spices good for? Should I cook with butter or oil or fat or something completely different? Everything else builds on knowing the foundations, so it's probably that I figure out the basic stuff.

Blogging

Getting points across can be challenging. Gathering a cloud of abstract thoughts and arranging them in a coherent manner such that they convey the meaning you hope to convey is hard.

And I want to get good at it.

So hi! I'm Dan. This is my blog.

I want to use this space to better my writing skills, as well as to give back to the (programming) community. I'm a firm believer that writing about something is the best way to learn about it. Writing guides your thinking, and is especially good at pointing out if there are grey areas still.

Lastly, blogging acts as a simple accountability buddy to me. The theme of Foundation was a deliberate choice, and one that I didn't make lightly. By writing about it, and by documenting my progress, I'm keeping myself accountable.

Although it's my tool to report the progress, some topics will have more weight than others. I plan on mostly writing about programming and software development, but who knows, the occasional weight lifting cassarrole may find its way into these pages.

Programming

We, programmers, are essentially magicians. We write semi-meaningful words and obscure characters, and the computer shows us a message that says "hello". Why? Because that's what we told it to do.

Thing is, there's so much depth when it comes to getting the computer to do what we want it to do. Although I've done a fair share of exploring those options (I didn't just sit idly this past decade), there's still a lot more to cover.

So I'm diving deep. I'm going back to the building blocks - just shy of reaching the hardware-level abstraction. Already started by getting a couple of books about algorithms and data structures, and interpreters.

That's a good start. Let's see where it takes me.

Other foundations?

There are also the areas I don't yet know. I'm sure 2022 will throw some curve balls and perhaps opportunities will also arise. Whatever happens, the guiding theme is Foundation: Focus on the fundamental building blocks instead of the ready-made high level end products.

Of course, it's important to stay flexible. It's entirely possible that my view on what foundational knowledge is will move throughout the year.

That's perfectly fine.

Another alternative is that I realize that what I thought the fundamentals are have a level below them on which they are built, and I descend into an ever evolving spiral of Inception-esque "we need to go deeper" investigations.

That's less fine, but can still be OK to a certain degree. For example, if I were to start looking into "How does Lego work", I would probably stop at the "It's made of plastic" and not look into how plastic is made.

So that's the plan for 2022. Here's hoping it'll be a successful one!

Until next time 👋

Have you ever made a new year's resolution, only to abandon it days or weeks into the year? I sure have. Comparing the average number of people at the gym on the first weeks of January versus a bit later in the year, I'd say others have done so, too.

Maybe you're one of these people. Or maybe not. Perhaps you don't make such resolutions because you think they are stupid, or you don't want to subject yourself to facing the (inevitable?) failure.

But wait, I've learned about this at work. Let's make it S.M.A.R.T.! Then, surely, I can navigate the resolution! For example:

I will work out every week at least once in the next year

..but then on week four, I catch a cold (or worse), and can't go. I have failed to accomplish the goal I set out.

The problem with this is that once you fail to do what you set out to do, often times you just give up. Oh well, I'll get around to it next year.

Same energy of saying "I'll start studying at 7 pm", but then 7:01 comes and goes, and "Oh well, 8 pm it is".

This is where The Theme System comes in. Let's look at mine from 2021:

Year of Health

First thing you'll notice, is that it's broad. It's not specific, at least not to corporate standards. But it's specific enough to help guide decisions and areas of focus.

Instead of spelling out all that I want to do and focus on, specifically, I just have a theme. A theme that helps me make decisions, that may (or may not) concern my health.

The real world is muddy and fuzzy, and there's never a clear cut distinction between two things with regards to their health benefits.

Sure, if the question is whether I should eat four bags of chips or a normal meal, then yes, but that's rarely the kind of decisions we make on a day-to-day basis (if it is for you, I'm really sorry).

The questions I faced were more on the level of:

1. should I work out or play video games?
2. should I be lazy and go to McDonald's (or order from them)?
3. should we go drinking or hiking?

Writing them out, there's always an obvious answer, but if we really think about it - are they really that obvious?

Sometimes we want to take the easy route. Sometimes we are just dead tired. And it's okay to have fun.

The idea of the theme is that the overall direction, the trend of our progress is in line with what we envisioned for the year (or season, or month, or whatever).

So did it work?

I even managed to apply it to both physical and mental health.

From the physical perspective, I have focused on eating more healthy foods than before, went to the gym 58 times (thanks, FitBod!), and had more outdoor activities (mostly hiking).

I wasn't the textbook description of health, mind you. My trips to fast food joints were in the double digits in the year, and I had my fair share of skipping leg days (or workout days, for that matter). But still, it was a better year for my health than the ones before it.

As for the mental aspect, I've taken steps to increase my mental hygiene, like removing myself from Facebook, lowering the number of unnecessary notifications I'm getting on my phone, and generally being more cognizant about how certain activities and sites/people are affecting me, mentally.

I'm happy that I stumbled upon The Theme System, and I'm always eager to suggest it to others if they're having some thoughts about their future.

If you'd like more information, check the Theme System's website, or this amazing video by CGP Grey (who's the co-creator of The Theme System, and also much better at explaining this than I am):

Next time you want to make a new years resolution - choose a theme instead. You'll probably thank yourself a year later.

Until next time 👋