This morning, I launched a new version of my portfolio website. It’s a fairly significant update from the previous version, and now has many of the features one would expect in a modern website, such as responsive layout, smooth scrolling, and a mobile-friendly nav.
If you’re an aspiring front-end developer, building your own portfolio website is a must-do. These are some tips to consider when building your first portfolio website.
1. Think of your portfolio site as a portfolio piece in itself
The site you are building is actually a portfolio piece in itself. If you are just starting out as a developer, it may in fact be your first portfolio piece. (Also, in that case you will want to keep the site super basic. More on that below.)
You should assume that a prospective employer will not just be viewing the site as an end user, but also looking at your source code and how you approached the development of your site and see that as an example of the code you might produce when working for them.
If you’re using, Atom, you can then use this package, to get immediate code formatting feedback.
2. Start by shipping a super basic version
Even though a portfolio site may seem like it would be quite straightforward to build, there is actually quite a bit of work involved in creating the most basic website. For this reason, I suggest keeping the first version very basic.
This is what the first version of my portfolio site looked like. It’s just a single page with some info about me, a list of links, and my email address.
Even so, there was quite a bit of work that went into building this site, including:
- Setting up a basic build system, with tasks such as converting SASS to CSS, minifying JS files, and live reload of a local development server.
- Setting up a password-protected staging environment (ie a clone of your production environment.)
- Creating a basic layout, selecting fonts, etc.
- Creating favicons, home screen icons, etc.
- Using JS to generate my email address, to make it harder for robots to harvest it.
- And more…
Now, I could of course have shipped a basic site without doing many of these things, but I think you should look at the first version of your site as an opportunity to create your development infrastructure, which is what many of the above steps are focused on.
3. Consider not using a framework (like Bootstrap)
If you look at the source code for the portfolio site, you might notice that I am not using a framework, such as Bootstrap.
On the one hand, I could likely have shipped the website much more quickly if I had used a framework. If your focus as a developer is not on the front end, going with a framework might be ok, but there are many reasons why using a framework might be a bad idea.
Building your portfolio site from scratch is a golden learning opportunity
First, in terms of being a portfolio site, if you use, say, Bootstrap, you are basically passing off the problem of solving many core design problems that you normally might need to solve as a developer. You are therefore both giving up an opportunity to learn how a website is built from the ground up, and you also risk a prospective employer reacting negatively when seeing that you needed to rely on a framework.
You might find yourself constantly ‘battling’ the framework
It is very likely that there are parts of the framework that you’ll want to customize. You might find that when you want to start making customizations to the framework, that you are spending a lot of time “battling” the framework, in other words, spending a lot of time creating overrides, workarounds and various hacks to get the framework to look like and/or do what you want it to. In my opinion, it’s far better to spend all that time instead creating the site from scratch, and use that as an opportunity to learn how to build something from the ground up.
Integrating 3rd party tools is different
To be clear, using a framework is different from integrating 3rd party tools. For example, I am using some parts of the Materialize framework specifically for the contact form input fields. Doing so shows that you are able to integrate other people’s code into what effectively is your own framework.
4. Treat it like a real project
One of the biggest mistakes you can make when working on your own site is to not think of the work as a formal project. Just from looking at the above list of features (which are only a sampling of all the tasks needed to build even a basic website), it’s clear that there is a lot to keep to track of.
Therefore, treat the creation of your portfolio site like a real project. This means working through a process similar to what you might do when building a ‘real’ website for a client, such as starting with a set of requirements, creating mockups, giving yourself deadlines, etc.
To stay organized, I recommend using an agile backlog.
Part of what makes it so powerful is its simplicity. It’s really just a prioritized todo list, but it helps you to not lose track of what needs to be done (just quickly create a card and add it to the backlog) while also staying focused on what is most important (regularly groom and update/re-prioritize the backlog.) I also like to include a ‘Resources’ section in my project board, where I keep site-related info, such as API keys, links to 3rd party tools I am using and more.
5. If you’re a more advanced developer, consider using a bundler for client-side code
When I was planning the implementation of the website, I briefly considered implementing it with React and Webpack, to gain access to all the benefits which those tools have to offer. However, at the time, it seemed as if this would be over-engineering. After all, it seemed I was just building a ‘basic’ website with mostly static content. So I decided to instead go old-school and use plain ES5 JS with JQuery for the front-end.
However, having now gone through this process, I realized that even for this seemingly simple portfolio site, there is still a good amount of client-side JS that needs to be written, and I could have benefited significantly from many of the niceties I had access to on the server side, in particular the use of modules.
Here is one quick example of something I could have avoided:
These are examples of some utility functions I used on the client side. If I had been using a bundler, I could instead have simply turned these into modules and imported/required them as needed.
However, I instead had to put them in a global utils variable and then make sure that this file loaded ahead of other files where I would be using the functions.
This works, but it’s hacky and I would definitely have preferred to use modules.
Therefore, for any future versions of this site (or the next time I need to build a ‘basic’ website), it is highly likely that I will use something like Webpack and React. This will give me access to a ton of bells and whistles, including ES6 JS on the client side, the ability to use modules, Promises, arrow functions and more.
Building the portfolio site from scratch was a great learning experience. If you are an aspiring developer and you have not yet started working on your portfolio site, I recommend moving it to the top of your todo list.
I hope these tips are helpful. As always, feedback in the comments is highly welcome!