Lessons learned managing my website

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’m going to explain what I learned...

Lessons learned managing my website

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…

Dunning-Krugger effect

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.