Alan Shortis

Make your own website

There are a lot of places to quickly post some content. It's quick, convinient but ultimately bad for you and your work.

There is a bit of a backlash against the likes of Medium happening, and for developers it goes deeper than their paywall and irritating clutter clogging up the page when you first visit. Writing about this industry is a great thing to do—with new concepts and approaches unfolding constantly, we're all googling questions every single day. Plus, if you're anything like me, writing about a subject while figuring it out is a great way to learn.

With Medium and similar services you do not truly own your content. Your own site, entirely under your control is invalueable if you have a web presence.

Consider Jeremy Keith has been posting to his own website since 2001. How many platforms have come and gone in that time?

Pick a platform, or don't

If you're a working front end developer chances are you're using React or some other library/framework on a daily basis, so it makes sense to stick with workflows and syntax you're comfortable with. You may even have some components ready to go. Gatsby is the king of this sector now, but there are a lot of other options for static site generators that let you keep your programatic approach for good developer experience while producing static assets for speed and performance.

Writing totally plain HTML and CSS is pretty rare now, but I love the idea of starting a project not with npm i but with touch index.html. Write the exact code that the browser will use and eliminate third party dependencies. This is all about owning your site, right? I have to confess, I haven't done this yet but I have an upcoming site that will be built this way for sure.

Prepare your content

I'd always opt for Markdown when writing technical blogs. It's very light, unobtrusive, supports inline code and code blocks, can be massively augmented with MDX and can be written in all kinds of editors very quickly. It also keeps your content very portable and readable even it's not parsed.

If you really love using a CMS, there are plenty of headless options that will let you keep your rich editor and still produce a static site via the JAM stack.

Design and build

The appearance and code is where you can really show what you can do. Use it to show off, appeal to peers and recruiters, but don't overdo it. A site comprised of mostly static text doesn't need Redux, Docker and a heavy animation library, for instance.

Most importantly - build something, deliver it, then iterate. If you're the only one ever touching the code, allow yourself to take some shortcuts if it means delivering quickly.

I promise you, the very site your're reading this on is very far from perfect and will never be finished, whatever 'finished' means in this industry.

Don't let perfect get in the way of good enough.


This is easy. GitHub Pages, Netlify or ZEIT. You don't need anything more powerful.

What next?

  • Keep writing. Even if you think it's something basic; if you faced a challenge in figuring something out or came across some gotchas, someone else may be in the same boat. However...
  • Write for yourself first. Writing about a problem while solving it will help it stick in your mind. You can also read your own posts if you get stuck again in the future.
  • Iterate. Seen some design/feature elsewhere and want to try and replicate it? You have a site for that.
  • Strike a balance. I don't feel that sites like this need to be feature rich. If you have an idea for a side project that is more complex, invloved, and interesting to you as a developer, do it. Don't neglect it either. It's your shop window, and if your bio mentions the job you had 2 years ago it's not an ideal first impression.