When I started my journey through Flatiron School's Software Engineering curriculum, I had already done my fair share of casual coding and thought I knew quite a bit. But as I began learning coding at an academic level, rather than a hobby level, I started noticing patterns I'd never been able to distinguish before.

And at first, they were confusing.

The first pattern I noticed was that I kept getting feedback that my code was too tightly coupled. I heard things like, "Introduce that by dependency injection," or, "If you split this into three functions instead of one, future you will be much happier."

Who was this "future me?"

The second pattern I noticed was that, no matter the project, I kept having to write certain helpers. JavaScript, for example, doesn't have a great built-in way to detect integers in every situation you might care about. If you want that type check to be bulletproof, you often wind up doing it yourself.

On nearly every single React project.

Talk about a pain in the neck.

The third thing I noticed was that so many people were using far more comments than I was. I'd look at their code and think, How would they ever forget that? It's as plain as day.

Lastly, I noticed that people used super-long variable names. When I learned to code, I was taught to make variable names concise. Abbreviated, even. They just had to hint at what they represented.

OK… that's a lie. In GW-BASIC, x was my go-to variable name for everything.

Since I was a student in a program, I tried to implement best practices as much as possible. I became more descriptive with my variable names. I started adding comments even when I didn't think I'd forget. I built a good library of helpers, which actually helped me uncouple things in my code. And I started using dependency injection religiously.

One of the first things I noticed was that more descriptive variable names could actually make code beautiful.

Which of these would you rather see in your code?

if (item.includes(criteria))

or

if (productName.includes(currentFilterCriteria))

More than being beautiful, it makes your code read like plain English. You never have to ask, "Which item?" or "What criteria?" It's all spelled out for you.

And that's exactly why commenting is such a valuable practice. Where variable names fall short, sometimes you really do need to explain your code. When you're working on a team, other developers are going to be working with your code, and they're not mind readers.

What's more — and I finally got this after a while — future you will be so happy when you start commenting your code. It's one thing to think you'll remember everything about a project while you're in the middle of it. But what about when you come back to it six months later?

One of the biggest time-savers I've found in project work is having a strong collection of useful helpers, then honing and maintaining them. Why reinvent the wheel on every project? If you've got a great helper that's abstract enough, you'll be able to use it again and again.

And, as I said earlier, getting the minutiae out of your functions — things that could, nay, should, live in your helpers directory — is a massive leap forward in uncoupling your code. If something is acting as a facilitator rather than a main actor within a function, take it out. It's a helper. Then add it back in as an argument rather than letting it hide away as a global variable.

I'll be the first person to admit it: I hate long argument stacks. They look awful. But they're a small trade-off for the benefits of loose coupling: easier testing, easier debugging, and greater functional modularity.

I'm a person who loves immediate gratification, and I did not get it from adopting these practices in my coding. It was painful. What I got instead, over time, was a deep appreciation for the benefits of laying that foundation and being meticulous about it.

That, to me, is the hidden thread.

Good coding isn't just about making something work. It's about making it readable, movable, testable, explainable, and reusable. It's about leaving behind something that other developers — and future you — can actually live with.

When you've got a repo full of modular, loosely coupled code from other projects, a great toolbox full of helpers, and all of it supported by descriptive comments and variable names, you don't just have old code lying around. You have building blocks. You have momentum. You have a head start.

And maybe that's what I was really being taught all along: not just how to code, but how to build code that can survive its own future.