Lessons learned over 20 years as a web developer

This article was written for and originally appeared on Blueprint by Tiny.

Is it just me, or does it still feel like the 90s happened only yesterday? It feels like yesterday that I started working as a web developer, but in fact, I’ve been building on the web for over 20 years now - time surely flies.

Comparing technologies, platforms, languages, and - heck - even internet speeds with those used 20 years ago shows just how much communication, the industry, and the world has changed: and is a reminder that no matter what language you’re writing code in, the only true constant is change - even if your language dictates it as a const, final or define.

Every project has the potential to teach you something that you can carry on to your next job. Without my start on Geocities, Netscape Composer, and dialup internet, I’d never have had the opportunity to learn, grow, and evolve as a developer. So, with no further ado, here are my top five areas of expertise that no web developer should be without.

Performance and optimisation are such broad terms that cover so many areas: from code quality to bundling to deployment to server configuration - and the impact can be felt on your users’ experience and even your search engine rankings.

The challenge is that in order to write performant and slick code, you also need experience across so many aspects, including your choice of languages, databases, bundling tools, and server configuration.

While “Hello, World” tutorials can be a great place to get started with new concepts, they can also omit real-world best-practice considerations (including security aspects too). If you’re working with a new language, framework, or tool, when you’ve understood the basics, keep reading the documentation: it’s there for a reason. Then, start to consider the performance and optimisation techniques needed to get the best out of your code for your project when deployed.

With databases

Your database can easily become a bottleneck in your app - especially if your code has an N+1 query, lacks appropriate design, or is poorly indexed.

Writing a database query is more than just the SQL itself - it’s also about how to most efficiently get what you need. You will need to spend time learning about your database server and your coding tools or framework features that can help you write better queries for your app.

Your database or framework may even offer caching to help improve the efficiency of your project - leverage the tools that you can to help your application fly.

Take time to learn and understand how your database system can be optimised, and perform some tests with large data sets to ensure your queries are still running efficiently. For example, in MySQL, EXPLAIN your queries to see where you can improve your raw SQL and where indices could be added to improve performance.

With bundling and build tools

Bundling tools can take your easy-to-edit modularised code and package it up ready for deployment. This can include bundling tools like Webpack or standalone desktop apps, and also language-specific approaches including LESS or SCSS for your stylesheets.

These tools can take your multiple source files, which may be short, easy to code with, and fully commented for you and your team, and bundle them up streamlined for publishing, including combining into single files, minification, and stripping of comments.

In other words, your code is organised and easy to work with for you and your team, but when bundled, it is lean and efficient for your users.

Spend some time exploring your build tools to ensure your project is built in the best way for your kind of project. For example, if you’re building a Single Page web app in Vue, with basic bundling, you might be given a rather large JavaScript file. However, not only is this a large initial download for your users, but a single line of code change means that their cached versions are redundant.

Build tools like Webpack make it possible to split your project into smaller pieces - such as a “vendors” file for your dependencies that may rarely change, a slim main file, and smaller chunks for different modules of your app that are automatically downloaded as required. By taking the time to set up your Webpack build configuration, you’re able to better leverage the caching of your users’ devices: when you change one line in your source code, then only that chunk needs to be re-downloaded by your users.

When configuring your build, you may also like to keep some packages external - especially if they are available with a cloud-based host, such as TinyMCE. Not only can this reduce your build output size, but it can also help improve perceived performance when clients may already have libraries in their cache and don’t need to download them again - such as a Vue or React runtime library.

With your server

Your server needs to be able to run your app with ease: and not just with a handful of concurrent users.

Slow server responses - due to overload, poor coding, or being located in an inefficient data centre - can detrimentally impact your users’ experience. No one likes to wait, and if your app becomes slow to respond, your users may well take their business elsewhere.

While bundling and chunking your project build can help with caching and user performance, configuring your server to compress assets as they’re requested can save even more bandwidth for your server and your users.

Search engines like Google also use your site's responsiveness as one of the many metrics to calculate your search engine ranking. Just remember though, when your server is running your project with fast responses and compressed assets, it is not only search engines that will notice: all of these performance gains are helping improve the experience for your end users.

Remember: it is not all about you

Optimising the performance of your project is not just for you. It’s for the users who have limited internet speeds or data caps. It’s for the users who may not be running the latest version of a web browser. It’s for the search engines. It’s for the users on mobile devices. And those on desktops. On Windows. On Mac. On a Linux breed.

When writing code and building your project, remember who the end users are: write good code for them - they’re the ones who will appreciate your efforts the most.

Whether it is your IDE, build tools, deployment tools, version control tools, testing tools, what tools do you use every day that make your life easier as a developer?

Use them.

Tools are here to help you - spend some time finding a good workflow for your project, and one that works well for your team. Remember the sort of work you are doing, and ensure you’re using the right tool for the job. Yes, you can write code in a plain text editor, but isn’t it easier to read and write when you have syntax highlighting, code completion, and automatic formatting?

And while someone else may love their IDE instead of your favourite, it doesn’t mean it is a better tool. It’s that whole debate of PC vs Mac, emacs vs vim, Ford vs Holden, McDonalds vs Hungry Jacks. We all have our preference for a computer, a car, a burger, but ultimately we all have our requirements satisfied.

When you’re working with a team across multiple platforms, keep in mind that platform-specific tools may create roadblocks: it may be more useful to employ tools that your whole team can use.

Your users have no idea how to save an image for the web.

Well, the majority don’t. And they don’t understand the problem with uploading a batch of 10MB JPGs to their website home page. With growing image sizes, thanks to more megapixels in digital cameras, photos are getting bigger, and some users just think bigger is better. But for the users with slow internet speeds or limited data caps, 10MB per image can be huge - and can negatively impact their experience.

If you’re building your own web app, can you have your system process images on upload, including resizing, cropping, resampling, and saving suitably for the web? This is my favourite choice: especially when originals are stored and you can tinker and tweak the compression without losing the original asset, or if they need to be re-processed at a later date.

If you’re using a platform or CMS that just uploads images, full stop, spend some time during your project handover to train your users on how to best save their images for the web. This could be through image tools on their computer, or even some web-based tools that can help with compression and image optimisation.

While tools like Photoshop have a “Save for Web” feature, they can still pack in some hidden metadata that can add to your file size. I love using TinyPNG to help with additional lossless optimisation - it is an online service that can help optimise PNG and JPG images for the web, and I’ve had significant impact with some large transparent PNGs, at times resulting in a saving of 50% of the file size.

Imagine you have spent all this time building something incredible: a complex process that triggers different actions and relies on certain data conditions to reach specific outcomes. And imagine that each time you manually test this, it takes minutes of your time.

How do you know that changing one line doesn’t break the outcome of your super cool feature?

Write automated tests.

While it can take time to write quality tests, they save you time in the long run, knowing that the rules of your super cool feature are automatically being tested.

Just remember though: it is important to write tests that are designed to actually test the logic, conditions, and outcome of your code, and not just write a test that passes a simple condition. For example, you could write a test that asserts that 1 + 1 = 2, but does that actually test the workings of your code? After all, you’re going to rely on the accuracy of the outcomes of these tests, so invest in writing quality tests.

What I love about being a web developer is the constant learning. When learning something new, remember that the voice in your head that makes you question your worth isn’t a reflection of the skills you DO already know: it is an opportunity for you to grow and evolve as a developer.

In the past, I used jQuery. Relied on it. Loved it. But as I explored new technologies in the Vue world, and as browsers themselves evolved, I found that it was no longer necessary. But all of my previous jQuery and JavaScript experience was not wasted while learning the Vue ecosystem: it was critical to giving me a solid foundation, and helped me achieve success in my learning.

I’ve been developing in PHP for 20 years now, and have been exposed to framework-less jobs, Joomla, WordPress, and even built large-scale projects on a bespoke framework. But more recently, I have been learning (and loving) using frameworks like Laravel (and the features they provide and time they can save with development). However, without my years of PHP experience, this learning process would have been more challenging. I’m already a skilled PHP developer: but now applying my skills to a framework’s conventions.

While learning something new may feel intimidating, and take you back to that “newcomer” feeling, remember that everyone has to start somewhere - there is always something you can learn. Just because you haven’t used “Tool ABC” or written an app in “Language XYZ”, it doesn’t mean you’re a bad developer: but what you can do is apply your past experience and skills to your efforts of learning something new, and up-skill yourself.