/reader

I think all of this happened in the check-in part, so before I was actually inside the gates area. I get the impression that I was going to travel by myself for work reasons, and losing my flight meant I had to explain to my boss why, since the company had paid for it; though I wasn't really that worried about this as I was about not finding the ticket.

It's an interesting dream. Airplanes take you places, and I interpret them to be a symbol of growth. The check-in booth is important since it is a liminal area, representing the threshold between normal life and access to the mechanisms of change and travel.

My misplacing of the tickets is strange, since I'm usually quite well organized in these matters, not to mention that technology makes most of the work for us nowadays. This means that perhaps this is an important symbol here. The ticket is sort of my authorization to undergo the process of transformation. Maybe the fact that I thought I had it but can't find it suggests I'm not yet internally convinced that I'm actually ready to undergo this transformation, even though I desire it?

Another interesting symbol is the clerk. He stoutly keeps rejecting my attempts at authentication, over and over. Maybe he can be seen as a king of critic here? I wonder though if he's being a protector (protecting me from something I'm not ready to experience), or whether he's a negative influence (sabotaging my attempt at self-growth). Maybe he can actually be both at the same time? The strict, unfriendly attitude seems to suggest the latter, but the fact that I don't view him as the enemy (I'm my own enemy here) suggests it can also be a bit of the former. Though I think it's more negative than positive, as the attitude does seem to be saying You're probably not good enough.

A core conclusion that comes to mind here is that I might be stuck in some sort of loop. I know I have the tickets, but my standards for allowing myself to grow are impossibly high.

It goes without saying that the only true non-negotiables are sleeping and eating because if the situation becomes dire enough, everything can be sacrificed. But thankfully I live in a quiet corner of the world so I don’t have to go to such extremes.

I found this to be an interesting exercise because there are a lot of activities that I thought were important to me—playing basketball, seeing friends in person, playing video games—and yet over the past few years I found myself drifting away from them without even noticing it. I have not played a game of basketball in probably more than a year, I barely play any games these days and I can count on one hand the times I’ve seen friends in person this year.

I’m currently in my experimental June and I can confidently say that listening to podcasts and watching videos definitely don’t need to be part of my life for it to feel complete.

The conclusion I came to while thinking about this question is that there are only three things I think are non-negotiable:

• Engaging in conversations with other humans
• Having access to nature
• Doing something creative

I struggle hard in non-natural environments and I need to be able to go out for walks in the woods and have access to the mountains. I don’t think I can go back to living in a city at this point. I also find immense value in exchanging ideas with others and that’s also something I think I cannot let go of. Guess I can’t be a hermit after all. And lastly, doing something creative, of any kind, is something I realised matters a lot. I can go maybe a few days with the output knob turned all down to zero but then I start to become very restless and I feel the need to do something. My brain is not wired for pure consumption apparently.

It’s going to be interesting to look back to this same question in a few years and see if things have changed. How about you though? Do you have non-negotiables things in your life?

Thank you for keeping RSS alive. You're awesome.

Email me :: Sign my guestbook :: Support for 1$/month :: See my generous supporters :: Subscribe to People and Blogs

There are languages I’ve been writing in every single week for the last 15+ years, of course, like PHP, Ruby, and JavaScript. And my underlying fundamentals are solid.

But is it really fair for me to be able to claim that I can code in Java, Go, or Python: languages that I’ve not used commercially within the last 5-10 years?

Obviously, I couldn’t just let that question lie². Let’s find out!

Contents

• Contents
• The Test
• The Theory
  • Simple case with O(n) complexity
  • Achieving O(1) time complexity
• The Implementation
• What did I learn?
  • Lesson #1: programming more languages can make you better at all of them
  • Lesson #2: even when I’m rusty, I can rely on my fundamentals
  • Lesson #3: structural rules are harder to gearshift than syntactic ones
• Okay, time for a new job
• Footnotes

The Test

I fished around on Glassdoor for a bit to find a medium-sized single-sitting tech test, and found a couple of different briefs that I mashed together to create this:

In an object-oriented manner, implement an LRU (Least-Recently Used) cache:

• The size of the cache is specified at instantiation.
• Arbitrary objects can be put into the cache, along with a retrieval key in the form of a string. Using the same string, you can get the objects back.
• If a put operation would increase the number of objects in the cache beyond the size limit, the cached object that was least-recently accessed (by either a put or get operation) is removed to make room for it.
• putting a duplicate key into the cache should update the associated object (and make this item most-recently accessed).
• Both the get and put operations should resolve within constant (O(1)) time.
• Add automated tests to support the functionality.

My plan was to implement a solution to this challenge, in as many of the languages mentioned on my CV as possible in a single sitting.

But first, a little Data Structures & Algorithms theory:

The Theory

Simple case with O(n) complexity

The simplest way to implement such a cache might be as follows:

• Use a linear data structure like an array or linked list to store cached items.
• On get, iterate through the list to try to find the matching item.
  • If found: move it to the head of the list, then return it.
• On put, first check if it already exists in the list as with get:
  • If it already exists, update it and move it to the head of the list.
  • Otherwise, insert it as a new item at the head of the list.
    • If this would increase the size of the list beyond the permitted limit, pop and discard the item at the tail of the list.

The problem with this approach is that it fails the requirement that the methods “should resolve within constant (O(1)) time”³.

Of particular concern is the fact that any operation which might need to re-sort the list to put the just-accessed item at the top ⁴. Let’s try another design:

Achieving O(1) time complexity

Here’s another way to implement the cache:

• Retain cache items in a doubly-linked list, with a pointer to both the head and tail
• Add a hash map (or similar language-specific structure) for fast lookups by cache key
• On get, check the hash map to see if the item exists.
  • If so, return it and promote it to the head (as described below).
• On put, check the hash map to see if the item exists.
  • If so, promote it to the head (as described below).
  • If not, insert it at the head by:
    • Updating the prev of the current head item and then pointing the head to the new item (which will have the old head item as its next), and
    • Adding it to the hash map.
    • If the number of items in the hash map would exceed the limit, remove the tail item from the hash map, point the tail at the tail item’s prev, and unlink the expired tail item from the new tail item’s next.
• To promote an item to the head of the list:
  1. Follow the item’s prev and next to find its siblings and link them to one another (removes the item from the list).
  2. Point the promoted item’s next to the current head, and the current head‘s prev to the promoted item.
  3. Point the head of the list at the promoted item.

It’s important to realise that this alternative implementation isn’t better. It’s just different: the “right” solution depends on the use-case⁵.

The Implementation

That’s enough analysis and design. Time to write some code.

Picking a handful of the more-useful languages on my CV⁶, I opted to implement in:

• Ruby (with RSpec for testing and Rubocop for linting)
• PHP (with PHPUnit for testing)
• TypeScript (running on Node, with Jest for testing)
• Java (with JUnit for testing)
• Go (which isn’t really an object-oriented language but acts a bit like one, amirite?)
• Python (probably my weakest language in this set, but which actually ended up with quite a tidy solution)

Naturally, I open-sourced everything if you’d like to see for yourself. It all works, although if you’re actually in need of such a cache for your project you’ll probably find an alternative that’s at least as good (and more-likely to be maintained!) in a third-party library somewhere!

What did I learn?

This was actually pretty fun! I might continue to expand my repo by doing the same challenge with a few of the other languages I’ve used professionally at some point or another⁷.

And there’s a few takeaways I got from this experience –

Lesson #1: programming more languages can make you better at all of them

As I went along, one language at a time, I ended up realising improvements that I could make to earlier iterations.

For example, when I came to the TypeScript implementation, I decided to use generics so that the developer can specify what kind of objects they want to store in the cache, rather than just a generic Object, and better benefit type-safety. That’s when I remembered that Java supports generics, too, so I went back and used them there as well.

In the same way as speaking multiple (human) languages or studying linguistics can help unlock new ways of thinking about your communication, being able to think in terms of multiple different programming languages helps you spot new opportunities. When in 2020 PHP 8 added nullsafe operators, union types, and named arguments, I remember feeling confident using them from day one because those features were already familiar to me from Ruby⁸, TypeScript⁹, and Python¹⁰, respectively.

Lesson #2: even when I’m rusty, I can rely on my fundamentals

I’ve applied for a handful of jobs now, but if one of them had invited me to a pairing session on a language I’m rusty on (like Java!) I might’ve felt intimidated.

But it turns out I shouldn’t need to be! With my solid fundamentals and a handful of other languages under my belt, I understand when I need to step away from the code editor and hit the API documentation. Turns out, I’m in a good position to demo any of my language skills.

I remember when I was first learning Go, I wanted to make use of a particular language feature that I didn’t know whether it had. But because I’d used that feature in Ruby, I knew what to search for in Go’s documentation to see if it was supported (it wasn’t) and if so, what the syntax was¹¹.

Lesson #3: structural rules are harder to gearshift than syntactic ones

Switching between six different languages while writing the same application was occasionally challenging, but not in the ways I expected.

I’ve had plenty of experience switching programming languages mid-train-of-thought before. Sometimes you just have to flit between the frontend and backend of your application!

But this time around I discovered: changes in structure are apparently harder for my brain than changes in syntax. E.g.:

• Switching in and out of Python’s indentation caught me out at least once (might’ve been better if I took the time to install the language’s tools into my text editor first!).
• Switching from a language without enforced semicolon line ends (e.g. Ruby, Go) to one with them (e.g. Java, PHP) had me make the compiler sad several times.
• This gets even tougher when not writing the language but writing about the language: my first pass at the documentation for the Go version somehow ended up with Ruby/Python-style #-comments instead of Go/Java/TypeScript-style //-comments; whoops!

I’m guessing that the part of my memory that looks after a language’s keywords, how a method header is structured, and which equals sign to use for assignment versus comparison… are stored in a different part of my brain than the bit that keeps track of how a language is laid-out?¹²

Okay, time for a new job

I reckon it’s time I got back into work, so I’m going to have a look around and see if there’s any roles out there that look exciting to me.

If you know anybody who’s looking for a UK-based, remote-first, senior+, full-stack web developer with 25+ years experience and more languages than you can shake a stick at… point them at my CV, would you?

Footnotes

¹ I suspect that when most software engineers look for a new job, they filter to the languages, frameworks, they feel they’re strongest at. I do a little of that, I suppose, but I’m far more-motivated by culture, sector, product and environment than I am by the shape of your stack, and I’m versatile enough that technology specifics can almost come second. So long as you’re not asking me to write VB.NET.

² It’s sort-of a parallel to how I decided to check the other week that my Gutenberg experience was sufficiently strong that I could write standard ReactJS, too.

³ I was pleased to find a tech test that actually called for an understanding of algorithm growth/scaling rates, so I could steal this requirement for my own experiment! I fear that sometimes, in their drive to be pragmatic and representative of “real work”, the value of a comprehension of computer science fundamentals is overlooked by recruiters.

⁴ Even if an algorithm takes the approach of creating a new list with the inserted/modified item at the top, that’s still just a very-specific case of insertion sort when you think about it, right?

⁵ The second design will be slower at writing but faster at reading, and will scale better as the cache gets larger. That sounds great for a read-often/write-rarely cache, but your situation may differ.

⁶ Okay, my language selection was pretty arbitrary. But if I’d have also come up with implementations in Perl, and C#, and Elixir, and whatever else… I’d have been writing code all day!

⁷ So long as I’m willing to be flexible about the “object-oriented” requirement, there are even more options available to me. Probably the language that I last wrote longest ago would be Pascal: I wonder how much of that I remember?

⁸ Ruby’s safe navigation/”lonely” operator did the same thing as PHP’s nullsafe operator since 2015.

⁹ TypeScript got union types back in 2015, and apart from them being more-strictly-enforced they’re basically identical to PHP’s.

¹⁰ Did you know that Python had keyword arguments since its very first public release way back in 1994! How did it take so many other interpreted languages so long to catch up?

¹¹ The feature was the three-way comparison or “spaceship operator”, in case you were wondering.

¹² I wonder if anybody’s ever laid a programmer in an MRI machine while they code? I’d be really interested to see if different bits of the brain light up when coding in functional programming languages than in procedural ones, for example!

🪄 Feeds are wonderful, and you're a wonderful person for using them. 🔮

I grabbed a pair of tweezers and removed it as carefully as I could. While doing that, I remembered an interview I once read with an entomologist—a bug expert.

He explained that ticks don’t really serve any meaningful function or provide any benefit. When asked the follow-up question, “Then why do they exist?”, he simply replied:

“They exist… because the possibility exists.”

Not exactly a comforting answer. Not educational or moral. Just a cold observation.

Our search for meaning

There’s something deeply human in how we may respond to explanations like that.

We so badly want everything to have meaning. We want there to be some kind of logic behind pain, discomfort, and setbacks. We want to believe that the bad things in the world—from tiny ticks to massive tragedies—exist for a reason, part of a larger story.

But sometimes, that’s just not how it works.

Sometimes things happen without rhyme or reason. A random coincidence, a fluke, a biological chance that simply took hold. Desperately, we search for meaning—and sometimes we settle for explanations that soothe us for the moment. Just to feel some kind of peace.

We call it fate. We call it evil. We call it karma.

All in an attempt to create structure in the chaos. And while it may help in the moment, the discomfort tends to creep back in.

The stone in the shoe

It’s like a small stone in your shoe—not unbearable, but there, quietly reminding you.

When we take the stone out, there’s a moment of relief. But does that mean we’ll never get something in our shoe again? Of course not. We’ll have to empty it over and over as we go through life.

That doesn’t mean there’s some malicious Shoe Monster targeting us. And it doesn’t mean life is out to get us. Sometimes, things just go wrong.

If you ask a successful entrepreneur or an enlightened monk—do they live in constant peace, free of fear and struggle? Of course not. It’s easy to think so when we only see the surface, but everyone has their ticks—their small, invisible trials.

So what should we do? Just accept everything and let life happen without trying to shape it?

No.

A small sting to avoid a bigger one

We truly have incredible possibilities to make the most of our lives. We can build safety, balance, and meaning—not by controlling everything, but by doing what we can, right where we are.

To return to that little tick behind my knee—some things can be prevented. Like TBE, for instance. Through vaccination. And that’s exactly what I chose to do after today’s little reminder of life’s unpredictability. A small sting, to avoid a bigger one.

Maybe that’s what life is really about: not finding a perfect explanation for everything, but learning to live with uncertainty—and still doing the best we can with what we’ve got.

Here are some examples of the kind of posts I've really enjoyed recently:

• Jason’s post on his moka pot
• Matt on blog comments and RSS feeds
• Seb’s post on Apple Music
• Jack’s Ghost tinkerings and his thoughts on online identity
• Manu and his pizza. C’mon, who doesn’t love pizza!

I love this corner of the web, so I was wondering — what kind of things are you enjoying in your RSS feeds (or wherever you consume this stuff)? Got a favourite blog or post? Send me an email — I’d genuinely love to hear about it.

Thanks for reading this post via RSS. RSS is great, and you're great for using it. ❤️

Reply to this post by email ● Sign my guestbook