I’ll Admit It, I’ve Never Had To Reverse a Linked List in My Career. Does Anyone Do That Anymore?

I’ll Admit It, I’ve Never Had To Reverse a Linked List in My Career. Does Anyone Do That Anymore?

What’s the point?

This is a very common feeling. We have it during high school when we’re learning about philosophy or the biology of the fly or even trigonometry while we’re daydreaming about working for Google or Facebook.

“I don’t need to know this; I’m never going to use it. What’s the point?” said every teenager, ever.

And then we go through the same mental process when we try to formally study computer science and we start learning about algorithms.

“Why do I have to learn about binary trees and linked lists? I already know enough JavaScript to get some freelance clients… I don’t need to know this, what’s the point?” said most of us at one point in our career.

But were we right? Did we never use this knowledge? Or have we somehow taken advantage of it without even realizing it? Let’s talk about that for a second.

I’ve Never Had To Reverse a Linked List in My 18 Years in the Industry

And it’s true, I never did. I’ve worked in web development and eventually, I moved into Big Data. Linked lists? What’s that all about? Who needs them? Am I right?

No, I’m not.

There is actually a very good reason why we go through those subjects and why we learn how to deal with data structures that we may never see in our work: abstraction.

Most of the work of a developer deals with the task of abstracting concepts into immaterial structures that can later be manipulated in many ways. I’m talking about arrays, hashmaps, dictionaries, variables, enums, etc.

Have you ever tried to explain what a variable is to a non-developer? We normally have to borrow concepts from the real world, like “It’s like a box where you can put stuff inside” or “A cup where you can put some data into before drinking it (using it).” But we don’t think like that when we think about our code, do we?

Over the years, developers become masters at abstracting concepts and dealing with non-realistic representations of solutions. Or rather, solutions to problems that are not based on the physical world. Which if you think about it, it’s quite extraordinary since we come from it and we grow and develop as individuals inside it.

So why are we constantly being asked to learn things that we’ll never use? Because it’s helping us stretch our capacity to abstract problems and solutions.

I mean, sure, there is always the slightest chance that you’ll end up working a job that requires you to constantly use these data structures, or you know, similar ones, but that’s not the case for everyone in our industry. And that’s OK too.

It’s all about stretching the abstraction muscles.


If you liked what you’ve read so far, consider subscribing to my FREE newsletter “The rambling of an old developer” and get regular advice about the IT industry directly in your inbox


Sometimes a Glimpse Is All You Need

The other big benefit I see when I think about learning these types of “unnecessary” concepts, is that by learning them you’re getting a glimpse into a world you’re not part of right now.

Why is that helpful? As developers, we’re always going to have to be learning new things, new tech, new languages, and so on. What makes this particular knowledge different from a new language then? Nothing.

I wrote a while ago about 4 programming paradigms you should know about, even if you’re not using them, and about 5 languages that also show you different ways of working, even if you’re not actively using them right now. Why did I do that? Because I’m a firm believer that extra knowledge, especially about fields and areas you’re not daily using, is like a window into another world. Just by peering through it, you can gain so many benefits that it’s scary to think that you don’t want to look.

Maybe you’ll never end up implementing a graph in your life, sure, but hey, perhaps next week you’ll have to deal with data inside a Neo4J database, and you know what? That graph theory you picked up a few years ago might come in handy. You may not remember the whole concept, but it’ll be enough for you to expand on it if you need it through Google and other tools. You got a glimpse into graph theory a few years ago, that was enough.

Perhaps You Need It and You Haven’t Realized It Yet

All right, personal storytime.

I started coding when I was 14. Back then I had just started using the internet and I had learned there were these people called “hackers.” I fell in love with the idea of them, so I wanted to be one.

Through research — whatever I could do borrowing phone time from my parents with a 2.400 bauds modem — I figured I had to be a coder if I wanted to be a hacker, so I started there.

By the time I reached my first job at age 20, I realized one thing: I had no idea what I was doing. I had picked up basic programming concepts on my own, yes, I know about control statements and loops and variables. In fact, I knew a thing or two about graphic and game programming as well. But I started working as a web developer, so almost none of these would help me there.

No worries though, I’m a pretty fast learner, so a few weeks later I had HTML and CSS down and was starting to pick up PHP and JavaScript. They were very easy.

Months later I was doing it; I was a full-blown full-stack developer — now remember this was almost 20 years ago; that term has changed a bit by now — there were no tasks they could throw at me I couldn’t do. That was it, I had peaked.

It took me a while to realize I hadn’t. Through conversations with my teammates, I started seeing how they used concepts I had deemed unnecessary throughout my learning path. Things like design patterns — I didn’t need any design patterns; I knew everything I needed.

And yes, that is partially true. I didn’t need them, I could work without them, but was I doing the best job I could without them? The answer is no, I wasn’t.

Long story short — as if it wasn’t already long — eventually I realized I had to go back to school, finish my degree, and formalize my education. Why? Because I needed someone to show me the world I had been neglecting to see. I needed to know about the words these other people were talking about and when I eventually did, I was a whole new developer.

Not because now I was able to hold a discussion on whether a Singleton pattern makes sense over an Observer (silly example, I know) but rather because I had interiorized that and many other “unnecessary” concepts into my day-to-day.

I wasn’t implementing patterns on every project, but they were a new tool under my tool belt, and I felt a lot more secure as a developer because of it.


Do not confuse the entry-level knowledge you need to start being a developer with what you need to master the craft. You don’t need any technical knowledge to start coding; I’ve seen people from many backgrounds making the switch and working as coders without a single problem.

However, if you do want to master the art of programming, you have to put in the hours and expand your horizons. Take the plunge, and don’t complain about learning new things. They all help in the long run, even if you don’t see it now.

Did you find this article valuable?

Support The Rambling of an Old Developer by becoming a sponsor. Any amount is appreciated!