Letter to my 2014 self: advice for the early years

This month marks nine years since I started keeping this journal. Back in 2014, when I wrote my first post about Composer, I just wanted to record what I was learning — I had no idea where any of it was going.

Looking back at that year, there are a handful of things I could have done better. I’m not writing this out of nostalgia or self-criticism; I’m writing it in the hope of passing something concrete on to anyone who finds themselves in the same place.

The trade-offs of chasing tools

Between 2014 and 2016, something new came out every few months and I’d feel this creeping anxiety: “if I don’t learn this, I’ll fall behind.” Gulp arrived, I dropped Grunt. Webpack arrived, I dropped Gulp. Nothing I learned was building on what came before — it was one clean-slate learning cycle after another.

Looking back now, I can see that most of the tools I learned during that period no longer exist. But the things I picked up while learning them — what a module system is, why dependency management matters, why a build step is necessary — those are still with me.

Learning the tool is unavoidable; but if you learn it without understanding the concept behind it, when the tool becomes obsolete you’re left with nothing. If you’re in 2014 learning Gulp, don’t learn Gulp — learn the answer to the question “what is a build pipeline?” The tool disappears, the question stays.

Fundamentals never go stale

During the same period I spent serious time actually understanding HTTP. The request-response cycle, status codes, headers, session management. It felt tedious at the time — “I’m already writing Ajax, do I really need to know HTTP?” I’d think.

In the nine years since, I never once saw HTTP become outdated. Designing APIs, setting up auth flows, integrating WebSockets — every single one of those has the same foundation underneath. Investment in fundamentals works like compound interest: you finish learning it once, but you collect the returns for years.

If I could live those years over, I’d redirect some of the time I spent on framework tutorials toward understanding the HTTP spec, SQL, and networking basics.

The cost of “perfect code” perfectionism

For a period, I couldn’t ship a feature until the code was “clean.” I had just learned SOLID; every class had to have a single responsibility, every method had to be short. Wasn’t that discipline?

Partly. But the bigger problem was this: software that doesn’t ship is worthless, no matter how elegant the architecture. Ship it, fix it, repeat — that cycle is what produces working code. Waiting for perfect code is usually equivalent to producing no code at all.

“Clean code” matters, but so does order. Make it work first, then clean it up. Reversing that sequence is one of the biggest time sinks in an early career.

The fear of specializing vs. generalizing

“If I focus on PHP I’ll fall behind in JavaScript. If I switch to JavaScript, PHP is over for me.” That thought felt very real back then.

Looking back: I learned both, and rather than canceling each other out, they reinforced each other. The OOP concepts I learned in PHP paid off in JavaScript. The async programming model I understood in JavaScript changed how I looked at PHP events.

You don’t have to choose between two domains — but learning both superficially doesn’t add much either. Go deep in one, keep track of the other. Over time, depth brings breadth on its own.

Making mistakes visible

This is probably the thing I learned latest. I was reluctant to admit I didn’t know something, or to flag when I was stuck. “I’ll research it, I’ll figure it out,” I’d say to myself — then grind away for hours; eventually solving it felt like a victory.

But those hours were usually spent in the wrong direction. Telling someone “I’m stuck on this — could we look at it together?” creates a learning opportunity for them too. Making the problem visible isn’t weakness; on the contrary, it’s how someone who knows how to make progress actually behaves.

Don’t be afraid of making mistakes. Be afraid of hiding them.

---

As I wrote this letter I noticed something: none of what I described is “learn this tool” or “choose this language.” Because those decisions change — they vary depending on the moment. What doesn’t change is: how you learn, how you look at mistakes, and how much you invest in fundamentals. Those things only become more important as time goes on.