2018 Year in Review: Where a PHP Developer Landed

When the last month of the year arrives, looking back feels good. For me, 2018 was a year of real transformation — both technically and mentally. As I close out a year I started as a mid-level developer, I want to answer three questions honestly: what did I learn, what actually worked, and where do I want to go?

Technical highlights of the year

The area I spent the most time on in 2018 was APIs. I learned to use Laravel’s API Resource classes, to design notifications around channels, to add multilingual support, and to manage the task scheduler in code. Writing about each of these topics as I learned them was a different kind of experience — trying to explain something is a real test of whether you actually understand it.

Looking at what PHP 7.2 brought, I can see the language continues to mature. strict_types, return type declarations, nullable types — I write all of these by habit now. A few years ago, writing PHP this type-consciously would have been unimaginable.

Vue.js truly clicked for me this year. Thinking in components felt like a mental burden at first; now it feels strange to think about a page without breaking it into pieces. async/await was the same story — I have no desire to go back to Promise chains.

The beginning of writing tests

The most important change of the year was starting to write tests. A modest start: unit tests for service classes, a handful of feature tests. No test philosophy, just searching for answers to “how do I do this?”

What I realized in the end: testable code is different from untested code. When you try to test something, it becomes much clearer that a method is doing too much, that classes are more tightly coupled than they should be. Testing is not just a verification tool — it is also design feedback. That perspective was one of the most valuable things I gained in 2018.

Things that did not work

While working on calendar functionality, I underestimated timezone management and had to backtrack. Not establishing the “always UTC in the database” rule from the start cost me time. Starting to design recurring events without thinking it through carefully cost me just as much.

The general pattern I noticed: things I started thinking “this is a small feature, I’ll knock it out fast” almost always took longer than planned. That is not really a problem — but it is a reality I need to account for when estimating time.

Getting lost in the npm ecosystem was another 2018 experience. Figuring out which package does what, and which one I should actually use, sometimes ate more time than writing the project itself. I learned to ask “what is the most minimal solution for this job?” before diving in.

Shifts in habits

A few concrete habit changes that define this year:

I add strict_types=1 to every PHP file. Type declarations are no longer optional — they are standard. Writing them does not feel like overhead; leaving them out feels like something is missing.

I include package-lock.json and composer.lock in Git. There was a time when I added these files to .gitignore; it is hard to explain why now.

I shape API responses from a dedicated Resource class, not from the model. As models grow, I understand the value of that separation more and more.

Writing tests is still a choice, not a habit. I want to change that in 2019.

Thoughts for the period ahead

I will continue deepening my work on the PHP and Laravel side. But for a while now, the thought of “another language” has been lurking in the back of my mind. I have been reading about Go, looking at examples. I am not planning a concrete step yet, but that curiosity keeps growing.

On the frontend side, I want to move to TypeScript. Writing JavaScript in Vue projects, I feel the absence of type safety; carrying over the habits I have built in PHP to the JavaScript side seems like the logical move.

Payment integration was a big learning experience the year before; this year, notification systems, calendars, and multilingual support were just as instructive. In 2019, I want less “learning mode” and more “application mode” — reinforcing what has been learned on real projects.

A brief assessment

To be honest, 2018 was a year of clear progress. Concrete things have accumulated that I can point to and say “I did it this way, and it worked.” But I am still in the middle of the learning road; there are very few things I feel fully settled on.

This journal was started to keep a record of that learning process. Looking back at posts from 2014, it is possible to see how much ground has been covered. I hope to have the same feeling when I look back at 2018’s posts a few years from now.