What 4 Years of Coding Have Taught Me

Introduction

June 24, 2017, was the first day when I opened index.html and started putting some HTML tags. I wanted to have a website where I could publish my podcasts that I was planning to record. I had no idea how difficult and at the same time interesting this path is. Thankfully, there are so many free sources on the internet, that it makes the learning path smoother.

Four years of coding have taught me a lot, but I'm going to share with you some of the most important lessons that will be useful for you.

Lessons that I've learned

1. Do what you think is right
2. Be careful of wrong estimates
3. Patience is your friend
4. Error handling is important
5. Use types everywhere

Do what you think is right

One of the most essential lessons that I got is that I always have to do what is best for me in a long run. Meaning, if I have to choose between working on a company that focuses on creating apps with the Laravel framework versus a company that develops WordPress plugins. I'll pick the first one because it's best for me in a long run.

I like the workflow with the framework and I enjoy every single minute working with it. Even if the second company offers a higher salary, it's not going to change my decision, even though I enjoy working on WordPress plugins lately.

Be careful of wrong estimates

It's very difficult to calculate how much time you need on a particular project. Unfortunately, every time when I've tried to estimate the cost of the project, I always failed. The best solution that I've found so far for myself is calculating the range instead of the fixed time or price.

The other solution is splitting the task into smaller tasks. It's also good for pull requests, instead of having 1 giant PR, you can have 3 or 5.

Robert C. Martin, known as Uncle Bob, has a wonderful talk “Effective Estimation”. I don't know if this video will be available for a while, but here is the link if you want to watch it.

Patience is your friend

There were times when I caught myself on a thought, that the project that I'm working on will be extremely hard. Sporadically, it's challenging to even get your head around all the features, functions, classes, SQL queries that you need to write and build them in your mind first.

We, as developers, take too much on our shoulders over time, especially if you work on a project by yourself. That's where the frustration can appear. Stay focused and patient. Once you split the project into tasks and write a plan, you'll become way more confident in your skills.

What worked for me for the last 6 months is I would do the initial setup of the project, push it to GitHub and write as many issues as I can for the repo, marking every issue with emoji.

To add an emoji, type a colon and start typing the emoji name. Here's the list of emojis that I like to use:

🔥 :fire (Important issue, needs to be done first)
🥇 :1st_place_medal (Issue has the highest priority, if there are no fire issues)
🥈 :2st_place_medal (Issue has the second priority)
🥉 :3st_place_medal (Issue has the third priority)
❓ :question (Not sure if this issue needs to be done)

Error handling is important

I've built many small apps throughout these four years, and I can't stress it enough how important error handling is, especially in those apps that make many requests to other services. This is probably the most significant lesson that I got, always handle errors.

Don't be lazy to put the extra if block to check if the variable is null. Don't be lazy to create custom exceptions or errors depending on your language. I used to skip putting the try/catch block, simply because it adds one more indentation. So instead of writing this:

class FetchGithubProjects extends Command
{
    public function handle(): void
    {
        try {
            $projects = $this->fetchProjects();

            Project::query()->truncate();
            Project::query()->insert($projects->toArray());

            $this->info(sprintf('%d projects has been uploaded to a database', $projects->count()));
        } catch (RequestException $e) {
            $this->error($e->getMessage());
            logger()->error($e);
        }
    }
}

I tend to skip the whole error checking part and write it like this:

class FetchGithubProjects extends Command
{
    public function handle(): void
    {
        $projects = $this->fetchProjects();

        Project::query()->truncate();
        Project::query()->insert($projects->toArray());

        $this->info(sprintf('%d projects has been uploaded to a database', $projects->count()));
    }
}

It's a big mistake that many developers make. I really like the words of Rob Pike about error handling in Golang.

Use the language to simplify your error handling. But remember: Whatever you do, always check your errors!

Rob Pike

Use types everywhere

Types prevent you from making silly mistakes like passing the wrong argument type to a function, or assigning the wrong value type to a property. If you're a PHP developer, consider enabling strict types for every file in your app. You will save tons of time on debugging your code.

I have plenty of examples where types can help you find a bug, but I'll give you only one. This is a tighten/laravelversions repository, where I found an interesting bug. Take a look at the code and try to find it as well.

This code works fine, except that it doesn't do what you expect it to do. As you can see, the IDE shows that the second parameter on the remember method is called ttl, which stands for time to live. So, instead of passing 3600 as the second argument and 'laravel-versions' as the first, the developer made a mistake.

Even if strict types were enabled, PHP would not throw a TypeError. Because the function declaration doesn't have type hints. It's important to give type hints for each parameter, especially when we have union types in PHP 8.

Except PHP, I've used JavaScript a lot, if you are like me, and you want to create cool apps with JS, you should definitely start learning TypeScript. The more types in your code, the better. On one hand, with TypeScript you'll write more code, on the other hand, your code will be well documented and easier to support.

Conclusion

Money is not the most influential thing in our craft. If I had to choose between working with technologies that I love or technologies that I don't, I will absolutely choose love, even if I have less salary on a loving job.

Remember to spit your task into smaller pieces. It will help you to make correct estimates and feel more confident. And don't forget to be patient, big work requires time. We can use GitHub issues in our advantage to stay focused on a particular feature instead of overthinking everything.

While working on those issues and writing code with types, we will always handle our errors like pros. There is no need to rush, extra check for null pointer exception or empty string is always appreciated.

❤️ Thanks to Michal Balog for the beautiful photo for this post.