I started my own website back in November 2014, and it’s safe to say that it has been one of the best decisions I have ever made. I’ve learned countless things I would never have learned if it weren’t for the periodic makeover I wanted to do, discovered new interests and I also started my blog. I’m going to explain what I learned over the course of these few months, because most of what I learned can be taught in a 30 minute crash course.

These are just some of the things that came to my mind at the time of writing, but there really aren’t many other ways of getting used to a specific technology or tool without putting a bunch of hours into it. I think of it like course assignments: when you look back after they’re done, you always tend to think that they are somewhat easy, and you wonder why some of them ruined entire nights. To me, assignments have a theoretical foundation, where you have to perform X or Y, but there is much to learn about the implementation of X and Y, and you’re only gonna learn it when you waste those nights away typing at your keyboard. So, without further ado, here are some of the things I’ve learned:

Knowing how to use FTP clients doesn’t mean anything

This is how I started. Whenever I wanted to update my website, I’d open up Sublime Text and make my changes. Then, I’d use FileZilla, send the files and that would be it. Once I moved to cloud hosting (like the pros do it), I realised that FTP was still going to be an option, although not the most ideal. But, being the stubborn person I am, I ended up installing an (S)FTP daemon on my server and uploading the server files there. But imagining this wasn’t just a personal website and instead was something a little more serious, there is a good chance that each update would have repercussions in multiple files and folders. Either you’d have to overwrite everything, risking an upload of unfinished and unstable content, or you’d have to manually upload files into their proper destinations. This is clearly a bad approach, but I only realised how bad it was when I moved to cloud hosting. The reason it took me so long to understand this is because I’m working alone.
When you’re working alone on a project you’re allowed to do the stupid things, develop very bad habits because you’re the boss and the employee at the same time. If there were more than one person, FTP would be totally out of the question.

Updates are boring

Having to update server software is somewhat bothersome. You have to do it on a regular basis because sometimes vulnerabilities are detected and quickly patched, and once the new version is published, attackers might try to see if you have the vulnerable version installed, and if so, exploit it. The last thing I want is for goncalotomas.com to show a defaced website saying “Hacked by Electronic Trollcopter Bunnies” or something like that… 😒

Keep in mind I’m definitely not a high value target, so I would probably be left out. But if someone is trying to target you specifically out of spite or something else (maybe a script kiddie that just doesn’t like your face), you have to update regularly to “be safe”.

There are tons of performance optimisations out there

If I told this to my 20 year old self, he wouldn’t be very surprised. What strikes you as surprising is the amount of optimisations you can make: there are literally hundreds of them. Most of them are what I describe to be good optimisations because they don’t require your code to be changed much. These are usually optimisations to web-servers themselves (e.g. better caching engines for NGINX or Apache), so at most you’ll have to fiddle with config files.
Other types of optimisations include uglification of static resource files like HTML, CSS and JS (this can still be done with NGINX or Apach modules!) and joining multiple script or style files into a single bigger file, in order to avoid having to do multiple requests.

In case you’re still thinking about file sync, use Git

Think about it. You have your local copy of the repository on your laptop, you work on it as much as you want, and you only send select modifications (read: commits) upstream. Then, when you really think you’re done, all you need to do is git pull on the server side.

Version Control Systems (VCS), and Git in particular, are truly a genius invention for the power they give developers. Both SVN and Mercurial would also be able to do what we wanted, but Git provides more fine grained operations over files and commits, plus… Nested repositories!

You might want to argue that putting your back-end and front-end teams working on the same repository would be a bad idea, and I’d agree that it could get messy. However, I recently found out that you can have nested git repositories, and that would probably make things right!

Since front-end files also come from the back-end (the server), the master repository would be the one for the back-end code. Inside it, you could have a directory with the front-end repository inside it. This functionality can be implemented using Git Submodules or Git Subtrees. In any case, since you’d be separating repositories from a logical point of view, each one of them would have their webpage with issues, pull requests and wikis, without ever getting mixed up with the other repository’s content.

Blogging is mostly about timing

This one is probably one of the biggest lessons I learned! Considering I’m writing to a fixed-sized audience (I don’t add friends on social media just to increase my visibility), there’s a science into making people click your links. Trust me, it’s way more than post titles and clickbaiting…

You have to pick a day of the week, a time of the day, and you see different outcomes depending on the publishing time. Sometimes I let posts sit for a couple of days to try and get the best possible result. The opposite of this happened once I published a post on a Wednesday morning: only a residual number of views, which wasn’t very surprising, but nonetheless impacting. I write mostly because I want to talk about something, but having extra views and good conversion rates (i.e. people that read the whole thing) is also very important. These metrics help me measure the importance of the topic I’m writing about, and how engaging my train of thought and post structure are.

There is still much to learn

I expect at least more than half of you to shrug your shoulders on this one. Of course there’s plenty to learn, the computer science field is huge and you could spend the rest of your life reading literature without ever getting to the end of it. But my point here is slightly different.

What’s important here is knowing what you don’t know.

You might be working on a specific technology for years without ever learning anything really useful about it. This is extremely relevant to those that are learning alone from tutorials on the Internet. In my case, I learned HTML, CSS and JavaScript from online courses, but none of them mention any tools other than Chrome’s DevTools. There are no guidelines for starting JavaScript projects, and Node is so full of packages and modules that just trying to decide on a module for a specific task might get annoying. If possible, getting to work professionally on it (and avoid freelancing, otherwise you’re not doing anything different) is also very important because good companies will have excellent software development tools, IDE’s, and you’ll be able to learn how it should be done.

You have to keep in mind that fiddling with JS by yourself for a year doesn’t make you a good candidate for a job if you’re competing with someone who has a year of professional, non-freelancing experience. I leave freelance out of the picture because I feel confident enough to tackle freelance projects, even though I’m very well aware that my knowledge of tools is very limited. I have to say this argument would look very fancy with a graph on it. Let me get one real quick…

I think I recently passed the middle part, which is bad and good at the same time. I know I’m not using the best tools out there, and I’m not yet proficient with the tools I’m already using, so I don’t feel (very) confident about my web development skills. Despite this, considering it’s just a hobby, I still feel pretty good with the overall result.